The best way to start describing the Agile Maturity Model (AMM) is by talking about what it is not.
The AMM is not
- A mechanism to measure the performance of a team
- A pre-defined set of practices, whose adoption guarantees successful delivery of projects in time and within a budget
The AMM, in contrast, tries to quantify degree of responsiveness of a team to an organization's business needs. The philosophy being that increasing the discipline and proficiency of executing some best practices will increase the degree of responsiveness. The AMM primarily focuses on application development activities; the dimensions of the AMM are
- Testing
- Source code management
- Collective code ownership
- Collaboration
- Responsiveness to business
- Assurance and governance
- Story formation
- Design simplicity
- Build process
For each of the above dimensions, the AMM lists behavioral patterns exhibited by teams. Teams can use the AMM as a reference to identify and compare the behavior that they currently exhibit and plan to alter and tailor them.
For example the behaviors identified in the testing dimension are
- Acceptance testing in lieu of all other tests
- No unit testing framework, ad hoc testing (Manual testing of individual components /controls)
- Unit testing, manual functional testing; application has a testable architecture
- Unit testing integrated into build process, testing automated as much as reasonable given application
- Developers write unit tests before writing functional code
- Test are identified and produced as part of a story creation
- Automated functional testing (e.g.. GUI testing); stories remain in development until all bugs are fixed or deferred
Using the AMM this team can then introspect and choose to introduce unit testing as a best practice.
The AMM Dimensions
Let us now look at the various dimensions of the AMM and the behavioral patterns that are identified within each dimension. The behavior listed at the start of each dimension is an undesirable behavior and teams should try and move away from them as soon as possible. However to what extent a team would like to mature in a given dimension is the team's choice.
The practices can be classified as
- Regressive
- Neutral or Chaotic
- Collaborative
- Operating (Consistent exhibition of competance)
- Adaptive (Expertise to adapt to change)
- Innovating (Creative evolution of practice, and spread these practices throughout the organization)
Testing
- Acceptance testing in lieu of all other tests
- No unit testing framework, ad hoc testing (Manual testing of individual components/ controls)
- Unit testing, manual functional testing; application has a testable architecture
- Unit testing integrated into build process, testing automated as much as reasonable given application
- Developers write unit tests before writing functional code
- Test are identified and produced as part of a story creation
- Automated functional testing (e.g.. GUI testing); stories remain in development until all bugs are fixed or deferred
- Traditional schemes based on fire-locking and time-sharing
- SCM supports version of code
- IDE(s) integrate with SCM; developers include meaningful comments in commits
- SCM support merging; optimistic check-ins
- SCM support atomic commits
- All development collateral is in SCM
- SCM is transparent to delivery team, behind build process
- Knowledge held by specific team members; people work in isolation
- No pairing, people work alone, some informal process for keeping people informed
- Pairing; no code locking
- Pairing scheme ensures rotation
- Team signs up for functionality rather than assignment to individuals
- Within an sprint, functionality delivery is signed up for just in time
- Old (bugs) and new functionality is queued, development team pops the stack in real time
- Regular progress updates from management to the delivery team (as opposed to the other way around); irregular team meetings
- Project collaboration tools (wiki, mailing list, IM) in place and used throughout project team; project status published and visible to all
- Daily stand-ups and sprint meetings; problem solving is bottom-up as opposed to top-down; team sets sprint objectives and agrees on estimates.
- Integrated, continuous build process, with build status notification to the team and collective responsibility for state of the build
- Business is part of the team, stakeholders accept working software at reviews in lieu of other tracking or progress metrics
- Frequent (near-real time) prioritization of old and new functionality
- Build automatically deploys to QA environment available to any interested party
- Frozen specification, unresponsive to business value
- Team tries to accommodate new requirements by ad hoc change requests ("pile it on")
- Iterative process with sprints of length short enough to respond to business change
- Showcases per sprint; business prioritizes functionality per sprint
- Continuous involvement of the business on the team: business certifies story complete out of dev; involved in (rather than approval of) story definition and acceptance tests
- Business writes high-level stories for all requests; organizational story queue exists; prioritization decisions made from full story backlog
- Development process is integral to business initiatives; development teams work as a part of the business unit rather than as a service to the business unit
- Status reports document progress; schedule acts as plan
- Concept of release planning is introduced
- Sprint planning is introduced
- Plan becomes communication and tracking tool rather than an exception report
- Every sprint review examines value delivered and assesses next sprint by need, priorities (and delivery)
- Organizational adoption: Introduction of Portfolio Planning and global optimization of resources (use of metric and standard measures)
- Business review of value and return helps teams on regular basis based upon status
- Development tasks extracted from voluminous, frozen requirements artifacts
- Production of lightweight artifacts (e.g. panel flows) to drive high-level requirements development
- Mapping granular requirements (e.g., use cases) in high level user requirements
- Marshaling use cases into discreet statements of functionality that can be delivered in time boxed development sprints
- Stories are an expression of end-to-end functionality to be developed, including testable acceptance criteria and a statements of value
- Spontaneous story development provided by business for in-flight projects; stories not derived from extant sources but are immediate expressions of customer demand/need
- Global repository of functional requirements for stories developed by business for any business requirements, including a formal measure of business value delivered
- Big up-front design that attempts to accommodate all potential future needs
- Application of fundamental design patterns
- Structural refactoring to decouple application architecture
- Doing only what needs to be done
- Aggressive and constant refactoring to improve code quality/simplicity extant code
- Spiking solution with each release to introduce new ideas and challenge architectural decision
- Technical design decisions taken with each story
- Ad-hoc build requests; scripting and component marshalling performed manually
- Consistent, repeatable build process with durable artifacts executed manually with each release
- Build is automated, executed on a timed basis
- Unit tests are integrated with the automated build; team is constantly notified of the status of the build; build triggered by SCM updates
- Test and metrics (e.g., code quality, complexity, check style, etc.) are integrated as gatekeeper events; build data archived and reported in build portal/dashboard
- All product components advertise dependencies; master repository established
- Product integration tests included; build process executes automatic deployment to QA testing environment
Conclusion
We will be talking about the above AMM model during the Agile Philly and discussing the interconnections between the various dimensions.
Ackowledgements
Ross Pettit , Gerg Reiser, ThoughtWorks Inc.
Related Blogs and Articles
- An "Agile Maturity Model?" by Ross Pettit http://www.agilejournal.com/component/option,com_magazine/func,show_article/id,44/
- Agile made us better but we signed up for great By Ross Pettit http://agilemanager.blogspot.com/2008/06/agile-made-us-better-but-we-signed-up.html
3 comments:
What do you say to someone who points out that many of these steps are not necessarily sequential? Or the questionable nature of the heirarchy of "Agile goodness"?
In the Collective Code Ownership list, I could practice step 5 without practicing step 4. Where does that put me on the ladder? Why is 5 listed above 4 anyway? Is there some level of rotation that is too frequent or too infrequent to deliver maturity?
Or in Source Code management. You could get all the way to step 7 without ever having an integrated scm/ide.
Testing step 7 implies that all bugs can be known before a story is released. That doesn't fit very well with a mature agile philosophy.
I think the recognition that teams, departments, or businesses can be on a path to "Agile Maturity" may have some value, but to try to pin certain practices to certail levels of maturity is probably misguided. A look at ability to deliver should be at the root of any attempt to pin an organization to a level of "Agile maturity", and these practices will not remain constant in their predictiveness of delivery satisfaction across broad ranges of delivery environments. To state the obvious, the 3 person team and the 30 person team will look very different if both have maximized their "Agile maturity".
Do I really need a formal measure of business value to be applied globally(Story formation step 7) to reach ultimate Agile maturity for my team? For a 30 person team on a two year project maybe, for a 30 person team on a 6 month project, probably not.
This does sound interesting. The more I think about Agile and changing my organization, I have realized that testing methodolgoies is the backbone of "becoming Agile" - that you cannot write good software until you can prove you write good sortware, which is what tests do. I think that it will be a good talk on Tuesday for anyone, since it pinpoints "next steps".
Jeff,
Lots of questions, Let me see if I can make things clearer
Regards
Ravindar
Jeff: What do you say to someone who points out that many of these steps are not necessarily sequential? Or the questionable nature of the heirarchy of "Agile goodness"?
Ravindar: We say yes these steps are not necessarily sequential. Infact we say nowhere that they should be, just that some practices are important and there should be an attempt to start making them part of your behaviour(eg:TDD)
Jeff: In the Collective Code Ownership list, I could practice step 5 without practicing step 4. Where does that put me on the ladder? Why is 5 listed above 4 anyway? Is there some level of rotation that is too frequent or too infrequent to deliver maturity?
Ravindar: As said before, there is no order. You could do 5 before 4. Rotation ensures that you have a healthy knowledge sharing in the team, not to mention the getting to know each other part. Each team finds there own rotation frequency. A pair that works for weeks on end together does not foster pair rotation.
Jeff: Or in Source Code management. You could get all the way to step 7 without ever having an integrated scm/ide.
Ravindar: You could, but why would you do that, when you have great IDE's. Seems like you would be making your life really tough:).
Jeff: Testing step 7 implies that all bugs can be known before a story is released. That doesn't fit very well with a mature agile philosophy.
Ravindar: What it implies is that we have fulfilled all the functional requirements and have tackled all the known bugs. Nobody is saying that we need to remove every bug, but fix the ones you know off. It is a very simple stop the line culture that is taught by Lean practitioners. I don't see why we shouldn't fix things we know off.
Jeff:I think the recognition that teams, departments, or businesses can be on a path to "Agile Maturity" may have some value, but to try to pin certain practices to certain levels of maturity is probably misguided. A look at ability to deliver should be at the root of any attempt to pin an organization to a level of "Agile maturity", and these practices will not remain constant in their predictiveness of delivery satisfaction across broad ranges of delivery environments. To state the obvious, the 3 person team and the 30 person team will look very different if both have maximized their "Agile maturity".
Ravindar: Agreed. Although, whether you are 3 member team or a 30 member team, if you are not practicing TDD are you really maturing and is your delivered software really of high quality? Shouldn't one self examine this?
Jeff: Do I really need a formal measure of business value to be applied globally(Story formation step 7) to reach ultimate Agile maturity for my team? For a 30 person team on a two year project maybe, for a 30 person team on a 6 month project, probably not.
Ravindar: Yes. The whole point is that you deliver to a customers requirements. If you can't attached a value, how are you prioritizing your story's.
Post a Comment