The Need for Proper Training of Team-Agility

July 19, 2017 — Posted by Al Shalloway

There is a lot of bad Agile out there. We all know this and have seen it. There are a lot of reasons for it, but one that I think is a major cause of it is not discussed very much. That is that the way we teach it – as a series of steps to follow. While this makes it easy to follow, it sets up people for not really understanding why they are doing what they are doing. I understand that people want to know what to do and we do need to give them tangible practices to start with. But the objective of what to do is equally essential – and is often not discussed. Instead people talk about starting with mindful practice and then going beyond those steps to the next level. Of course, how to do this is left unexplained. And, without understanding why we are doing the practice, it's hard to consider viable alternatives. Instead, people often just get frustrated and stop doing the practice entirely. Many a team doing "kanban" started out as a Scrum team that abandoned sprints, but didn't pick up kanban practices required to take their place.

I would suggest a lot of bad Agile is because people don't know what good Agile looks like. For example, something as ubiquitous as the daily standup has evolved into little more than a status meeting about the individuals of the team. This is not what it should be. Simply stated, the purpose of the daily standup is to increase collaboration, make a daily plan to increase focus, see if the iteration plan needs to change, ensure visibility is present and ensure impediments are visible. Note, these last two shouldn't take any significant time because if they are visible no one needs to mention them. If they are not visible, their lack of visibility is a symptom of something else going wrong.

Also note that if, in fact, we need a status report, it's also likely our board isn't clear. But it's worse than that. Talking about what each individual is doing ("I worked on this, I'm going to work on this, this is what is in my way") has people focus on themselves and not the team.

How and why we teach team-agility can create the proper mindset adopted by the team – that it is a team working in a bigger team, not merely a collection of individuals following a playbook. When teaching team-agility, we need to:

  1. Realize that team-agility must work within the context of the overall effort to realize business value faster, with predictability, sustainability and high quality
  2. Recognize that teams are part of a complex system and that we must consider how they interact with the rest of the value stream
  3. Train the team in their part of the Agile Product Management workflow of identifying what needs to be built and refining those parts that are about to be built
  4. Keep our context in mind when we decide on the practices we are going to use. These practices do not need to exactly match those of the framework we are adopting, but rather should meet the objectives that these practices are intended to achieve. Practices that fit our context may work better

The anti-patterns for not doing the above steps (respectively) are:

  1. We optimize teams and lose sight of the end objectives
  2. This optimization of the teams comes at the expense of overall value realization
  3. Teams complete stories and features but can’t deliver value as required components being built from other teams are often missing
  4. If we can't use a practice exactly as stated teams tend to stop doing them and don’t find other practices that could meet the objectives just as well with less effort

More, of course, is coming :)

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban