Visualizing an Agile Project to Find Balance
In the second post, we discussed the need for metrics and examined agile metrics, but isolated project “value” as the ultimate metric that you need to move toward.
In this third post, I want to change gears and help you to visualize yourself on an actual agile project.
Moving, but Toward What?
You are working as a project manager on a big software development project to develop a complex and integrated system. Multiple scrum teams are in place, in several locations, and even part of different organizations, but all are working on the same overall project.
The project tempo is rapid; sprints are executed in a cadence of every two weeks. The constant stream of meetings – sprint planning, design reviews, requirements meetings, integrated test planning, scrum of scrums, and more – can be overwhelming.
The wheels are turning, the train has left the station and it is moving at high speed, but what is the ultimate destination?
How do you sift through the constant flow of activity and get a sense of the end state it’s all moving toward?
Questions to Ask
You have two challenges: what is going on within each scrum team and what is being accomplished on the overall integrated project.
Here are a few basic questions that you can use to help dissect the situation:
- What are we building? What is clear…and what is not? What can we do right now to make it clearer? How will we know when we are done? How can we track our increasing clarity as it reveals itself?
- When are we on the hook to deliver? How can we monitor our progress – not knowing 100% what the end state is? How can we track progress on what we know and prioritize, and clarify what we don’t yet know - and make course corrections on the journey to our destination?
- How can we execute at the required quality level, consistent across all scrum teams?
- How can we do all of this for the least cost, and with the most efficiency? How will we know?
These questions show the constant challenge between managing for the short versus long term on the project, and managing locally, at the scrum team level, versus globally, at the project integration level. In the end, it is all about controlling what we can in the short to medium term, empowering people to contribute, figuring out the unknowns along the way, assuring stakeholder concurrence…and moving toward an increasingly clearer picture of an end state of value.
Finding Balance
This last point –moving toward a clear picture of the end state—is where many agile projects can easily trip. The key is to provide some guidelines to the scrum teams, and then let then run with the ball. Insulate them from the issues of figuring out where we are going ultimately, but give them the autonomy to run their own show within bounds that enable you to feed the overall system with the components it needs. By striking a balance on this control, you can avoid focusing too much on the short-term, with an incremental focus and lack of an eventual longer-term goal.
This post is part of the series: How to Empower People and Control Performance on Agile Projects
You want to create the most valuable software possible – as determined by your stakeholders - in the least amount of time and for the lowest cost. This four-part series will give you tips and tools to succeed.
