Scrum is not something “IT does”

June 24, 2010 CollabNet VersionOne

Thanks to a ton of help from Michael James, I just put the finishing touches on my new webinar, “Necessary conditions for enterprise agile success: The subtle stuff you’re probably getting wrong.” In this presentation, I plan to review the common mistakes and pitfalls I witness at organizations around the world who have tried to do agile and who are looking for some coaching because they’re struggling. There is an underlying theme to many of those pitfalls that I’ve encountered so many times in the last month, that I want to bring it to everybody’s attention via the blog.

So here it is: Scrum is not something “IT does.” Agile isn’t something IT does either. Let me explain. Organizations of all types with all kinds of projects are notoriously bad at communicating an integrated vision of their company, products and projects from customers and executives down to all of their workers. Dan Pink has a great exercise to illustrate this phenomenon called “Whose purpose is it anyway?” You can find his direct explanation in his book, Drive. I’ll give you my version here. Take everyone on your team and hand them a 3×5 notecard. Ask them to write down what they think the mission of your organization is (or of your project) and three primary goals for this year. Collect the notecards and then read them aloud. Based on my experience, I’m going to guess that the answers won’t be the same. In fact, you’ll probably find them to be shockingly different.

When an organization is “doing Scrum,” they are participating in a framework that improves communication of the big vision all the way down to little requirements, in a way that results in all of our team members charging toward the same goal. Scrum enterprises have regular meetings to discuss the organization’s vision overall, what that vision means to each product, what it means to each team and finally on how to realize that vision by providing technical experts with sufficient context and priority so they know how to maximize value delivery (a prioritized product backlog). We expect that each individual team can take this prioritized list of items and deliver to their customers, real working functionality at the end of every iteration. Agile engineering fits into this puzzle as it allows technical teams to execute the delivery of real, working product to our customers at the end of each iteration. However, if the business isn’t participating in high quality communication of the organization’s vision into a prioritized list of stuff for the teams to develop and deliver to them, the organization isn’t getting much out of agile except higher quality code.

Scrum is ultimately a communication framework that helps business and technical people have better conversations and ensures that business experts are driving business decisions and technical experts are making technical decisions. The majority of failures I see in agile and Scrum implementations today are the result of the attitude that Scrum and agile are things IT do to cut costs and be more efficient. Your IT folks can be the most efficient team in the world, but if they don’t have strong (and coordinated) business decision makers telling them what is important to the organization, they will continue to fail (they’ll have beautiful code that doesn’t result in useful features).

So, if you’re part of an IT team that’s frustrated with your business people who are never happy, I would suggest sitting down and trying to understand their vision for the product and what’s really important to the end users or stakeholders they’re responsible to. Try to understand the big picture a bit better and try to figure out why they’re frustrated. If you’re on the business side and can’t figure out why your IT teams continue to fail, ask yourself if you’ve done a sufficient job communicating with them about business priorities. Also, do you understand what technical issues have them stuck? If not, have a long conversation about what’s really going wrong and what you can do to help get the technical folks focused on the real priorities.

Of course, if you do Scrum, these conversations will be part of the regular meeting cadence you agree to participate in. But even if you can’t do agile or Scrum, having great conversations with your colleagues isn’t just nice… it’s the only route to having a successful organization.

Previous Article
Transitional Velocity and your Agile Rollout
Transitional Velocity and your Agile Rollout

You’re going agile and you couldn’t be more excited.  You’ve read  about all of the benefits and want that ...

Next Article
Why I don’t like the metric system
Why I don’t like the metric system

I like to get involved in the various agile development discussion groups.  These groups tend to provide a ...