Ease Your Transition to Agile and Learn What Your Team Needs
I’m not religious about any particular agile way. I often mix and meld the agile approaches for clients, who have found tremendous value in that.
If you are starting a transition to agile, first ask yourself: Why do we want to transition to agile? Agile is about the ability to respond to change. You get this ability by technical and management discipline. You don’t get it from just the technical teams delivering features. If management doesn’t do its part by creating product ownership, providing a reasonable work environment, and managing the project portfolio, the technical teams can’t deliver.
Before you move to a program, practice with one small agile project first. Become accustomed to delivering features every week, evaluating the project portfolio based on value, and having a single product owner develop a roadmap for a product and a product backlog for that product.
Once you understand what your organization’s issues are and you can resolve them, you can move to a program. You will have more and different issues and risks, but at least you won’t be starting your agile transition while dealing with them.
When I work with teams, I tell them to start with two-week iterations. They all groan and tell me the iteration is too short. And then we start to slice and dice their stories. I used to ask project managers how little could be done to meet the requirements for the project. Now I ask product owners and the technical team, “What are the acceptance criteria for this story? What does 'done' mean? How little can we do and still add value?”
Whether you are part of a feature team or management on this agile journey, you have to earn and extend trust. On a feature team, your job is to deliver finished features. If you are part of management, your job is to create an environment that allows the feature teams to flourish.
If you trust each other, management can ask for order-of-magnitude estimates if necessary and make project portfolio decisions based on value. More often, if the project portfolio team is doing its job and the team is delivering, management won’t need the estimates. The management team learns to kill a project before getting emotionally hooked by sunk cost.
Both the technical teams and the management teams need to learn new behaviors when transitioning to agile. From my reading, Scaled Agile Framework reinforces old behaviors. It postpones feedback and doesn’t help management learn to look for value instead of estimates. It looks to me as if it’s Theory X management.
Agile is Theory Y management. Tell people what you want. Provide them the resources to do it. And get out of their way. Then see what they’ve done, and if there is more value in the backlog, continue to fund the project or program. It's that easy.
