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.

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.

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.

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:

1. There is not enough experienced hands to code any more, since the team size is bigger.
2. 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:

1. 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.
2. 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.

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.