In Effective Agility Requires Cultural Changes: Part 1, I said that real agile approaches require cultural change to focus on flow efficiency, where we focus on watching the work, not the people. Too few organizations can do that. But teams can change how they work—in any approach.
Here are three suggestions to emulate flow efficiency thinking:
- Start the project with a cross-functional team that stays together for the entire project.
- Timebox all phases or up-front work.
- Deliver something internally at least as often as every month. (Yes, more often is better, but once a month is my minimum.
If you and your team have been practicing real agility, you might say these ideas barely show any agility at all. But here's how they can work to create more agility.
Tip 1: Start and Maintain a Cross-Functional Team for the Entire Project
I still see many supposedly agile “teams,” where the project has a “development team” and a “testing team.” Even if the developers and testers are one team, I still see UX or UI teams. (See Unearthing Your Project's Delays for how that creates multitasking and increased cycle time.)
While your organization might focus on functional teams, your project can agree to act as a cross-functional team. In my experience, this might require a facilitative project manager who acts as the “Wall Around the Team,” protecting the team from external mayhem.
I don't care what the organization calls this person. But that person supports the team, so they can focus on their overarching goal. Not any single person's individual goal. No. The goal to release the product. It's even better when the team collaborates, but a cooperative team is better than every person working alone.
When the team can focus on the product, as a cross-functional team, they can create some agility.
Tip 2: Timebox All Phases or Any Up-Front Work
Many organizations have months- or quarters-long backlogs or roadmaps. There are plenty of problems with these roadmaps or backlogs, but the biggest problem is they contribute to aging. (See Flow Metrics and Why They Matter to Teams and Managers for more information. The older the work is, the more cognitive load people have, thinking about all that work.
Or, someone “needs” to define an architecture, all up front, without any of the features. (And don't get me started about estimating something we haven't started yet. That's why I wrote Predicting the Unpredictable.) I like to ask how little we can do up front, and start the work instead.
So many organizations remain wedded to long and complex plans. In that case, ask them to agree to timeboxing any up-front work. For example, see if they will timebox requirements gathering to a maximum of two weeks. Why? Because everyone knows what the first few necessary requirements are. And, with a lot of innovation, we cannot predict the next batch of requirements. Instead of trying to define everything, define the minimum.
Do the same for analysis, architecture, anything that occurs before actual development and testing.
This can work well if you demo something at least monthly once you start writing code and tests.
Tip 3: Demo Something Monthly (At a Minimum)
The more your project demos your progress, the more other people—especially managers—will trust you. If you can demo something valuable every day, no one will ask for an estimate or prediction. If you can demo once a week, very few people will ask for estimates. It's a little trickier if you only demo once a month, but if your team implements through the architecture, you can show your work with demos.
Several of my clients say that their customers can't take monthly deliveries. That's fine. You can deliver inside the organization, especially to yourselves, to show your progress. And you can use other people across the organization for internal feedback.
The more frequently you can demo, the better. But do not let even a month go by without a demo. Otherwise, you are likely to fall into the black hole of “thing thing isn't done so we can't show that thing, either.”
Return to finishing something valuable through the architecture and demo as often as possible. (See Managing the Stream of Features in an Agile Program to see images of thin slices of features through the architecture.) Yes, this changes your approach to an incremental lifecycle.
Demos aren't the only measure of progress. You can use the flow metrics, too.
Use the Flow Metrics to Monitor Your Progress
The four flow metrics are:
- WIP, Work in Progress. All the work that's in progress: started and not yet finished.
- Throughput: The number of work items a team/manager can complete per unit of time.
- Cycle time: The time to release value, as a trend.
- Aging: How long a piece of work has been in progress.
When teams start and stay together, they tend to collaborate. That collaboration allows them to limit their overall WIP. With any luck, they can increase their throughput and decrease their cycle time. That allows them to more easily see older items, what's aging.
When teams timebox any up-front phases or work, they do create old(er) items, especially if they use several two-week timeboxes. However, once that up-front work is “done,” the teams can manage their WIP and start to increase their throughput. Remember, all the upfront work creates long cycle times. And in my experience, the team will have to re-address any up-front work they thought they completed.
But that's the value of the demo. The more often teams demo their work, the faster they can receive feedback from others. That's when the team realizes when they succeed and when they need to rework what they thought they completed.
I would much rather create shorter feedback loops with shorter cycle times and faster feedback. That allows the team to manage its WIP and throughput. Not to mention aging.
All effective, even if it's not “real” agility
Effective Agility Works Better than Fake Agility
In fake agility, teams use practices and dread their supposedly agile approach. But effective agility sees the reality of the lack of culture change.
You can use effective agility and create a better team environment. And avoid the death marches so common to people who say “Agile stinks.” Because what they're doing does not align with the agile principles. Even if they do use agile practices.
I'll explain about how to change your team's project culture to increase agility in the next post.