In a previous post, I talked about the change in software development approaches over the past 15 years. It has been slow, but in aggregate, the effect is striking. People are doing iterative development now, and succeeding with it. But despite the growing body of evidence in support of these approaches, in some cases it’s still difficult to get an organization to adopt them, to follow along.

There are lots of approaches to get an organization to move – there are course in MBA programs designed around this very problem. With the opportunity for efficiency with iterative management, managers need to take the lead.

I have a story of one such reluctant organization. This is a successful business, it’s been running for years on a business system that was created in-house. The business is going well, they weathered the 2008-10 downturn well and are now looking to grow. They’re nicely profitable and well-managed. They know they need a new business information system to support the growth they’re seeking. They’re willing to commit significant capital investment to produce this new system. All sounds good, right?

The problem is this: while the business leaders are creative and energetic, and interested in aggressively pursuing the business opportunity they see, the IT and development staff in the organization are reluctant. They have done waterfalls for so long, that they eat, sleep, and breathe formal requirements analysis documents. They are accustomed to large meetings, building consensus, and deliberative efforts. This old-school approach results, frankly, in an inability to execute. The engineering team cannot seem to make any progress on the project, and if they are actually making progress, they have no good way of demonstrating that to the boss, the guy who is paying for the effort. It’s frustrating, and the boss is not so sure that his investment in the new business system is being managed wisely.

Often, strategy and business leaders are inclined to delegate – to let the development teams do what they do, and that’s just what was happening in this case. They stood back, figuring that participating too actively in the development effort would be distracting.  But the business leaders were unsatisfied with the progress on the project. This was the catalyst for action.

At first they tried to persuade the dev teams to get more Scrummy, more agile. There was some grudging movement, but no real commitment. Progress was still slow. Meetings continued to be painfully large and inefficient.

Finally the boss, the CEO, decided to get tough.  He insisted on a status update meeting, every other week.  He wanted the meeting to be 30 minutes only, and he wanted to focus on measuring and demonstrating progress. He insisted that the meeting be attended by only a small number of people, and that the dev team conceive and use a clear metric for measuring its progress that they could show him during these meetings. He insisted on seeing actual working demonstrations of the application.  

None of this fit with the path the dev team was intent on.  But, notably, it all fit very well with Scrum.  The demand for measurable progress is characterized in a burndown chart. The working demonstrations requires a sprint-like approach.  The small cross-functional team is right out of scrum. He’s getting scrum sideway.

Now, this isn’t a perfect situation. It would be nice if the organization could adopt scrum “openly”. It’s almost as if the CEO had to sneak it in sideways.  But, this may just work.  His demands for this sort of status update, with regular progress reports and demonstratable code, has moved the dial. It may be the thing to convince the conservative dev team that it is safe to be more agile.

It will be interesting to watch…