August 26th, 2008[Agile 2008] Expanding Agile: the Five Dimensions of Systems
Besides presenting the Coding Dojo experience report, one of my main interests of going to Agile 2008 was to attend some of the Lean-related sessions. In this and the next posts I will give a quick summary of the sessions I attended.
Expanding Agile: The Five Dimensions of Systems – Mary Poppendieck
Although not directly related to Lean, in this session Mary gave some insights on leadership and systems thinking that are worth talking about. By using the metaphor of Plank Roads (that provided fast improvements, but deteriorated over time, eventually overcoming its benefits), Mary questioned how sustainable is Agile?
She gave a great overview of the history of software development and the term Software Engineering. From Waterfall to Agile, going through ‘Plank Roads’ such as CMM, Spiral, and RAD, but also highlighting some lessons learned. Her main point was that the fragile aspects of our short history are mostly related to processes and what she called Project Management concepts (life-cycle, requirements, stages of testing, maturity levels, among others). On the other hand, the successes from our history are related to the Systems Engineering aspects of software (built-in quality, information hiding, continuous integration, skilled technical leaders, among others).
As she has already said, successful leadership needs two views: technical vision and marketing vision. She thinks process-related roles (such as a Scrum Master) does not guarantee a successful software. The team needs to understand the entire system, and she highlighted 5 dimensions to consider:
- Purpose: Is there a clear vision and shared understanding of success? Is there technical leadership and built-in learning cycles to verify and improve suitability for purpose?
- Structure: Do junior people have the training and oversight to assure they produce well-factored code? Does everyone on the team understand what they are producing and how it fits into the overall system?
- Integrity: Is quality built-in or inspected at the end of development? Are failures rare and investigated deeply to fix their root cause? Is such learning captured and shared in an effective manner?
- Life Span: Are those responsible for operations deeply involved during development? Is there a long-term vision of maintainability? Are rewards structured so that developing a robust system that performs well over time is the most strongly encouraged behavior?
- Results: Does the system meet its overall economic investment? How quickly is ROIÂ realized?
I think my main lesson from this session is that we should start re-thinking our approach to operations and support. After all, they are all part of the software life span and essential to the value stream. More about Lean and Agile 2008 in my next posts…