Process Rarely Fixes The Problem

Over the past week, there has been an interesting thread being talked about in software development. It started with a blog post by Ted Neward where he quoted Billy Hollis as saying:

Agile is treating the symptoms, not the disease.

Here, the agile being talked about is a reference to agile software development processes. Agile processes help manage the software development lifecycle, as well as managing what features should be in a project and managing expectations. These are good things, but it does not address the real problems in software development. Now, please stay with me as I am using this software development example to refer to a larger point.

Returning to Ted’s post, he summarizes his feelings very well in this one quote:

How does an agile process reduce the complexity load? And the answer, of course, is that it doesn’t—it simply tries to muddle through as best it can, by doing all of the things that developers need to be doing: gathering as much feedback from every corner of their world as they can, through tests, customer interaction, and frequent releases. All of which is good … But agile is not going to reduce the technology complexity load, which is the root cause of the problem.

Agile processes have been adopted by many development teams around the world. The processes do help in the long term, but the basic idea is that we are still just managing risk. Agile processes highlight the issues developers may be facing as well as quickly identifying any delays in the schedule. This is still risk management. The question is not how do we manage risk better (though that is still a good question), the real question is how do we remove risk.

Finally, I get to the point, but I am going to continue my software development examples. In any business, people will fail at various aspects of their job. Usually, this becomes a problem as more failures occur. At some point, a process is created to ensure that we know when a failure occurred, instead of finding out at the deadline. This is more of an issue with new concepts, software development being fairly new compared to engineering disciplines, and new technologies. For example, look at social media and its effects on marketing and feedback. Many companies are undertaking new “social media marketing” campaigns. Typically, they create a hopefully viral video and post it on YouTube. Then they share a link on Twitter and post a note on a Facebook page. Maybe they even get a PR firm to email a bunch of bloggers about this cool new viral video. Lastly, they sit back and wait for the sales to increase.

In this example, there is a boatload of risk and absolutely no management of that risk. Now, companies are looking into social media monitoring tools to start managing the risk, with risk being a huge number of negative comments on YouTube, Twitter and Facebook. In other cases, companies manage risk by moving in the opposite direction, shutting down their social media efforts, but failing to realize that the risk is already there because the people are there. Social media monitoring helps you identify failure or success much quicker than before, but it is just a process that tries to manage risk. Again, the process rarely fixes the problem.

So, how do we eliminate or reduce risk? Simplification. If we look at a follow-up post by Ted Neward, he looks at this from a different angle.

Why can’t end-users create tools of their own to solve their own problems at a scale appropriate to their local problem? … End users have just as much a desire and right to be amateur software developers as we do at being amateur cooks, photographers, poets, construction foremen, and musicians. And what do you do when you want to add an addition to your house instead of just building a doghouse? Or when you want to cook for several hundred people instead of just your family? You hire a professional, and let them do the project professionally.

Basically, if the problem is really too big for you to handle, you can minimize risk not by managing it, but by hiring people who do that for a living. Hopefully they are more experienced than you or have more expertise in the particular niche where your problem lies. This transfers the risk from yourself to the consultant.

There is another approach which has wider reaching affects, and that is simplifying the tools. Ted has a great quote from the first post mentioned, “Where is this decade’s Access?” Access is the database program in Microsoft Office that allowed users to create a form based application to store your data. In the 1990s, lots of people were creating little applications for their department to use. Sometimes these applications would later be absorbed by a larger corporate data warehousing strategy or they were converted to a small web application on the company’s intranet.

In terms of the departmental applications, we are seeing their equivalent in offerings like SharePoint and Google Sites. Granted, the development tools to create even form based applications are still too technical for normal users, these applications get users much closer to a local Access application. However, for larger web applications there is not a simple tool to help you get started. Ted uses the example of what a new Java programmer needs to learn in order to be productive in today’s web applications. He outlines a 5-week training program that is fairly limited in its scope compared to some applications.

This is the kind of thing that happens when people do not address the problem, but only address the symptoms. For the Java developer example, some people would say, use a framework like Spring. Even then, things may be simpler, but are they really simple enough? Why can’t we create an application like we put together a puzzle? Why do we need one application to post our video online, another to monitor the reactions, a third to send emails to various bloggers, and another that let’s us reply to people on Facebook and Twitter? A process will not fix this problem, it will only address the symptoms.

5 thoughts on “Process Rarely Fixes The Problem

  1. While I heartily agree that a process or a tool (Agile, Twitter, whatever) is not a solution to a problem, I’m not quite convinced that one can sign on to a platform of eliminating risk. Perhaps the word “eliminating” is an exaggeration, but even if one is talking about a massive reduction in risk, that can’t happen either.

    Let me share an example. Let’s say that an organization faces the risk of its message not being heard. Now you can simplify the creation of communications by using ready-made tools such as Blogger or WordPress. Now you have simplified your tools and provided a way to get your message out…but your competitors have access to that same tool. Louis Gray just noted that there are ten million content creators on Blogger alone. So risk hasn’t been dramatically reduced by simplification – if anything, the risk that your message won’t be heard has increased.

    And even if an organization simplifies via a proprietary technology that is not accessible to its competitors, such simplification comes at a cost. The people or financial resources who simplified the tool are people/resources who couldn’t work on something else, thus increasing other risks of the firm.

    Risk can be redistributed, but I’m not certain that it can be dramatically reduced.


  2. John

    You make some very good points. When I was writing the post I was trying to not focus on software development which was a mistake.

    In your example, you say that using a tool like Blogger makes it easier to get your message out, but competitors also have access to the same tools. Therefore, you still risk not being heard. That is closer to the point I am trying to make. A blog does not get you heard, a blog that is shared bunches of times on Facebook, Twitter and FriendFeed gets you heard. How do you simplify that process?

    Coming from the business angle you present, a custom solution to this type of problem does cost money. If the costs associated with the tools is of greater risk, then you have just transferred the risk. I agree with that, and in that case you really have not solved the problem, you just made the problem someone else’s.

    I may have to write another post on this that focuses on the tools that need to be created to make things simpler.

    Thanks for the excellent comment!


  3. Rob, interesting post… This post really catches my interest as I make my living identifying need in business and applying a process to successfully scale that process (given it aligns with and/or supports the offerings of the business).

    As with all things, when taken to extremes first create problems and then become the problem themselves; why do you think large corporations are so often held up as examples of soulless and following the letter of the law (instead of spirit). It’s because they have allowed process to overgrow the foundational reason for the process in the first place.

    Process is intended to mitigate risk. In this you are certainly correct. It is also to shore up delivery of the product or service to the customer. All of this aside, I have always believed the Agile model to help development teams cope with all of the multiple injection points solicitations will come from in today’s business environment, and the increase the speed to [accurate] delivery – or reduce exposure to a missed feature, which can be built in more quickly.

    So I agree that process is not a “fix” for a problem. However, did you realize that the word problem originates from 2 words in Latin which could be translated to mean, “to throw forward”. One interpretation of this might be that we place the “problem” in front of us for all to see and observe; thus if we see the issue we can accurately identify it, or so the hope would go.

    Perhaps the problem is not the application of process, or even simplification itself. Perhaps the resolution to our problem might just be perspective. After all, if in your example the company spent the time building relationship with its customers instead of trying to force some video to go viral wouldn’t that build trust for a long term community of clients? The proper perspective applied would certainly show us how our clients respond best.

    Of course, as a prospective customer, I might have the perspective this company was simply out for a quick hit – and might not be around tomorrow. That does make my decision much more simple!

    Warmest Regards,
    Ken Stewart


Comments are closed.