Agile’s positive impact on strategic planning
This blog entry is primarily based on a wide ranging conversation the author had with Steve Johnson in late September 2013. Steve Johnson is a product management and business process expert with over 20 years of experience both bringing products to market and helping others do the same. You can learn more about him and his eBook From Fragile to Agile on his web site at http://under10consulting.com/books
In Part 1, we looked at some ways that making the move from traditional waterfall software planning, development, and testing models to an Agile approach brings a set of process and culture challenges to some key, non-programming roles.
In this second two parts we’ll discuss possible impacts of Agile on strategic project artifacts, a perspective on documentation, the way in which Agile can help other teams understand that software development is in fact a creative art.
4. A transition away from monolithic planning artifacts
Steve elaborated on one perspective of traditional large-enterprise waterfall planning artifacts. “We have executives used to the old days when we had these large documents that supposedly explained exactly what we were going to do and exactly when we were going to get it. But they have forgotten that most of the documents were complete fiction. We spent months writing and revising these wonderful market requirements documents and business cases. After the fact we conveniently forgot how we often missed our dates by years and that many of the features we expected didn’t get completed.
Team members and leaders not yet properly exposed or trained in Agile methodologies may defend large, monolithic planning document suites as necessary for a number of reasons that include:
- Historical momentum: We’ve always done it that way
- Regulatory issues: We need to show what we are going to do before we do it
- Career safety: Cover-your-behind mode
- Budget: Financial and project and resource planning
- “Public Roadmaps” and “Special” customer briefings.
Yet, as most large organizations have experienced at least once—or maybe every time—these kinds of monolithic documents can:
- Burn up inordinate amounts of team time writing and getting approval on
- Sometimes end up being fiction – guessed on timeframes and unreasonable goals
- End up just sitting on a shelf rarely to be referenced
An organization has to ask itself “Has this been working?” Is the giant up-front monolithic feature-book working for your schedules, your teams, and your customers? Do you regularly get products months later that bear little resemblance to that plan? If the organization’s answer is that the monolithic planning approach is in fact working, and they are happy with the cost, time to market, and revenue match to plan, then an Agile process was probably not even considered anyway because it wasn’t needed.
Criticism of large monolithic documentation should not be interpreted as abdicating responsibility for strategic or tactical planning or documentation thereof. Agile processes must reflect thoughtful, strategic planning that may be months or even years ahead of a delivery.
5. Agile isn’t “cowboy coding”—Strategy and roadmap are key
Agile doesn’t mean “no roadmap.” It doesn’t mean no executive decisions that may in some cases and in the proper process override a product owner and Scrum team decision. But, as Steve says “Without a roadmap, Agile teams are in danger of building the wrong thing faster than ever.”
Agile also doesn’t mean cowboy coding. It means addressing agreed upon user personas with features. It means defining the role of product owner in the enterprise and how that person can best perform the role of being the “go to” customer expert on-demand to scrum team. Fundamentally, Agile is a team-sport. It’s about a cohesive team working together to build something great.
6. Valuing results over documentation doesn’t mean no documentation
The Agile Manifesto, which is where much of the current Agile practices come from, values “Working software over comprehensive documentation.” That should not be interpreted as no documentation. Living, breathing strategic planning and tactical documents are necessary. But the idea is not to be a slave to the worst practices of monolithic, inflexible, and “immediately out of date and gathering dust on a shelf” documentation.
The business will suffer without documentation appropriate to the business and market. Imagine a support team trying to understand how to help customers and report issues with only source code and limited access to a developer. Imagine a trainer trying to build training materials as part of a new release, and having only limited access to a live developer. Imagine a technical writer trying to build user and administrator help to be delivered with the product with nothing documented from which to work. Imagine an executive trying to explain the future possible vision to Wall Street or technical analysts and having nothing to go on except what was said in passing at a meeting. These are not ideal scenarios, and an Agile process should not be an excuse to allow an organization to arrive at these inappropriate places.
Much like the rest of the project development in an Agile framework, documentation work should be broken into smaller chunks and formal checkpoints built in that can address the businesses needs and make development more responsive and effective in the context of the needs of other teams in the enterprise.
7. Impact on perception of software development as a creative art
A wonderful side effect of a well implemented Agile framework in an enterprise is that it helps all teams recognize that design and programming is a creative art. It is not merely the rote assembling of pieces, like building a product out of interchangeable widgets on a factory floor.
The recognition of the creative process and its interdependencies on the market and the business can go a long way toward improving “stereotypical” approaches to code development: “We can get it overseas for pennies on the dollar!” “It’s just software!” “It’s just a simple change, can’t we just squeeze it into this release!”
Looking at it from the developer outward, Agile can help bring new or renewed recognition of what other teams in the enterprise bring to the software development process.
Scaled Agile Framework (SAFe)
Any examination of Agile in the enterprise should mention the Scaled Agile Framework (SAFe). This undertaking is a knowledge base and graphical summary of an approach to implement Agile on a large scale. It is an important read (whether you agree with it all or not) as you look at how to implement or improve Agile methodologies for a larger enterprise. You can read more about it on its project page.
This second entry discussed some ways in which an Agile development methodology impacts strategic planning artifacts necessary to produce a product that makes sense for your customers and market. These development and team artifacts, created and created and used well in an Agile process, will make life easier and more effective for developers and testers. They do this because they involve and communicate with other teams appropriately and map more closely to reality than traditional monolithic waterfall planning documents.
SmartBear’s portfolio supports your Enterprise Agile teams
Regardless of which Agile approach your team takes, SmartBear is there with development, testing, performance monitoring, and team collaboration tools to support your development workflow. Learn how SmartBear’s suite of tools can help your Agile processes.
Has your team implemented Agile? How has it changed your workflow? Let us know in the comments section below.
- Agile and The Enterprise: Part 1
- 25 Agilists to Follow on Twitter
- Selling Agile to the CFO: A Guide for Development Teams
- Less Process, More Discipline