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.
Sunday, December 28, 2008
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.
Saturday, August 23, 2008
Agile Intelligence: Peer Review
There is no peer review activity in Agile Programming. It's embedded into it. When the proponents of the Agile methods started practising it in a bigger way for serious IT projects, there was serious need to doing reviews. Traditionally, the programmers following Agile were all experienced hands and hence there was a little need for doing such reviews. As the projects following Agile started becoming large and complex, two problems started bugging the Scrum Masters and Product Owners a lot:
- There is not enough experienced hands to code any more, since the team size is bigger.
- Complex codes require comprehensive look through the second pair of eyes.
Pair programming principles came very handy this time. In this setup of work, no single developer is assigned a programming task. It's always assigned to a group of two programmers. The technique instructs this pair of programmers to sit in front of a single workstation (computer) and perform the programming corresponding to the assigned task. One programmer is supposed to do the typing of the codes: to be called as the driver. The other programmer is supposed to continue reading the codes being typed and review the correctness of the codes: to be called as the observer. Some books also term the latter person as the navigator. As a result of this setup, the codes are getting reviewed on the point of production.
This technique has been adopted in many IT projects and being implemented successfully, the simple reason being its effectiveness. A traditional software development method mandates review of the program after production, but is mute on the technique. Most often, a developer writes a piece of code, compiles and re-compiles it till it becomes error free (not bug free), and then leaves the program unit for review for an elderly programmer. By the time the reviewer steps in, the program unit may reach to a size of many thousand lines, with the implementation of several requirements. The reviewer on hot seat now has a daunting task of reading through the requirements, and then reading through the programs to make some review comments. There are a many good ways to make such reviews effective, but at large the task is no more a fun affair. This is where pair programming technique clicks. It makes the programming a fun. The programmers interacts continuously between themselves about the codes and implementation and through instantaneous iterations, make the codes better. No more pain and effort for documenting review comments, no more closing the review comments through a loop of comprehensive work flow. Sample this: How many of the traditional code review comments don't start with a statement on the code indentation or comments? The answer is probably "not many". While it's very important to produce properly organized readable codes while programming, quite often the reviewer gets lost within such show-off stuff instead of getting deeper into the question whether any alternative coding would make the implementation better. Pair programming technique allows such review comments to be made right on spot by the observer so that the driver can make the necessary changes right there.
Criticism is not few though. One big question is always put up is about productivity. Deploying two programmers to program on a single workstation perceivably reduces the productivity to half. However, the equation is not that linear. The proponents of pair programming submits two points in this respect:
- Zero Review Effort: Review being embedded into the technique, no separate review activity needs to be planned and managed. This would save some good degree of time and effort. Each organization or project team maintains its own review effort benchmark, and it varies widely. So quantification may be difficult, but everybody agrees that it does not fully substitute a second programmer's time. Here comes the second point, a bit upright and direct.
- Productive Hours: Some of the proponents of this technique openly challenged to walk by the cubicles of the programmers who are nested within their own self for programming. Their revelation was that about half of the population were doing something but coding: checking emails, preparing reports, web browsing, and even blogging like yours truly. According to them, this time would not go waste if two of them staring at the workstation for programming. In a pair programming process, the pair typically gets exhausted after 6 hours of work, simply because the intensity of the focus they need to put into work. On the contrary, according to the proponents, the single programmer programming is not worth more than 4 productive hours sans review.
I admit that this is a questionable argument. Not all organizations foster similar culture, and hence the outcome would largely vary. However, given the quality of the output through pair programming, it may be useful at many times. If not for the entire set of programming tasks, but certainly for the complex and critical sets.
Pair programming also opens up an avenue that the proponents largely ignored: possibility to deploy junior resources. Agile methods don't have enough room for junior programmers, pair programming allows the formation of senior-junior tag team to perform programming and learning to do better coding on the way.
Saturday, July 12, 2008
Agile Intelligence: Project Kick Off
In traditional software development project, project kick-off is an event. Project Kick-off indicates a start of the project. It ceremonially authorizes a person as Project Manager to run the project, and recognizes the sponsors, business or otherwise. Before a kick-off happens, the project charter is ready, the stated objectives are clearly understood, and approved budget is there. The project manager knows where to start from and where to reach, with a given duration and money. Project kick-off also recognizes the key contributors and influencers, and lays down the ground rules to be followed.
In Agile Programming, project kick-off remains an event, with the exception of the roles involved. Agile Programming did not start with the project mind-set but with a programmer’s perspective. By and large it remained a programmers’ work till recently, the mainstay organizations started seriously looking into its benefits, and the skeptics started raising difficult questions. In an attempt to put a project wrapper on Agile, the project kick-off eventually started happening.
Agile Programming does not recognize the project manager. So the Product Owner and the Scrum Master jointly slip into this role. They convene the kick-off meeting. Agile does not recognize the hierarchy among programmers. So it calls all programmers into the kick-off meeting. Agile Programming does not care of project funding or sponsor’s constraints. So project charter, objectives, and budgetary considerations are not put into the kick-off agenda.
Still, there are widely recognized benefits of a project kick-off meeting in Agile Programming. The IT Services organizations have done some good amount of thinking to fit an effective kick-off meeting for projects following Agile Programming. The best practices include a soda-popcorn speech by the Product Owner, where the Product Owner is expected to outline his/her own vision about the end product. The Product Owner also hints out how he/she anticipates all the features of the products will be built out. After the Product Owner finishes his/her job, the Scrum Master steps in for the next show. The Scrum Master puts the Products Owners wish list into multiple sprints and the high level distribution of features among the sprints. As you may understand, these two persons need to do a good homework together; otherwise the meeting may turn out to a disaster through each one contradicting the other.
After that, the kick off meeting is expected to end with some questions and fixing the time for Scrums. Sprint 1 starts from the next day.
Till now, Agile does not have any standardized kick-off method for projects. Over the period of time, it is expected to mature to a certain extent. As example, the traditional projects foster multi-stage kick-off meetings based on the phase driven involvement of various roles. In many projects programmers are not called in till the requirements analysis progress to a reasonable extent, so that all the early questions of the programmers can be well answered during the programmers’ kick-off meeting. Many organizations involve external IT service providers for getting a part or whole of the software developed. Their involvement does call for a specific kick-off meeting, however, that may not be the very first kick-off meeting. Traditional project methods allow addressing such situations by sub-classifying the projects within project, whereas such a concept is yet to evolve with the Agile Programming perspective.
If you are the person assuming the role of the Scrum Master (most obvious role for an erstwhile PM), or a Product Owner; my suggestion would be to plan for an effective kick-off meeting. You may need to support this meeting with conference call and live meeting bridges since the programmers will be spread practically everywhere in the world. Lastly, don’t hesitate to borrow the project kick-off methods and techniques laid out in the traditional project management books. You will need those to make it a success.
In Agile Programming, project kick-off remains an event, with the exception of the roles involved. Agile Programming did not start with the project mind-set but with a programmer’s perspective. By and large it remained a programmers’ work till recently, the mainstay organizations started seriously looking into its benefits, and the skeptics started raising difficult questions. In an attempt to put a project wrapper on Agile, the project kick-off eventually started happening.
Agile Programming does not recognize the project manager. So the Product Owner and the Scrum Master jointly slip into this role. They convene the kick-off meeting. Agile does not recognize the hierarchy among programmers. So it calls all programmers into the kick-off meeting. Agile Programming does not care of project funding or sponsor’s constraints. So project charter, objectives, and budgetary considerations are not put into the kick-off agenda.
Still, there are widely recognized benefits of a project kick-off meeting in Agile Programming. The IT Services organizations have done some good amount of thinking to fit an effective kick-off meeting for projects following Agile Programming. The best practices include a soda-popcorn speech by the Product Owner, where the Product Owner is expected to outline his/her own vision about the end product. The Product Owner also hints out how he/she anticipates all the features of the products will be built out. After the Product Owner finishes his/her job, the Scrum Master steps in for the next show. The Scrum Master puts the Products Owners wish list into multiple sprints and the high level distribution of features among the sprints. As you may understand, these two persons need to do a good homework together; otherwise the meeting may turn out to a disaster through each one contradicting the other.
After that, the kick off meeting is expected to end with some questions and fixing the time for Scrums. Sprint 1 starts from the next day.
Till now, Agile does not have any standardized kick-off method for projects. Over the period of time, it is expected to mature to a certain extent. As example, the traditional projects foster multi-stage kick-off meetings based on the phase driven involvement of various roles. In many projects programmers are not called in till the requirements analysis progress to a reasonable extent, so that all the early questions of the programmers can be well answered during the programmers’ kick-off meeting. Many organizations involve external IT service providers for getting a part or whole of the software developed. Their involvement does call for a specific kick-off meeting, however, that may not be the very first kick-off meeting. Traditional project methods allow addressing such situations by sub-classifying the projects within project, whereas such a concept is yet to evolve with the Agile Programming perspective.
If you are the person assuming the role of the Scrum Master (most obvious role for an erstwhile PM), or a Product Owner; my suggestion would be to plan for an effective kick-off meeting. You may need to support this meeting with conference call and live meeting bridges since the programmers will be spread practically everywhere in the world. Lastly, don’t hesitate to borrow the project kick-off methods and techniques laid out in the traditional project management books. You will need those to make it a success.
Thursday, June 05, 2008
Agile Intelligence: Test Driven Development
Test Driven Development (TDD) is a widely popular practice within the Agile practitioners. As the name suggests, this approach puts extra emphasis on passing the tests. I will try to draw up the popular activity block diagram a little later, before that, let's try to understand what this approach intends to achieve.
By and large, the developers are used to do coding by looking at the software requirements specification, aka spec. Developers, or the project teams that are not aware of the mature engineering processes (software or elsewhere), tend to write lines after lines of codes by looking at the spec without realizing the purpose. They tend to forget that the codes produced by them are also intended to run at some point of time. So, they code, and they code, only to realize at the fag end that all those beautifully thought out lines are of no use, because those did not get compiled in first place. Even if those were lucky enough to get compiled, those didn't run. For those luckiest fellows, even if it ran, it did not run as desired. The bottom line is, all those effort had been meaningless. For these developers, TDD brings in a gentle reminder in its name itself: Guys, don't just code; do some testing as well.
Test harness and test bed preparation concepts have been around for a while, primarily to boost the developer's mind and encourage them to do testing. At a latter stage, the professional testers took these two terms to a more sophisticated level by incorporating theories and mature practices. Nevertheless, if we still consider the older practices, all it talked about was unit testing of the codes after completing the code writing of the smallest possible unit (say, a method within a class). While the development is on, the same test on the same unit is to be repeated many times since the new codes are getting developed and interlinked with the existing ones. Instead of putting the developers into the rigor of manual repeats of the same tests, they were encouraged to write test codes so that the testing could be done by the programs. Historically, these were the first attempts in asking the developers to eat their own cooked food.
TDD formalizes the process from a different perspective. TDD assumes that the developer is not required to develop codes that would be perfect in all counts. Rather, it initiates the idea of developing codes that would pass the fitness tests employed, doesn't necessarily would pass with flying scores. To put this into implementation, it says the developer to develop just enough codes to pass the test cases. The diktat puts the developer to write the test cases first, then do the development, and do the development in such a way that it passes through the test cases. Sometimes, the developer doesn't write the test cases still, a tester writes the test cases for him/her. The developer then uses those test cases to conduct his testing and remain compliant to TDD.
By and large, the developers are used to do coding by looking at the software requirements specification, aka spec. Developers, or the project teams that are not aware of the mature engineering processes (software or elsewhere), tend to write lines after lines of codes by looking at the spec without realizing the purpose. They tend to forget that the codes produced by them are also intended to run at some point of time. So, they code, and they code, only to realize at the fag end that all those beautifully thought out lines are of no use, because those did not get compiled in first place. Even if those were lucky enough to get compiled, those didn't run. For those luckiest fellows, even if it ran, it did not run as desired. The bottom line is, all those effort had been meaningless. For these developers, TDD brings in a gentle reminder in its name itself: Guys, don't just code; do some testing as well.
Test harness and test bed preparation concepts have been around for a while, primarily to boost the developer's mind and encourage them to do testing. At a latter stage, the professional testers took these two terms to a more sophisticated level by incorporating theories and mature practices. Nevertheless, if we still consider the older practices, all it talked about was unit testing of the codes after completing the code writing of the smallest possible unit (say, a method within a class). While the development is on, the same test on the same unit is to be repeated many times since the new codes are getting developed and interlinked with the existing ones. Instead of putting the developers into the rigor of manual repeats of the same tests, they were encouraged to write test codes so that the testing could be done by the programs. Historically, these were the first attempts in asking the developers to eat their own cooked food.
TDD formalizes the process from a different perspective. TDD assumes that the developer is not required to develop codes that would be perfect in all counts. Rather, it initiates the idea of developing codes that would pass the fitness tests employed, doesn't necessarily would pass with flying scores. To put this into implementation, it says the developer to develop just enough codes to pass the test cases. The diktat puts the developer to write the test cases first, then do the development, and do the development in such a way that it passes through the test cases. Sometimes, the developer doesn't write the test cases still, a tester writes the test cases for him/her. The developer then uses those test cases to conduct his testing and remain compliant to TDD.
I am not too sure if the image above is readable enough, so you may need to click on it too see the big picture. This is the so-famous diagram depicting a classic TDD. The process addresses the requirement preparation, followed by test cases preparation for customer and developer. By customer test cases, we can safely assume to be UAT cases or business cases. From left to right it starts from requirements, test cases, and the last block is for development. The backward direction indicates successful completion of each of these activities, i.e. after the code getting developed passes through the developer test cases successfully, and so on.
I have already talked about the benefits of the unit testing before code release, and the diagram shows how TDD implements that. There is a significant risk too. The success of the codes depend on the adequacy of the test cases and its coverage of the requirements, both explicit and implicit. With this, the developer gets tempted to pass the test cases instead of looking into the overall objective in mind. For a business consultant, this may be far detrimental than it sounds since the consultant is also expected to keep the respective business objectives in mind. Fortunately, the lack of coverage gets detected when the customer sits in for testing. The flip side is that the customer would need to sit in for testing same piece several times, and this would dilute the overall value proposition of your institutional ability to deliver a solution for business. The only emphasis I would like to make here is not to stretch the TDD to the extent where it actually doesn't; and at the same time build this practice within your developer self. Testing your own code before release would always remain a good practice.
Tuesday, May 13, 2008
Agile Intelligence: Continuous Integration
The philosophy of continuous integration was first brought in the process of Extreme Programming. Subsequently, it been successfully deployed in several Agile development projects. Continuous Integration is a practice where the development team members integrate their work products frequently. This is more of a learned wisdom over the years than something that got developed in a lab or meeting room. Over the years, the software projects started with big promises and landed into endless integration phases with tons of rambles around. Continuous Integration aims to manage the integration mess in a better way.
Traditional development models used to keep the integration at the end of all development work. Quite often such approach turned into the eleventh hour rush of doing everything, and in many cases redoing the development of some of the modules/functionalities. The project managers were scared to death since after all those fancy progress reporting over months they were handed over with a reality of cost and schedule overrun. No matter how well and detailed the planning was, the integration phase was never smooth tide. Rather, those unfortunate fellows (who could not leave the scene before integration) ended the project with experience which they would remember in gory details for a long period.
To tackle this problem, Continuous Integration started with a hard frequency of one day. In other words, the early proponents of continuous integration aimed to make it a daily integration. Everyday, the programmers would contribute their day’s work to the shared location. At night, or on the next morning, one volunteer would take all those codes together and build those into a single application. After that happens, it would remain open to all for viewing. This would help the individual programmer to see the behavior of his/her codes at the integrated environment. This would also help the programmer to fix some (if not all) of the broken elements into his next day’s work. As a result, the next day’s contribution of the programmer would have some new developed codes as well as some fixes on the previously developed codes. Subsequent build would be expected to have fixes for some of the broken elements, and as the days progress the software application would be getting more refined collectively.
The benefit of such a practice is manifold. It provides a tangible work product for showcasing no matter how messy that could be. The project managers can breathe easy since they now can see what’s going on, as well as a big risk of software integration failures are getting mitigated in steps. The other stakeholders who are not involved with the technical stuff would also get an opportunity to see what’s getting cooked in the kitchen. The programmers also get the benefit to self-correct their own mistakes which could have become a Herculean job if accumulated till the end. It also helps sustaining the morale of the team since a lot of eleventh hour bickering can be avoided.
Continuous Integration comes with its own limitations. Since everything in a software engineering project cannot be related to the programming only, it leaves a good part of the team out of the integration practice. Project Managers practicing agile processes should do a careful planning around them to ensure that their work products too move along harmoniously.
Also, the build process can be long and complex depending upon the size and complexity of the software application getting developed. Daily Integration would require some specialized full time staff allocation to do this job, thus raising the cost of project execution. For such cases, the frequency should be rightly defined. If you are a consultant working for a client, you may be asked to prepare daily builds since the client has read it through some magazines on Agile. If you think the software under consideration is large and complex, it may be a good idea to explain the cost impact of daily builds to the client. Agile does not address the project economics well (we will talk about it later) so it’s your responsibility to bring that under client’s radar for a better cause. For most of the software applications, a twice weekly frequency (Monday morning, and Thursday morning) should be enough. For large and complex applications, take it to a weekly frequency (Friday night, or Monday morning).
Introducing Continuous Integration could be a challenge if the integration process eats up a lot of energy and enthusiasm of the team members. The Agile practitioners use and recommend using the process improvement tools for improving the situation. Maintaining a shareable code repository would be one such step. Nowadays, having source management software like PVCS, or VSS are pretty common, so ensure that it’s in place for your project too. The other important improvement would come through automating the build process. The code compilation, build preparation, and deployment should be automated using scripts and templates to the maximum extent possible; this would provide significant incentives for increasing the frequency of integration during the course of development.
Monday, May 12, 2008
Agile Intelligence: Sprint
Those who have already read through the pages of Agile Alliance and Scrum Alliance should have fair familiarity of the cycle of software engineering by now. The diagram is epic, and is widely used anywhere when there is a discussion on Agile Software development. It has been hard, but somehow I resisted myself to upload the same diagram here, but the diagram is still important for everybody to understand the core purpose of being agile.
Those who are already familiar to the diagram should be aware of the term “sprint” as well. For the others, the definition goes like this: Sprint is a time period within which the team completes the development of the backlogs committed by them at the beginning.
Those who are well aware of the software development life cycle should know that the life cycle does not contain the “development” alone. To give a software application a complete shape, development should be preceded by the analysis and design; and should be followed by various flavors of testing, bug fixing, and deployment. The proponents of Agile took a conscious attempt to fuse all these activities into a continuous set of activities, and hence they used the word “development” only to describe the activities within a sprint. However, the sprint activities does not remain confined within development only, it does have analysis, design, and testing.
Those who are well experienced with the commonly used software engineering models like waterfall or iterative should know that the duration of a phase is driven by several constraints like time to market, availability of resources, etc. Sprint, on the other hand, is fixed with duration. Its duration is 30 days. Agile practitioners around the world follow the same guidelines, albeit with some minor changes to fit their purpose. In most of the cases, the sprint starts on the first working day of the calendar month, and ends on the last working day of the same calendar months. Some take it to 30 working days, thus making a 6-week schedule corresponding to every start date. Although, people stretching the duration beyond 4/5 weeks are quite rare, and those who do so, have mastered the software engineering processes before getting into Agile. Most of the Agile development teams are charged up to show something been accomplished at the end of the sprint, and sooner the better. So it’s a self imposed restriction towards stretching or postponing the deadlines, everybody around an Agile development project know that something is getting done at the end of the sprint, which in turn is not far away on the calendar.
A software development project may have many sprints. Since the sprint duration is fixed, depending upon the size and complexity of the software application, the number of sprints varies. The sprints must be sequential, i.e., end of one sprint can only trigger the start of the next sprint. While the same team is expected to continue on the following sprints as well, the Agile methodology does not put any restriction on this area. In fact, at the end of each sprint, the product owner and the sprint master should take a joint review of the resource requirements on the following sprint(s) depending upon how much of the product backlogs should be converted into the sprint backlogs in a single sprint. End of sprint review would also help the sprint master to re-balance the team with the individual team members (e.g. somebody fell sick in the middle, or expected to go on a vacation on the following month, etc.).
Those who are already familiar to the diagram should be aware of the term “sprint” as well. For the others, the definition goes like this: Sprint is a time period within which the team completes the development of the backlogs committed by them at the beginning.
Those who are well aware of the software development life cycle should know that the life cycle does not contain the “development” alone. To give a software application a complete shape, development should be preceded by the analysis and design; and should be followed by various flavors of testing, bug fixing, and deployment. The proponents of Agile took a conscious attempt to fuse all these activities into a continuous set of activities, and hence they used the word “development” only to describe the activities within a sprint. However, the sprint activities does not remain confined within development only, it does have analysis, design, and testing.
Those who are well experienced with the commonly used software engineering models like waterfall or iterative should know that the duration of a phase is driven by several constraints like time to market, availability of resources, etc. Sprint, on the other hand, is fixed with duration. Its duration is 30 days. Agile practitioners around the world follow the same guidelines, albeit with some minor changes to fit their purpose. In most of the cases, the sprint starts on the first working day of the calendar month, and ends on the last working day of the same calendar months. Some take it to 30 working days, thus making a 6-week schedule corresponding to every start date. Although, people stretching the duration beyond 4/5 weeks are quite rare, and those who do so, have mastered the software engineering processes before getting into Agile. Most of the Agile development teams are charged up to show something been accomplished at the end of the sprint, and sooner the better. So it’s a self imposed restriction towards stretching or postponing the deadlines, everybody around an Agile development project know that something is getting done at the end of the sprint, which in turn is not far away on the calendar.
A software development project may have many sprints. Since the sprint duration is fixed, depending upon the size and complexity of the software application, the number of sprints varies. The sprints must be sequential, i.e., end of one sprint can only trigger the start of the next sprint. While the same team is expected to continue on the following sprints as well, the Agile methodology does not put any restriction on this area. In fact, at the end of each sprint, the product owner and the sprint master should take a joint review of the resource requirements on the following sprint(s) depending upon how much of the product backlogs should be converted into the sprint backlogs in a single sprint. End of sprint review would also help the sprint master to re-balance the team with the individual team members (e.g. somebody fell sick in the middle, or expected to go on a vacation on the following month, etc.).
Friday, May 09, 2008
Agile Intelligence: Backlogs
The Agile development process talks about two types of backlogs: Product Backlogs, and Sprint Backlogs. We will talk about the specifics a little later; let’s try to understand the fundamental constitution of backlogs first. Backlogs, unlike the word suggests is not about falling behind. It’s about maintaining a to-do list. A backlog is a master list of all functionalities desired in a product (software application).
The proponents of Agile development are of opinion that the details specification of a software application are not known during the start of the project. So, the obvious requirements are listed down as the product backlog. As the project progresses, the requirements get more elaborated and refined, and the product backlog grows accordingly. While such a statement does not provide enough confidence at the investor level, but works pretty nicely to the people who work on the project.
The backlogs are documented in tabular format. Each backlog has a name (or short description) to it, and a priority mark (high/medium/low) with the respect to the critical success factor. The product owner takes the responsibility to maintain and update this backlog. The product owner gets the inputs from the various groups of potential users and beneficiaries of the software application, and converts those inputs into backlogs with due priority. The product backlog does not have any other project planning attributes attached to it.
The product backlog works as the input to the sprint backlog. A sprint backlog is the list of backlog items that the team commits to deliver in a particular sprint. In a way, sprint backlog is a sub-set of the product backlog. However, there may be additional backlogs into a sprint backlog which are normally the supporting work for the sprint. Sometimes, a product backlog is also broken into multiple sprint backlogs for better granularity and distribution of work. As example, the product backlog may specify that only the employees of the organization will be able to access the software application. At the sprint backlog, this may be broken down into the login pages, authentication module, and integration with the enterprise directory. Sprint backlogs are picked up by the team members, which is largely a self-assignment process. The sprint master keeps track of the assigned work through the scrums. Scrum also helps the sprint master to fill up the start and end dates of each sprint backlog.
The webmasters of the Agile Advice website has brought in the Queuing Theory to understand the backlogs better. The theory helps the mathematical analysis and optimization of the work packages flowing from starting point to the finish line. The theory denotes the entire work package completion path using the time interval of having the work packages for start, the time required to complete the work within each package, and the number of resources (in software engineering, it should be the number of team members) available for the work packages. My personal opinion is not to focus too much on the advanced techniques at the beginning. Just apply some common sense if you are a sprint master. In case you have to apply something fancy, first focus on the principles and best practices of software project planning, tracking, and supervision.
The proponents of Agile development are of opinion that the details specification of a software application are not known during the start of the project. So, the obvious requirements are listed down as the product backlog. As the project progresses, the requirements get more elaborated and refined, and the product backlog grows accordingly. While such a statement does not provide enough confidence at the investor level, but works pretty nicely to the people who work on the project.
The backlogs are documented in tabular format. Each backlog has a name (or short description) to it, and a priority mark (high/medium/low) with the respect to the critical success factor. The product owner takes the responsibility to maintain and update this backlog. The product owner gets the inputs from the various groups of potential users and beneficiaries of the software application, and converts those inputs into backlogs with due priority. The product backlog does not have any other project planning attributes attached to it.
The product backlog works as the input to the sprint backlog. A sprint backlog is the list of backlog items that the team commits to deliver in a particular sprint. In a way, sprint backlog is a sub-set of the product backlog. However, there may be additional backlogs into a sprint backlog which are normally the supporting work for the sprint. Sometimes, a product backlog is also broken into multiple sprint backlogs for better granularity and distribution of work. As example, the product backlog may specify that only the employees of the organization will be able to access the software application. At the sprint backlog, this may be broken down into the login pages, authentication module, and integration with the enterprise directory. Sprint backlogs are picked up by the team members, which is largely a self-assignment process. The sprint master keeps track of the assigned work through the scrums. Scrum also helps the sprint master to fill up the start and end dates of each sprint backlog.
The webmasters of the Agile Advice website has brought in the Queuing Theory to understand the backlogs better. The theory helps the mathematical analysis and optimization of the work packages flowing from starting point to the finish line. The theory denotes the entire work package completion path using the time interval of having the work packages for start, the time required to complete the work within each package, and the number of resources (in software engineering, it should be the number of team members) available for the work packages. My personal opinion is not to focus too much on the advanced techniques at the beginning. Just apply some common sense if you are a sprint master. In case you have to apply something fancy, first focus on the principles and best practices of software project planning, tracking, and supervision.
Tuesday, May 06, 2008
Agile Intelligence: Story
There have been multiple traces of origins to this terminology so far the Agile programming goes. By and large the proponents are indebted to the ad makers who traditionally prepare the storyboard while creating an advertisement. The concept of storyboard was eventually borrowed by many streams of content development including those done for digital consumption. Before getting into the definition of Story in Agile Programming, let’s dig out the definition of storyboard first: Storyboards are organizers to depict a series of illustrations or images that would get composed sequentially to display the purpose with better visualization. (Multiple Internet based sources)
Now let’s look into the definition of Story: A story is a high level depiction of the user requirements, which would provide just enough information to the programmer to estimate and implement the requirements. (The Agile Modeling website)
While the similarities are quite obvious, I would like to highlight the words “high level” in the definition of the stories in Agile Programming. Depending upon how the user perceives and composes the requirements, the stories can be of diverse shape and size. However, the objective here is not to write a requirements bible, but to communicate the needs or expectation from the software application. So, the user story may well start with a bulleted list of actions to show how the business process should be. Subsequently, each of the bullet points would be blown out to a set of user screens, business rules, data units, etc. In other words stories are expected to branch out as the requirements evolve, and so is the development work.
Being discreet in providing high-level and just enough information to the programmers would ensure that more iterations happen during the course of development, thus enabling the test driven development more rigorously. Let me explain, how it works. For sake of simplicity, let’s assume that the story under consideration talks about developing one screen. The story provides just enough information so that the developer would be able to develop the UI with all the input/output controls positioned correctly. Immediately after that, the programmer would need to know the input validations to be implemented. The story-writer could have given this in the first cut of the story itself. But there would be some limitations: a) the story-writer might not have thought of all the validations that would be required; b) the programmer would have to wait till the story gets completed with the description of validations. So, the first story came out without any validations requirements. After implementing this, the programmer went back to the story-writer (or user group, or product owner, whoever are in the loop) to show his work as well as to gather some more requirements (validations). Now the story-writer could see how the UI came up, and could provide some upfront review comments on it. At the same time, the story-writer now would be able to provide more crystallized information on what kind of validations would be best fit here. With this second story, the programmer goes back to work and implements the review feedback and the new set of requirements (validations). Then comes the requirements related to the more comprehensive business rules, like how the input data should be saved, how it should be deleted, browsed, and so on. The beauty of this iterative process is it keeps the programmer and the story-writer (normally the user representative) continuously engaged with the happenings around the software development. So the risk of expectation mismatch with the users is minimized to the lowest probability.
However, it comes with a pinch of salt, too. It sets the pre-condition of having the user groups continuously engaged with the programmers. Those who work in the IT consulting space know very well what I am talking about. It’s not easy to get such a high degree of time commitments from the user groups since they too have their daily chores to take care of. To them, contributing time in larger chunks with lesser frequency would be a preferred option than what I have been writing in the paragraphs above. Such a situation creates the weakest link of failure in the Agile programming, as the lack of frequent iterations would eventually result of delayed completion of tasks.
To those who are consultants, and are doing programming for your clients (external organizations), my suggestion would be take a judgment call here. Not too high-level, not too detail-oriented may turn out to be a critical success factor for most of you, specifically those who are competing for your clients’ time as users and trying to make a killing using Agile. Nevertheless, as Agile is gaining popularity, you would also see quite a few organizations are committing larger share of the users’ time during the development of the software application.
We will talk more about such trade-off later in the following posts. Now, I would like to move on to the topic of Backlogs. For those who would like to develop deeper understanding on Stories, may go through one of the early attempts to compile the subject within a book: User Stories Applied - For Agile Software Development (by Mike Cohn)
Now let’s look into the definition of Story: A story is a high level depiction of the user requirements, which would provide just enough information to the programmer to estimate and implement the requirements. (The Agile Modeling website)
While the similarities are quite obvious, I would like to highlight the words “high level” in the definition of the stories in Agile Programming. Depending upon how the user perceives and composes the requirements, the stories can be of diverse shape and size. However, the objective here is not to write a requirements bible, but to communicate the needs or expectation from the software application. So, the user story may well start with a bulleted list of actions to show how the business process should be. Subsequently, each of the bullet points would be blown out to a set of user screens, business rules, data units, etc. In other words stories are expected to branch out as the requirements evolve, and so is the development work.
Being discreet in providing high-level and just enough information to the programmers would ensure that more iterations happen during the course of development, thus enabling the test driven development more rigorously. Let me explain, how it works. For sake of simplicity, let’s assume that the story under consideration talks about developing one screen. The story provides just enough information so that the developer would be able to develop the UI with all the input/output controls positioned correctly. Immediately after that, the programmer would need to know the input validations to be implemented. The story-writer could have given this in the first cut of the story itself. But there would be some limitations: a) the story-writer might not have thought of all the validations that would be required; b) the programmer would have to wait till the story gets completed with the description of validations. So, the first story came out without any validations requirements. After implementing this, the programmer went back to the story-writer (or user group, or product owner, whoever are in the loop) to show his work as well as to gather some more requirements (validations). Now the story-writer could see how the UI came up, and could provide some upfront review comments on it. At the same time, the story-writer now would be able to provide more crystallized information on what kind of validations would be best fit here. With this second story, the programmer goes back to work and implements the review feedback and the new set of requirements (validations). Then comes the requirements related to the more comprehensive business rules, like how the input data should be saved, how it should be deleted, browsed, and so on. The beauty of this iterative process is it keeps the programmer and the story-writer (normally the user representative) continuously engaged with the happenings around the software development. So the risk of expectation mismatch with the users is minimized to the lowest probability.
However, it comes with a pinch of salt, too. It sets the pre-condition of having the user groups continuously engaged with the programmers. Those who work in the IT consulting space know very well what I am talking about. It’s not easy to get such a high degree of time commitments from the user groups since they too have their daily chores to take care of. To them, contributing time in larger chunks with lesser frequency would be a preferred option than what I have been writing in the paragraphs above. Such a situation creates the weakest link of failure in the Agile programming, as the lack of frequent iterations would eventually result of delayed completion of tasks.
To those who are consultants, and are doing programming for your clients (external organizations), my suggestion would be take a judgment call here. Not too high-level, not too detail-oriented may turn out to be a critical success factor for most of you, specifically those who are competing for your clients’ time as users and trying to make a killing using Agile. Nevertheless, as Agile is gaining popularity, you would also see quite a few organizations are committing larger share of the users’ time during the development of the software application.
We will talk more about such trade-off later in the following posts. Now, I would like to move on to the topic of Backlogs. For those who would like to develop deeper understanding on Stories, may go through one of the early attempts to compile the subject within a book: User Stories Applied - For Agile Software Development (by Mike Cohn)
Monday, April 28, 2008
Agile Intelligence: Scrum of Scrums
With the rising popularity, the Agile methodology started getting applied in almost everywhere. The project sponsors and some other stakeholders in many organizations were bought into it pretty quickly; not much due to the fascinating stuff Agile brought in, but the scars left by the traditionally approached and failed projects. Very soon, the large projects started with agility have been caught with an unprecedented reality: the overhead of communication.
So far, Agile methods fostered communication in all direction, and in small projects with small number of team members, that worked quite well. As the size grew, the numeric formula of 2n-1 started taking toll that was due. By and large, the project management practitioners take the project communication very seriously. Each project plan comes with a communication plan, be it a software development project or a stadium development project. The project managers take a meticulous measurement of the communication cost in terms of hours and infrastructure (long distance and international calls) spent. Accordingly, the project team structure and the communication plan have been devised for traditionally approached projects. For the projects following Agile methodology, the communication channels active would be 2n-1, where ‘n’ being the number of team members, stakeholders included. This means, a 4 member team would create 15 communication channels, and a 12 member team would create 4095 number of channels. As you know, the team size can grow even larger for large scale implementation work, and this theory of Scrum may wreck a havoc, to put it mildly.
The proponents of Agile methodology were quick to respond. Instead of trying to pester with the same technique, they quickly brought in the age-old method of communication clustering; this time under the guise of Scrum of Scrums. In a nutshell, Scrum would be held within the small workgroup or team formed on the basis of the geographic location and modules they work on. The Scrum Master of each Scrum would then assemble in another meeting to discuss the same topic, albeit with a different phrase. Instead of asking how the individual has been doing, the questions would focus more towards how the team has been doing. Accordingly, a set of 5 questions have been formulated –
1. What did your team do during this period?
2. What will your team do in the coming period?
3. What are the obstacles on your team’s way to completion?
4. What are the tasks that your team will put forward for other team(s) in the coming period?
As you can see here, the fourth question comes with a lot of relevance. This question now addresses the collaboration need among the teams. One team finishes a certain work (say, development of a module/screen) and hands over to another team (say, for integration) is a common phenomenon in a project, and the fourth question is set to address that. With the answers provided by each Scrum Master on this question, the other Scrum Masters would get to know the tasks they are going to get assigned in the coming period.
Another important shift was on the change in frequency. Scrum takes place everyday, and hence the questions are about yesterday and today. Scrum of Scrums are not meant to be an everyday affair, so it talks about the last period (i.e. the days between last scrum and the present scrum), and the coming period (i.e. the days between the present scrum and next scrum). That brings an important question: what would be an ideal frequency? The answer to this varies widely. The early proponents of Agile still believe a daily frequency should be the ideal dose. The practitioners who are transitioning into Agile from traditional approach thinks it should be much less; they are grouped into twice weekly and once weekly frequencies. Once weekly frequency practically imitates the traditional project progress review meetings, while the twice weekly frequency provides more substantive discussions among the Scrum Masters, not necessarily all those would be relevant.
I would recommend the readers to visit the same Scrum Alliance website to read more about the latest happenings in this area, while I would like to proceed on stories.
So far, Agile methods fostered communication in all direction, and in small projects with small number of team members, that worked quite well. As the size grew, the numeric formula of 2n-1 started taking toll that was due. By and large, the project management practitioners take the project communication very seriously. Each project plan comes with a communication plan, be it a software development project or a stadium development project. The project managers take a meticulous measurement of the communication cost in terms of hours and infrastructure (long distance and international calls) spent. Accordingly, the project team structure and the communication plan have been devised for traditionally approached projects. For the projects following Agile methodology, the communication channels active would be 2n-1, where ‘n’ being the number of team members, stakeholders included. This means, a 4 member team would create 15 communication channels, and a 12 member team would create 4095 number of channels. As you know, the team size can grow even larger for large scale implementation work, and this theory of Scrum may wreck a havoc, to put it mildly.
The proponents of Agile methodology were quick to respond. Instead of trying to pester with the same technique, they quickly brought in the age-old method of communication clustering; this time under the guise of Scrum of Scrums. In a nutshell, Scrum would be held within the small workgroup or team formed on the basis of the geographic location and modules they work on. The Scrum Master of each Scrum would then assemble in another meeting to discuss the same topic, albeit with a different phrase. Instead of asking how the individual has been doing, the questions would focus more towards how the team has been doing. Accordingly, a set of 5 questions have been formulated –
1. What did your team do during this period?
2. What will your team do in the coming period?
3. What are the obstacles on your team’s way to completion?
4. What are the tasks that your team will put forward for other team(s) in the coming period?
As you can see here, the fourth question comes with a lot of relevance. This question now addresses the collaboration need among the teams. One team finishes a certain work (say, development of a module/screen) and hands over to another team (say, for integration) is a common phenomenon in a project, and the fourth question is set to address that. With the answers provided by each Scrum Master on this question, the other Scrum Masters would get to know the tasks they are going to get assigned in the coming period.
Another important shift was on the change in frequency. Scrum takes place everyday, and hence the questions are about yesterday and today. Scrum of Scrums are not meant to be an everyday affair, so it talks about the last period (i.e. the days between last scrum and the present scrum), and the coming period (i.e. the days between the present scrum and next scrum). That brings an important question: what would be an ideal frequency? The answer to this varies widely. The early proponents of Agile still believe a daily frequency should be the ideal dose. The practitioners who are transitioning into Agile from traditional approach thinks it should be much less; they are grouped into twice weekly and once weekly frequencies. Once weekly frequency practically imitates the traditional project progress review meetings, while the twice weekly frequency provides more substantive discussions among the Scrum Masters, not necessarily all those would be relevant.
I would recommend the readers to visit the same Scrum Alliance website to read more about the latest happenings in this area, while I would like to proceed on stories.
Monday, April 14, 2008
Agile Intelligence: Scrum
When I look into the roads through which the Agile framework has been evolving, it points back to a multiple source of managing software development. Like a project manager on any other mission, the peers in the field of software development also realized the importance of instituting a process. Thus there is Scurm, the process to address the complexity of software development by implementing inspection, adaptation, and visibility requirements in a simple set of rituals. It implements a simple iterative process skeleton which hangs on its own practices. At its core, lies a daily ritual of all-hands meeting to allow everybody to open up their hearts and deep (dark) secrets of their coder life.
Referring back to the classical way of managing projects, and the best practices recommended by the apex PM bodies; such a ritual fits within the project communication management. While the project communication management outlines a comprehensive set of methods and standards to address the communication requirements across the hierarchies, Scrum is largely focused for the people to whom the said project is the primary responsibility.
Being simple in approach, it makes the communication in a peer-to-peer format. Each Scrum starts with a Scrum-master who is tasked to ask 3 questions to everybody:
1. What did you do yesterday?
2. What will you do today?
3. What are the obstacles on your way to completion?
Each member of the project team is to answer these questions, in its most brevity possible, and the Scrum ends there. The collection of the responses form the progress made so far, the anticipated progress to be made in the next one day, the risks/issues in action.
The responses for the third question are particularly very interesting. This is the time the team members (read coders) are asked to open up. More they bring out their problems in hand, more transparent the project becomes. While Scrum does not offer the scope of problem solving right there, it facilitates the agreement of helping each other for problem solving. As example, when a developer is having a particular problem, another developer in the same room may have already overcome with an innovative solution. Scrum facilitates to have an agreement of getting this problem resolved on the same day. Similarly, when two (or more) developers are having the same problem at the same time, Scrum facilitates to have an agreement of joint attempt of resolving the problem instead of trying it from different silos.
The trick here is the culture of opening up. Programmers, by nature, take enormous amount of pride of accomplishing a complex programming problem. When they hit a problem, quite naturally, they try to own that and try to solve that by themselves. Not all programmers are comfortable enough to state a problem with the expectation that somebody will bail them out. Although, the Scrum master is tasked to ask a set of questions, this is the area where he/she needs to overcome the mere role of facilitator, and take a deeper interest in helping to get the problem uncovered. Similarly, there are team members who would describe their problem(s) with such details that it may appear to be very high on severity and complexity. The Scrum master also needs to ensure that such problems are discussed with their due priorities.
While writing this post, I came across two very good documents on Scrum. Both impressed me with their clarity and brevity in describing this practice and it fits well into your busy project life:
- Agile Meetings by Linda Rising (http://members.cox.net/rising1/Articles/STQE.pdf)
- What is Scrum by Ken Schwaber (http://www.scrumalliance.org/system/resource/file/275/whatIsScrum.pdf)
Monday, March 31, 2008
Agile Intelligence: While I was Sleeping
I wasn’t really sleeping but otherwise engaged. I was focused on the software development using Microsoft tools; old and new. I spent most of the time in looking into how a project can be brought to more close to the quality processes, and on continuous improvement on delivery. So, when a sound from the rugby field hit me right at my workplace, I, frankly speaking, shrugged it off. After all, borrowing murky words from a different area is an old practice to draw attention within the software community; the list is practically endless.
With the time, I started hearing it again and again. Our classical concept of waterfall model has got faded quite some time back. The iterative approach of software development came into practice and has been thriving a lot. Although the commonly accepted process guidelines like CMMI standards don’t exactly specify what methodology to follow, many of its processes work better with iterative model.
On the side, the attempt to find out something different went on. Started with Extreme Programming, it started to take shape into more explicit and recognizable form. The name Agile Programming probably came much later with some solid implementation successes. And with success, the noise level amplified. Finally, the day had come when I have started to follow the Agile Programming; the days to scream in a Scrum.
In this series of Agile Intelligence, I will blog my learning on Agile Programming so far, and to see how our own delivery processes can fit with it. While, I am not too sure how frequent I will be in writing this, but I will certainly look for your comments on Agile Programming as I blog forward.
Meanwhile, I must recommend you go through the website of Agile Alliance. It’s a good one to start with.
With the time, I started hearing it again and again. Our classical concept of waterfall model has got faded quite some time back. The iterative approach of software development came into practice and has been thriving a lot. Although the commonly accepted process guidelines like CMMI standards don’t exactly specify what methodology to follow, many of its processes work better with iterative model.
On the side, the attempt to find out something different went on. Started with Extreme Programming, it started to take shape into more explicit and recognizable form. The name Agile Programming probably came much later with some solid implementation successes. And with success, the noise level amplified. Finally, the day had come when I have started to follow the Agile Programming; the days to scream in a Scrum.
In this series of Agile Intelligence, I will blog my learning on Agile Programming so far, and to see how our own delivery processes can fit with it. While, I am not too sure how frequent I will be in writing this, but I will certainly look for your comments on Agile Programming as I blog forward.
Meanwhile, I must recommend you go through the website of Agile Alliance. It’s a good one to start with.
Subscribe to:
Posts (Atom)