Agile Project Management - The Scrum technique

I Agile Project Management - Background

It is no longer adequate to have the best ideas popping into your or your team's brains.

The team that capitalizes on brain-power the most is the team that is the first off the block to bring their brilliant idea to the market.

This idea positions itself in the form of a product/service that is panacea for the public or a niche segment of the public.

Having done so, the winning team does not allow any breathing space for the competition to catch up; and keeps delivering newer and more enhanced solutions at a pace that creates a distance between them and the runner-up both in terms of market penetration (top line) as well as profit-after-tax (bottom line).

Sounds like a dream? Well, such is the stuff of all corporate dreams. Breaking new paths, and building such a scorching pace that a dominant position is achieved and maintained - is what every business warrior aims for.

Agile Project Management methods and practices in project management are an attempt to answer the prayers of these warriors. Scrum is one such method.

Agile Project Management methods and practices strive to break the major bottleneck of customer / stakeholder response - when the project slides off the assembly line into their hand - which is usually anything but encouraging.

Their usual responses range from disappointment at “receiving something that is short of their expectations”, to very merrily stating that their “specifications have changed in the interim”.

These Agile Project Management practices encourage the stakeholders to take part in the development process early on in the game; and instead of expecting them to play the role of a “passive commentator/recipient” at the end of the process; they seek their “proactive participation” throughout the process.

From “passive commentator/recipient” to “proactive participation”: the stakeholder can not only guide the development as per their expectations, but also any changes in specifications can be incorporated while there is still time.

II Agile Project Management : Scrum, defined

This method was first proposed in an article in the HBR, January 1986, issue. Written by Hirotaka Takeuchi and Ikujiro Nonaka, the idea propounded here was elaborated upon further in their book - “The Knowledge Creating Company”, published in 1995. Ken Schwaber and Mike Beedle have fully described this agile method in their book “Agile Software Development with Scrum”, published by Prentice-Hall in 2002.

In this method, the project manager is given a set of resources to work with. They then proceed to build a goal-line: a list of goals that incrementally build upon the cumulative output of preceding goals. The project thus gets developed in iterations.

Each such goal is called a “sprint”, and for each sprint, resources in terms of manpower, infrastructure and money are allocated. The duration of a sprint is usually fixed - typically it is 30 days. Goals are designed such that they are realistically completed within this time frame. Once work has been fixed for a sprint, any additions/changes to the targeted functionality can be done only by the team’s participants.

The entire project is viewed as “backlog” from the very beginning. All work to be done immediately preceding a sprint is viewed as a backlog. The project manager themselves are given a different label: that of “Scrum Master”. Alternatively, there may be one overall project manager, with group/task leaders functioning as “Scrum Masters”. A Scrum Master manages the sprint, and is responsible for its successful outcome.

Within the 30-day sprint, the Scrum Master conducts a daily “standup” meeting, lasting all of fifteen minutes, in which each team member is supposed to have answers ready for questions such as:

• What were your activities since the last Scrum meeting?
• Are there any obstacles in the way? Is there anything that might hold things up?
• What will be your activities before the next such standup meeting?

Near the end of each sprint, a release review meeting is held, that compares the goal of each sprint against what actually is getting delivered. A “potentially shippable product increment” is then released to the stakeholders. Note that it is “potentially shippable”, and may not necessarily be actually shipped.

From the above, it is clear that each activity is time-bound, expecting all players to be ready with pre-defined deliverables at each step of the process.

The project manager typically plans the project such that the sequence of product design, development, testing, documentation (which is ideally meshed-in into every stage), implementation, and hand-over to user is broken into a series of sprints. Each sprint delivers some output that is objectively measurable, and which the stakeholder can comment upon (“falling below/meeting expectations”, or “specs have changed; so please amend this spec here”).

III Benefits of Agile Project Management (Scrum)

Scrum delivers some objective evidence of functionality, quality and fitness in an iterative manner to the stakeholder. Since these are eminently measurable, they have an advantage over traditional development cycles where the results are not visible until quite late in the game, when considerable man-days of effort have been expended.

IV End Word

Scrum as an Agile Project Management technique flies in the face of traditional, waterfall-cycle-wisdom that expects specifications to be engraved in stone before the project has started. It also scorns at the presumption, that allowing specs to be changed; and attempting to incorporate the changed specs in the course of the project is an expensive affair.

Finally, Scrum begins to show tangible results early on. The project manager can actually visualize in real terms where and how the project is heading.

Return to Software Project Management