In This Issue
- Best Practices for Governing Agile Project Teams
- Hot Links
Best Practices for Governing Agile Project Teams
Agile approaches to software development are quickly becoming the norm, probably because recent surveys show Agile teams to be more successful than traditional teams. Our Agile Adoption Survey, summarized in the August 2007 issue of Dr. Dobb's Journal, revealed that 69 percent of organizations surveyed had one or more Agile projects underway. Our Project Success survey, which will be summarized in the December 2007 issue of Dr. Dobb's Journal and be online the first week of November, showed that Agile teams had a 72 percent success rate compared to 63 percent for traditional teams. As organizations gain experience with Agile approaches they are asking serious questions about Agile software development, including how you can govern Agile projects effectively.
IT governance establishes chains of responsibility, authority and communication in support of the overall enterprise goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. The goals are to balance risk versus return on investment (ROI), set in place effective processes and practices, define the direction and goals for your IT department, and define the roles that people take.
The good news is that Agile projects are far easier to govern in practice than traditional projects. In my column Governing Agile Software Development (Dr. Dobb's Journal, November 2007), I describe in detail how the regular delivery of working software provides a true measure of the earned value being delivered by Agile project teams. I also describe how stakeholders have control over the budget, scope, and schedule of an Agile team. These greater levels of visibility and control provided to business stakeholders enable them to govern Agile teams far more easily than they can traditional teams.
Over the summer Per Kroll (coauthor with Bruce MacIsaac of Agility and Discipline Made Easy; Addison Wesley, 2006) and I wrote a three-article series describing best practices for a lean approach to governing software development:
- Best Practices for Lean Development Governance: Principles and Organization
- Best Practices for Lean Development Governance: Processes and Measures
- Best Practices for Lean Development Governance: Roles and Policies
Traditional governance often focuses on explicit command-and-control strategies. Although valid and effective in some situations, this approach can be like herding cats for many organizations. Much work is put into establishing the governance framework and managing the governance effort, but very little is achieved in practice. Lean governance, on the other hand, focuses on collaborative strategies that strive to enable and motivate team members implicitly. For example, the traditional approach to coding guidelines would be to create them and then enforce their usage through formal inspections. The lean approach would be to write the guidelines collaboratively with your programmers, explain why it's important for everyone to adopt the guidelines, and then provide tooling and support to make it as easy as possible for developers to continuously code within those guidelines.
Successful development governance focuses on enabling the right behaviors and the best practices through collaborative and supportive techniques. It proves to be far more effective to motivate people to do the right thing instead of forcing them to do so. The 18 practices we identified for lean development governance reflect the realities of software development today are:
- Align human resources (HR) polices with IT values. Hiring, retaining, and promoting technical staff requires different strategies than non-technical staff. A common HR process will not be effective for all staff members.
- Align stakeholder policies with IT values. Business stakeholder policies, such as requiring a detailed estimate early in a project lifecycle, can severely limit your ability to work effectively and will often increase overall project risk. Educate your stakeholders on the implications of their decisions and motivate them to act accordingly.
- Align team structure with architecture. Conway's Law tells us that your project team structure will affect the structure of your system architecture. For example, distributed teams motivate you to have partitioned architectures.
- Business-driven project pipeline. Invest in the projects that make the most sense from a strategic and return on investment (ROI) point of view.
- Continuous improvement. Your process must evolve over time to reflect lessons learned and changes to your situation.
- Continuous project monitoring. Use automated metrics to monitor projects, recognizing that you can't manage by the numbers and that instead metrics are merely warning signs telling you that you need to go and work with the team directly.
- Embedded compliance. Build compliance into your day-to-day process, automating as much as possible. Separate compliance processes causes unnecessary overhead and increase the chance of inconsistency.
- Flexible architectures. Your system architectures must be flexible to support your business in a timely and effective manner. SOA, components, objects, patterns, and so on lead to greater levels of consistency, reuse, enhancability, and adaptability when implemented effectively.
- Integrated lifecycle environment. Automate as much of the drudge work as possible, tools and processes should fit together effectively throughout the lifecycle.
- Iterative development. Reduce delivery risk by building a system in time-boxes, not as a single-big bang effort.
- Pragmatic governance body. This team adopts cost effective techniques which focus on enabling development teams, not controlling them.
- Adapt the process. Because one process size does not fit all you must tailor the process to meet a team's exact needs.
- Promote self-organizing teams. IT professionals are intelligent people who, given the right coaching, can determine their own strategies for working within established parameters (such as iteration boundaries).
- Risk-based milestones. Address business and technical risk explicitly early in the lifecycle.
- Scenario-driven development. A given system may support several business processes or portions thereof. To effectively manage your overall IT portfolio you need to understand the business processes which your IT department is striving to support, and allow this understanding to drive your decisions.
- Simple and relevant metrics. Have a small handful of metrics which you collect, know why you're collecting them, and act on them appropriately.
- Staged program delivery. Roll out the program in increments where subprojects must sign up to release date. If a subproject misses the release date it waits for a future release, minimizing overall impact to customers.
- Valued IT assets. People will follow guidance, reuse assets, and conform to common infrastructure because these things add value, not because they're forced to do so.
If your organization has one or more IT projects then it has an IT governance process in place. This process may not be explicit, nor may it be effective, but it does exist. If you let the bureaucrats define your governance process then you will very likely end up with a bureaucratic approach. Is that what you really want? Personally I'd rather have an effective governance process which is lean and agile, wouldn't you?
Hot Links
The three-part series of articles "Best Practices for Lean Development Governance" written by Per Kroll and myself are found at www.ibm.com/developerworks/rational/library/jun07/kroll/, www.ibm.com/developerworks/rational/library/jul07/kroll_ambler/, and www.ibm.com/developerworks/rational/library/aug07/ambler_kroll/.
The article Survey Says... Agile Has Crossed the Chasm summarizes the results of the 2007 Dr. Dobb's Agile Adoption Survey.
The article Governing Agile Software Development shows how Agile projects prove to be far easier to govern in practice that traditional projects.
The Discipline of Agile. The greater level of discipline exhibited by Agile teams which results in higher quality end products, better software economics, and greater visibility provided to business stakeholders.
"Success Rates of Software Development Projects" coming up in the December 2007 issue of Dr. Dobb's Journal explores how organizations define project success, apparently "on time and on budget" isn't as important as we've been led to believe. It also compares the success rates of Agile, traditional, data warehouse, and offshore projects, finding that Agile project teams lead the way.
Agile on a Fixed Budget provides strategies for taking an agile approach to development even when the budget, schedule, and or scope is constrained.
The article Agile Model Driven Development (AMDD) overviews strategies for scaling agile software development via effective modeling and documentation.
The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.
The Agile Models Distilled page provides links to overviews of a wide variety of models.
The Principles of Agile Modeling v2 are described here.
The practices of Agile Modeling v2 are described here.
Check out the Agile Modeling mailing list here.
Scott is Practice Leader Agile Development, IBM Rational
