Is it a defect or an enhancement? The answer to this question makes a big difference to the software team. The developers are very much involved with the product that they are building and often times they take offense if a requirement defect or an enhancement (new functionality request) are mislabeled as defects, i.e., a problem with design or implementation.
The problem is, none of this matters to the business stakeholder. A good Agile team shouldn't even care about the difference between a bug, requirements defect or enhancement, as long as it is work that needs to be done. Clinging to categories is often a symptom of team division and dissension.
Monday, December 8, 2008
The business value of fixing defects
Less defects is always a good thing. Right? Not so fast. Fixing a defect has both benefits (more obvious) and costs (often easy to ignore). In this posting, I'll concentrate on some of the costs and why they can sometimes outweigh the benefits. This analysis is performed from the perspective that everything we do in a software project has to come in line with adding value to our stakeholders.
First, let's discuss the opportunity costs. Allocating resources to fixing a defect takes away from doing other things - such as fixing more important defects or implementing new features. The way to prevent misallocation of precious resources in an agile setting is to treat defects as any other quantity of work - create stories for them and, based on a prioritization exercise that takes into account feature stories, work them into the backlog. In a non agile setting, misallocation of resources due to high opportunity cost is trickier. Since prioritization is usually fractured between requirements and defects, defects usually get prioritized among themselves and get fixed within the allotted time. This usually leads to inefficiencies - since very seldomly the predetermined time for 'fixing bugs' is just right. Many times, teams will over fix some parts of the code and under fix others. There is also a temporal horizon bug fixing problem (I'll deal with that more in depth in a separate entry) - in brief, more recently discovered bugs tend to be fresher in people's minds, and thus, receive more attenting than older bugs.
Second, fixing bugs is risky. Touching a piece of code runs the risk of introducing more bugs, in other words, doing more harm than good. This risk should be managed by the project manager just as she would manage any other project risks. This is particularly heinous since time and attention for retesting are often in short supply.
To conclude, I'm not advocating against fixing defects. The point I'm making is that fixing defects should be treated as any other quantity of resource consuming endeavor, and as such, it should be balanced against other resource demands from the perspective of getting the most bang for the buck for the project stakeholders.
First, let's discuss the opportunity costs. Allocating resources to fixing a defect takes away from doing other things - such as fixing more important defects or implementing new features. The way to prevent misallocation of precious resources in an agile setting is to treat defects as any other quantity of work - create stories for them and, based on a prioritization exercise that takes into account feature stories, work them into the backlog. In a non agile setting, misallocation of resources due to high opportunity cost is trickier. Since prioritization is usually fractured between requirements and defects, defects usually get prioritized among themselves and get fixed within the allotted time. This usually leads to inefficiencies - since very seldomly the predetermined time for 'fixing bugs' is just right. Many times, teams will over fix some parts of the code and under fix others. There is also a temporal horizon bug fixing problem (I'll deal with that more in depth in a separate entry) - in brief, more recently discovered bugs tend to be fresher in people's minds, and thus, receive more attenting than older bugs.
Second, fixing bugs is risky. Touching a piece of code runs the risk of introducing more bugs, in other words, doing more harm than good. This risk should be managed by the project manager just as she would manage any other project risks. This is particularly heinous since time and attention for retesting are often in short supply.
To conclude, I'm not advocating against fixing defects. The point I'm making is that fixing defects should be treated as any other quantity of resource consuming endeavor, and as such, it should be balanced against other resource demands from the perspective of getting the most bang for the buck for the project stakeholders.
Tuesday, July 15, 2008
Small teams: PM or tech lead?
So you're trying to assemble your development team for a software project. You are limited in the number of overhead resources you can afford. Which is better - looking for a strong tech PM type (e.g. someone that can control the project variables - scope, budget, product quality, etc.) or looking for an architect / master coder / lead by example team lead type? Unfortunately, most often than not, the two skill sets don't come in the same package. A lot of small teams (3 - 6 developers) are often forced into having one or the other. The tradeoff may be forced not only by budget constraints but also by trying to avoid a top heavy small team.
The answer - as anyone working with consultants is already predicting - is that it depends. A higher complexity project - using new and unproven technology, building something from scratch will lean the balance in favor of the team lead type. Immovable milestones and a bunch of developers with gold plating tendencies will lean the balance in favor of the PM type.
Regardless of what you decided need most, the mistake to avoid is blaming the project woes (if any) on the absence of the person / type you did not choose. A project, like anything else in life, is subjects to constraints and imperfect situations. Once you made a decision on who will lead your project down in the trenches, live with it.
For example, assume you do not have a team lead to bring the team to consensus once in a while. Well - losing some efficiency by allowing too much bikering about some of the technical decisions is just an opportunity cost of better project control (assuming your tech PM is doing a good job).
The answer - as anyone working with consultants is already predicting - is that it depends. A higher complexity project - using new and unproven technology, building something from scratch will lean the balance in favor of the team lead type. Immovable milestones and a bunch of developers with gold plating tendencies will lean the balance in favor of the PM type.
Regardless of what you decided need most, the mistake to avoid is blaming the project woes (if any) on the absence of the person / type you did not choose. A project, like anything else in life, is subjects to constraints and imperfect situations. Once you made a decision on who will lead your project down in the trenches, live with it.
For example, assume you do not have a team lead to bring the team to consensus once in a while. Well - losing some efficiency by allowing too much bikering about some of the technical decisions is just an opportunity cost of better project control (assuming your tech PM is doing a good job).
Friday, February 1, 2008
Ideas or instantiations?
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.
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.
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.
Monday, January 21, 2008
Project and SDLC methodologies and Agile development
This entry is a quick comment on how 'official', PMBOK-style project management is so far removed from software development using Agile methodology.
All these monolithic methodologies / frameworks - PMBOK, CMMI, etc. claim that you can tailor them to the realities and specificities of your project. This is true. But at what cost? I had an engagement where I had the luxury of spending 3 months tailoring PMBOK and CMMI frameworks before I engaged on a grueling, 15 months software development cycle. But most engagements cannot afford that. Most clients (unless they are in the government space) expect you to come to battle with your arrows already sharpened; they won't pay for you to get your act together as you go. Hence the usual demise of PMBOK and CMMI.
That's where Agile (or Agile-style processes) come into place. In Agile, everything happens as you go (or as you see a need), including creating processes. You might not get it right the first time around, but you eventually get there. The beauty of it is that you only build the processes that you need, when you need them. Team getting bogged down because you don't have a defect management process? It might be time to sit down and create one. Need a more complex process where you include a step for triage and approval of what gets fixed with priority? Better add it in the process. After a while, you're going to get to a state of equilibrium. There - you have the process and not only that, but unlike many monolithic methodology implementations, you will also have buy-in from the process stakeholders.
All these monolithic methodologies / frameworks - PMBOK, CMMI, etc. claim that you can tailor them to the realities and specificities of your project. This is true. But at what cost? I had an engagement where I had the luxury of spending 3 months tailoring PMBOK and CMMI frameworks before I engaged on a grueling, 15 months software development cycle. But most engagements cannot afford that. Most clients (unless they are in the government space) expect you to come to battle with your arrows already sharpened; they won't pay for you to get your act together as you go. Hence the usual demise of PMBOK and CMMI.
That's where Agile (or Agile-style processes) come into place. In Agile, everything happens as you go (or as you see a need), including creating processes. You might not get it right the first time around, but you eventually get there. The beauty of it is that you only build the processes that you need, when you need them. Team getting bogged down because you don't have a defect management process? It might be time to sit down and create one. Need a more complex process where you include a step for triage and approval of what gets fixed with priority? Better add it in the process. After a while, you're going to get to a state of equilibrium. There - you have the process and not only that, but unlike many monolithic methodology implementations, you will also have buy-in from the process stakeholders.
Subscribe to:
Comments (Atom)
