In the first post, that key challenge was identified – a push and shove, a top-down versus bottom-up, a yin and a yang…the tension between advance planning versus planning as you go. In the second post, we discussed the need for metrics to manage to, and examined agile metrics…but isolated project “value” as the ultimate metric that you need to move toward. In the third post, we examined an actual situation or case study where these challenges were real. We will outline some conclusions in this post.
What Drives You?
The driving force behind agile is that it addresses some unique challenges in software development. The pace of technological change, technical complexity, and rapidly changing needs make it very difficult to know exactly what you will need in the end. Agile includes a healthy acceptance of the reality that you will not know everything before starting to develop. At the same time, an agile approach includes a drive to an increasingly clear end state through regular involvement with stakeholders to ensure they are satisfied.
This process of ensuring that your agile processes are driving toward an end state is the key challenges. The key question is “How do you know when you are getting there?” After all, you cannot just be satisfied to say, “We are making progress.”
Throughout the project, your team and stakeholders are climbing a learning curve, but at the same time need to be making progress. A big part of the process involves setting a tempo with a system to ensure that all things are happening.
Setting a Tempo
This “tempo” in agile has at its heart the management of relatively short duration projects – let’s say 6 weeks plus or minus increments and even 2 week long sprints – while at the same time evolving and following a vision for the end state. Using a rolling wave, the process is on of constantly managing these short-term projects that have 95 percent clarity, and closing them out while pushing for the next chunks that come into clear view and are prioritized.
Long- and Short-Term
In the beginning, clarity on the end state product might be 50 percent at best. It’s like hitting a golf ball in the general direction of the flag, even when you cannot even see the flag. You start out with a strategy about how to get down the fairway – considering wind, slopes, hazards, and your own knowledge and capabilities. Each shot is like an agile sprint and is the complete focus of that moment. You could never know in advance exactly what you might encounter and need to face it at the time. As each shot is taken, you are closer to the green, where you can finally focus on getting the ball into the hole. It’s the ultimate balance of short-term and long-term.
The bottom line is that managing an agile project is a process. You need to come to grips with what you do and do not know and create a system for filling in the blanks as the project unfolds. You assemble the team, develop an ecosystem and manage in chunks of short duration while you figure out the rest. In the process, you deliver early and often. Nevertheless, you always need to maintain a view of the end goal, keeping stakeholders part of the process, and move toward it.
This post is part of the series: How to Empower People and Control Performance on Agile Projects
- Recognizing the Tension on Agile Projects
- Powering Through the Tension on Agile Projects
- An Agile Case Study
- The Importance of Process on Agile Projects