– Back to the Agile Practice Guide (all) –

This is the Agile Practice Guide from the Project Management Institute and Agile Alliance, and this particular one is delivering in an Agile environment.

Check out the video and article below!

Delivering in an Agile Environment

There are two things in focus when delivering in an Agile environment, and the first is the team and the project charter.  The second is the way we measure results – it can be very different than that of a traditional approach when we’re using Agile.  First let’s look at the Charter.

Charter the Project and the Team

Usually in a traditional approach using the project management body of knowledge, which goes through very set steps that will initiate a project with a project charter.  It will go through what the project stands for, what the risks are, who the stakeholders are, all those things.  It will initiate that project and kick it off.

Now in addition to that when we’re using an Agile approach, our cross-functional team will initiate with a team Charter.  What that means is you’ve seen the cross-functional team before where we’ve got the roles like the facilitator, we’ve got the product owner, and they represent the customer or the business.  And then we’ve got our cross-functional team members who are those T-shaped members who have a general knowledge of a lot of things and then one really deep specialty knowledge.  So these team members are extremely valuable because they might have one deep specialty of development and then many many general knowledge areas such as design or testing or or even leadership.  All of those different things.

Our team Charter includes the project vision or the purpose, and this is so important and it’s so wonderful as well.  Why?  Because we want to start with “why”.  Start with why is a classic book by Simon Sinek, and it’s just a wonderful way to get everyone on the same page and make sure everyone is heading in the right direction. “Why” is it that we are doing this in the first place?

Once we’ve got that, we work on a clear set of working agreements and that can involve many different things.  When we were working on the purpose and the why we ask the questions “why are we doing this project, who benefits from this project,” and what does done mean for this project?  What is the definition of done, when do we finish working?  And then how are we going to work together.  Now the best role and this can be anyone who has this leadership quality is the Servant Leader, who may facilitate that chartering process sitting down with the team, facilitating everyone, getting them working together and extracting that information from the team.

So they can put it down into words where it may have been hidden before.  The servant leader’s role is also to help coach and to help remove blockers.

Now the team charter is also a social contract.  That social contract can include things like team values, such as the sustainable pace and the core hours.  We’ve talked about the sustainable pace before – we don’t want people to be working the midnight shift and then crashing and burning the next day.  Or really going crazy one week and then having three days off sick – it’s just not sustainable, and it’s not a great way to work.  From an Agile perspective we want that sustainable pace, and we want to put that down in words.  What is that sustainable pace?  Do we have set breaks, do we have set hours, what are our core hours, are they late or are they early, does everyone get in at the same time?  All of those things, let’s write it down.

We have working agreements such as what “ready” means, so the team can take in work.  So when are you ready to take in more work?  What done means – so when are you finished that work?  And the team can judge that completeness consistently.

Respecting the time box – so they are iterations of two to four weeks, and their work in progress limits.  If the team is working in an Agile format where they’ve got cards and maybe they have limits for how many cards they can take on at a time, you don’t want all of your cards sitting in the backlog of work, but likewise you need to make sure that everyone understands when they can take on a new piece of work as well.  And that goes in the team charter.

We want ground rules, such as one person talking in a meeting at a time.  Or maybe you want a lot of discussion, a lot of collaboration at a time and maybe everyone agrees with that.  And we want group norms such as how the team treats meeting times – is everyone on time?  Or can someone miss it if they’ve got something really important on?  What are those rules and does everyone agree?

Of course you can put any other behavior that the team wants to work with or address. Maybe something has bugged someone in a previous working arrangement and they just want to bring it up and they want to say – “Hey this didn’t work well the last time or maybe this worked really well,” and they want to bring this up and that can go in the team charter
as well.

How Agile Teams Measure Results

As we’re delivering in an Agile environment, Agile teams measure things quite differently to that of a normal project.  The way they do that is that they actually measure results in the way that the project is delivered in other words the pieces of the project that are delivered, the functional pieces.

Agile favors value-based measurements, and that’s value from the perspective of our customer.  So what are the valuable pieces that our customer can get their hands on and use, and how many of those pieces have we delivered?  Instead of normal predictive measurements like Earned Value Management or Schedule Management or cost management that we could use in a more traditional waterfall approach, by measuring what is done and re-planning at each iteration by iteration there’s less room for error and more room to correct course.

And we’ll see that in the way that we measure those results with a burn-up chart or a burndown chart, and these burn up charts or burndown charts are basically these story points remaining.  As you can see we might have features and then often many smaller “stories” will make up those features.  And features can make up larger increments that we’re delivering to a customer.

The pieces of work that we’re working on as a team – maybe we have a thousand stories altogether in the in the product backlog and then per iteration we might have 20 or 30 or 50, but each time one of those stories is finished we’re marking it off on the chart, so we’re basically counting down the number of stories that we have completed.  We want to aim for a certain amount of stories so as you can see here over 10 iterations we’re wanting to
finish that amount of stories but in reality sometimes it is a little bit different.  So we can give ourselves a guide but obviously when it’s happening it might fluctuate – it might go up and down or not go at the exact pace that we want it to, because life happens and things get in the way.

So by making it visual and by measuring by the story points and the features that we’re releasing and the things that are getting done and the value that we’re adding to the customer – that is the way that an Agile team will measure results.

And that is delivering in an Agile environment.

– David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

View All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting