Agile and Scrum short iterations should provide software development organization with quicker feedback cycles and help them shifting from building the product right to building the right product. In their book “The Lean Mindset”, Mary and Tom Poppendieck provides an original perspective on this issue.
What’s next is to stop thinking about software development as a delivery process and to start thinking of it as a problem-solving process, a creative process. Time and again we run into software delivery organizations – IT departments operating as cost centers and software firms working under contract – whose job is to turn someone else’s requirements into delivered software. Agile practices have helped these organizations handle requirements in smaller batches, reduce work-in-progress, and speed up software delivery. But unfortunately, agile practices do not address the underlying problem: the very idea of a software delivery organization is flawed.
The concept of a software delivery organization is so ingrained in the structure of many companies that questioning its existence is nearly impossible. Yet there are many companies – typically those founded after the mid-1990s – that never got around to creating software delivery organizations in the first place. These companies purchase digital infrastructure as a commodity and consider the development of software-intensive products to be a line responsibility. They don’t think of software as something to be delivered; they think of it as one of the raw materials that goes into a product. Consequently, they do not have software delivery teams; they have product development teams.
What is the difference between product development teams and software delivery teams? The most important difference is that product development team members find it easier to become engaged in their work. Rather than implementing lists of requirements, they are expected to think creatively, solve problems, and make trade-offs based on things such as profitability, market share, and long-term business impact. The sense of purpose, the challenge, and the local decision making found on product teams bring out the best in people. Product teams are judged by the business results they produce rather than by proxy measures such as cost, schedule, and scope. Therefore, product teams include everyone involved in the end-to-end feedback loop from problem to solution. Given the proper charter and appropriate staffing, it is common for product teams to uncover and solve hidden problems, change course quickly, and take advantage of unexpected opportunities. Consequently, product teams tend to be good at delivering superior business results.
Delivery teams operate under a significant handicap. They are chartered to implement someone else’s solutions to problems that team members are not expected to understand. They deliver these solutions without assuming responsibility – or receiving credit – for the resulting business improvements. Even when agile practices speed up delivery, feedback loops are lengthy and plagued with handovers. Therefore, it is a challenge for delivery teams to find a purpose, generate enthusiasm, or spark innovation. So it should not be a surprise when these teams deliver mediocre business results.
Source: “The Lean Mindset: Ask the Right Questions”, Mary and Tom Poppendieck, Addison-Wesley
The problem discussed in this quote, being focused only on software delivery (and often as the lowest possible cost), will continue to plague organizations as long as they see software development only as a cost center. But software is continuing to become a more important part of the customer experience and you might now also choose your bank considering the interactive tools supplied to manage directly your accounts. In this context, integrating the software developers input in the product definition and creation should be more and more considered as a key success factor. Software developers will be more and more considered as problem solvers instead of just infrastructure builders.
lots to consider here. For example, agile seems to fail badly at analyst & design. Who needs to think? Why?
The say “garbage in = garbage out” is always true in software development. Using a framework like Scrum, the Product Owner should be the source of good requirements. Agile does not solve the case when you build the “wrong” software, it should just make it easier to spot that you go in the wrong direction with its shorter delivery and feedback cycles.