Processes Do Not Fail, People Do
I was recently looking at Google Analytics
and the data for this blog. For whatever reason, I was only looking at a
two day span in the recent past, and I was focused on search keywords.
One search caught my attention because it was short and was not one of
the typical searches in this blog’s top ten, “scrum failed”. Obviously, I
wanted to understand how people go to the blog, and this search pointed
to a post from mid-summer about companies being anti-agile. In particular, Google
was highlighting the following quote:
I have seen this practiced at two organizations where Scrum had failed previously and the company was definitely hostile to agile methods.
Granted this quote looks like I am saying that Scrum, the process, had failed, but what is actually meant is that the projects using Scrum had failed. In general, software development processes do not fail on their own. If they did, then they would never gain popularity. Even in the case of the Waterfall model, a great team can make the process work and in theory the process does work. I am a firm believer that most SDLC models are actually the waterfall model, just with shorter project durations. If you look at Scrum, you have the product backlog to determine what features you want to work on, and you select these features during your planning phase, or the sprint planning meeting. Please note that I am not an agile zealot so my terminology may not match the process definitions exactly, but you probably will know what I am talking about. Once the features are selected, the developers will likely ask the business analyst, a.k.a the customer, for clarification of the details of the feature (the analysis phase) before starting development. Once a feature is completed, it can be tested, hopefully approved and deployed. With Scrum, you are still going through the full SDLC just in micro-phases. The benefits of the quick feedback loop have been demonstrated in various studies for various processes.
The problem in some cases is that a company may be hostile to certain
practices within your adopted process. For example, your company may
not be able to support a full-time customer for your agile project. Or
your company still has worries about the productivity of pair
programming. In many cases, these projects may fail and the company will
decide that their agile process failed. In my agile zealotry post I tried to explain what
these companies should do:
Software development is an inexact science. There is no silver bullet. There is no process that maintains the “one size fits all” idea. If a majority of the concepts in Scrum work for you but there are one or two that your corporation will not allow, then adapt Scrum to your organization.
The question that we really need to deal with is how we focus our energy. When a project fails, most companies need to find someone or something to blame. In a post earlier this month, I talked about some comments regard everyone being “bad programmers”. In that post, I focused on the fact that software engineering is hard, and people make mistakes. However, I did not talk about the real problem.
Are you the person blamed for the project failure? Was the process blamed for the failure? Was there something during the project that went wrong, like a chosen technology not working as expected? Many different variables can make a project fail. Project management has several ways to try to ensure that projects do not fail.
One question that needs to be answered in your company is what is your definition of project failure? This is the topic of a longer post by itself. A few simple guides are whether a project finished by a planned deadline, whether the project finished within a planned budget or whether the number of production defects, or even late QA defects, is within some threshold. Once your definition is set, then you know who to blame, right? If the project is late, then the project manager should be blamed. If the project is over budget, then the customer is to blame because they requested too many features. If the number of defects is too high, then the developers are to be blamed.
Nice and simple, right?
Wrong. There are two problems with this simple blaming pattern. First, there are likely several things that went wrong during a project. So blaming one thing is never the answer. The second problem is the stigma of failure within software engineering. What if your definition of failure, a late project, is met but your customers love the new system? Is that really a failure? Even if the project meets the three simple definitions of failure, late delivery, over budget and poor quality, blaming someone does not help. Projects and companies fail all of the time. If people stopped at their first major failure, half of the entrepreneurs currently working in Silicon Valley would not be working.
So, what did you learn from the failure? Sometimes people do not work well together, even if they are all the best and brightest in your organization. Cultures may clash or different assumptions caused misunderstandings. Maybe the “most hyped tool of the month” could not deliver what you needed. If you publish a blog post on your findings with this tool, your company profile could improve because people see you taking risks with new technologies. This could mean a better talent pool when you are looking for new software engineers. If you could not devote a full-time customer to your project, schedule specific days for the customer to be available.
Adapt your processes to your environment. Adapt your teams to how people work together. Adopt failure as a badge of courage. We all fail during our careers, but it is what we learn from those failures that defines our career.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)