Enterprise-scale companies invest a lot of time and money in preserving and protecting what works — or more correctly, what they believe works. It’s this preserve-and-protect mentality that makes switching software development approaches so difficult.
After having invested so much in training, documentation and tools for software development, these companies are understandably reluctant to make major changes to their chosen approach. In addition to the time and cost, there are the people who have embraced and championed the status quo. How do you tell them to let go and move on?
Making the switch from a command-and-control approach like waterfall and it’s variants to an agile approach like Scrum, XP or Lean is a big deal. It’s not easy and there are many pitfalls along the way. The story of the fall of Blackberry has some interesting lessons that I believe apply to enterprise companies making a development approach switch.
Blackberry Gets Its Bell Rung
A great example of the preserve-and-protect behavior is Blackberry, formerly Research in Motion. I’m sure you know that Blackberry has been in a near fatal free-fall ever since the Apple iPhone was announced in 2007. Blackberry was in the business of designing, building and selling phones. Apple was in the business of doing the same things with computers and music players.
The iPhone wasn’t really a phone — it was (and still is) a computer. This puzzled Blackberry. They couldn’t understand how such a device would succeed. It used too much mobile network bandwidth. It’s battery life was too short. It didn’t have a physical keyboard. It’s security was weak. It (the original iPhone) didn’t even offer email support.
Blackberry didn’t get it. They were so entrenched in their way of doing things that the iPhone was incomprehensible. They thought they knew what their customers wanted but they, and their customers, even got that wrong.
Prior to the iPhone, major corporations dictated what features a smartphone had to have. They worked with the telecom providers and handset manufacturers to get what they wanted. Once the iPhone arrived, the power began to shift from major corporations to consumers. Blackberry’s market was changing and it couldn’t react fast enough.
Lessons for Software Development Teams
What does the Blackberry story have to do with software development? They’re connected by human behaviors. People become strongly attached to what they know and understand. That bond is even stronger if the status quo has been working — which it clearly was for Blackberry prior to 2007. Yet the smartphone world changed in 2007 and so did the future of Blackberry.
Lesson 1: Don’t assume that simply because the current approach has worked well that it will continue to work well.
Blackberry was phenomenally successful prior to 2007 but the market changed and they needed a new approach. Any company successfully using a command-and-control approach to software development will question the need for change. “If it ain’t broke, don’t fix it”, right? Unfortunately, by the time people realize that “it’s broke”, it may be too late.
Business processes continually evolve. They must to keep pace with market, regulatory and legal changes. Our approaches to software development have to evolve also.
Lesson 2: Don’t make changes simply to jump into the latest business fad.
Blackberry rushed the Storm to market in 2008. It was their first all-touchscreen smartphone. It was also awkward, slow and buggy. It failed. If a company is going to change their development approach, they need a good reason to do so — a problem to solve. They also need the time and patience to do it right. “Me too” is not a good reason and hasty conversions are failure-prone.
Many companies are eager to adopt the latest management trends or business process ideas. Unfortunately, they also have a tendency to corrupt those ideas via poor implementation.
Lesson 3: Don’t compromise without solid justification for altering the approach.
Blackberry tried to strike a balance between its existing keyboard phones and the Storm. In doing so, the end result didn’t appeal to traditional Blackberry users or to those wanting to switch to a touchscreen phone. There were too many compromises coupled with poor execution. Trying to blend command-and-control with Scrum — or another agile approach — leads to dysfunction and confusion. Pick a new approach and embrace it.
Try to adopt an agile approach and implement is “as is”. Blend the old approach with it if you must but strongly resist the urge to do so. You’ll likely end up with a hybrid that won’t appeal to anyone.
photo credit: Viewminder via photopin cc