Scaling Agile: Reasonable Practices for Program Management
It seems as if everyone is talking about “scaling” agile. What they mean is a strategic collection of projects with one business deliverable: a program.
We don’t have “best” practices for agile program management. However, you might find some reasonable practices help you use agile or lean even better.
Think Product, Not System
Sometimes, we think of our applications as systems, releases, programs, or projects. Those names might all apply to your product. I prefer to think product instead of any of the other words. I find I am more likely to think about the customers, what they need, and when they need it.
That thinking helps me create an agile roadmap with external and frequent internal releases. Product-focused thinking also helps me know if I have all the people I need across the organization so we can release the product.
Customers buy running, tested features packaged as products. Product-focused thinking helps us have more empathy with our customers, and it makes it possible to collaborate among teams to deliver the product.
Deliver Value as Often as Possible
Big-picture thinkers know what they want as a final outcome. They may think, “Unless it’s all done, it’s not useful.” We use agile because that assumption is not true.
I have learned that if I can’t deliver the entire thing in an afternoon, I’d better determine how to deliver very small chunks so I can make progress and deliver value often. I’ve been using inch-pebbles (one- or two-day tasks, done or not done) for almost forty years. Now, I define my work so nothing is more than a couple of hours in duration.
Why such small chunks? The larger the effort, the more difficult it is to get the entire program to done. As humans, we need to see progress so we can inspect and adapt, and use agile to help us deliver better. The way I like to do that is ask, “What is the first thing we can do that delivers value?” The more often we deliver value—across the program—the easier it will be for people to see our progress.
Track the Work in Progress
I bet you’ve seen products where the software was done but the marketing wasn’t ready. Or training wasn’t ready. Or the entire rest of the organization was ready but the software wasn’t. In my experience, many of those problems are work-in-progress issues. We started something and didn’t quite finish it so other people could use the deliverable.
I was a developer on a program where one team was supposed to measure the performance of the software. They started and then got diverted to other deliverables. Marketing waited for those performance numbers and was late with the glossies. The entire program suffered.
Think of scaling agile as program management, and consider how you can deliver your product one small finished bit at a time.
