It is striking how the dichotomy between framework based approaches to managing projects vs. agile methodologies resembles the metaphysical discussion around Plato's theory of forms.
In Plato's opinion, forms / ideas are more real than their instantiations that we see in everyday life. The idea of a human being is more real than all the people you see around you every day.
Take this concept and apply it to framework based approaches such as CMMI. CMMI, we're being told, is a model, a framework for process improvement.
The point I'm trying to make is not that CMMI is more 'real' than any of its implementations / applications. It is that CMMI is a syntetic construct, just as an idea (in the Platonic sense). The problem is that, just like Plato's ideas, CMMI only sounds good when it is not applied. Once applied, it loses its universality, it's just faint shadows on the background of a cave. Thus, the framework itself is never to blame for inefficiencies or unnecessary processes. The framework is never the efficient cause of failure. The only blamable part is the implementation.
Agile on the other hand is a collection of disparate practices (what makes sense) collected during numerous project life cycles. The beauty of it is that, because these processes are already 'implementation', they are the cause of failure or, more often, project success.
Friday, February 1, 2008
Self organizing teams - quo vadis?
I have a team of 5 developers and 2 functional analysts and we use mostly an agile approach to developing software. Coming from a non-agile environment, I had to get used to the concept of letting the team make decisions, including those involving self righting. I instantly recognized some of the benefits. First and foremost - the dream of any project manager, I didn't have to tell everybody what to do all the time. One of the pitfalls of managing project is trying to do too much and by doing so, curtailing the natural lines of communication between project participants. Developers did not expect me to tell them how to communicate with each other or with the functional analysts. If we hit a bump in the road or communication was not efficient, we would discuss it at the iteration post mortem meetings and right it for next time.
However, lately I have been nagged by a side effect. There have been several instances lately where the team took decisions that should have been brought up to my attention. An example is making a decision to refactor code instead of picking up new functionality off of the product backlog. This put the overall schedule and our commitments to the client organization and their board of directors at risk.
The moral is that self organizing teams is a great thing to do if it can be kept under control. Multidimensional communication should still include the PM and the role of the PM as the gatekeeper on scope, schedule and cost should still be recognized. There is a delicate balance to be striken between micromanaging that strangles team initiative and an absolute 'hands off' approach where the project manager is rendered powerless by the voice of the crowd.
However, lately I have been nagged by a side effect. There have been several instances lately where the team took decisions that should have been brought up to my attention. An example is making a decision to refactor code instead of picking up new functionality off of the product backlog. This put the overall schedule and our commitments to the client organization and their board of directors at risk.
The moral is that self organizing teams is a great thing to do if it can be kept under control. Multidimensional communication should still include the PM and the role of the PM as the gatekeeper on scope, schedule and cost should still be recognized. There is a delicate balance to be striken between micromanaging that strangles team initiative and an absolute 'hands off' approach where the project manager is rendered powerless by the voice of the crowd.
Recognizing business value in software development
I think that it is more important than ever for the development team to recognize the business value of the application they develop. The traditional approach had the requirements handed down from the 'business owners'. It was almost sacrilegious for the developers or even analysts to suggest improvements or discuss the ultimate business purpose with the business owners. Think separation of duties, don't do anything you're not 'qualified' of doing.
The problem with this approach (for the development team), is that it is the development team is the place where value is created. Not allowing or encouraging collaboration between business owners and the development team is similar to blindfolding a master painter and ask him to paint a portrait from memory after a cursory look at the model. The development team needs to understand not only what but also why something is built. This ensures project success and prevents finger pointing situations where everybody is right in their own ways.
The problem with this approach (for the development team), is that it is the development team is the place where value is created. Not allowing or encouraging collaboration between business owners and the development team is similar to blindfolding a master painter and ask him to paint a portrait from memory after a cursory look at the model. The development team needs to understand not only what but also why something is built. This ensures project success and prevents finger pointing situations where everybody is right in their own ways.
Subscribe to:
Comments (Atom)
