Tag Archives: David McLachlan

We’re looking at the Agile Practice Guide from the Project Management Institute and Agile Alliance. This one in particular is “Evolving the organization.”

Check out the article and video below!

Evolving the Organisation

When we say evolving the organization, really what we’re talking about is bringing Agile into an organization in a way that also uses the Agile methodology. Maybe traditionally you’ve been using a more linear approach, very step-by-step, very focused and figuring out all the scope and cost upfront, and then being afraid when all that changes as the project rolls out.

But if we’re moving towards more of an Agile approach it’s really recommended that we undertake that work incrementally. In other words we’re actually using Agile, and our Agile way of putting things in the hands of our customers (which in this case is our teammates and our organization) then we’re using that to actually roll it out so we treat the change as an Agile project with its own backlog of work, and backlog of changes or Agile things that we could implement and that could be introduced to the team, based on the perceived value.

In this case our team is the customer so whether you’re leading a team or maybe you’re trying to implement it across an organization, but either way the customer in this case is other people who you’re moving the implementation of Agile onto. That means that the value has to be based on what they perceive the value to be, and that’s very important.

Iterating Towards Agile

When we’re iterating and getting that feedback from the customer as we’re implementing Agile, then we’re putting that feedback back into the process and using what works and discarding and what doesn’t. So when we are are implementing practices like Scrum or Kanban or Feature Driven Development, or maybe Scrum of Scrums across multiple teams, or many other things like the whole team approach and regular feedback using iterations – each of those changes can be treated as an experiment. They can be tested for a short period of time to determine the suitability or need, or to further refine it.

What that means is we don’t have to say “Look everyone, this is happening!” We can instead say “Let’s try it out for one or two iterations,” in this case using Agile terminology again, say four to eight weeks in total, and then let’s round back on it using a Retrospective where we ask is this working well, what didn’t work well, what did I learn and what still puzzles me during this implementation.

Then we can put that feedback back into the process.

Using the Agile Method of Kanban to Track Progress

We can also use Kanban boards to track the progress of the things that we’re implementing – showing the new approaches to use as “done” and the things that we’ve tried as or we’re currently trying as in progress. Again this is another Agile approach. We’ve got all of these things that we want to implement in the backlog – maybe we’re going to move to Scrum, maybe we’re going to use Kanban, maybe we’re going to use the Whole Team Approach or a cross-functional team and some of those will be moving those across into “in progress” and some of those will already be finished.

Assessing the Current Culture

We’ll have gone through that retrospective process to find out what worked, what didn’t work, what we want to keep and what we want to discard. Now before we get into all of this or to start implementing these changes we can assess the current culture and its readiness for a job and tailor a solution to suit.

As we’ve seen there are quite a few different methods and practices that we can use in Agile and not all organizations will want to use all of those practices. One model that we can use to find out what would suit an organization is where we ask:

Do we value exploration more than execution for example, maybe we really really just need to deliver things and we need to deliver things quickly and in that case maybe we can increment and deliver increments every two to four weeks on a regular basis. Or maybe we want speed or maybe we’ll want stability in the team. Which one is more valuable?

Maybe we want quantity maybe we want quality. And maybe want flexibility in our work or maybe want predictability in our work. This will just help us determine which of the Agile practices will be valuable from a team’s perspective. You could use any framework really when you’re figuring this out and what to use from an Agile perspective but the key point is that we want to be understanding the team. Whether it’s just going and talking to the team and saying “Hey what are you currently doing, would this work, can we use it as a test?” and we then get feedback on it, let’s work together. The whole point is delivering value from the perspective of your customer, and in this case the customer is the team.

And that is evolving the organization from an Agile perspective.

– 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.

Leadership Quote – Ken Blanchard on Servant Leadership

November 17, 2019QuotesDavid McLachlan, ken blanchard, leadership quote, servant leadershipDavid McLachlan

– See all the Leadership Quotes here –

“Servant-leadership is all about making the goals clear and then rolling your sleeves up and doing whatever it takes to help people win. In that situation, they don’t work for you, you work for them.” – Ken Blanchard

Have you heard this leadership quote from Ken Blanchard?

Ken is a well known author and coach in the leadership field, having authored over 60 books including the 13 million best seller – “The One Minute Manager”. Most recently Ken’s thoughts have turned to servant leadership, where the leader serves the team. This really contradicts most modern managers and thinking, where people believe the team should serve the manager.

In fact, both are true – read on to the end to find out why.

Leadership Quote Servant Leadership

The Rise of Servant Leadership

With the advent of Agile and Agile project management and leadership methodologies, we have seen a greater focus on Servant Leadership.

In an Agile environment, Servant Leaders have a few roles.

Servant Leaders Facilitate

Rarely do Servant Leaders dictate to the team. Instead they facilitate discussion and encourage participation. What does this look like? It looks like a leader sitting down and collaboratively deciding outcomes or goals with the team. It looks like a leader checking in every day to see how things are going. It looks like a leader sitting with the team and asking “What’s working well, what’s not working well?” and then putting that feedback back into the process.

Servant Leaders Remove Blockers

In her groundbreaking research on employee motivation and engagement, Teresa Amabile found that employees were at their happiest when they were making progress. And it makes sense, doesn’t it? Now think about your own job. How many times have you been blocked and stalled for reasons beyond your control? You might be waiting on another person or department, on a customer or a payment or in many cases on a manager themselves.

Servant leaders check in with their team every day, ask what is blocking them from achieving their collaboratively set objectives, and help them put the pieces in place to remove those blockers. Maybe it is connecting them with another person, maybe it it having a conversation with a higher level of manager within the organisation, maybe it is improving the process itself, maybe it is raising an issue to be fixed with another relevant team. Either way, servant leaders help their team make progress, and that progress makes people happy.

Servant Leaders Are Coaches, not Bosses

Lastly, servant leaders coach their team. They don’t boss people around, they don’t give orders. As a coach, they don’t need to. But what is the function of a coach? Let’s think about it. A good coach will give you a playbook – they will give you the moves on the field of play and A good coach will give you feedback on your process – not on you as a person, they will not judge – but they will tell you when you’re running the wrong way or if your stride needs adjusting or your pass is on target. They will help you adjust your process so you can continually get better at the game you are playing.

And that leads to Mastery

Lastly, you might be wondering, what is the point of all this? Improving your game, removing blockers, constant practice and improvement – all of these things lead to one of our core driving forces called Mastery of a task. You see – people will go to great lengths to master something they love, are passionate about or are good at, even when they are not being paid. So money has nothing to do with it – they are being motivated by the process of mastery itself.

That’s why people play video games, do woodwork or stitchwork, play sports. It’s also why they take pride in being “that person” who knows how to use the database, or the system, or the sales method. They have spent many hours mastering it and can take pride in their work. And that pride leads to engagement, and that engagement leads to profit.

– David McLachlan

Get the Leadership Card Deck or the Lean CX Score Book:

View All The Leadership Cards (48)

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

Get "The Lean CX Score" now, and start creating disruptors in your industry that completely annihilate your competition.

Oh and good news! You'll be improving the speed, morale and engagement of your teams at the same time. Get the Lean CX Score now.

Leadership Quote – Don’t Give Orders, Teach Them To Yearn

November 16, 2019QuotesDavid McLachlan, leadership quote, meaningful work, start with whyDavid McLachlan

– See all the Leadership Quotes here –

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” – Antoine de Saint-Exupéry

Have you heard this Leadership quote from Antoine de Saint-Exupery? He was a French writer, poet, and pioneering aviator in the early 1900s, and his quotes on leadership really hit the mark. Why?

Because only now is the research starting to reveal just how right de Saint-Exupery was.

Leadership Quote Meaning Yearn for the sea

Start. With. Why.

By now you may have heard of the famous book by Simon Sinek, “Start with Why”. In it he explains the importance of not starting with “What”, not starting with “who”, but starting with “Why” we are doing what we are doing. The overarching reason for us all to be working together is the most important thing that leads to success, profit, and engagement.

Starting with the reason for doing something is also the key to Meaningful Work, and meaningful work has been shown to improve productivity. After all, how many times have you worked on something – maybe a hobby or a task for a friend – simply because you believed it was important? While we need money to survive, money is not the main motivating factor when it comes to doing great things in our work.

Research on Meaning

One study from Wharton University also discovered that meaning had a big impact on the quality of work. Employees in a donation collection call center were allowed to speak with some of the recipients of the donations they collected. Doing that, they could see the real difference it made to people’s lives. After hearing the impact their work had, and using those stories, donations collected by those employees tripled.

They didn’t whip their employees (the classic “stick”) or pay them hefty bonuses (the often used “carrot”). They taught them the meaning behind what they were doing – they taught them to yearn.

Researchers Jaqueline and Milton Mayfield also found the power of meaning in their research on what kind of pep-talks gave rise to action. After clarity or certainty evoking language (the path of what must be done), meaning-making language gave the biggest impact to motivation and results.

Bringing meaning to your work is something that can be done for free. It doesn’t cost a cent to do, all you have to do is be willing to do the thinking up-front with your team, write down your “why” and the reasons your work is important, see the benefits your work brings, and agree to it as a team.

– David McLachlan

Get the Leadership Card Deck or the Lean CX Score Book:

View All The Leadership Cards (48)

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

Auxiliary Agile Frameworks – Dynamic Systems Delivery Method, Agile Unified Process, Behavior Driven Development

November 15, 2019Agileagile, agile methodologies, agile practice guide, agile unified process, aup, David McLachlan, dsdm, dynamic systems delivery methodDavid McLachlan

– 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.

We’re looking at this because as you go along your Agile journey, you’ll find many core methods, and people may call themselves an Agile team and use only one or two of these methods. That’s often fine as long as we’ve got the core Agile practices as part of that – things such as the whole team approach, daily doing stand-ups, retrospectives. Many teams will have some of these core methods and sometimes even some of these auxiliary methods that they’re practicing as an Agile team or an Agile company.

This one we’re going to look at is the Agile auxiliary methods of Agile Unified Process, DSDM or Dynamic Systems Delivery Method, and Behavior-Driven Development.

Check out the video and article below, now!

Dynamic Systems Delivery Method

Dynamic Systems Delivery Method or DSDM was designed to add more rigor to the rising iterative methods of the 1990s. It’s most known for its emphasis on constraint-driven delivery, which sets Cost, Quality and Time in the beginning and then uses formalized prioritization of scope to meet those constraints. In other words, it’s meeting up with the Agile approach of having fixed time, where we’ve got our fixed time boxes of two to four weeks depending on what your team has arranged or has agreed on and then a set time frame for delivering the product. The cost might be fixed as well, and the quality – we always want high quality and that needs to be fixed within an Agile team. However, we can adjust the scope as we go along. And as we iterate with our product, yes, sometimes that product will change and the requirements might change when a customer sees it and just has a little bit of feedback based on what we’ve been developing.

Agile Framework DSDM Constraints

Eight principles guide the use of DSDM. We focus on the business need, and there are many different ways of doing this within Agile. The product owner represents the customer, and we’ve got reviews of the product every two to four weeks so the customer can see, feel and touch it and make sure that we’re on the right track.

We’ve got delivering on time, collaboration, never compromising quality, and building incrementally from firm foundations. We’re making sure that we understand what the main feature and the main product is going to be, as part of our feature-driven development (that you might recognise) and then building incrementally – building those features out from those firm foundations.

We’ve got developing iteratively. So making sure our customer can see it by performing those reviews at the end of our iteration. This means a customer can see what’s going on and make sure that we’re on the right track and adjust if necessary.

We’ve got communicating continuously and early – that’s part of our daily stand-ups that you might recognize, and we’ve got demonstrating. control, using the appropriate techniques and prioritization of scope.

We’re making sure that the product owner is involved and making sure the customer is involved in prioritizing the scope that they want to see, and we develop what’s most valuable to them.

Next, we’ve got Agile Unified Process or AUP as well. The intent of AUP is to perform Iterative Cycles across seven key disciplines and incorporate the associated feedback before formal delivery. So someone using AUP will have these disciplines within a release:

We’ve got the model implementation, testing deployment, configuration management, project management, and the environment. All of these are the disciplines of AUP.

But the principles guiding those disciplines are: we want to make sure that the team understands and has clarity and knows what it’s doing. We want simplicity with what the team is doing- so we don’t want complex things just for the sake of doing that. We want agility – so the ability to adjust and change quickly if needed. Focusing on high-value activities, of course we’ve seen that many times with the Product Owner getting involved prioritizing that backlog of the highest value activities for the customer. We’ve got tool independence, so things can function on their own if necessary – if one item goes down, it doesn’t bring the whole thing down. We’ve got tailoring to fit and situationally specific.

Lastly, we’ve also got Behavior-Driven Development as one of our auxiliary methods to Agile. This is another simple way of defining these stories or the features from the Customer’s point of view, and it’s a great way to define those when you’re performing collaborative user story creation. So when the whole team is getting together, creating that user story based on all the different inputs from the tester, the developer, the designer, the product owner, we make sure everyone has an input into that so that it’s a wholly created card from the customer’s point of view.

With BDD, we’ve got “Given” some initial context, “When” an event occurs, “Then” ensure some outcomes. So given this system is in this mode, when this happens then we want that to happen. And that’s just a nice way to describe it so everyone is on the same page.

Those are some more of the auxiliary methods of the Agile and lean frameworks.

– 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

Crystal – The Agile Practice Guide

November 13, 2019Agileagile, agile methodologies, agile project management, crystal, David McLachlan, frameworksDavid McLachlan

– Back to the Agile Practice Guide (all) –

These are the Agile and Lean frameworks from the Agile Practice Guide, from the Project Management Institute and Agile Alliance.

We’ve already looked at the core methods involving Scrum, Kanban, eXtreme Programming and Feature Driven Development, and these are frameworks you’ll usually find at least one of in an Agile team.

But there are many auxiliary methods to Agile as well, and some of these will be scalable methods to scale across an enterprise or an organization, not just within one team. It can now be across business teams as well.

Now we’re going to look at Crystal as part of our auxiliary methods.

The Agile Framework of Crystal

Crystal was introduced by Alistair Cockburn in his book “Crystal Clear”, and it was created at IBM in 1991, long before the term Agile was even imagined. Crystal is an Agile framework now, and it’s focusing on individuals and their interactions. This is one of the core Agile principles, and doing this is opposed to (or more than) “processes and tools”. This is the first agile principle.

As it notes it is not a set process but it’s more of a guideline for team collaboration and communication. We’ve got three core beliefs – firstly:

Technologies change techniques.
As you’ve seen, depending on what technology you’re working on or what product you’re developing you may need to adjust the technique that you’re using to develop that.

Cultures change norms.
The culture of an organization will have an effect on the norms that you have within your team.

Distances change communication.
That’s why in an Agile team we recommend the “whole team approach” – all co-located in the one place so you can just look over your shoulder and say “hey Joe, can you help me with this?” instead of sending an email or making a telephone call and not getting a reply.

Crystal is designed to scale and it realizes that each project may require a slightly tailored set of practices based on its size and its complexity. It has a few core values and a few common properties. From a Crystal point of view its core values are focusing on people their interactions, the community, their skill sets, talents and communications.

Then the common properties are frequent delivery (very traditional for Agile), reflective improvement (think of your retrospectives – asking what went well, what didn’t go well, what still puzzles me, and what have I learned?) and putting that back into the process, improving every iteration of two to four weeks.

We’ve got close communication, so that’s the whole team approach – everyone in the same place, nice and easy. Personal safety, when you feel safe as a team it’s much easier to be to be honest about what’s going on and to make honest responses to the product or to the development cycle. It’s much easier to improve as well.

We’ve got focus and easy access to expert users – usually through the Product Owner from the whole team approach, someone who represents the customer or the customer themselves. We’ve got technical environment with automated tests, configuration management and frequent integration – that’s our continuous integration core practice within Agile as well.

So you can see why all of these things match up so closely with Agile and fit with it so well, even though it may not necessarily be one of the most core practices, its methodologies definitely are part of the core methodologies.

But Crystal is also designed to scale. We realize that each project may require a slightly tailored set of practices, and this is what it means. We’ve got the sizing framework within Crystal and it’s based on a few things – the life of the project, the money of the project, discretionary money and the comfort level of the project, and then the number of people involved. So maybe we’ve got only one to four people it’s nice and small, maybe there’s a lower level of money involved, maybe it’s a short project life cycle as well this is Crystal Clear. As you can see, it goes all the way up to Crystal Red just depending on the sizing of all of these things – the people, the money, the comfort level and the number of people involved and based on those you can size and scale up the Agile approaches. We’ll see we’ve got things like Scrum of Scrums and many other scaling frameworks that can be used in larger projects or scenarios.

And that is the Agile auxiliary method of Crystal.

– 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

Feature Driven Development – The Agile Practice Guide

November 11, 2019Agileagile, David McLachlan, feature driven developmentDavid McLachlan

– 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.

As you go along your Agile journey you’ll notice that there are many different methods that people will use, and they might be calling “Agile” many different things. Usually those methods will be some form of these core methods, and maybe some part of these auxiliary methods, but definitely all of the practices that we’ve looked at like standups, iterations, using visual management. This is a good way to understand what they are, and a little bit of background so you can tell if a team is truly Agile or not. This one we’re going to look at is Feature Driven Development.

The Core Agile Framework of Feature Driven Development

Feature Driven Development is an iterative model for developing software, or it could be for developing a product. With any project, when developing a product for a customer it should add value for the customer. So it could be software or it could actually be a product as well.

It focuses on developing an overall model, building a features list, then planning by those features, designing by those features and ultimately building by those features.

So from left to right we’re:

Developing the high-level model of what we’re looking for and what we’re going to develop.
Then we develop the features list, so how would we support that here at the overall view of what we’re wanting to do. What features will we develop?
Then we plan by those features – for example how are we going to get it done?
Then we design by those features – so we design the overall product by those individual features. We build those features and then we get the feedback.

As you can see in an Agile approach we’re always getting feedback, using iterations of two to four weeks, showcasing to the customer and then putting that feedback back into the product so that we know whether they’re happy or not. When we get that feedback we go back to the beginning and we adjust the high-level model perhaps, and then we adjust the features that we might need to be building, adjust the planning that we might need to be planning for our features, and the design and so on.

This is a core framework of Agile because with Feature Driven Development we’re always developing increments, or features to showcase to our customer. Everything is designed with showcasing that feature to a customer so they can tell us if it’s what they expected or not, and we can adjust if we need to. The feature driven development activities are supported by a core set of software engineering best practices as well, and these can apply to a product or a business-side team if you like. We’re developing by feature, as we saw with using feature teams so a team will focus on a specific feature. We’re showing that to the customer and asking are we on the right track, are we not on the right track? And we’re usually doing that at the end of our iterations of two to four weeks.

We’re implementing regular builds – that’s our continuous integration policy where we’ve got all of our changes, and we’re putting all those changes up into the one environment and then we’re usually testing that, so we’re seeing if something has broken or not. And we’re doing that regularly so we know that everything is going well or not going well.

We’ve got visibility of progress and results – we’ve seen that in our Kanban board and our visual management.

Configuration management, individual class ownership, and domain object modeling, and those are your more software owns in terms but the ones at the top here will definitely apply to any project or any business side team as well as software.

And that is the core Agile framework of Feature Driven Development.

– 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

Kanban – The Agile Practice Guide

November 7, 2019Agileagile, David McLachlan, Kanban, project managementDavid McLachlan

– 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 →

Scrum – The Agile Practice Guide

November 5, 2019Agileagile, agile practice guide, David McLachlan, project management institute, scrumDavid McLachlan

– 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.

Continue reading Scrum – The Agile Practice Guide →

Demonstrations and Reviews – The Agile Practice Guide

November 3, 2019Agileagile, agile practice guide, David McLachlan, demonstrations, project management institute, reviewsDavid McLachlan

– 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 demonstrations and reviews.

Check out the video and article below!

Demonstrations and Reviews

As part of gathering early feedback, the team will complete features in the form of user stories. The team periodically demonstrates that work – the working product or the pieces that they’ve created – they demonstrate that to the customer or to the business or the product owner (remembering that the Product Owner in in the Agile Whole Team Approach represents the customer and the business).

So you could be demonstrating it to the Product Owner and they could relay that information, but usually it is best to go straight to the source and demonstrate your working increment to the customer or to the business who is ultimately getting the value that you’re creating.

Often this occurs at the end of an iteration of around two weeks to four weeks or when enough of those features have been completed into a set that’s coherent. For example maybe it takes a few of these features to be to be created to have something that a customer can see, feel and touch, and that you can actually demonstrate to a customer.

We demonstrate this increment or usable set of features so that we can start getting feedback on that increment. Team members can also get feedback that prevents them from heading in the wrong direction by using this approach, and that’s why it’s so valuable.

And that is Agile demonstrations and reviews.

– 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

Release and Iteration Planning – The Agile Practice Guide

October 28, 2019Agileagile, agile project management, David McLachlan, iteration planning, release planningDavid McLachlan

– Back to the Agile Practice Guide (all) –

The Agile Practice Guide

There are certain Core Practices in Agile that are important to understand. If you’re performing some or all of these core practices then you’re likely getting the benefits of Agile whether you call yourself an Agile team or not.

One of the best ways to increase your Agile knowledge is through the Agile Practice Guide from the Project Management Institute and Agile Alliance.

Check out the video and article below!

Release and Iteration Planning

When we’re release and iteration planning for Agile life cycles, two kinds of planning occur. In release planning, our business representatives establish and prioritize user stories for the release. Our business representative is that Product Owner role, but could also be another person who represents the business or the customer themselves who you’re doing the work for.

Part of their role involves gathering the requirements, and they’re defined as the Product Owner role in the Whole Team Approach. We gather that whole team together remember for an Agile project. They will establish and prioritize user stories for a release, collaborate with the team, and they’ll refine larger user stories (big pieces of work) into a collection of smaller stories, features or items. So different people can work on different cards and all up it’ll be a part of this larger release.

This then results in backlog preparation.

The backlog is the ordered list of all of the work, presented in a story form for the team. That story is usually “As a [role]”, “I want [feature]”, “So I can do [requirement]”.

Continue reading Release and Iteration Planning – The Agile Practice Guide →