Yesterday's post explored Agile that felt messy but delivered results. Today we’ll explore Agile that feels ok, but doesn’t deliver any improvement in results.
Your organization has made a big investment in Agile, everyone is trained, there’s a new process in place, all the role definitions are clear. But you’re not seeing the dramatic results you were promised. Why is this happening? Where are the big results that we keep hearing about from other companies? Are we doing something wrong or is Agile just a bad fit for our company?
A factory worked once described Lean to me this way, “Lean is when you used to do something one way and then management comes in and tell you to do it a different way. The new way is supposed to be more efficient.”
I see Agile organizations do the same thing. They have unplugged their waterfall process and plugged Agile into the same socket. They have not addressed the constraints that were blocking productivity in the first place. Typically I have seen companies move to Agile Practices without changing the Structure and Culture of the organization.
But hey, we’re not all at liberty to change the company from the top, so what can you do to help?
Here are some things that I’ve seen work.
Do a little detective work. Identify the biggest blocker to productivity. Two of the common blockers I’ve seen are “Unrealistic timelines” and “Non-Dedicated Team members”. These appear beyond the control of the team, but in fact I’ve seen teams take responsibility and turn them around. You probably have many blockers and constraints, choose ONE to focus on.
Leverage team velocity to fight pressure to overcommit. I’ve seen teams buck Scrum practices because of pressure from above. For example, an executive slams their fist and says “we need these 10 features this month!” But the team velocity is only 4 features per month. What does the team do? Commit to the 10 features, deliver 6 poor quality features and fail to deliver the other 4. “Hey it’s better than telling them we can’t do it.” Use your velocity data to drive the discussion. “We have been successfully delivering 4 features per month. When we do too many we have quality problems and deliver fewer features the next month because we are fixing bugs from the prior month. Let’s talk about prioritization of features or alternative solutions to meet the need.”
Illuminate the blocker. Transparency is one of the greatest tools you have at your disposal. How can you shine a light on the blocker? For example, if a key team member keeps getting pulled off to work on production issues from an old system (not a result of the team’s work), indicate on the scum board that those stories are blocked. Try tracking the time it cost the team having those issues blocked this sprint, and the financial impact it had. Armed with this information the team can move into solving the issue. Maybe you decide to take that information to someone that can help get an additional person to help with production issues. Or maybe you decide to give the team member some time to transition their knowledge to someone else so they don’t keep getting pulled away.
These tactics worked for me. I’d love to hear what worked for you.
