Metamorphosis - Manager to Agile Steward

I was listening to someone recently talking about the role of steward in previous centuries. The steward managed the estate for his lord and tried to get the most return for his lord while also keeping the people of the land content.

I thought of how this is a better metaphor for those in management, and perhaps more appropriate goals than I've experienced. My experience is that most managers are simply trying their best to keep everyone happy - mainly those requesting resources (people under the manager). They are also often simply trying to make sure everyone defensibly busy.

It's in the best interest of the manager's boss, though, that resources are used for the most return. This might take some educating or a little pushing. Think in terms of how a financial advisor is both making sure your funds are being put to use, but also often educating you along the way about why he thinks you should move some of your money here or there. This would obviously help get clarity around value - the value of different initiatives, the individual strengths of the people and how to best leverage those, and helping to see that value realized as soon as practical.

Without a clear path to value back to the manager's boss, managers can be left to simply growing their department as a means of validating their value (and therefore security) in the company. But imagine this happening with your financial advisor - "I can't tell you how your funds are doing because I really have no idea, but I have some reports that show how many people report to me."

Introducing Scrum at Your Organization

A Bad Prescription

I am often asked for advice on how to either introduce Scrum and agile at an organization, or how to roll-out from a given implementation of a team or teams to a broader level, such as program or division level.  While there is much to be said on this topic, it is best to start off with the imperative that there is no prescriptive approach that will work for everyone. There are many approaches, some successful despite being counter to standard recommendations. There are important contextual variations, such as company culture, personalities, recent experiences and history, project storyline and product market space that may all play an important part in how to roll out agile in your organization. This section will review some of those aspects, tools you can use, and then get to general recommendations.

Simply, here are the most important points that I have seen be effective:

1.     Ask why management wants to go agile. What is the win for them? Define success together. Rally co-creates Agile Success Plans at the beginning of customer engagements.

a.     Look at Geoffrey Moore’s adoption curve and mark where you think the company sits. Based on that, what is that group’s standard view of risk?

2.     Looking for the natural law win for those involved. Whether backers, decision makers or influential, be sure that you’re aware of or find out what would make this transition a win for each person. Along the way, you should find out, or uncover, what their concerns are (fear, uncertainty and doubt).

a.     Take a look at George Schlitz’s presentation on Mapping the Agile Battlefield for a deeper look at this area.

b.     The book What Got You Here Won’t Get You There is a coaching-view towards helping managers succeed in change situations like these.

3.     Remember that your agile roll-out plan and effort in itself should be agile. Plan it, and then routinely assess what’s working and not working in it, and adjust.

a.     Organization change is not complicated, it’s complex. Look at the Cynefin model and remember to gather data, especially people and process narratives and then determine what to do next.

If your company isn’t agile yet, but you want management to consider adopting agile, consider selling it based on the success of other well known companies. That might lighten their risk.