What To Look At When Starting an Agile Transition

December 6, 2013 — Posted by Al Shalloway

There are two popular approaches to starting an Agile transition. One is a using a pre-defined approach, such as Scrum, or the opposite extreme, the Kanban Method, start where you are.   The first (Scrum) suggests jumping to a structure and workflow we know works, when it’s followed.  The second says to start where you are, manage your work in process, and then go from there.  I think both miss the main point of agile – “inspect and adapt.’  In other words, one should always see where one is, then one should consider what's the best course of action. 

Lean-Agile

Before we go into that, let’s digress just a little bit and look at what we are trying to accomplish when we go to Agile.  Agility should be about delivering business value quickly (incrementally), not about team iterations or managing work-in-process.  In other words, the result is what we want, the mechanism of getting there is not important (except for whatever mechanism we have for learning).  So how do we get the most value in the shortest time?  First, we have to select the most important things to work on.  Deciding on minimum business increments (MBIs) and prioritizing them is the best way to do this.  Then, there’s the question of how our teams should be structured.  Well, it’s pretty well established that cross-functional teams are the best way to go.

Unfortunately, achieving these things in organizations with more than 10 or 15 developers is not always easy. So what do we do?  Well, first we need to understand the challenges in our way.  Two of Lean’s best known mantras are “deliver fast” and “eliminate waste.”  This is good advice, but it doesn’t directly tell you what to do.  But that’s not really hard to figure out.   Let’s look at each of these mantras.

Deliver Fast.  One way to deliver fast is to work on small batches of value.  If half of a six-month project could be delivered in three months with the other half done the second three months, then that’d be faster delivery of value. Delivering half the value in three month and the rest in six months is definitely better than all of it in six months. Doing this also gives you the option to assess whether you want to complete the project or if another one with more value has come up.  And, serendipitously, as Eli Goldratt (creator Theory of Constraints) once said “Often reducing batch size is all it takes to bring a system back into control.”  So ‘deliver fast’ has both business value and tends to improve feedback.

Eliminate Waste.  I would suggest that there are three main causes of waste in software development: delays in the workflow (e.g., waiting for others), delays in feedback (e.g., discovering late that something is not correct), and redundant effort.   These three causes are, in turn, caused by three things: work items being too big, working on too many things, poor structures for collaboration.  So again we see how too big work items not only delays value, but causes extra work as well.

What We Can Do

First, we must recognize we have an holistic problem and likely need an holistic solution.  Here are some of the main issues that cause us problems:

  • Too many, too large, work items hitting the team
  • Our work structures do not match our work flows
  • The order of our workflow is not ideal
  • We have too much demand for our capabilities

When starting a transition, we should look for opportunities to address these quickly.  But how can we know if a change will be advisable?  Isn't  software developments complex and doesn’t that mean they are unpredictable?  The answer is yes and not all of it unpredictable.  I would suggest that in almost all organizations we can tell if certain actions will improve things or not. The issue is no longer knowing what to do, the issue is really about getting folks to do what they should do.   Let’s go through each of the above causes and see if there are appropriate, well-defined actions that one can take that we can be confident of improvement if we take them.

Too many, too large, work items hitting the team.  Addressing this challenge by breaking the work hitting the teams into MBIs is almost always readily possible and advisable.  The challenge is getting the business side to agree.  Even if they don’t, the development side should manage things by building in increments and giving the business side the opportunity to make changes as segments are completed.  This is almost always something that can be done at the beginning.

Our work structures do not match our work flows.  If one watches where in the organization the work flow takes you, one often sees many handoffs, waiting for people to be available, the work flowing into different parts of the organization, and long delays for feedback. In other words, if the steps in the work flow do not match the organizational structure the work is taking place in, delays in both the work and in feedback are inevitable.  Very often it is easy to see ways to improve this.  Scrum’s cross-functional teams are one – and in my opinion, the number one reason Scrum works so well when it does.  The work goes to the team and stays there until done. A perfect match. See Cross-Functional Teams Eliminate Waste and Manifest Lean for more on this.

I would say that, without exception, the alignment of workflow with team structures highly correlates with more efficiency in development.  This means we can use any disparity between these as a guide for future action with virtual 100% certainty on whether our actions will result in an improvement.  The closer the work matches the organizational structure of the people doing the work (e.g., fewer handoffs, delays, etc.) the more efficient we’ll be.

The order of our workflow is not ideal.  Let’s just call this the way it is – if you are not defining your tests at the acceptance level before you are writing your code you are creating waste. This waste includes misunderstandings, not being clear about what is to be built, and not providing proper guidance to the development group how to build things.  Acceptance Test-Driven Development, or Behavioral Driven Development if you prefer, have strong track records and should be being done just about everywhere.  Test-first is one of the best mantras to follow.

We have too much demand for our capacities. While it may always seem that there is too much work for our folks to do, the truth is a little more complicated.  The fact is, there is almost always too much work for a few people to be doing. Every organization typically has a few people that there just aren’t enough of.  This is not appreciated enough, nor visible enough.  Many times an organization assigns these folks to important projects only to find others don’t have much to do.  So they have these folks start additional projects which end up putting more load on the critical folks.  Or worse, some organizations think all they have to do is hire (or outsource) more people to do upcoming projects.  But this also typically overburdens already overburdened people - exactly those people who become constraints on everything.   (not intentionally, of course).  Thus, we make our most important people, those who are already doing too many things, do even more.

One way of discovering our limitations in capacity is by using Kanban boards with explicit policies and well defined queues.  We can improve things by managing the WIP in the queues, but these other items we’ve mentioned, should almost always be investigated first.  In other words, before trying to manage queues that are too large, we should see if we can readily identify and correct what's causing those large queues in the first place. We should always remember the mantra - flow where you can, pull when you must.  See what’s stopping the flow and see if you can stop that. Our first efforts should not be on managing queues, but asking why they are there in the first place.

Why You Shouldn’t Start With A Prescribed Method

All too often one here’s a manager say – “we’re going to do Scrum”, or “let’s try Kanban.”  But both statements miss the point.  One should look to see what will make you more effective.  Looking to:

  • Work on the right things
  • Create proper team structures
  • Do the work in the proper order (test-first)
  • Limit work to capacity

should be first on your list.  If you see how to do any of these, do them.  Scrum is often a great place to start if you can create cross-functional teams.  If you can’t do any of these items, then the Kanban Method is probably a good approach to start with.  But just to start with either without looking at these other options runs the risk of serious challenges and delay to improvement.

The point is - understand what you are trying to accomplish. Then take the steps that move you forward.  If you can’t move forward, get better clarity on where you are.  If you follow the Kanban method to do that, look for change when you can do it. The Kanban Method shouldn’t be just about managing the queues between the steps – it should be looking at the causes of the queues in the first place. 

BTW: If you identify with this blog and want some help, check out our Multiple Scrum Team Workshop or just drop me a note. Always happy to provide help.

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.



        

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