In This Issue
- Governing Agile Development Teams
- Hot Links
Governing Agile Development Teams
From some of the discussions in agile forums it seems sometimes that "governance" is a dirty word. I suspect that this is because many agile developers perceive IT governance as being ineffective if not downright harmful. This attitude should come as no surprise: The Dr. Dobb's November 2009 State of the IT Union survey found that only 11 percent of respondents worked in organizations where agile teams had benefitted from their IT governance efforts. Yikes. As I've argued before in previous newsletters, not only is it possible to govern agile project teams effectively it is also easier to do so because of the greater visibility and control provided to project stakeholders. The challenge, however, is for the stakeholders to recognize that they have such visibility and control and to take advantage of these new opportunities wisely. That's the topic of this article.
IT governance addresses the issues of accountability, responsibility, and tying IT activities into the overall activities and goals of an organization. IT governance is often organized into several sub-domains: Data governance, which focuses on the operations and evolution of your organization's data/information; Technology governance strategies, such as SOA governance or Cloud Computing governance, which focuses on operation and evolution of a specific category of technology within your organization; Development/delivery governance, which focuses on overseeing and guiding development/delivery projects; and operational governance which focuses on the operation and support of existing IT solutions. There are more aspects to IT governance than what I've listed, but these aspects are representative of the scope of the effort. It's my experience that your governance sub-domains strategies must reflect your overall IT governance strategy, and vice versa, in order to be successful -- the last thing you want is your data governance strategy to undermine your SOA governance strategy, for example.
There are several reasons why existing IT governance programs may not work well for agile software development projects:
- Paradigm mismatch. Many IT governance programs are based on a "command-and-control" strategy which often is reflects a lack of respect between stakeholders and IT teams. Agile software development is based on self-organization, collaboration, and trust-based relationships.
- Scope mismatch. Because IT is broad IT governance is also broad, addressing governance of solution delivery projects, operations and support of the solutions, and cross solution issues such as portfolio management, enterprise architecture, and strategic reuse (to name a few). This broadness may account for some of the impedance mismatch between typical IT governance efforts and the more narrowly focused view of agile software development teams.
- Vision mismatch. When there isn't a common understanding of the goals of IT governance, when there isn't an agreed to strategy, then disparate strategies are likely to be introduced in the governance sub-domains.
The list of challenges leads to interesting implications for succeeding at agile governance. For agile governance to be effective, the governance paradigm must reflect the agile development paradigm, agilists must recognize and appreciate the larger scale of the issues which IT governance must address, and your agile governance strategies must reflect the overall IT governance vision. So how do you go about doing these things?
Let's start with aligning the paradigms. For the most part, this is going to require management to rethink their approach and adopt more flexible and collaborative strategies. Here is a critical observation for IT governance: IT professionals are intellectual workers. As such they don't respond well to being told what to do, but they do respond well to motivation. The implication is that at a minimum IT governance must be based on motivating IT professionals to "do the right thing" instead of telling them to do the right thing. Better yet it should be on enabling them to do so by making it as easy as possible for people to exhibit the behavior desired by your organization instead of trying to "inspect/review" this behavior into the process. The desirable behaviors of IT professionals often includes working to a common technical infrastructure (thereby reducing cost), working towards a common business vision for your enterprise (hopefully leading to greater profits), and following common technical conventions (thereby increasing consistency and thus quality and maintainability).
Motivation and enablement isn't going to get the job done, senior management should monitor IT teams to ensure that their activities reflect the overall goals of your organization. This is important because senior management can guide the team through complex issues which are beyond the scope and ability of the team lead/ScrumMaster and Product Owner to address by themselves. Sadly, many IT professionals view IT managers as "pointy-haired" bosses that make poor if not down-right stupid decisions. My observation is that very often managers are in fact intelligent people who are making decisions based on the best information they have available to them at the time. With better information in their hands they are likely to make better decisions, which in turn should make life easier for the people in the trenches.
To address the scope and mismatch issues the required change is mostly on the agile side of the equation. Agile methods should strive to optimize the whole, not just sub-optimize on construction or delivery. To do this we need to recognize and appreciate the issues pertaining to IT, and even the business as a whole. We need to work closely with people who have a much wider view of the enterprise, particularly enterprise architects, portfolio managers, operations staff, and even data management professionals to ensure that what the agile team is doing truly reflects the overall priorities of the organization. Too many agile teams are building high-quality silo applications, which is better than building low-quality silo applications I suppose, but what they really need to be doing is building high-quality enterprise-class applications and the only way to do so is to take enterprise considerations into account throughout the delivery lifecycle.
The How Agile Are You? 2010 Survey, which I ran during the last week of July 2010 and the first week of August, explored many of the issues pertaining to agile solution delivery and governance. There were 293 respondents, 33 percent indicated that they were programmers or agile team members and 39 percent were managers or team lead/Scrum Masters. 64 percent had 10+ years in IT, 15 percent worked in organizations with 500 or more IT people, 39 percent lived in North America, 29 percent in Europe, and 12 percent in Asia-Pacific countries. A link to the survey was posted on my IT Surveys home page at www.ambysoft.com/surveys/, announced on my Twitter feed, my mailing list (firstname.lastname@example.org), the Agile Alliance discussion group on LinkedIn, and the Yahoo discussion groups for test driven development (TDD), agile modeling, and agile databases. As usual, this is an open survey in that you can download the source data, the original questions, and a summary slide deck free of charge from my IT Surveys home page at http://www.ambysoft.com/surveys/.
The good news is that agile development methods such as Extreme Programming (XP) and Scrum include some inherent governance strategies such as iteration demos (called sprint demos in Scrum) and daily stand-up meetings (called scrum meetings in Scrum). The demos are important to communicate how much progress the project team has made by showing key stakeholders what the team accomplished since the last demo, providing visibility into the project and enabling them to steer accordingly. The survey found that of the people claiming to be on an agile team, 79 percent indicated that they do a demo to stakeholders at the end of each iteration. The daily meetings are primarily for coordination within the team and 77 percent of respondents indicated they were in fact doing such meetings. The culture within the agile community is that anyone interested in team status, including senior managers, are welcome to attend and listen in. Sadly, this appears to be more rhetoric than reality because only 31 percent of respondents indicated that a senior manager attended their daily stand up meetings to get a status update at least once a week.
But what about other strategies to monitor the success of agile project teams? According to the survey, 42 percent indicated that they do "all hands" demos every so often to show a wider group of stakeholders what they've built to date. Such demos are a great way to let people know that your team is making progress and to validate that your product owner truly represents the full stakeholder community. Interestingly, 46 percent of people claiming to be on agile teams indicated that they produce a status report at least once an iteration for senior management and 39 percent indicated that they were using development tools such as Rational Team Concert (RTC) which are instrumented so as to populate a project reporting dashboard to automatically provide status information. Although many respondents indicated that they provided information to senior management in at least one of the aforementioned ways, only 40 percent of them felt that senior management used that status information to help their team succeed. The implication is that although many opportunities exist for senior management to monitor project teams, and apparently they do, that they aren't perceived as leveraging that information effectively.
This begs the question whether agile teams are leveraging the resources available to them. Of the respondents claiming to be on agile teams, 59 percent indicated that their organization has development standards (such as programming standards, data conventions, and user interface conventions) but only 82 percent (of the 59 percent) actually followed those development standards as appropriate. Similarly, 54 percent of agile respondents indicated that their organization has identified a common technical infrastructure and 74 percent (of the 54 percent) will leverage that common technical infrastructure. The implication is that if your organization puts development standards in place, or introduces common technical infrastructure to reuse then there's a good chance that agile teams will leverage these assets.
In the past I've written that it is not only possible to govern agile teams it is much easier to do so than traditional teams. The recent How Agile Are You? survey shows that some organizations are in fact governing their agile teams effectively but there is clearly room for improvement. My advice is for organizations to rework their approaches to IT governance to make them based on collaboration, motivation, and enablement instead of on command-and-control. Disciplined agile delivery teams are not just self organizing, then are self organizing within an appropriate governance framework.