The Context Leadership Model

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

Sheepdogs Simple projects with low uncertainty
Colts Simple projects with high uncertainty
Cows Complex projects with low uncertainty
Bulls Complex projects with high uncertainty

Let’s look at a collection of projects that comprised the overall release of a complex engineering simulation application suite.

Component Quadrant Team Size Iteration Length Standup
User Interface Front End Sheepdog 5 Iterationless 2/week
New Graphical Output Colt 7 1 week 1/day
3D Visualization Sheepdog 2 1 week 1/day
High Performance Computing Simulator Cow 14 3 weeks 3/week
Overall Bull 28 3 weeks none

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.

About Todd

Todd Little is VP of Product Development for IHS, the leading provider of information and analytics shaping today’s business landscape: energy, economics, geopolitical risk, sustainability and supply chain management. For over 30 years he has been involved in almost all aspects of software development with a focus on commercial software applications for oil and gas exploration and production. He is on the Board of Directors for the Agile Alliance. In 2003, he co-founded the Agile Development Conference, and served as the General Chair for ADC2004, Agile2005 and Agile2006. He has returned for the 10 year anniversary of the Agile Manifesto to be the General Chair of Agile2011. He is a co-author of the Declaration of Interdependence for Agile Project Leadership ( and a founding member and past President of the Agile Project Leadership Network (APLN). Along with Pollyanna Pixton, Niel Nickolaisen, and Kent McDonald, he is a co-author of the book “Stand Back and Deliver: Accelerating Business Agility,” Addison Wesley
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>