– Back to the Agile Practice Guide (all) –

We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, from the Project Management Institute and Agile Alliance.

What you’ll find is that there are many different Agile and Lean frameworks and ways of describing what are essentially very similar Agile practices. We’ve already looked at the core Agile practices and traditionally you could call yourself an Agile practitioner if you were doing those Agile practices, no matter what framework you were using in an organization. That’s why it’s important to understand what’s underneath these frameworks, and also the names of the frameworks that you might come across in your day-to-day work as an Agile practitioner.

There are a handful of core methods that you’ll definitely see in almost every Agile way of work, and then many auxiliary methods and even “scalable” methods because Agile has made its way out of software development, out of production in general and into the broader organization, into the Project Management Office and across the Enterprise as well. So we’re going to start with the core methods and the first one we’re going to look at is Scrum.

The Core Agile Framework of Scrum

Scrum is a single team framework for managing product development. In a project, we’re creating a product for a customer – something that delivers value for our customer. Now, we’ve already looked at this in the core Agile practice of the whole team approach, where it really matches up to what a scrum team consists of.

First we’ve got the Product Owner. The Product Owner represents the customer – they are responsible for maximizing the value of the product. The Product Owner represents the customer or represents the business and they help “groom the backlog of work” through the user stories, usually on a Kanban board (which we will see as well). In other words they put that work, in the form of user stories, into prioritization.

They prioritize the most valuable pieces of work to deliver, from the customers point of view.

Next we’ve got the development team. The development team develops and tests the product and it’s a cross-functional team. They are self-organizing usually, and have all the roles needed to deliver the product in that one team, in that Whole Team approach again, and with those cross-functional team members as we saw in our core Agile practices they are the “generalizing specialists”.  So they’ve got many different general knowledge skill sets, but also one deep knowledge or specialty area and that might be development or design, it could be testing or could be the product itself.  And then they might have many different general knowledge areas up the top here as well – that’s our T-shaped team member.

Lastly we’ve got the Scrum Master, who is that facilitator role. They’re responsible for ensuring the Scrum processes for example, stand-ups and retrospectives and they coach the team and they help remove the blockers for anything that’s impeding the work that time.

There are a few core events in Scrum, and a few core artifacts in Scrum. First, we’ve got the Sprint.

The Sprint is the time boxed project iteration, usually of two to four weeks. This is where we are iterating towards a better product, and we’re developing something, showcasing it usually to the customer or the Product Owner and then making adjustments based on their feedback on that particular increment.

Sprint planning occurs at the start of each Sprint. The Scrum team selects the highest priority items and that’s usually driven by the Product Owner, who represents the customer.

We’ve got the daily scrum, which is your short 15-minute stand-up meeting – again a core Agile practice -and it walks through the project tasks, often done on a Kanban board which we will see more of later on.

We’ve got the Sprint review. The development team gives a demo on the product to the customer or Product Owner for sign-off. Basically we’ve done our iteration and we’ve we’ve delivered something to the customer, and the customer can say “Yes, I’m happy with that,” or “No, I’m not happy with that,” and then we can adjust and put that back into the next iteration. This stops us from having to go back once we’ve finished a complete project, finished a product and rework all of that information or rework that product at a greater cost than if we had just done it during development.

Then we’ve got the Sprint retrospective. The retrospective is at the end of a Sprint, and it’s there to improve the way of work for the next iteration. We gather as the whole team, our cross functional team members or the facilitator (that Scrum Master role), the Product Owner, and we ask:

• What went well – what are we happy about?
• What didn’t go well?
• What did we learn?
• What still puzzles us?

We take all of that feedback, and it can be anonymous if it has to be – sometimes it’s easier to give genuine feedback if we know that we’re not going to be reprimanded or come back on us in any way. Sometimes that’s necessary. But we take all of that feedback and we put that back into the process, our way of work, for our next iteration in our next Sprint.

The key artifacts as part of Scrum.

We’ve got the product backlog – now the Product Owner manages that product backlog. It’s a prioritized list of planned product items and that evolves from Sprint to Sprint. Obviously, we get the feedback from our customer. And that list will evolve, things will get done, but the product backlog and the product owner ensures that the high priority items are getting done in the eyes of the customer, and any feedback on those items is also going coming from the customer and being put back into the product.

We’ve got the Sprint backlog – the items selected during Sprint planning for the upcoming Sprint, and that’s for two to four weeks as we saw, and then we’re doing that iteration and delivering a feature, or an increment. The increment is all of the product backlog items completed during a Sprint and that’s one of those steps towards the main vision or goal. It’s usually something that we will showcase for our customer in the Sprint review or showcase. And that way the customer can get their hands on it and they can see, feel and touch it and say yes, this is great and no this just needs a little bit of adjustment and then everything can move forward nicely in the eyes of the customer.

And that is the core Agile framework of Scrum.

– 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

 

Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable. You can get the whole book on Amazon here and enjoy your own copy.