Sunday, February 21, 2010

In Praise of Middle Management

On a recent post on on Scrum's (alleged) shortcomings,  Bob Martin (aka Uncle Bob) wrote:
Scrum carries an anti-management undercurrent that is counter-productive. Scrum over-emphasizes the role of the team as self-managing. Self-organizing and self-managing teams are a good thing. But there is a limit to how much a team can self-X. Teams still need to be managed by someone who is responsible to the business. Scrum does not describe this with enough balance.
I agree with Bob: Self-organizing teams can focus too much on themselves. This can manifest itself as an uncooperative relationship with other teams and/or as an antagonistic relationship with management.

In a theoretically perfect Scrum organization, there might not be much of a middle management layer, just Product Owners and ScrumMasters guiding their interdisciplinary teams on a quest of building better products and services while continuously improving their ability to do so.

The current state of the organization is much more likely to be a hierarchy organized on functional boundaries. The Scrum organization is potentially a factor 10 more effective that the current structure, but reorganization is dramatic, scary, painful and not without risk.

Scrum enables change. Scrum demands change. The essence of Scrum is change. Very quickly, the Scrum Team (or Teams) will come into conflict with the structures the company has in place. These structures are not anybody's fault. At the time they were created, they seemed like the best thing to do.

Change demands leadership. Who provides that leadership? Middle management.

Middle management (and probably one or two middle managers) is the unsung hero of a successful Scrum transition. Middle management is the source of lasting change in an organization. Initiatives from top management often fade as soon as the relevant manager changes roles.  Operational staff is too powerless to instigate change.

Middle management is caught between the rocks and the hard place. The "rocks" are the demands from above and the "hard place" is the reality of accomplishing those goals.  Middle management has influence, especially the 2nd level and up. When middle management recognizes that the methods and structures currently in place are not competitive, they look to something better.  That something is Scrum.

Middle management does not have the power to command change in the organization, so it has to negotiate and build consensus about how to move forward. Eventually, when that consensus is achieved, someone at the top will bless it, and there will be a new org-chart.

Scrum means tremendous change in the way the organization works and eventually, the way it is structured, too. So the middle managers driving the change also have the most personal risk. Ironic isn't it? Why do they do it? Because the company needs to be better than it is. (And they needn't worry - there will always be room for managers who can make their company better than it is!)

Once I realized that middle management is the true source of leadership and why they do it, my respect for the importance of middle managers grew tremendously. I have banned Dilbert and the Pointy Haired Boss from my presentations. And I encourage my coaching customers to realize the importance of their mission and the importance of their role in accomplishing it.

XP Day Suisse, Geneva, 29 March 2010

The agile community is strong and active throughout Switzerland. On March 29, Agile-Swiss.org will be holding the XP Day Suisse in Geneva. This is one day event with a management track and technical (or should I say team?) track.

In any case, I am pleased to be invited to talk about Agile Contracting and look forward to seeing people I know, like François Bachmann, and meeting many people I don't.

It looks like a great event! Check out the program or go directly to registration.


Wednesday, February 3, 2010

Agile Software Development and Governance

Today, Pierre Neis journeyed down from Luxembourg to talk to us about Agile and Project Governance. He talked about a 2-team Scrum project he had coached for a large organization and how that project tracking was integrated into their corporate governance tools. He then talked about a flavor of earned value management 'Agile-EVM' which he applied to the project.

EVM strikes me as an oxymoron: an inherent contradiction, like 'military intelligence' or 'serious play'. EVM was created to track the creation of value vs the accumulation of costs. A series of indexes get reduced down to a green/amber/red traffic light which indicates whether the project is on track or not.

The only trouble is, a waterfall project does not produce any customer value until the test phase is complete. So the EVM concept is meaningless when applied to a waterfall project.

The situation is quite different when applied to an agile project. A Scrum project produces finished functionality, i.e. value, every sprint. The product burn down chart compares the progress to the plan. Since the product owner can change the remaining scope after every sprint, traffic lights produce by Agile-EVM mean
  • Green: Plan and Progress are in sync
  • Amber: Plan and Progress are diverging
  • Red: A serious reality check is necessary.
In the discussion, we talked about the lack of Quality figuring into the calculation. If you have poor quality, this will be higher maintenance costs and must worse development performance in the future.

The big open question: How to integrate a Net Present Value calculation of the impact poor quality into the financial indicators of the project?

Download: His slides and the Nokia Test.