Tag Archives: project management

Scalable Agile Frameworks – The Agile Practice Guide

– Back to the Agile Practice Guide (all) –

We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. There are core frameworks and auxiliary frameworks that you will come across on your Agile journey.  Depending on the organization or the team that you work in, usually someone will be using some of these methods.  You don’t have to use all of them, as often many of them have the same core practices underneath such as visual management, daily stand-ups, having a product owner, and grooming a backlog.

It’s really useful to know the actual frameworks and the names that
people might be using to refer to them, just so that you can keep up with the conversation and also understand what’s happening underneath – the underlying principles behind these methodologies. This one we’re going to look at involves Scaling Agile methodologies. We’ve got Scrum of Scrums, the Scaled Agile Framework, we’ve got Disciplined Agile, and we’ve got Large-Scale Scrum.

Check out the video and the article below!

Scrum of Scrums

With Scrum of Scrums, it is similar to Projects, Programs and Portfolios. If you’ve worked in project management you’ll know that we’ve got portfolios at the high level, then we’ve got programs underneath that, and we have a number of projects underneath that. It’s just a really high-level approach to managing a portfolio of work.

Scrum of Scrums is conducted when we’ve got two or more teams, usually of three to nine people (most often in a scrum team we’ve got three to nine people so it’s not too big but also not too small) and we’re needing to coordinate all of the work across those teams. A representative from each team will attend a meeting with other team representatives around three times a week. This is very similar to the daily standup but not quite – it’s just a method of keeping everyone on the same page across streams. That representative from the team will attend the meeting with the other representatives from their teams three times a week to report on their completed work, their next set of work, any current blockers in their work and potential upcoming blockers.

This is a really good practice and it’s good to see what other teams are doing.  Keeping that
communication line open is important when you’ve got multiple streams of work all working towards similar dates or similar deliverables. The goal is to ensure that our teams are coordinating their work and removing blockers across teams, not just within the team itself.

The way it looks is you’ve got your Scrum teams of between three to nine people. You might have multiple Scrum teams so then one of these representatives will come and report to the Scrum of Scrums meeting three times a week. Then once a week we’ve got the Scrum of Scrum of Scrums – similar to that portfolio level.

Scaled Agile Framework (SAFe)

As part of our Scaling Agile frameworks we’ve also got the Scaled Agile Framework, or SAFe.  SAFe basically helps with detailing practices, roles and activities at the portfolio, the program and the project levels, similar to our scrum of scrums.

It focuses on organizing the enterprise around value streams, that provide value to the
customer. We’re focusing on the customer’s point of view.  These programs that we’ve got and the projects within them provide this particular piece of value and it’s basically with the end customer in mind, so everything is all organized around that value to the customer.

The principles are to take an economic view, to apply systems thinking (so to understand that this small piece in the system will affect the bigger cog in a system will and so on), in other words nothing is done in isolation and we always think about the consequences of even the smallest actions.  Assume variability and preserve options, building incrementally with fast integrated learning cycles.

Does that sound familiar?  That’s definitely an Agile principle – we’ve got our iterative approach, we’ve got our incremental approach, all of these things help us get stuff into the
hands of our customers quickly.

We want to base milestones on objective evaluation of working systems. This is Continuous Integration where we’ve got all of our changes going up into the one
environment so we can see whether it’s working or not, and we can see that on a daily
basis.

We want to visualize and limit the work-in-progress, reduce batch sizes, and manage queue lengths. Now that will be familiar to you as well with the visual management approach of Kanban.  We’ve got the Kanban board and we can clearly see the work and whether it’s flowing through the the value chain, or our team value chain, from the backlog on the
left to done on the right.  We can clearly see whether it’s flowing or whether it’s stuck.

We want to apply this cadence for synchronizing with cross-domain planning, and that is where our scrum of scrums will come into it. So now we’re planning with other teams and we’re helping other teams remove blockers, and we’re making sure that we know what’s
happening across streams as well.

We want to unlock the intrinsic motivation of knowledge workers.  This is something that I haven’t seen mentioned in any other part of Agile, but it really is a core part of Agile. In fact the all of the practices that we perform as an Agile team and their core methods will actually help unlock that intrinsic motivation.  That’s where you’re motivated internally as opposed to just motivated by money or a bonus or something similar like that.  We’ve got things like checking in with with our team and making sure that everything is really clear, helping bring meaning to the work by making sure the work is connected to the customer.  All of those things really help with the intrinsic motivation.

We’ve got decentralizing the decision making, and that comes across with our whole team approach where we have all the people involved, not just you know one person or one team.

Large Scale Scrum (LeSS)

As part of our scaled Agile frameworks we’ve got Large Scale Scrum, also known as LeSS.  LeSS aims to organize several development teams towards a common goal by extending the Scrum method across teams, similar to scrum of scrums.

Because of that you’ll see some similarities between LeSS and Scrum and some LeSS techniques have been added to scrum.  These similarities we’ve got one single product backlog, we’ve got one definition of done for all teams so everyone is on the same page. We’ve got one potentially shippable product increment at the end of each sprint (and we’ve touched on that many times we’ve got a sprint of two to four weeks and we’re showcasing an increment to the customer at the end of that so that they can see whether we’re on the right track or not and that’s our potentially shippable product)

We’ve got one product owner, who is someone representing the customer.  We’ve got complete cross-functional teams – that’s our T-shaped person, our generalizing specialists with one specialty area and many general knowledge areas.

We’ve got one sprint and sprint planning is more formally divided into two parts of what
and how.

We’ve got organic cross team coordination, we’ve got overall cross team refinement (an overall retrospective focused on cross team improvements). This is where we take all of those normal scrum methodologies and we apply them across all teams. For example that retrospective where we can get all of our teams together and say what’s working well
across our teams, not just within the one scrum team itself.

Enterprise Scrum

Enterprise scrum is a framework designed to apply the Scrum method at an organizational level, not just at a single product development effort.

It advises leaders to extend the use of scrum across all aspects of the organization and to generalize the scrum techniques to apply easily at those various levels. We are wanting to scale the scrum method with supplemental techniques as necessary – core principles like stand-ups, retrospectives, Kanban boards and visual management, having iterations and
increments and all of those things.

In other words we’re not precious about which scrum techniques we’re using, but we can add to them whatever we feel works for our teams as long as it helps us scale that method across teams.

Disciplined Agile

Lastly for our scalable methods we’ve got Disciplined Agile.  DA is a process decision framework that blends various Agile techniques based on the following principles:

  • People-first
  • Learning oriented where we’re encouraging collaborative improvement,
  • Full delivery lifecycle, where we’re promoting fit for purpose life cycles
  • Goal driven, where we’re tailoring processes to achieve specific outcomes so we’re looking at results over the process – that’s one of the core things you’ll see in Agile come back time and time again.
  • Enterprise awareness, where we’re offering guidance on cross departmental
    governance.  That means we’re still managing across teams whether it’s by
    any of these scalable techniques that we’ve seen or just a scalable scrum
    technique that seems to be really the core common denominator across all of
    these scalable techniques.
  • Lastly, Scalable, covering multiple dimensions of program complexity and doing that in such a way so using the Agile techniques where we’ve got Visual management across streams and Scrum or stand-ups across teams

All that can help us scale this this approach and help all of our teams work together.

And those are the auxiliary methods and the scalable methods of Agile.

– David McLachlan

– Back to the Agile Practice Guide (all) –

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

Leadership CardsView 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.

Kanban – The Agile Practice Guide

– Back to the Agile Practice Guide (all) –

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

The reason we’re looking at these is because there are many different methods that you’ll come across in your organization on your Agile journey, and there are many core methods that you’ll come across and also many auxiliary methods that you’ll come across as well. It’s important to know what they are, and a little bit behind them so you can match them up to the core methods and see whether a team is truly Agile or not. This one in particular is Kanban.

The Core Agile Framework of Kanban

Kanban translates to “visual sign” or “card” in Japanese. It has come from the Toyota Production System so it’s got decades and decades of proof behind it in a production environment, and now it’s found its way into technology and project management and even enterprise management as well.

It’s a form of visual management, and it comes from Lean manufacturing for monitoring the Work In Progress. It enables “Pull” and “Flow”, which are two key Lean concepts. The Lean concept of Pull means that we pull the work when we’re ready, so we never have too much work on our plate – we’re never overburdened.  It was traditionally used for inventory, so we would never have too much inventory (which is basically money just sitting there in a manufacturing plant, in a business sense) but it’s the same for technology.

Continue reading Kanban – The Agile Practice Guide

Collaborative User Story Creation – The Agile Practice Guide

– Back to the Agile Practice Guide (all) –

The Agile Core Practices

There are certain core Agile practices you might be doing as a team – and not necessarily calling yourself Agile or using the framework names, but still working in an Agile way. Knowing these core practices is a great way to get a deeper understanding of Agile as an approach.

One of the best places to update your skills in Agile is from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. This one in particular is collaborative user story creation.

Collaborative User Story Creation

With collaborative user story creation, it’s important because poor specifications are usually a major reason for project failure. We may have specified what the customer wants, and then when they actually get their hands on it they may actually have wanted something different. Or we may have misinterpreted what they wanted in the first place. Al of this results in them not really being happy with the end result. So poor specifications are often that major reason for project failure.

In Agile development, user stories are written with with a lot of the people involved, from the customers through to the people creating the product. We’ve got the developers who are developing our product, testers, business representatives or the product owner in the whole team approach. We have frequent informal reviews of the things that they’re creating just to make sure that they’re right, and everyone who needs to be is always involved.

Continue reading Collaborative User Story Creation – The Agile Practice Guide

Daily Stand Ups – The Agile Practice Guide

– Back to the Agile Practice Guide (all) –

Daily Stand-ups

There are certain core Agile practices that you may already be performing as a team – and if not they are very easy to start.  Direct from the Agile Practice Guide, and by the Project Management Institute and Agile Alliance, this is a guide to daily stand-ups as they relate to Agile and Agile project management.

Check out the video and article now!

What is a daily stand-up?

Daily stand-ups are short meetings to update the team on what we’ve done since the last meeting, and what we intend to do before the next meeting. The intention is also to help remove any blockers and make sure everything is flowing nicely. In that way a daily stand-up is a short meeting that’s used to micro commit to each other as the whole team. With the whole team approach we’ve got everyone involved in the one place – it’s a cross-functional team. Everyone necessary is in the one place to produce this product or complete this project, so when micro committing to each other and uncovering and removing blockers we’re raising them in this short meeting called the daily stand-up.

Continue reading Daily Stand Ups – The Agile Practice Guide

Different Project Lifecycles and When to Use Them – Agile and Waterfall

– Back to the Agile Practice Guide (all) –

Project Development Lifecycles

Project Lifecycles: The Agile Practice Guide

Do you know the different types of project lifecycles you can use to manage your project, develop a product, or bring a change about in a company?

The Agile Practice Guide goes into four main project lifecycles: Waterfall, Incremental, Iterative, and Agile.  There is also “Hybrid” – a combination, which many companies end up using.

Check out the video for details on them now!

There are Many Different Project Environments

In the video, we’re looking at the different types of project life cycles and when we might need to use them.  The reason we’re doing this is because there are many different types of projects, different environments they operate in, and projects are often very different.

We might have different organizational structures – for example it might be PMO controlled or it might be functional manager controlled, it might be just within one team or within many departments.  There are different life cycles involved in how to manage those projects, there are different  management styles, different sizes, different customer needs and requirements, different products or outputs, and the list really does go on.

You might also have co-located teams or dispersed teams you might be governed by a supportive, controlling or directive project management office, or the functional manager of a team.  Your sponsor or customer might want daily reports, weekly reports, or they may just have a completely hands-off approach and want you to do the work and report in once it’s done.  You may have more than one customer group receiving the benefit of the project which can really complicate things, and of course the project may be technically simple simple or technically complex.

Now all of these things combine into what we look at as the project having easily definable work or high uncertainty work and that’s the difference where the different life cycles and the ways of managing a project comes into it.

Continue reading Different Project Lifecycles and When to Use Them – Agile and Waterfall