by Nate McKie of Asynchrony Solutions
Over the last five years, Asynchrony has been successfully utilizing Agile and Lean methodologies within software development processes for both internal work and on client projects. While the processes themselves are fairly straightforward, we found that there are significant cultural and organizational challenges that must be addressed when transitioning large corporations and government agencies from Waterfall or Spiral methodologies to Agile and Lean.
The reason is not hard to see: a move from a command-and-control philosophy to a culture of trust, empowerment, and team accountability requires a major shift in thinking and culture and this is hard to do.
Why is it so hard for the organizations to change?
The issue has never been illustrated better than in the March 26, 2010 episode of NPR's "This American Life" radio program. In this case study, we heard about the creation of New United Motor Manufacturing, Inc. (NUMMI), an amazing joint venture in the mid-1980s between two industry giants: General Motors and Toyota.
Toyota agreed to show GM the way they were making quality cars that Americans were buying like crazy. In return, Toyota would learn how to deal with American workers (and specifically American unions). It actually worked. The plant began creating cars that were significantly higher in quality than what was coming out of other GM plants, and doing it with unionized American workers.
Sounds great so far, but the real story is that even though GM had learned these successful quality lessons from Toyota (and in fact witnessed them first hand in their plants), it still took them almost 30 years (yes, 3-0… thirty) to implement these ideas across the corporation.
The struggles GM has faced, the obstacles it has encountered, and the mistakes made along the way are a cautionary tale for large organizations that want to enact real change. I always share this story with anyone I encounter who is a change agent or wants to see change happen in a corporate or government environment. It helps frame plans for how to truly see change happen and how quickly to expect it.
We never claimed to be geniuses. In fact, before we found Agile, we were just as guilty as anyone of “hero-based” project success. Having a software development background myself, I was put in the position -- even as the project manager -- of making those last few fixes late at night or implementing that final screen so that the software could get out the door on time.
The last straw came when we had a team of developers working on a project for a client, and even though they had great technical specs that told them exactly what to do, the developers still created an integration nightmare that took the project four weeks past the deadline to get working. That was our impetus to change to Agile, as we needed more discipline and a better process to keep the last minute surprises from hitting us so hard.
As a small company, change came easy for us. All it took was a decision by upper management, buy-in by our small development team, and a customer who was willing to try something new. We made lots of mistakes and stumbled a bit, but there were so many obvious benefits from the outset that it was worth the pain.
Once we got better, we were able to expand what we had learned from one team to another throughout the company; bringing an even more improved process to every project we took on. We still messed up from time to time (fewer mistakes with more projects), but we had made a complete paradigm shift across our company in very little time.
Since then, our customers have seen how we create high quality software for clients. Better yet, it’s created with a predictable process that puts surprises where they belong: as early as possible.
Many of our philosophies are right in line with Toyota’s:
- Empower the team members.
- Give them ownership over quality.
- Do not tolerate defects.
- Constantly look for ways to eliminate waste.
Now, our customers, who generally have their own in-house developers, often want us to teach them our project management techniques. It would seem that we could just have one or two of our developers go to their teams, show them how we develop software, give them a push, and see great software come rolling in, but of course it doesn’t work that way.