The Death of Process as a Product

And_you_do_the_cokey_cokey

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?

Comments

re: The Death of Process as a Product

Great posting!One of the things I discuss a lot at my site (through the use of cartoons) is what the "dogma" of Scrum talks about and what happens in reality.As with any process you roll out, make sure it is right for your environment and team and do not become a slave to the process for the sake of just using a process.Make sense?Remember.What is the goal of almost all agile software development processes (or frameworks or methodologies)?Working software.And.Delivering value to the customer.However they define it.

re: The Death of Process as a Product

You hit the nail on the head. Wham! But you bent it. Why do you think issues with process only relate to software development? I suggest we need to talk about 'THE DEATH OF PROCESS', period. Therefore we also need to talk about the 'death of (hard-)coding' for business software. Why?Our process-illusion has a psychological reason. Our memory does not work with images as many believe but with sequential experiences. Long-term memory works by creating emotional bookmarks in such memory sequences. That leads humans to believe that defining a process is the solution to do things correctly. For situations where ONE person does something complex that has to produce repeatedly the same result process is fine. Linking process pieces together may work also fine for manufacturing. In all other situations that involve human interaction and creativity, process is absolute nonsense. Why would you restrain people by a straight jacket if we want them to be 'agile'. Arrrgh! How I hate that stupid word.Creating something that people find useful and makes them more productive is certainly not related to taking away people's initiative and restraining their intuition. So we can dump development processes just as we can dump BPM!!! We need defined goals, some milestones, test scenarios, a way to keep track of all the pieces, a meta-data, process and content repository (not an archive!) to manage life-cycle and deployment, as little coding as possible, an iterative, adaptive approach, where IT delivers a first version, business starts to work with it and then new features and improvements are delivered for example biweekly.Business users need a collaborative environment that puts all business data and content into customer focused process (I prefer case) context, authorizes users, secures data, tracks progress and enables auditing. What else do you need? Why are we hard-coding all this nonsense business processes with GUIs that need weeks of training???If we take this direction then software development processes become irrelevant!

re: The Death of Process as a Product

great post,a very similar message to what I have been delivering to my clients.Processes, methodology, roles and responsibilities, etc. can all be valuable on a project. But people who are responsible for actually doing project work need to be empowered to decide which tools are appropriate for their specific situation.I have found that a good balance between complete choice in some form of centralized standardization is to frame a set of common principles and best practices that all projects to follow, support these with a number of pattern oriented guidelines and standards. Finally, allow project teams to decide which guidelines to follow, and which to invent...I have spoken a little bit more about thisat http://agileconsulting.blogspot.com/2008/01/sdlc-guiding-principles.html