In my previous posting, Getting Started with Agile Delivery, I provided some guidelines to help you get up and running quickly with an agile adoption initiative. In this article, I’ll cover some ways for you to monitor the health of your agile initiative through regular process inspection and adaptation.
Background
Inspection and adaptation are built intrinsically into agile methodologies: Scrum, eXtreme Programming, DSDM, Feature Driven Development, etc., are all based on the iterative Shewart/Deming Plan-Do-Check-Act (PDCA) quality control cycle.
Since agile project delivery is iterative and incremental, every process iteration and every product increment provides opportunities to plan and deliver, and then inspect feedback from delivery. Finally, your process implementation can be adapted appropriately to meet the desired business outcomes of the project and or/ the business requirements of the product, and the PDCA process cycle can begin again. Here’s how to achieve this in both qualitative and quantitative ways.
Qualitative Inspection
You can inspect your agile process qualitatively through personal observation and project reflections.
Personal Observation
How do you tell from observation if your team is agile? Here are some of the distinguishing characteristics of agile teams (see my book Managing Agile Projects, Prentice Hall, 2005, for more) to look for when you are “managing by walking around”:
- Customer-value orientation. Agile methods make customers an integral part of every project team. Customers or their proxies are collocated on-site with development teams. Customers define acceptance tests along with desired features and they get to decide the order in which features get implemented, giving them the opportunity to select features with the highest value first–and to change their minds at the beginning of each iteration about which features to implement in future iterations.
- Individual competence. Strong demand for individual competence differentiates agile teams from others that focus solely on process and mistake process skills for individual competence. Many agile teams employ the software craftsmanship model of software development to exploit the advantage that comes with using small teams of really good developers. Likewise, testers, managers and business experts are also expected to carry their weight and play a part in keeping the team light and nimble.
- Sustainable self-discipline. Along with possessing individual competence, agile team members need to be highly disciplined. A methodology cannot be mandated top-down–it will suffer deterioration in its application over the long term. Sustained process adoption will only come when your team members individually commit to the process, and then discipline themselves to follow it.
- Small team sizes. Agile teams are built around small groups of talented individuals. Because team members are individually competent and self disciplined, the overall team size can be kept to a minimum. For example, Scrum recommends a team size of 7, plus or minus 2 people.
- Intense collaboration. On agile teams, collaboration draws in all of the people, all of the time. For example, on Scrum teams, sprint planning and review meetings demand intense collaboration between customers and developers. Developers provide effort estimates to implement features, and customers decide priorities and order features contingent on developer estimates.
- Reduced decision feedback time. Incremental and iterative delivery dramatically reduces the time between a decision is made and the effect of that decision is seen. Agile teams also reduce decision feedback time in several other ways besides increment and iterative development, including: making customer representatives available to the development team to validate and approve every increment, ensuring that a regression test suite is always available to monitor the effects of any changes, and making small releases to ensure viability of the solution.
These are some clear indications to watch for when examining the health of your agile process implementation. Another good qualitative way to inspect the process is by holding project reflections.
Project Reflections
Project Reflections (also called Project Retrospectives) are facilitated meetings for reflecting on the successes and failures of a project and it underlying delivery process. You can conduct a project reflection thus:
- Arrange for a neutral facilitator–someone other than yourself–to run the reflection.
- All project team members seat themselves in a large conference room, preferably in a circle.
- All participants follow simple ground rules (cell phones off, no interrupting others, each person gets a time-limited turn, and no judgment on feedback).
- Each team member provides feedback on these questions: What’s working well? What can we improve? What are some obstacles or issues facing the team?
- A brainstorming period follows to address the major issues.
- The meeting ends with the facilitator capturing action items.
Unlike the traditional “lessons learned,” you should conduct reflections while the project is underway, say every 2-3 iterations, to qualitatively inspect your agile process.
Quantitative Inspection
The primary purpose of an agile process should be to deliver customer value. Two simple ways to quantitatively measure customer value are cycle time and customer satisfaction.
Cycle time is the time elapsed between the time your customer specifies a product feature and the time that feature is delivered back to that customer in production. This critical process metric allows many organizations to compete on the basis of speed: improving their business success by improving the rapidity with which they deliver solutions. You can measure cycle time by using a value stream map that details value added and non-value added activities along your entire project delivery chain.
Business customer satisfaction can be measured by asking this simple but incredibly important question: Would you recommend the product (or service) produced by this process and project to a friend? Industry best practices indicate that the response to this one question is sufficient to determine whether customers are receiving value from the process (see Fred Reichheld’s The Ultimate Question: Driving Good Profits and True Growth, Harvard Business School Press, 2006). Note that the question doesn’t address the agile process directly–this is because agile is simply a means to deliver better customer value and raise customer satisfaction.
Adaptation
Armed with the results from your qualitative observations and quantitative measurement, you should be in a position to make adjustments to your agile process implementation. Use your personal observations of customer value orientation, individual competence, team size, etc., to make appropriate changes.
The output from value stream maps will indicate areas of process waste that need to be streamlined. Feedback from project reflections provide things that are working well that should be reinforced, and things that are not working well that need to be eliminated or streamlined. Simple process adaptations, like moving the timing of a meeting to allow for uninterrupted work and ensuring customer satisfaction by measuring and improving it based on feedback, can have profound effects on team productivity and process effectiveness. By inspecting and adapting, you can ensure the long term success of your agile initiative.
