A New Agile Team Approach Emerges

October 16, 2014 — Posted by Al Shalloway

The next generation of team Agile approaches is beginning to emerge. It is built on what the industry has learned from earlier Agile methods. It is perfected with Lean thinking. It is tailored to the needs of the team and the needs of the organization to deliver value quickly and sustainably. It is the fourth wave of Agile.

Lean thinking is the key. All successful approaches to Agile software development have some amount of Lean thinking within them. XP, Scrum, and Kanban (in its various flavors including the Kanban Method) each tell some of the story.  This next generation of team Agile uses the eyes of Lean thinking to craft a more robust approach going forward.

This fourth wave approach lets a team or an organization begin with proven methods of Agile and then select new practices to fit their needs. It provides a simpler path for transition and growth because it uses Lean and Agile first principles to guide their choices.

This blog looks at what we have learned from the earlier approaches and identifies the practices we have found that all teams should do. It then offers questions to help teams identify what other practices to use.

Looking for the Core Practices

XP, Scrum, and the flavors of Kanban each describe essential practices for every team. They are not the same for each method but, taken together, form an interesting set.

Method

Practices identified in the method

XP

  • Test-First and automated testing
  • Continuous integration
  • The power of small stories
  • The value of collaboration

Scrum

  • Value of cross-functional teams
  • Cadence
  • How iterations create discipline
  • Short-term planning
  • Failing to teach the principles on which an approach is based dooms new teams to relearn old lessons

Kanban

  • Kanban as method to manage workflow
  • Importance of visibility and explicit workflow
  • Value of including management
  • Ability to do projects without cross-functional teams
  • Focusing only on workflow means missing other opportunities for improvement

Kanban Method
(a flavor of Kanban)

  • How to affect change when it is not possible to do change up front
  • Only doing kaizen improvement can often lead to stagnation

It is tempting to try to do a mashup to create a superset but it does not work in practice. They are not all compatible because they were created by different people with different mindsets and driven by different forces. But step back a minute and put on your Lean thinking hat. They each represent different subsets of Lean principles. That is the way to unification.

Think of it like this. A grocery store has a host of ingredients. A recipe specifies a subset of these ingredients to create a particular dish for a particular need: a pie, a soup, some bread. Great if that is what you need. But what if you need to make a Waldorf salad and you don't have the recipe? Or what if you want something similar to a known recipe but need to change it due to food allergies. You are out of luck or you learn to think like a chef and figure it out. 

Likewise, having defined Agile methods is good and helpful. Everyone knows what to do. But when your method doesn't fit the situation, what will you do? You have to learn to think differently.

With Lean thinking, we can make three observations:

  • Some of the practices done above, while specified for only some of the methods, should, in fact, be done by virtually everyone
  • There are other practices that are not in the above approaches but should, in fact, be done by virtually everyone
  • There are some questions that would help you determine what approach to take

 

The Practices Every Team Should Do

Here are practices that virtually every team should do:

Workflow Management

  • Use explicit workflow
  • Have daily standups
  • Make everything visible
  • Use a common cadence even if you do not have sprints
  • Build incrementally and iterate on the increments
  • Focus on finishing
  • Do continuous integration
  • Estimate work items and compute velocity (exception at times for maintenance groups)

Workload

  • Work in small batches
  • Use small stories
  • Manage Work in Process (WIP)

Team Structure

  • Create cross-functional teams to the extent possible

Workflow Order

  • Use Test-First Methods (Start with ATDD and then adopt TDD)
  • Keep downstream groups apprised of what is happening (in particular DevOps)

The Questions Every Team Should Ask

Here are essential questions to help you think about additional practices to add to the team:

  • Do we need iterations for planning?
  • Do we need iterations for discipline?
  • Can we adopt test-driven development?
  • Are our developers willing to pair?

 

A New Method Emerges

Starting with these practices that every team should do and expanding with the questions every team should ask, you can create a specific “recipe” to help any team get started in Agile. This approach is based on Lean principles. Therefore, if one of the practices becomes difficult, you can use Lean thinking to decide whether to struggle with the practice until you manage it, learn how to do the practice better, or learn another way to accomplish the intended outcome of the practice,

Next Steps

I began by describing this as a "Fourth Wave" of team Agile. Maybe that sounds presumptuous. And, in truth, we have been teaching this approach for years in our Implementing Lean-Agile For Your Team course. What makes this new and not just a mashup of existing techniques is the integration and guidance that Lean thinking brings.

If you are looking for a unified approach for your organization while looking to allow teams to self-organize for their situation, I suggest you investigate this new method.

Al Shalloway

CEO, Net Objectives

 

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.


Comments

Hi Alan,

I like this post. It says that there isn't any fixed formula, no "best practice", just some values and principles to be guided by...
Now where have I heard that before? :)

The problem is though, is when you get into the business of selling "best practice" you end up loosing credibility when "best" doesn't work.

This is where the Agile community finds itself. If you remember, this is where I said we would end up when you were enthusiastic about the latest "best" a couple of years ago, "Kanban".

We have disagreed over the years, but not really about substance, more about the mood music I think. And yes labelling this "The Fourth Wave of Agile" is presumptuous :)

So where does that leave us? With some great organisations and teams who have been able to make these ideas work for them, and with the vast majority struggling to find the leadership and cultural change needed.

Jerry Weinberg has been struggling with this *wicked* problem a lot longer then both of us. I guess he could call his latest works the 20th Wave of Agile, but he is wise enough not to :)

Interestingly I agree with you about System Thinking, another one of the tools Mr Weinberg employs... I would drop the label "Lean" though... I'm even tempted top drop the label "System" and just talk about "Thinking" :) "Holistic Integral Thinking" maybe?

The labels don't help... They just become another moniker for "best", and help perpetuate the fad cycle in "best practice/method/approach" adoption. The perennial promise of a quick fix.

Interestingly, I think the Agile brand is pretty tarnished now and on the "dip" phase of the fad cycle... Those who "get it", are busy doing it and making it their own. Those who don't are struggling to get to grips with the basic prerequisites needed for incremental delivery and mostly failing... We will end up with a spectrum of approaches I think.. With no single approach gaining a dominate mind share.

This could be a good thing... A label free world where the only divide is those who can and those who can't.

Paul.

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