– Back to the Agile Practice Guide (all) –

Agile Core Practices

Looking at the core Agile practices from the Agile Practice Guide is a great way to see if a team is really Agile, even when they may call themselves something different.  This is direct from the Project Management Institute and Agile Alliance.

Watch the video below to find out now!

The Whole Team Approach

The Whole Team Approach means involving everyone with the knowledge and the skills necessary to ensure project success. What that means is instead of having to gather different people from all around the organization or another area to actually work on your project in little bits and pieces, we’re including them all in the one, whole team. They’re one hundred percent dedicated to the project and can really deliver much more quickly.

The team should be relatively small, as successful teams have been observed with as few as three people and as many as nine people. The reason for that is when you’ve got only three people, the communication channels are much smaller and much easier. You can’t have a lot of side conversations or a lot of extra conversations on scope, and overall the communication is much simpler. When you’ve got twenty people for example or many different people you could have conversations in many different channels, and from many different people as well.  All of a sudden the communication becomes a lot more complex.

There are many different ways that people communicate – by the water cooler, by SMS, they might pick up the phone and call someone, you might be using slack or email and all of a sudden some scope starts to creep in because someone’s had a side conversation over here.  That communication is much more complex the more people you have involved.

So a nice small team with everyone that you need to get the job done in the one place is where the whole team approach comes in.  Ideally the whole team shares the same workplace – they are co-located.  Now this co-location strongly facilitates that communication and interaction. You can look over your shoulder and say “hey Joey, did you finish that, or do you need this from me still.”  You can really get an answer quickly. You don’t have to send an email wait three days and you know and maybe not get the answer that you need. This interaction and this communication is really enhanced by having everyone in the one place.

Teams are often 100% dedicated to the delivery.

It’s been shown that when you’re switching tasks or multitasking people actually make more mistakes. There have been studies on this and it’s been proven that people lose productivity of between 20 and 40 percent. You’ve experienced this for yourself haven’t you? If you’re working really hard and concentrating on something and then you know someone comes over and says hey do you want a coffee or maybe they ask you another complex question.  All of a sudden you have to go and answer this and then you have to go back to the task that you were doing and wind up again – remember where you’re up to, get the history again.

Look at game Game of Thrones – George R.R. Martin famously re-reads his entire manuscript before he gets to writing again, so that he’s completely up to speed. The loss of productivity there is huge and it’s the same in non agile teams.

The people that we have in a whole team approach are cross-functional.

They’re people who are generalizing specialists. That means they have a broad range of skills – general skills but then one deep specialty. Now in our case it could be for a development team, and you might have the deep skill of design, but then you might have the broad skills of some development skills, you might have some stakeholder skills or some product development skills or you might have some testing skills for example. All of these things will contribute overall broadly, but your really deep area of expertise in this case is design – or it could be any other thing, for any other product that you’re developing.  That’s the t-shaped approach, or the t-shaped person that we’re looking to have within our team.

For the whole team approach itself for an agile team we’re looking at having the Product Owner who represents the customer, the team facilitator who will help facilitate daily stand-ups, help remove blockers and help coach through servant leadership for a team. And then our cross-functional team members who are our t-shaped people – “generalizing specialists”.

When you’re gathering these people to be in your whole team it’s not always easy to overcome organizational silos. We have all had them – for example we’ve got Jane with a department over here and Kelly with a department over here, Bob and and Jimmy over here and they don’t necessarily want to give up these people to go and work on this wonderful project or product that you’re creating, even if it is doing the company good.

They’re looking after their particular silo. So work with those managers and those team members to have them dedicate those necessary individuals to the cross-functional team, it will make your project much easier in the end. It’ll create the team synergy that you need and allows the organization to see how leveraging its people into these project teams and building their skills will optimize the product being built.

Now let’s look at the cross-functional team members in our whole team approach.

First of all our cross-functional team member that we were talking about before is the t-shaped, generalizing specialists. These cross-functional teams consist of team members with all the skills necessary to produce a working product or to complete the product that our project is working on in software development these cross-functional teams are comprised of people like designers, developers, testers and any other required roles that are needed to get the job done. These teams deliver small, releasable products on a regular basis – that is the iterative and incremental approach. We’re iterating every two to four weeks and we’re releasing something every two to four weeks that the customer can see, feel and touch. And then they can say if it’s working or not, if the requirements are right or not, or if it’s what they expected.

By iterating every two to four weeks we’re actually getting that feedback so that we can improve and make sure the requirements are right for our customers.

Now these people are critical because they can deliver finished work in the shortest possible amount of time with a higher quality and without external dependencies.

Next we have the Product Owner. The product owner represents the customer and generates, maintains and prioritizes the product backlog of work, to ensure the highest business value without creating waste.

Another part of Agile that you’ll become familiar with is the Kanban board. Now it doesn’t have to be a Kanban board but it’s just the most commonly used way that an Agile team will work. You’ll have the the product backlog over here and you’ll have the features, stories or cards in that product backlog. The product owner’s job to prioritize that backlog and prioritize what gets done and what gets worked on as it moves across the Kanban board, all the way to done.

The product owner is not the team lead.  They work with the stakeholders and the customers – they represent the customer and they work with the team to define the product direction – what will bring the most value. They rank that work based on the business value. Typically product owners will have a business background and bring that deep subject matter expertise to the decisions that they make to give the best outcome for our customers.

Next we have the Team Facilitator.

The team facilitator really works with another core principle, and that is servant leadership.  Also known as a servant leader, they can also be called a project manager, a scrum master, a project team lead, a team coach, team facilitator or many other different names that people might call them, but they are all essentially the same thing – that servant leadership role.

The servant leadership role really focuses on things like facilitation – facilitating the daily stand-up meetings. Those daily stand up meetings help a team micro commit to each other and we’ll go into more on that later. It is usually 15 minutes a day, everyone stands up and shows what they’ve done yesterday, and what they intend to work on today, if they are blocked, if they need help.  And that 15 minute meeting is facilitated by the servant leader role – the team facilitator or servant leader works on facilitation, coaching the team through any issues and removing blockers. This might be working with other teams, having the contacts that they need, having the other people that they need, making sure that any of those blockers that are raised during a stand up are able to be removed – not necessarily during the stand up but definitely as the day goes on.

There are many benefits to the whole team approach.  Basically we’re enhancing communication, enhancing the collaboration (because everyone is in that one place), we’re enabling various skill sets within the team to be leveraged for the benefit of the project (the t-shaped, generalizing specialists) and we’ve also got all the people that we need in that one team, not in their organizational silos. Because we have everyone here we’re making quality everyone’s responsibility, so the whole team is responsible for quality on agile projects. And that is the whole team approach!

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