I’ve never met a customer who cared about user stories. Why would they? They care no more about user stories than they care about test cases, code reviews or any other artifact from the software development process. Yet almost the entire agile software industry, one that outputs volumes of books, videos, papers, seminars, training, tools, seems obsessed with just that. Take the leading tools for example, I won’t mention specific vendors, but these tools are designed around the creation and management of user stories. Put these tools into the hands of development teams and we’ve now got projects whose primary focus is the delivery of user stories. In all my years of working with agile development teams I have never seen so much abuse of a concept. Iteration backlogs have become dumping grounds for every imaginable project task, the vast majority of which provide no conceivable benefit to an actual user of the software. One typical consequence of this is that people in customer-facing roles such as product managers, program managers or executives often struggle to get the answer to a simple question – how many customer committed product features have been completed so far, and what is the status of the remainder? The frequent inability of project teams to come up with a straightforward answer to this simple and entirely reasonable question should be a cause of major concern. Typically the tools do not help. What happens next after the escalations begin usually involves exporting project user stories to spreadsheets and applying elaborate post-processing to get close to what might represent a reasonable answer to the question we started with.
User stories are a great way to break down product features into smaller fragments of functionality that can be implemented and demonstrated in a single iteration. But go ahead and take a look at a backlog created by one of your development teams. You may be left wondering what this list of stuff is actually for, and you may struggle to identify anything that remotely resembles a feature your organization plans to deliver to an actual customer. The team may show you a burn-down chart that suggests that they are completely on track. But on-track to deliver what?
Customers have no interest in ‘user stories’. Customers pay for product features. This is not just semantics. Some of the tool vendors have finally caught on and are now talking about ‘Portfolio Management’. This seems like a way of introducing their users to feature delivery like its a brand new concept, requiring more training, seminars, tool licenses and so on.
My goal in this book is to start with the customer and their requirements stated in terms of product features. We then focus on how to design a software development framework where feature delivery – not user stories – is the primary objective. The question then is: what is the optimum framework for transforming customer requirements into production quality product increments? We continue to embrace the concept of delivering small batches of customer-facing functionality in short, fixed time-boxes, as a way to achieve maximum flexibility in the face on uncertainty, while maximizing quality and minimizing risk. However, we also need a ‘front-end’ process that takes in raw requirements and transforms them into ‘development-ready’ units of customer-facing functionality (user stories) as an input to a product realization process that can proceed without delay, interruption or re-work. This front-end process must run concurrently – not sequentially – with the realization process, keeping development teams supplied with at least 2 iterations worth of development-ready stories at all times.
Finally, organizations must at all times have a clear, unambiguous and accurate picture of the status of a release, right down to the status of individual features. Tracking a release by focusing on user stories is misleading, and can sidetrack both development and management teams with a false sense of security. We introduce an approach to ‘feature-centric’ project tracking and reporting that eliminates any confusion about project status, and provides early warning signals that can be acted upon to mitigate risk.
Software Business Models
These days we hear a lot about ‘Dev Ops’ and businesses that provide a cloud-based ‘Software-as-a-Service’. A good example is Spotify – the music streaming service. In this example, and many others like Netflix, SalesForce, and LinkedIn, the software is built internally by the company itself and end-users typically pay a monthly subscription to use the service. These companies have total control over what, when and how to release new features to their users, and users have little direct say in the content of any new release.
Meanwhile, the vast majority of software developed today is from businesses that operate the more traditional model, where software is delivered in a series of releases which are then licensed to customers. Obvious examples are Microsoft, Oracle, SAP, IBM and Symantec. These companies are typically ‘roadmap-driven’, where releases are planned by product marketing teams based on market trends, competitive forces and emergence of new technologies.
A third major classification is for businesses who develop software in response to individual customer contracts. In this model there is little debate about which features to build – it’s in the contract. This model typically involves ‘Statements-of-Work’ (SOWs), with payments made against the completion of specific milestones in the contract.
Finally, a large amount of software is constructed by IT departments within companies. Typical examples are banks and financial services companies. These companies do not sell software to end users, but use it to operate their businesses and provide services to their customers.
This book is applicable to software development within any of these operating models. It is particularly relevant for those directly responsible for delivering on business objectives – meeting the sales forecast, achieving earnings targets, and nurturing customer relationships. There is much in today’s agile literature about empowering development teams and this is a critical dimension of any agile enterprise. Development teams should be completely aligned with the organization’s business goals – and understand them sufficiently to be able to make good tradeoffs and priority calls, and must play a prominent role in bringing ideas and solutions to problems to the broader organization. Let’s be clear though, software developers are not directly responsible for the P&L, and software teams do themselves no favors when they make statements like:
- “Leave us alone, we will deliver the right product”
- “We are agile, we don’t gives dates or do reports”
- “We cannot tell you when feature X will be done”
This kind of talk terrifies executives. Agile Development is a means to an end, and that end is to improve business performance by delivering software faster, with higher quality at lower cost and risk, and with more flexibility to absorb changes in product requirements.
Those in customer-facing business roles need visibility and data from software projects to be able to accurately articulate progress and risk to both internal stakeholders and customers. This reality does not change whether software is developed in an agile or waterfall fashion. This is not an issue of ‘command and control’ – no-one is telling developers how to do their jobs, but development teams exist to serve some business purpose – and solid alignment between the development team and the business team is crucial for a successful business outcome.
This book is about how to achieve successful business outcomes in the field of software development. Whatever the business model, this book offers guidance for anyone involved in the construction of complex software systems, where new feature creation typically involves modification to multiple subsystem components, and validation involves testing end-to-end on a fully integrated system. There are a handful of practices that are required to establish a foundation for agile development.
- Requirements. Agile development requires a solid process for converting customer requirements into development-ready work items in the form of User Stories, that permit development teams to deliver incremental product deliveries in a ‘shippable’ state.
- Adaptive Planning. Means keeping the backlog that feeds the development team continuously filled with development-ready user stories so that there are no delays between requirements elaboration and realization. This also means only producing enough ready work required for the team to complete at least one iteration, so that plans can be revised without throwing way a lot of unnecessary detail.
- Iterations. Breaking a project down into small batches of work that deliver measurable incremental progress is a way to improve productivity, boost quality and reduce risk. To succeed in today’s tumultuous environment, development teams need to be able to turn on a dime and abruptly change direction whilst ensuring that work already completed is not waste. Iterative development is the best defense against this kind of risk.
- Production-quality code with every iteration. Delivering partially completed work in iterations is a wasteful and expensive mistake. Practices like peer code reviews, continuous integration and maximum test automation are an absolute prerequisite to achieving this goal.
The overall goal of agile development is to achieve an uninterrupted flow of value-adding activities from the arrival of feature requests to the delivery of ship-quality product increments.
In this book we will be digging into the details of each of these while keeping our primary focus on feature delivery. Readers are assumed to be familiar with the basic concepts of agile and scrum, however, for completeness, I have included a primer on these topics in an appendix.