The Context Leadership Model shown below is a model that I have written about in an Agile2004 Experience Report, IEEE Software and in the book “Stand Back and Deliver: Accelerating Business Agility” (Free Chapter or Amazon) The following post is a short section extracted from my Agile2012 Experience Report.
Over the years I have used the model to look at projects based on the degree of uncertainty and complexity.
Complexity includes project composition such as team size, geographic distribution and team maturity.-
Uncertainty includes both market and technical uncertainty.
The four quadrants are named with metaphorical animals
|
|
|
|
|
|
|
|
|
|
|
|
Let’s look at a collection of projects that comprised the overall release of a complex engineering simulation application suite.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Front End team, while globally distributed was nonetheless fairly small and as well had very well defined tasks necessary for the update from the legacy simulator to cover the new functionality. With low uncertainty, generally low complexity and a senior team leader, we let the team largely manage themselves.
The New Graphics was a new product and was looking to provide a solution that no other commercial product currently solved. This meant that it had high uncertainty. The team was relatively small, although globally distributed. The senior developers were collocated in Houston with 2 remote developers and a tester in Romania. The product manager was in Houston and his proactive involvement was critical. To get the product started he developed a user story board. The graphical description of the results he was looking for worked very well to communicate with both the local and the remote team. Of course the pictures were just an invitation to a further conversation. The team relied heavily on the product manager and he made sure to spend time with each of the senior developers typically daily and often several times per day. The remote team was managed independently by one of the senior developers and communicated as necessary via email and phone conversations with a minimum of a weekly synch up meeting.
The 3D Visualization team was enhancing and maintaining an existing application with a team of two developers and one primary tester. This project had some overlap with the New Graphics project so we simply merged the teams together in Scrum meetings.
The simulator team was by far the largest team but was all collocated within Houston. The simulator is the core engine and must coordinate with the other supporting applications. The product had been under development and in the market for several years and the focus was on displacing legacy applications. The gap was relatively well know so uncertainty was moderate and the general complexity put it into the cow category. As a result we settled on a longer iteration length of 3 weeks. The team started with daily standups, and while they found value in the standups they felt that the nature of their R&D work fit better with standups every other day. The team adjusted and continued to deliver in a highly effective manner.
The overall system of systems required managing all of the uncertainty and even more complexity. The total team size was such that we did not feel the need for a Scrum of Scrums model. Instead, we had two ScrumMasters that covered all of the projects, and essentially had them pair to cover the overall release. Each ScrumMaster had primary accountability for a couple of teams, and the other participated in key Scrum meetings for those projects that they did not have direct responsibility. In that way both of them were up on the overall program and knew what cross team issues needed to be resolved. This model worked quite well as not only did the cross team communications happen efficiently, but when one of the ScrumMasters was out we had the other one help out without missing a beat.
