Channels ▼
RSS

Design

Dr. Dobb's Agile Update 10/08


In This Issue:

  • Why Developers Should Demand Effective IT Governance
  • Book Review: Thinking From A To Z
  • Hot Links

Why Developers Should Demand Effective IT Governance (Yet Have Little Hope of Getting It)

IT governance, also referred to as systems engineering 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. Your governance effort should balance 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 your IT department.

It is important to recognize that governance and management are two different things. Governance looks at an organization from the outside, treating it as a system that needs to have the appropriate structure and processes in place to provide a stream of value. Management, on the other hand, is inside the organization and ensures that the structure and processes are implemented effectively.

Still awake? IT governance isn't exactly the sexiest topic in the world, but it's absolutely critical to our success as IT professionals and it's unfortunately something that we struggle with as an industry. My experience is that many IT governance efforts suffer from too much overhead, an unfortunate aspect of governance is that it attracts people who mistakenly believe that bureaucracy is rigor, and who as a result very often take a command-and-control approach. The former reduces the effectiveness of your organization and the latter proves to be the least effective approach to organizing intellectual work such as software development. But at least the bureaucrats among us feel good about themselves.

Is it any wonder that developers show little interest in governance? Although traditional approaches to governance are based on noble goals, they are just not getting the job done. We need to rethink our governance strategy: instead of basing it on what the bureaucrats want to do we instead adopt an approach which reflects the actual behavior patterns of developers. In the companies where I've seen good IT governance, it has focused on organic concepts such as enablement, making it as easy as possible for people to do the right things, and difficult to do the wrong things. It's also focused on motivation, making people aware of what the right things are, what the wrong things are, and the implications of their actions. Finally, good IT governance is based on self organization, the pushing of decision rights and authorities, including planning, into the hands of the people doing the work.

Governance should be based on trust and respect, but that doesn't mean that you should be nave: you still need to verify that the right things are happening by monitoring people's activities. Effective governance can only occur when you have honest and accurate status reporting, something that is difficult to achieve in traditional IT environments. Few status reports include the "juicy bits" that indicate what is really happening on projects, and even if they initial reports do that detail is typically lost as the status information "green shifts" up your reporting chain. The challenge is that traditional/waterfall projects are opaque to management, the primary strategy for updating management is through status reporting, and status reports rarely include the juicy bits of information about projects. A better approach, taken by agile projects, is to produce working software on a regular basis and thereby provide concrete evidence of progress. You can take this one step further by generating status information based on the actual activities of the people on the team. These automated metrics, generated by integrated toolsets, provide accurate real-time status which enables management to make fact-based decisions.

A live example of such reporting can be found online at www.jazz.net for the IBM Rational Team Concert (RTC) product, an Eclipse-based development tool for distributed agile teams. Headed up by Erich Gamma, of design patterns fame, the team is taking a commercial open source approach to development and as a result their current status is publicly available for all to see. RTC's project dashboard technology is used to display the current status of the team, including their work item stack (product backlog), burn down charts, build history, and much more. With key information such as this, on top of demos of the current version of the software, management knows exactly what is going on. You're certainly not going to get information of this quality from manually written status reports, at least not easily, and you'll still run the risk that the team doesn't convey the complete picture.

Effective IT governance is important for everyone involved with IT. First, it is important for developers because it can enable you to focus on the important activities which add true value and to avoid activities which do not. Second, it is important to operations and support professionals because it motivates development teams to focus on quality, something that disciplined agile teams already do, and because it increases the chance that development teams will leverage the existing infrastructure and not create yet another silo application. Third, it is important for management because it enables them to accurately identify which teams are doing good work and which are struggling. This puts them in a position where they can share lessons learned from successful teams and provide coherent leadership for the teams that need it. Fourth, effective IT governance enables senior IT management to actually lead their organizations effectively.

Most IT governance efforts are sadly doomed to failure. Most governance efforts are driven by bureaucrats who are overly focused on paperwork instead of practitioners who are focused on value, resulting in overly complex strategies with too much manual effort. They also have a tendency to adopt command-and-control strategies, they're in charge after all, instead of the organic strategies which reflect the realities of intellectual work. Furthermore, IT governance efforts will likely run into trouble if you treat them like a program because you implicitly tell the people being governed that it's an add-on effort which could easily be ignored by them given the right reasons. Considering that Dr. Dobb's 2006 Data Management Survey found that it was practice for close to two-thirds of development teams to ignore their internal data groups, it is clearly a very real danger that they will also ignore their internal IT governance efforts too. A better strategy is to embed good governance practices into your culture through education, leadership, and automation.

Given the opportunity, the knowledge, and the proper tools, my experience is that developers will adopt disciplined strategies which achieve the actual goals of your organization. This is particularly true when you show them respect and allow them to self organize within a decision rights framework which reflect the realities of your situation. Self organization doesn't mean anarchy, it means that authority is pushed down your organizational hierarchy into the hands of the people with the skills and knowledge to make the right decisions. Many managers are threatened by this concept, believing that their staff doesn't have the ability to plan their own work. But if they have the skills to do the work, surely it must be a rather straightforward task to help them gain basic planning skills? Management still needs to monitor the work and provide leadership -- in other word they should trust but verify.

Book Review

Thinking from A to Z Third Edition
Nigel Warburton
Routledge 2007

At Dr. Dobb's Architecture and Design World conference in Chicago this summer, I sat in on an architecture skills presentation by Rebecca Wirfs-Brock. During the presentation she highly recommended Nigel Warburton's Thinking from A to ZThird Edition as a great source of information about critical thinking skills, one that she had been using for years. So I bought it, read it, and have come to the same conclusion: It's a valuable resource for software developers.

The book is small and short, 164 pages in pocket-book format, making it a quick read. Better yet it's written as a reference book, organized as a collection of ideas each of which are usually described in a few short paragraphs. Some ideas are concise descriptions of concepts, such as what is empirical thinking or a rhetorical question. Other ideas, such as drawing a line and knock-down argument are closer to patterns. Just as important are concepts that are similar to anti-patterns such as democratic fallacy and inappropriate precision. I found the book to be perfect airplane reading and definitely gained some insights which I have already put into practice.

Critical thinking is an important part of the job for IT professionals, particularly anyone involved with modeling, so this book will prove to be a valuable edition to your bookshelf.

Hot Links

The IBM whitepaper Lean Development Governance by myself and Per Kroll overviews a collection of practice for effective governance of development projects

Operational IT Governance by Cantor, M. and Sanders, J.D. (2007). Rational Edge May 2007.

The Green Shift Anti-PatternDr. Dobb's Agile Newsletter, July 2006

My November 2006 Dr. Dobb's column Whence Data Management?, I summarize the results of Dr. Dobb's 2006 Data Management Survey where we explored the effectiveness of internal data management efforts

The Enterprise Unified Process (EUP) describes how to extend the software development lifecycle to address the full lifecycle of a system and how to apply agile strategies to enterprise-level issues.

My September 2008 Dr. Dobb's column Iteration Negative One describes the portfolio management efforts which occur before the "start" of a software development project to select the right projects and get initial funding for them.

My Agility@Scale blog discusses strategies for adopting and applying agile strategies in the complex environments.


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.
 

Video