Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Dr. Dobb's Agile Newsletter 01/08


In This Issue

  • Practices for Governing Lean/Agile Projects
  • Hot Links

Practices for Governing Lean/Agile Projects

IT and systems engineering governance establishes chains of responsibility, authority and communication in support of your organization's overall goals and strategies. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. You do this by balancing risk versus return on investment (ROI), setting in place effective processes and practices, defining the direction and goals for the department, and defining the roles that people play with and within the department. Development governance is an important subset of IT and system engineering governance, the scope of which covers the steering of software and system development projects.

If your organization has one or more software or system development projects then you have a development governance process in place. This process may not be explicit, nor may it be effective, but it does exist. Although many organizations have adopted existing governance frameworks, such as COBIT or OPM-3, they often fail to meet their promise because the frameworks are implemented too strictly. The frameworks are viable, but you need to loosen the reins a bit.

I like to compare traditional, command-and-control approaches to governance to herding cats -- you do a bunch of busy work which seems like a great idea in theory, but in the end the cats will ignore your efforts and stay in the room. Yet getting cats out of a room is easy to accomplish, as long as you know what motivates cats. Simply wave some fish in front of their noses and you'll find that you can lead them out of the room with no effort at all. Developers are intellectual workers, and as such don't like to be told what to do or how to do it. Sounds like cats, doesn't it? Rather than telling developers what to do they should instead be motivated to work in the desired manner and be enabled to do so. With a slightly different outlook towards governance you can dramatically increase your chance of success.

Effective governance for lean development isn't about command and control. Instead, the focus is on enabling the right behaviors and practices through collaborative and supportive techniques. It is far more effective to motivate people to do the right thing than it is to try to force them to do so. A lean approach to development governance weaves the philosophies of lean and agile software development into traditional IT governance to form a lightweight, collaboration-based framework that reflects the realities of modern IT organizations.

The Lean Development Governance Framework, created by Per Kroll and myself, is composed of 18 practices:

  1. Adapt the Process. Because teams vary in size, distribution, purpose, criticality, need for oversight, and member skillset, one process size does not fit all. You must tailor the process to meet a team's exact needs. Furthermore, processes must be evaluated and allowed to evolve over time to meet the changing needs of your organization.
  2. Align HR Policies With IT Values. Hiring, retaining, and promoting technical staff requires different strategies compared to non-technical staff. You need to establish specific incentives/rewards appropriate for the mindset of your technical staff to ensure timely delivery as well as other key accomplishments, such as retraining on a new technology.
  3. Align Stakeholder Policies With IT Values. Your development efforts are driven and constrained by your stakeholders. Your stakeholders may not understand the implications of the decisions that they make, for example that requiring an "accurate" estimate at the beginning of a project can dramatically increase project risk instead of decrease it as intended.
  4. Align Team Structure With Architecture. The organization of your project team should reflect the desired architectural structure of the system you are building to streamline the activities of the team. For example, distributed teams are well suited for building architectures; centralized teams are often more adept at building centralized architectures.
  5. Business-Driven Project Pipeline. \ You should invest in the projects that are well-aligned to the business direction, return definable value, and match well with the priorities of the enterprise. This approach implies less focus on "cool technology" and greater focus on supporting the business.
  6. Continuous Improvement. You should strive to identify and act on lessons learned throughout the project, not just at the end. For example, a quick retrospective at the end of each iteration and a more detailed retrospective at critical milestones is a straightforward way to improve as a project progresses.
  7. Continuous Project Monitoring. Automated metrics gathering enables you to monitor projects and thereby identify potential issues so that you can collaborate closely with the project team to resolve problems early. You will also initially need to identify a minimal set of measurements to collect.
  8. Embedded Compliance. It is better to build compliance into your day-to-day process, instead of having a separate compliance process that often results in unnecessary overhead. Automation is critical.
  9. Flexible Architectures. Architectures that are service-oriented, component-based, or object-oriented and implement common architectural and design patterns lend themselves to greater levels of consistency, reuse, enhanceability, and adaptability.
  10. Integrated Lifecycle Environment. You should strive to automate as much of the "drudge work" -- such as metrics gathering and system build -- as possible. Your tools and processes should fit together effectively throughout the lifecycle. An initial investment at the beginning of a project to set up your toolset can pay significant dividends in reduced work effort throughout a project.
  11. Iterative Development. An iterative approach to software delivery allows progressive development and disclosure of software components, with a reduction of overall failure risk, and provides an ability to make fine-grained adjustment and correction with minimal lost time for rework.
  12. Pragmatic Governance Body. Effective governance bodies focus on enabling development teams in a cost-effective and timely manner. They typically have a small core staff with a majority of members being representatives from the governed organizations.
  13. Promote Self-Organizing Teams. The best people for planning work are the ones who are going to do it. IT professionals should be respected as intelligent people who can determine their own strategies for working together. When given a bit of coaching and guidance, they can plan their work within established parameters, such as iteration boundaries.
  14. Risk-Based Milestones. You want to mitigate the risks of your project, in particular business and technical risks, early in the lifecycle. You do this by having throughout your project several milestones that teams work toward. The goal of each milestone is to address one or more risks, such as the Lifecycle Architecture (LCA) milestone in the Rational Unified Process (RUP) that requires your architecture be proven through working code before Construction begins.
  15. Scenario-Driven Development. The whole cannot be defined without understanding the parts, and the parts cannot be defined in detail without understanding the whole. By taking a scenario-driven approach, you can understand how people will actually use your system, thereby enabling you to build something that meets their actual needs.
  16. Simple and Relevant Metrics. You should automate metrics collection as much as possible, minimize the number of metrics collected, and know why you're collecting them.
  17. Staged Program Delivery. Programs, which are collections of related projects, should be rolled out in increments over time. Instead of holding back a release to wait for a subproject, each individual subprojects must sign up to predetermined release date. If the subproject misses it skips to the next release, minimizing the impact to the customers of the program.
  18. Valued Corporate Assets. Guidance, such as programming guidelines or database design conventions, and reusable assets such as frameworks and components, will be adopted if they are perceived to add value to developers. You want to make it as easy as possible for developers to comply to, and more importantly take advantage of, your corporate IT infrastructure.

Development governance isn't a sexy topic, but it critical to the success of any IT department. When we leave governance to the bureaucrats, and unfortunately they're eager to do the work, we shouldn't be surprised when we end up with a bureaucratic governance process. Instead, if we focus on high-value activities, on making it as easy as possible for developers to do the right thing, to help instead of hinder development teams, then we create a practical and realistic governance process which people will actually follow.

Hot Links

My November 2007 Dr. Dobb's Agile Newsletter column Governing Agile Software Development shows how Agile projects prove to be far easier to govern in practice that traditional projects.

Per Kroll and I have written a IBM whitepaper entitled Lean Development Governance that is oriented towards senior managers which goes into greater detail into the overall framework.

Last summer we published a series of three articles which go into the practices in detail.

The Agile Alliance homepage is the best starting point for anyone interested in

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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.