The 3 Phases of an Agile Project

The 3 Phases of an Agile Project
By Robert Kelly

If you recall my post “3 Things to Know About Agile” then you know I am by no means an Agile expert. The majority of my experience has been managing large, enterprise initiatives that may consist of an IT function running their piece in an agile fashion. I have since taken a more hands-on, engaging role in this project delivery approach and said I would share my experiences (right, wrong, good or bad) as a traditional waterfall PM moving into the agile space. As with much of the PM profession…I am moving foward with limited training and joined a group that had zero documentation or formalized process. I find myself seeking out mentors, leveraging others’ skills and reading everything I can get my hands. I am happy to say that after 3 months, I have 3 teams with approximately 12 client projects all brought back from red. I am sharing my experience so other newbies can get an idea of the things to expect, as well as hear it in plain terms.

Ready….Set…Go!

When I receive a new project, I am given very little in the way of requirements. I am told…Client A has purchased modules 1,2 and 4 of the application. Your team needs to implement by this date, manage to these billable hours, and here is your client contact. Go. As a traditional PM, my first reaction was “Great! Where are the requirements? Did they complete a Charter? etc” As a sleeves rolled up agile PM (yes there is a PM in agile!) I have quickly learned that these few key parameters are all I needed to get going on the project.

After a quick call with the sales rep and my team to discuss the scope and relationship, I quickly engage the client. We have an initial call (30 mins) with the key client stakeholder/s to make sure we are all on the same page with regards to the scope, timing, and other key (high-level) project parameters. I run through the approach (agile approach, 2 week sprints, communication plan, etc) and tell them I going to send them some homework that needs to be received by X date. Before we hang-up, I make sure I understand who from their organization needs to be on project kick-off, that they know what /when/how of the homework, and we lock down the kick-off date.

On the kick-off we run through some of the same aspects of the 30 minute hand-off, but jump right into the demo of the application. We tell them, this is the standard but that is what this project is for…to build a platform that suits your businesses needs. We encourage them to ask questions and interrupt with comments. This is where we start to develop our requirements…clients ask if the application can do ABC, we ask what they are trying to solve for, they respond with further explanation of the business process/problem and we write down that experience or user story they need. As we work through the application and its functionality, we have a scribe creating user stories and building them out….all of these user stories develop the product backlog. Waterfall folks might call this the requirements, business requiremens documents, etc.

Stop the talking…get to work!

Now that we have developed a product backlog (wish list, requirements, etc) it is time to start development. We will have conversations around this, but have enough to get started…and this is the beauty of an agile approach. I don’t have to get bogged down in details of the details and thinking Change Management at this point. Why is that great? Have you ever painted a room and said “Wow! I didn’t realize it was that yellow!” As much as you try to whiteboard it and mock it up, you don’t know what you don’t know and can’t picture it complete until you start to see it on paper, in the screen, in your hand. Agile lets you get started with what you have and is built to embrace change and catch unknowns upfront…not months down the road when the client says “yes, that is what I asked for, but I don’t want it”

The team looks at the product backlog and starts, what we call around here… backlog grooming. This is a meeting in which, they (the team) step through the user stories and make sure everyone understand what it is asking for, consider the complexity of the work, and estimate how much effort/time it would take. Then they (the team) assign each one a number…around here they call it a story point (1-5).

Once grooming is complete, the team will meet for sprint planning. This is essentially when the team looks at the product backlog and say “I will take that one, and that one, oh yeah and I would like to work on that one”. The team gets to pick items they are familiar with, tickets that are challenging, etc. Each team members can handle approximately 20 story points per week or about 40 in a sprint (around here). You may ask about prioritization and that is where the sprints and sprint plans come into play. The PM (yes there is one) has set a general framework/expectation with the client as to what sort of functionality will be delivered (i.e. – the client facing portal to be completed in Sprint 1 and email engine generated it Sprint 2). The team is going to pull items from that backlog that fit that plan best. Sprints are usually 2 or 4 weeks of effort in which the team develops specific chunks of functionality….often call shippable. At the end of a Sprint, the team should be able to conduct what is called a sprint review. This is where the team comes to show what they have completed for that Sprint. It is either done or not, there is no halfway in agile. Additionally, there is on-going QA work that is being done so these sprint reviews go well, so you are positioning yourself well for the end run.

Another nice part of agile is that flexibility for the team. If they complete their items sooner than expected, they can go to the Sprint backlog and pull additional tickets from there. Oh yeah…Sprint backlog and Product Backlog. As mentioned, the Product Backlog is essentially the wish list of all things. A Sprint Backlog is includes the tickets that apply to that specific Sprint. Developers grab enough tickets/story points to keep themselves busy for the week….as they finish, they can grab additional tickets that are specific to the functionality/promises being delivered to the clietn at the end of that sprint.

So Agile is perfect? No lessons learned?

Like anything else in life, there are no gaurantees. At the end of a Sprint your team may not have been able to complete the work they thought or the client sees the end-game and says “sorry, not what I wanted.” At this point, items can be moved into the next sprint or one could be added on. Point being…you didn’t hear the client say that after 6 months of development and 2 weeks from a public announce. The Sprint review is a lessons learned with your client and at much more frequent intervals with the client. Waterfall could do this (we do at KPS) but most don’t…sad to say. The other item that is great, is the retrospective. The retrospective happens at the end of a Sprint and is meant fo your internal team. It is an opportunity for the team to say what is working and what isn’t…as it relates to the process, product, client relationship, etc. This is great because it allows the team to have a voice and reduces frusration among the team.

This is a blog post, not an end-all education of the agile approach. While there is certainly much more to it, I hope this proved useful in picturing how an agile project may flow. I would welcome some added comments and/or corrections from the agile experts out there, so please drop a line. Also, if you are new to agile and have some questions, drop a line. I will answer it or get a smarter person than I to respond.

Robert Kelly, PMP, is a program/project manager that does not simply track projects & populate templates, but adds-value by taking ownership and driving results. During his 10 year career, he has managed complex, multinational projects with teams of four through thirty team members at all levels of the organization (Intern through Vice President). You can read more from Robert on his blog, Kelly’s Contemplations