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.
Saturday, July 12, 2008
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.
Subscribe to:
Posts (Atom)