It has now become my habit to retort to the old and trusted sticky notes whenever I see an avalanche of pressing deadlines heading my way. I like to break down projects into individual tasks and scribble them on a sticky note. The feeling of crossing off a task, once completed, is sublime and re-anchors my motivation of getting things done. Agile project management works on more or less the same principle. As oppose to the waterfall method of project management, where tasks are completed in a strictly linear fashion, Agile Project Management enables the project team to constantly reevaluate their progress and use a combination of feedback and lessons learnt to make quick changes to the course of the project. In this way, the end result is not a shock but an outcome of a series of informed decisions.

During past couple of years, Agile Project Management has been all the rave in the software development industry. It has enabled development teams to work in the open, side by side with the business units. Instead of developing the complete product in one single go, the development teams now ship iterations of the uncompleted product. Each module released is fully functional on its own and targets a single business objective.

Power Rangers are a good analogy. The rangers themselves are fully capable of tackling bad guys on their own however when the going gets tough they come together to form a giant robot. Similarly, each module is designed to take care of a single objective however when those modules are combined together, they become a force to reckon with.

Recently I had a debate with a friend of mine over whether agile methodologies can be applied to non-IT projects. I was the naysayer in the debate. However, after some research, I am convinced that agile methodologies can and should be used in all types of projects as long as they meet the following two perquisites:

  • The project execution is not constrained by procedures written in stone. In other words, there aren’t any pre-defined steps associated with successful completion of the project.
  • The business requirements of the product or the end result could be met in phases. Even partial completion would be capable of satisfying some business objectives at the least.

The following is a step by step guide to how a project team can employ an Agile Methodology to successfully complete a project. To help readers better understand the process, I have added links to relevant sample documents. These sample documents refer to a fictitious construction project.

What follows is a diagram, illustrating the process flow of an agile project along with the recommended amount of time that should be spent on each step:

Envision Phase:

As the name implies, the first phase in an Agile Project is to create and share a clear end goal or objective and map out a route to get there. For this purpose, three documents can be of great help: Project Charter, Product Data Sheet & Team Norms:

  • Project Charter helps in the identification of Project Scope, Key Stakeholders and Team Member responsibilities and respective job descriptions. This is no different from the Charter you would create for conventional Projects. However, the budget being set aside for the project needs to be extensively researched because unlike other projects, the budget is one of the three parameters that indicate when an agile project should typically come to a close; the other two being completion of all features and conclusion of project timeline.
  • Product Data Sheet: The Product Data Sheet will remain a critical document for the entirety of the project. It will also be most frequently accessed and modified. The Product Data Sheet has information about the features of the end solution/product, benefits associated with those features, issues and the accompanying risks. It also prioritizes potential constraints to ideal project execution such as: schedule, quality, people, scope, and other resources. This serves as a compass for making crucial decisions in the future that may involve trade-offs.
  • Team Norms: Before the start of the project, all stake holders should congregate to create a document detailing how team members are expected to interact with one another. Things such as the decision making mechanism, working hours and responsibilities should be listed in this document. This is also the document where you can define the scope of influence enjoyed by different team members and explain how the team hierarchy is expected to work. Even though any kind of hierarchy is usually frowned upon in the new age management thinking however hierarchies are not always detrimental for a team. I am covered with scars of working in a team with no hierarchy and trust me, it wasn’t a pleasant experience. Too much time was wasted in making petty decisions; time which otherwise could have been spent on more worthwhile pursuits.

The above three documents are only useful if they are continuously reconsidered and revised and if they are easily accessible to every single member of the team. The biggest sin of any project or for that matter, any organization, is a restricted flow of information. In some instances things that are considered too trivial to share end up being crucial links in solving critical problems. Not only this, but information empowers teammates with a homogeneous perspective of the direction and the end goal of a project which is, without any doubt, a key ingredient for success.

Speculate Phase:

Once the Project's objectives, timeline, features and team norms have been established, it’s time for the team to enter its first sprint. Every sprint has a list of features attached to it. A sprint is basically an event where the team tries to build as many features as possible within the assigned time constraint. The feature list can be grouped together in different ways such as: business objectives prioritization, availability of resources, interdependency of features etc. With the exception of the first sprint, speculate phase also involves review of a potentially new feature list and backlog of incomplete features. The aim is to select those features which are crucial to success of the current sprint.

The team is expected to estimate the time it will take to build all the features in the sprint. The estimation usually becomes accurate as the team reaches the end of the project. However, a system to record key feature characteristics and the time it took to complete those features can be really helpful in efficient time management. Another way of getting accurate estimates is through extensive communication. Talk to everyone team member; try to get their opinion on the timeline. Refine the schedule based on team feedback.

Once the feature list has been reviewed, prioritize and agreed upon, it’s time to fold up your sleeves and deal with the nitty gritty of things.

Explore Phase:

In the explore phase, the team builds the features. There are number of different methods and tools that the team can use in order to better manage the explore phase of the sprint. The primary aim should be to track two things: Progress and Issues.

Stand ups, which are short meetings at the start of the day, are quite valuable in maximizing the team’s productivity. There are some ground rules associated with them:

  • Every team member is expected to discuss their progress from the previous day and their plan for the day ahead.
  • Issues should not be discussed during Stand-ups.
  • Everyone is given 2-3 minutes of talk time and the overall duration should be kept within 30 minutes.
  • The Team Leader should be a silent participant.

Stand Ups are a good way of analyzing the team’s position with respect to its goals and can be used as an effective way of motivating the team and reinforcing the Project's objectives. Since it’s really hard to wrap issues based discussions in a 30 minutes window, therefore they are kept out of the stand-up meeting agenda.

Another tool that can be quite useful during the Explore phase is the Task Board. You can have a five columned board with the headings Sprint, Features, in process, to verify and done, respectively. These headings are self-explanatory.

The stand-up meeting can take place in front of the task board. It is advisable to make use of sticky notes so that team members can physically move a feature through different phases while explaining their progress during the meeting.

Any issue that may arise during the Explore phase should be recorded in the Product Data Sheet. The goal is to have the issues table visible to every member of the team. All the members are allowed to make new entries in the issues table. Meetings to discuss those issues could take place either daily or weekly. In these meeting, team members are encouraged to brainstorm possible solutions for the issues. Based on the team norms the solution to the problem could either be selected by the Project Manager or decided through a voting system. Issues are linked to the lessons learned table. Therefore, after finding and implementing a particular solution, it is encouraged to note the lessons in the Product Data Sheet. In this way, overtime, the company can develop a bank of issues faced and the respective solution and lessons learnt. The benefit of such a database needs no explanation.

Adapt Phase:

Adapt phase is the part of the sprint where you identify the features that the team was unable to complete during the last sprint and record them in the features backlog list. After new incomplete features have been added to the backlog list, the next step is to organize the list based on each feature’s relative importance. The same should be done for unsolved issues in the issues list. The team should also have at the least one brainstorming session to discuss lessons learnt from the previous sprint and to reevaluate the timeline attached to the project completion.

Close Phase:

This phase is one of the most underrated phases of an agile project. The close phase is the best time to reinforce lessons learnt, reflect on team performance and identify areas for improvement. Other tasks that can be performed during the Close Phase are listed as follows:

  • Ensure vendors are invoiced.
  • Reconcile the accounting sheets.
  • Redeploy the team members.
  • Communicate overall results.
  • Ensure business benefits are monitored.
  • Provide a special recap.

Most important of all, don’t forget to celebrate your success!

Conclusion:

It is my observation that outcomes of most projects cannot be accurately analysed until some passage of time has passed since the project completion. According to Standish Group, approximately 70% of the projects undertaken last year met failure. This is a pretty demoralizing figure, however, what most people are unable to realize is that each failure is an opportunity to adapt and grow. Agile project management gives you a framework to capture a team's collective lessons. It also brings together the business and technical units of an organization which are usually separated by a chinese wall. In this way, the project objectives and most importantly the definition for success remains consistent.