First there was Bill Gates. Boy wonder. College dropout. Billionaire cofounder of Microsoft. And the company’s chief software architect through 2006, when he began transitioning out of the company’s day-to-day operations to focus on his philanthropic foundation.

Next there was Ray Ozzie, the father of Symphony, the unsuccessful office suite from Lotus Development Corp., and then Notes, the collaboration software he created at Iris Partners, which was acquired by Lotus, which was in turn acquired by IBM. Ozzie came to Microsoft in 2005, and was named chief software architect in 2006.

And now Ozzie is leaving Microsoft after only four years in that pivotal role.

Ozzie made a huge mark at Microsoft, in large part because of an internal document he wrote in 2005 called “The Internet Services Disruption.” This document, which leaked out, shows not only that Microsoft was missing the boat on the Internet, but that Ozzie was a Big Thinker who had a vision for the future of the computer industry.

How did Ozzie do? Results are mixed. On the consumer side, which was never his strength, Microsoft has lost ground. Apple has leapfrogged Microsoft’s earlier start in both tablet computing and smartphones, and its Mac OS X, while still a nice player, was helped by Microsoft’s missteps with Windows Vista. Google, not Microsoft, rules in online services, including search, advertising and hosted services, despite the major investment in Bing.

On the business software side, Microsoft has fared better. Products like SharePoint, SQL Server and Windows Server are very strong and are growing stronger. What’s more, Microsoft has emerged as a major player in cloud computing, thanks to a very robust offering in Windows Azure.

That said, from our vantage point outside Microsoft, we don’t see that Ozzie delivered as a chief software architect. He had some good ideas, but we don’t see his fingerprints on the company’s recent initiatives. If he was the visionary behind the company’s recent success, like Windows Azure, or its up-and-coming platforms, like Windows Phone 7 and Bing, he did a good job of hiding it. The lack of broad, true integration between Microsoft’s myriad software products and platforms indicates, to us, that his role was a passive one.

In announcing Ozzie’s departure, Microsoft CEO Steve Ballmer said that the role of chief software architect was unique, adding that he didn’t intend to replace Ozzie. Instead, the company will rely upon strong technical leaders within each business group.

Frankly, we don’t see how that will be different than what he had before. Bill Gates’ central role in visioning and planning was legendary. Ray Ozzie, by contrast, seems to have been invisible, with each business group doing its own thing.

What does the departure of Ray Ozzie mean for Microsoft? If we consider the Gates era to be Microsoft 1.0 and the Ozzie era to be Microsoft 2.0, then the third iteration (without a chief software architect) will be just like the one before. We believe the company needs a strong visionary to drive it forward. But Microsoft hasn’t had one since 2006.

Agile success requires developer autonomy
Classical software development was a rigid, top-down process. Requirements, tasks and goals were pushed down from stakeholders to managers to programmers, who did what they were told.

If we want to succeed with agile, we can’t keep working the same way. Too much rigidity—too much top-down centralized control—can doom agile projects, or at least hamstring the developers.

Over the past couple of years, much attention has been paid to the mechanics of agile software development: choosing the tools, defining the taxonomies, creating the organization chart, making sure that top management bought into the new methodology. That’s all well and good, to be sure.

Yet we believe that in this emphasis on structure, a key aspect of agile development has been lost: That individual developers, or small teams of developers, need the autonomy to decide what to do and how best to do it. Software development is a creative process.

While it’s important to make sure that the developers know, for example, which features the client wants to see, often the development team knows the best sequence for implementing them, which, to mix some metaphors, are the lowest-hanging fruit that deliver the biggest feature bang for the development buck.

The more rigid and micromanaged the requirements for software delivery, the less agile the agile process will be. Our advice to managers and stakeholders: Back off, and give your developers room to work.