Lack of Blog Posts!

I'm writing a book.  There, I said it out loud.  

It's consumed most of my time, and the blog has suffered.  I apologize.  I have a writing schedule I have to meet, and I'm finding the process harder and more rewarding than I ever imagined.   

During this time, I'm going to make an effort to post a blog at least once a month.  In the meantime, if you're interested in learning more about the book as it progresses, please type in your email address in the SUBSCRIBE section at the bottom of the page.  

Thanks,

Erik

Top Five Leading Causes of Failed Agile Projects

VersionOne does an annual "State of Agile Development" survey and publishes the results for the cost of your email address.  Thanks VersionOne!  I recently read through the 9th annual survey results for 2015, and there's lots of good, useful data there.  For now I want to highlight the top five reasons agile adoption fails, and what you can do about it:

Here are the top 5 leading causes of failed agile projects:

1. "Lack of experience with agile."  

2. "Company philosophy or culture at odds with agile core values."

3. "Lack of management support."

4. "External pressure to follow traditional waterfall processes."

5. "Lack of support for cultural transition."

My strategy for overcoming these challenges in most large global organizations is employing the Studio Model, something Ken Schwaber wrote about in Software in 30 Days.  The basic idea is to carve out a part of your organization as a new "Agile Studio."  Within the Studio, we start projects that are allowed to use various agile concepts techniques.  And because most of the people are unfamiliar or inexperienced with agile techniques (#1), we only allow trained professionals to be on projects in the Studio.  And the training we use is not a weak professor led teach-at-you course or silly learn-by-playing-metaphorical-games workshop, it's serious experiential courses that include actually building software.  

Making the decision to set up the Studio inherently involves management.  It actually requires managers to take action to form such a structure inside their organization.  By doing this we ensure buy-in, which intrinsically tackles the problems of #3 and #4.  Sound too easy? Yes, we aren’t done yet… The scale of the Agile Studio is the primary management discussion point once we’ve achieved buy-in.  Do we start with just one project because we're just not that confident in this agile thing?  Ok, let's do that!  Or do we start with a major scaled initiative because it's critical to our business’ success?  OK, let's go!  Once management has made a decision about how to start, they are the ones actually organizing and supporting the Studio. The lines of communication between management and the team are now open; they have skin in the game and are incentivized to see the Studio succeed. In fact, because change like this tends to make us humans nervous, we find management quite engaged in the Studio start-up. Additionally, everyone - managers included - require training and coaching in order to operate in the Studio - don't forget that #1 applies to everybody!

#2 and #5 are a bit trickier.  I wish there was a simple technique to install a new culture at your big company.  Instead, I've come to believe that culture is a symptom.  Culture change follows after other change - structural, organizational, process, communication style, etc.  The best I can tell, and this is by no means a scientific study, an organization’s culture is mostly a result of the processes they use, and the communication styles of their leaders.  So in the context of an Agile Studio, we actually change the processes we're using from day one.  Do you want a culture that is transparent and freely inspects and adapts the work product?  Well, let's use a process that builds those elements in.  Soon you'll start seeing these things bleed into everyday work.  As for leadership and communication styles, one of the things I often do in the Agile Studio is work one-on-one with each manager on this very topic.  As an agile coach, I am skilled in this area, but I often use a Professional Coach for this type of work simply because it's such a different skill-set than "agile process coaching."  

Anything - absolutely anything can fail if it is not executed properly. What is clear from research is that using Agile techniques for software development is far more cost, time and demand effective than Waterfall or other, older methods. If your company has experienced any of the above obstacles to success in Agile adoption, let’s revisit your approach.  Contact a Professional Scrum Trainer to ensure you remain competitive in the ever-increasing battle for better software with faster delivery.