Getting Started with Agile… Two of ‘Who Knows’
Okay… way too big a gap between meaningful blog posts. Since it has been so long, you might want to go back and take a look at the first post in this series called “Getting Started with Agile… One of Five“. There is a bit of irony here around how this post came to pass.
Personally, I am not prepared to believe that Scrum’s failure rate is because people don’t implement Scrum properly. That’s the whole Scrum-but argument. Scrum is such a light framework, if you give it a serious go, it’s pretty hard to really do it wrong. That said, I do believe that many organizations aren’t prepared to fix the organizational disfunction that Scrum is going to show them. Scrum’s primary benefit is that it shows you the stuff you need to fix. If you aren’t willing to fix the problems, you aren’t going to get the benefit.
How many companies using Scrum are really trying to transform the entire enterprise? I’d wager that most Scrum teams live within a larger, more traditional enterprise. In these organizations, structure and culture are going to trump anything that a single Scrum team does with people, process, or tools. You could have the best team members, run a perfect Scrum, have big visible charts everywhere, and I bet you still stand a chance of falling into Schwaber’s 75% statistic.
For everything we do to build a high-performing agile team, the organization is going to work to pull that team a part. The pull might be intentional, led by people that are threatened by any change to the status-qou. More than likely, the organization just doesn’t get it. The value delivered by the Scrum team just get’s lost within the larger underperforming organization. Even though the team was effective, it just never really translated to any kind of measurable value for the larger organization.
So therein lies the problem. What does it mean to have a successful Scrum team in an organization that isn’t performing very well? What do you do when Scrum helps you identify an impediment that can’t be solved by the team, but no one outside the team seems to care? Scrum ends up being a local optimization within the larger enterprise value stream. Unfortunately, it doesn’t matter how hyper-productive your team becomes… getting higher team velocity isn’t your biggest problem.
The trick to adopting agile is to form a team around a business problem the organization actually cares about solving… one that will increase bottom line performance. And this is where the conversation get’s interesting. Many of us aren’t responsible for improving the whole system. We are only empowered to do our part. We can only operate within our circle of concern. Our challenge is to figure out a way to make our local improvements, but in a way that is respectful of the whole.
There are a few things I want to suggest that will help you understand how your company looks at value delivery. For the rest of this post, I want to talk about aligning your agile pilot team to something your organization actually cares about. The important thing to realize is that not every company has the same kind of goals. If we are going hook ourselves up to big business problems, we need to understand how our companies look at value… how they look at the unit of production. For most, a unit of production is not a single user story delivered by a single team.
You're absolutely right, Mike. Team failure can result from a failure to recognize and materialize organizational change. And in these environments, when blockages aren't removed – teams can quickly become demotivated because they aren't experiencing the results they want to get from being agile. Often times, I think the change isn't realized because those working in large companies are used to such high levels of disfunction. They are used to the pain it causes and can't see the need for change.
"What do you do when Scrum helps you identify an impediment that can't be solved by the team, but no one outside the team seems to care? "
"The trick to adopting agile is to form a team around a business problem the organization actually cares about solving… one that will increase bottom line performance."
I was tempted to just say "well, duh…" or "you think?" This is true of any project. I am actually curious what the team is working on that has no perceived business benefit.
You'd be surprised.
Impediments the team can't solve: Functional management silos, HR policies, 18 month projects, multiple concurrent projects, being assigned to multiple teams… just to name a few.
Teams working on problems people don't care about: Building a component within a large systems architecture while the rest of the project is underfunded, working on features that will never get released into production, building features that will never be sold.
Believe me, this stuff is not as obvious as you'd think. If you have these problems solved, that's awesome… some people need to hear these messages.
Thanks for the comment. It was great seeing you this weekend.