The death of process as a product

Share

During the last six weeks we have been researching the state of software development processes and a number of very interesting trends have become apparent.

These trends and the results of our research will be documented in the research report Best Practices In Software Development Processes slated for Q1 2009. But I just couldn’t wait to share some of the insights and get your reactions to them before then.

Hybrid Processes take the floor

One interesting trend is the number of development leaders saying that they are not following Scrum or RUP, but instead talking about their process as a hybrid. Examples include Scrum and XP, RUP and Scrum and perhaps the most surprising DODAF and Scrum! Traditionally customization has always been a tricky job with organizations finding it hard to decide which process element to include and how these very different processes fit together.

Process power to the people doing the work

So what has changed? Have organizations suddenly discovered the DNA of process and now can transplant X bit of one process to a Y bit of another process? Our research seems not to indicate that. Organizations are not trying to develop the perfect hybrid process, but instead leaving it to the development teams to select the bits that work for them from either experience or from the latest agile / lean method.

Instead of focusing on building a perfect process and then getting all the teams to follow it, organizations are focusing on making teams more educated and process aware. The process police seem to be changing from enforcement to enablement. Here is my first pass at a three step guide to enabling practical process implementation;

  • Empower teams to make process decisions – By giving teams the power to decide on the process they are going to follow, that process is much more likely to succeed.
  • Educate teams on what they need to do to be compliant – Instead of hiding compliance behind a wall of process steps and artifacts, educate the team on what they need to do, when, to ensure that the project conforms to the company compliance steps.
  • Enable teams to learn new processes and techniques – By encouraging a culture of continuous improvement teams are continually looking for new and improved ways to make do their work.

But with ownership comes risk

As with any change there comes a set of risks. By putting process power with the development teams mistakes may be made with time being wasted doing things that are not really valuable or activities being undertaken poorly.

I encountered a number of war stories with customers starting a project and finding half way through that they really should have undertaken some work up front in the area of architecture or requirements and now are missing a key aspect of the system. In the case of these customers they highlighted two things for resolving these issues.

Firstly having experienced people on the team. These may be outside consultants or internal experienced practitioners.

The second tip was in the area of software development lifecycle with the implementation of a light SDLC, which describes a series of milestones and key events that must happen on all projects, but does not prescribe all the activities necessary to deliver those milestones.

Another concern was highlighted by the management concerning productivity and efficiency of the teams. Allowing the team an almost free hand in the work they undertake could lead to very inefficient processes. You would have to address this with a set of measures being put in place that encourage efficiency whilst promoting ownership.

I would love to hear your feedback around the idea that the religion of process is going away and being replaced with empowered, educated and enabled teams who consider they can change the way they work. What are you finding?

 
#renderView(view="/XSiteincludes/coldbox-views/tracking/twitter", args={ident="nvk5o"})# #renderView(view="/XSiteincludes/coldbox-views/tracking/linkedin", args={id="116509"})#