Agile Zone is brought to you in partnership with:

I am a software engineer, database developer, web developer, social media user, programming geek, avid reader, sports fan, data geek, and statistics geek. I do not care if something is new and shiny. I want to know if it works, if it is better than what I use now, and whether it makes my job or my life easier. I am also the author of RegularGeek.com and Founder of YackTrack.com, a social media monitoring and tracking tool. Robert is a DZone MVB and is not an employee of DZone and has posted 87 posts at DZone. You can read more from them at their website. View Full User Profile

Processes Do Not Fail, People Do

11.23.2010
| 2324 views |
  • submit to reddit

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.

Accepting Failure

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.

References
Published at DZone with permission of Robert Diana, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Emma Watson replied on Fri, 2012/03/30 - 3:56am

recently read a post by Robert Diana claiming that processes do not fail, people fail.  It made me think… we define project success or failure by measureable factor.

JDBC

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.