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 04/08


In This Issue

  • Repeatable Results over Repeatable Processes
  • Hot Links

Repeatble Results Over Repeatable Processes

In January, 2008, Dr. Dobb's conducted a survey which explored the adoption rate and effectiveness of various process frameworks. The survey ran for a week and was completed by 219 people. One of the issues that we looked into was how people felt about repeatable results compared with repeatable processes. We asked the question twice, once about how the respondent perceived their organization to value these things and once to explore their personal values. Both times respondents could indicate that repeatable processes were most important; that repeatable results were most important; that both were equally important; or that they didn't know. As you would expect we discovered some potential cultural challenges which could be affecting your overall productivity and potentially even staff morale.

Of the 33 people who indicated that they were in IT Management, 16 percent indicated that repeatable processes are most important to their organizations, 48 percent said repeatable results are, and 36 percent said both are equally important. Their personal values differed -- 12 percent, 60 percent, and 28 percent respectively -- with a clear preference for repeatable results. This difference between organizational values and personal may be an indication of a growing shift towards repeatable results within IT departments. Time will tell.

137 respondents indicated that they were in a developer position. When it came to organizational values, 23 percent perceived that repeatable processes are most important, 36 percent thought that repeatable results are most important, and 28 percent thought that both were equally important. Personally, their results were 6 percent, 60 percent, and 32 percent, respectively. The personal preference for repeatable results, when compared to the perception that their organization leans more towards repeatable processes, may be one explanation for why many developers feel that "management" simply doesn't get it. This can have a negative impact on morale and overall developer effectiveness, as well as on your organizations' retention rate. On the other hand it's interesting to note that the personal values of developers and IT managers are fairly close to each other, indicating that it may be easy to reconcile these issues through increased dialog between the two groups.

There were 34 respondents who indicated that they were in the role of project manager. Organizationally they were incredibly consistent -- 31 percent indicated that repeatable processes are most important, 31 percent indicated that repeatable results are, and 31 percent said they are equally important. Their personal preferences didn't change much, voting 28 percent, 34 percent, and 28 percent respectively. Granted, a sample size of 34 isn't very big and therefore we need to take these results with a grain of salt, but the results are worrisome.

  • First, the project management (PM) community has a strong culture around certification, a culture which molds their belief system. Their belief system appears to be different than that of IT Management or of the developer community. In Dr. Dobb's 2007 Project Success Survey we saw a similar pattern, with project managers having measurably different views on what project success actually means.
  • Second, if the a project is out of sync with both the people they report to and the people that report to them, it doesn't bode well for them because they run the risk of making decisions which don't reflect the actual environments that they're working in.

It is interesting to compare the beliefs of people who are working in organizations where there are only agile projects with those where there are only Traditional projects. 23 respondents indicated that their organizations were only doing agile projects whereas 83 respondents indicated that they were only taking a traditional approach. For the agile-only respondents, organizationally 4 percent perceived that repeatable processes are most important, 48 percent said that repeatable results are most important, and 35 percent said that both are equally important. Personally, there was a shift towards repeatable results with ratings of 4 percent, 65 percent, and 21 percent respectively. In traditional organizations the organization perception was 20 percent, 31 percent, and 34 percent respectively and personally 11 percent, 51 percent, and 34 percent respectively. Although the traditional respondents also shifted towards repeatable results, their scores where much lower both times as compared to the agile-only respondents. This greater focus on repeatable results within the agile community may be one explanation for the consistently greater success rates that we've been finding in various Dr. Dobb's surveys over the past few years (and of course in the studies of other people). The 2007 Project Success Survey also showed a preference for concrete results, an indication that the values of agile professionals appears to be better aligned with those of the business community than those of the traditional community. The "agile paradigm shift" appears to be taking us in the right direction.

It's important to remember that there are always trade-offs to be made. Stephen Hunt, a colleague of mine at IBM, points out that there is a potential governance challenge for organizations that are overly focused on repeatable results. The problem is that over time your organization can come to rely on highly skilled individuals to produce these repeatable results and then when these individuals leave you find yourself in trouble. This risk can be mitigated by non-solo development practices such as pair programming and modeling with others, a focus on collaboration, and adoption of just enough process and training around that process. Repeatable results are more important than repeatable processes, but process still has its place in your organization's overall success.

For years the process community, in particular the purveyors of process frameworks such as Capability Maturity Model Integrated (CMMI) or various International Standards Organization (ISO) frameworks, has argued for the importance of repeatable processes. This sounds good in theory, but from a practical point of view it doesn't ring true. With the exception of the PM community, there was a clear preference for repeatable results over repeatable processes regardless of job role or development paradigm. The greater personal preference for repeatable results over repeatable processes tells me that there is a "repeatability elephant" in the room that we should recognize and then address.

Hot Links

You can read the results of the survey, including the original questions as they were asked and the source data.

Dr. Dobb's 2007 Project Success Survey is summarized in "Defining Success", published in the December 2007 issue of Dr. Dobb's Journal and online. Details of the survey are also available.

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

See my Agile@Scale blog.

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

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.