This is in fact a tricky spot: for both Agile practitioners, and the economic buyers. I will pick up the case for Agile practitioners a bit later, let's see where do the economic buyers stand with price-to-value game. So far, these group of people were sold on the Agile methods with the fact that they would get to see what's getting cooked in the kitchen. In turn, there were no certainty on the cost involved in cooking that dish. Increasingly, the economic buyers realized that they don't really need to be in the kitchen to see how the cooking happens. It's important to get the dish right; it should be palatable, and it should be hygienic. In other words, the software application delivered for use should be effective in meeting its objective of existence, and it should be trustworthy for carrying out the business. The economic buyer, may be the CFO of the company, doesn't need to spend time in seeing that a singleton class is getting developed, tested, and deployed for other classes to invoke it.
Once that's realized, the next big question is how to ensure that the software production cost is contained with respect to the value it will eventually deliver. The easy path would be to determine the value (or IRR), and calculate back the maximum amount of money to be spent. Once the maximum amount of money to spent is confirmed, that becomes the budget for that particular application development.
So far so good. The problem is that there is still no certainty that the application will get developed within that budget. After running sprints after sprints, the budget may get burnt completely only to deliver a bunch of classes and database objects with no realizable business benefits. The poor economic buyer, being part of the entire drama of cooking codes, would now be left with the pieces of marvels, but without any clue what to do with that. Agilists delivered, though.
On the contrary, the help is actually around. The IT service suppliers are available to design, develop, test, and deploy codes with demonstrable credentials in hand. The competition among them brings the benefits of bidding fixed fee quote, thus insulating the economic buyer from any financial risk. This is a proposition too hard to resist. But can Agile methods be fitted with this fixed fee structure?
Agilists, on the other hand, had a different problem in hand. What used to be a sideline process so far, has become a mainstream. Being a mainstream software engineering process, it's difficult to avoid the monetary question: how to ensure that the business benefits are realized at right cost? To address this concern, the initial thought was to follow Agile methods with a fixed budget. The product owner should know how much money to spend. Based on that, the product owner would determine the number of sprints to be performed, with the number of team members. Subsequently, the product owner should also make a broad classification of the features and functionality to various sprints. With this, our Agile project has become a fixed sprint project. A seemingly uncompromisable deviation, but okay!!
The fun part of market forces is it not only negates inefficiency, it also makes an open mockery of it. When the competition demanded to quote fixed fee for a software development project, even if it is supposed to follow Agile, it really pushed Agilists very hard. Too hard to stay sane. This time the question of ethics came out of the pocket. Apparently, asking developers to develop a program in fixed fee is an unethical practice. With this hypothesis, the argument was structured that software development in a fixed fee fashion is unethical practice. Agilists, being always on the right side of ethics (no matter how much they abused the traditionalists before), cannot accept this. So, Agilists will do T&M work.
Without going to the details on ethical practices and all that, let's try to look into the issue with our feet on ground -
1. Agile is going to stay, some of its practices are not available anywhere
2. Fixed Fee work is inevitable, a buyer is not actually buying programmers' time, buyer is buying a piece of software
3. How to fit the best of Agile practices into a fixed fee project would be the puzzle to solve.
My next post will try to address it.
Saturday, January 31, 2009
Sunday, December 28, 2008
Agile Intelligence: Schedule Variance
Whenever I sit on a project review and ask the question on quantitative management, this is the first quantitative parameter that I hear: Schedule Variance. Across the projects, IT and non-IT included, this is a metric of concern. Or, may be this is the easiest metric to measure, only to discover that the results are dismal at large.
Riding on the old English anecdote that Time is Money, the importance of schedule variance is indeed paramount. However, when it comes to following the Agile method, it becomes a bit different. May be a bit interesting too. Let me explain why: Agile methods by definition, cannot have any schedule variance. All deliveries are contained within one sprint or other. Sprints do have a fixed end date. As a result, the schedule variance of all sprints are zero.
While the sprints end on time, the deliverables don't. The unfortunate fact is covered up by simply pulling the deliverable off the sprint, and pushing it to the next sprint. So, if the measurement is done sprint-by-sprint, the schedule variance is zero. If the measurement is done output-by-output (or by deliverable), the result is unlikely to be zero. Sad but so real!
At the risk of antagonizing the proponents of Agile methods, the metrication on this area needs a pragmatic approach. Sprints are fine, but their end dates are curved on stone. But the buyer get most benefit when the work products are delivered on time. The product owner may take the responsibility of listing down the macro level deliverables to define such packages. The product owner may also need to do a thorough homework in determining the realistic and beneficial date for each of these packages to become usable. For the consultants working for their clients, it would be useful to have an open meeting with the client to agree on these dates. Once the dates are agreed, measure the schedule variance of each of these deliverables, and aggregate those to the project level.
Many a times, while speaking to the buyer or sponsor about Agile methods, it was found to be drawing a good degree of enthusiasm simply because there was a promise of showing the work products early enough while in the making. The same enthusiasm get converted to frustration when the buyer gets to see a lot things frequently, but none of those make any sense to him/her. A delivery centric view covering only the deliverables that matter most would be good to sustain the enthusiasm, as well as would save some time for both developers and buyer. The same feeling can get echoed through the measurement technique described above for schedule variance. We cannot simply ignore this metric for sake of the definitions within Agile Programming method.
Riding on the old English anecdote that Time is Money, the importance of schedule variance is indeed paramount. However, when it comes to following the Agile method, it becomes a bit different. May be a bit interesting too. Let me explain why: Agile methods by definition, cannot have any schedule variance. All deliveries are contained within one sprint or other. Sprints do have a fixed end date. As a result, the schedule variance of all sprints are zero.
While the sprints end on time, the deliverables don't. The unfortunate fact is covered up by simply pulling the deliverable off the sprint, and pushing it to the next sprint. So, if the measurement is done sprint-by-sprint, the schedule variance is zero. If the measurement is done output-by-output (or by deliverable), the result is unlikely to be zero. Sad but so real!
At the risk of antagonizing the proponents of Agile methods, the metrication on this area needs a pragmatic approach. Sprints are fine, but their end dates are curved on stone. But the buyer get most benefit when the work products are delivered on time. The product owner may take the responsibility of listing down the macro level deliverables to define such packages. The product owner may also need to do a thorough homework in determining the realistic and beneficial date for each of these packages to become usable. For the consultants working for their clients, it would be useful to have an open meeting with the client to agree on these dates. Once the dates are agreed, measure the schedule variance of each of these deliverables, and aggregate those to the project level.
Many a times, while speaking to the buyer or sponsor about Agile methods, it was found to be drawing a good degree of enthusiasm simply because there was a promise of showing the work products early enough while in the making. The same enthusiasm get converted to frustration when the buyer gets to see a lot things frequently, but none of those make any sense to him/her. A delivery centric view covering only the deliverables that matter most would be good to sustain the enthusiasm, as well as would save some time for both developers and buyer. The same feeling can get echoed through the measurement technique described above for schedule variance. We cannot simply ignore this metric for sake of the definitions within Agile Programming method.
Tuesday, November 25, 2008
Agile Intelligence: Quantitative Management
The purpose of Quantitative Project Management is to manage projects by a set of defined number driven parameters to achieve the stated project objectives. Apart from having familiarity of various quantitative methods, such activity also demands planning, reporting, and analysis. Unfortunately, Agile methods don't support activities like planning and reporting in a formal way. It doesn't have any role for Project Manager. That leaves the entire space of quantitative management open for interpretation.
So, how should an Agilist address the need of Quantitative Management? The earlier proponents openly discarded the existence of such need, but no longer. As Agile methods are becoming mainstream, such questions are real, demand for demonstrating project performance through numbers are phenomenal. The only quantitative reporting available with Agile methods are burn charts. The chart shows the effort burned over a period of time, and how the budget gets consumed. The chart does not reflect anything with respect to the work product quality. The chart does not reflect anything with respect to the meeting project objectives. The chart does not reflect anything pertaining to the analysis and resolution. As a result, the seasoned Agilist is bound to look into the classical quantitative management techniques, devise his/her own plan and execute it.
This brings back to the same situation similar to my previous post: wearing a project manager's hat while still within the team. Somebody like the product owner should prepare the metrication plan, collect data during scrums/otherwise, report data through a frequency driven reporting, and perform necessary analysis. If the data collection becomes part of the scrum, then the scrum format needs to be tailored. Instead of sticking to the 3 question format, a fourth question may get introduced by asking 'Tell me your numbers'. Or, a standard form can be used to collect data in writing.
The good news is, many large projects today use some process support IT platform, even if the project follows Agile methods. Tools like Team Foundation Server, etc. becomes quite useful in storing and updating the sprint backlogs. The same tool can also provide quite a few meaningful metrics based on how much of the backlog tracking is being done through it. At a minimum, the three basic project performance criteria can be derived quite easily: schedule, cost, quality. There is a minor twist though. The definitions of these parameters within the scope of Agile Programming are different to that of what the classical project management techniques taught us. My next posts will start exploring those areas.
So, how should an Agilist address the need of Quantitative Management? The earlier proponents openly discarded the existence of such need, but no longer. As Agile methods are becoming mainstream, such questions are real, demand for demonstrating project performance through numbers are phenomenal. The only quantitative reporting available with Agile methods are burn charts. The chart shows the effort burned over a period of time, and how the budget gets consumed. The chart does not reflect anything with respect to the work product quality. The chart does not reflect anything with respect to the meeting project objectives. The chart does not reflect anything pertaining to the analysis and resolution. As a result, the seasoned Agilist is bound to look into the classical quantitative management techniques, devise his/her own plan and execute it.
This brings back to the same situation similar to my previous post: wearing a project manager's hat while still within the team. Somebody like the product owner should prepare the metrication plan, collect data during scrums/otherwise, report data through a frequency driven reporting, and perform necessary analysis. If the data collection becomes part of the scrum, then the scrum format needs to be tailored. Instead of sticking to the 3 question format, a fourth question may get introduced by asking 'Tell me your numbers'. Or, a standard form can be used to collect data in writing.
The good news is, many large projects today use some process support IT platform, even if the project follows Agile methods. Tools like Team Foundation Server, etc. becomes quite useful in storing and updating the sprint backlogs. The same tool can also provide quite a few meaningful metrics based on how much of the backlog tracking is being done through it. At a minimum, the three basic project performance criteria can be derived quite easily: schedule, cost, quality. There is a minor twist though. The definitions of these parameters within the scope of Agile Programming are different to that of what the classical project management techniques taught us. My next posts will start exploring those areas.
Monday, October 27, 2008
Agile Intelligence: Risk Management
Traditional software engineering has Risk Management as an activity by itself. It is recognized as a process area or knowledge area by the most project management standards. Interestingly, it was never been part of Agile Programming. The reason was easy: Agile Programming was conceptualized and devised by the programmers. Programmers don't like activities like risk management and many others. This worked well to the point where the team was largely formed by two (three max) seasoned developers, and they used to churn out some of the great codes every month. The problem started when large projects started following agile methods. The methods and practices started getting questions that were never thought out, nor addressed. Risk Management was one of those.
So, doesn't a project following Agile methods need any Risk Management? Certainly, it does. The project needs to take help from the established project management standards. There is a problem though: Risk Management is a PM's job. Agile projects don't keep any PM. Who would manage the risks in that case? The question has been so far addressed by the volunteers. The Product Owner or the Scrum Master put on the hat of the PM to manage the risks. That demanded the risk manager to come out of the project chores time to time and take a thirty-thousand feet view to identify and assess the risk.
The broad level steps are same for risk management in Agile: Risk Identification, Risk Assessment, Risk Planning, and Risk Monitoring. These steps are implemented through scrums, the Scrum Master facilitates the session. However, these scrums don't follow the traditional 3 question format. These are more akin to the brain storming interactive sessions to ensure that all risks are identified and their impacts are rightly analyzed and understood. These sessions also demand the Scrum Master and Product Owner to provide a good perspective on the project risks. Being part of the team and weathering the daily chores, the risk of missing the forest for trees are very high in such a situation. Many project teams try to address this by bringing in an external expert / observer into these sessions and take their inputs. Such attempts are undoubtedly good but deviates from the Agile principles to a good extent.
To summarize, IT projects following Agile methods do need risk management. To accomplish this, the project team must leverage one of the many established formal project management standards and guidelines. The project team must assimilate the role of the PM within one of them to ensure the risks are formally managed. External support, if available would do good to the entire project process of risk management.
So, doesn't a project following Agile methods need any Risk Management? Certainly, it does. The project needs to take help from the established project management standards. There is a problem though: Risk Management is a PM's job. Agile projects don't keep any PM. Who would manage the risks in that case? The question has been so far addressed by the volunteers. The Product Owner or the Scrum Master put on the hat of the PM to manage the risks. That demanded the risk manager to come out of the project chores time to time and take a thirty-thousand feet view to identify and assess the risk.
The broad level steps are same for risk management in Agile: Risk Identification, Risk Assessment, Risk Planning, and Risk Monitoring. These steps are implemented through scrums, the Scrum Master facilitates the session. However, these scrums don't follow the traditional 3 question format. These are more akin to the brain storming interactive sessions to ensure that all risks are identified and their impacts are rightly analyzed and understood. These sessions also demand the Scrum Master and Product Owner to provide a good perspective on the project risks. Being part of the team and weathering the daily chores, the risk of missing the forest for trees are very high in such a situation. Many project teams try to address this by bringing in an external expert / observer into these sessions and take their inputs. Such attempts are undoubtedly good but deviates from the Agile principles to a good extent.
To summarize, IT projects following Agile methods do need risk management. To accomplish this, the project team must leverage one of the many established formal project management standards and guidelines. The project team must assimilate the role of the PM within one of them to ensure the risks are formally managed. External support, if available would do good to the entire project process of risk management.
Saturday, September 20, 2008
Agile Intelligence: Good To Great!
This is no plagiarism. My intention was not to pickup some perfect lines from here and there, but to rationalize a thought process. A thinking that keeps me asking to myself: Are organizations becoming great by adopting Agile Programming?
There is no denying that in an environment of continuous change demand for more agility from the business support functions are at historic high. At the same time, dependence on IT to run business and deliver goods & services are increasing like never before. Combining these two, the flexibility of the IT systems and processes to respond to ever-changing demand becomes the contributor to the business success. Certainly, Agile Programming can help in removing the inflexibility of the IT systems and processes by adopting some of its proven practices.
However, the agility may bring some compromises as well. While Agile methods don't explicitly denounce any structured approach and the need for documentation, there is a subtle ignorance towards this. Programmers love Agile Programming because quite often it relieves them from doing the mundane documentation, or following some lengthy processes. This is a dangerous trap. Sooner, the organization would either become captive to those rogue programmers due to their know-it-all attitude, or it would succumb to the fact that the IT systems are no longer maintainable. Yours truly had a recent experience of the latter situation, where a great software application became miserable and painful just because it was no longer maintainable, and nobody knew the inbuilt functionality well enough to develop a new application. So, Agile Programming is not necessarily a path towards greatness.
Many companies have adopted the process standards like CMMI, and Six Sigma for their IT organization to ensure proper adherence to the processes and fostering an environment to improve. CMMI, if effectively implemented, can be helpful in having a great structure in place for IT work. Six Sigma can help in removing all the wasteful processes and steps thus making the CMMI structure quite efficient. None of these two have any conflict with Agile programming, and can very well embrace some of the proven best practices like pair programming and scrums. Such a combination may bring some amount of greatness within the IT organization.
Unfortunately, there are not enough takers of such a theory, let alone practice it. Of late, the proponents of Agile have started denouncing that there are conflicts between Agile and CMMI. They are also openly encouraging the need for documentation within an Agile process. All these are good sign. It also shows a desperation to become mainstream practice for software development. But to make an IT organization great, only Agile may not be enough.
There is no denying that in an environment of continuous change demand for more agility from the business support functions are at historic high. At the same time, dependence on IT to run business and deliver goods & services are increasing like never before. Combining these two, the flexibility of the IT systems and processes to respond to ever-changing demand becomes the contributor to the business success. Certainly, Agile Programming can help in removing the inflexibility of the IT systems and processes by adopting some of its proven practices.
However, the agility may bring some compromises as well. While Agile methods don't explicitly denounce any structured approach and the need for documentation, there is a subtle ignorance towards this. Programmers love Agile Programming because quite often it relieves them from doing the mundane documentation, or following some lengthy processes. This is a dangerous trap. Sooner, the organization would either become captive to those rogue programmers due to their know-it-all attitude, or it would succumb to the fact that the IT systems are no longer maintainable. Yours truly had a recent experience of the latter situation, where a great software application became miserable and painful just because it was no longer maintainable, and nobody knew the inbuilt functionality well enough to develop a new application. So, Agile Programming is not necessarily a path towards greatness.
Many companies have adopted the process standards like CMMI, and Six Sigma for their IT organization to ensure proper adherence to the processes and fostering an environment to improve. CMMI, if effectively implemented, can be helpful in having a great structure in place for IT work. Six Sigma can help in removing all the wasteful processes and steps thus making the CMMI structure quite efficient. None of these two have any conflict with Agile programming, and can very well embrace some of the proven best practices like pair programming and scrums. Such a combination may bring some amount of greatness within the IT organization.
Unfortunately, there are not enough takers of such a theory, let alone practice it. Of late, the proponents of Agile have started denouncing that there are conflicts between Agile and CMMI. They are also openly encouraging the need for documentation within an Agile process. All these are good sign. It also shows a desperation to become mainstream practice for software development. But to make an IT organization great, only Agile may not be enough.
Subscribe to:
Posts (Atom)