The Dilemma of an Agile Coach

As an agile coach you can often run into people who believe that agile IS the flexible model. But do those two models (scrum and kanban) really mean the same thing? Can you assume that they are equivalent from team to team? This question posed may help to clear up our discussion today:

“As an Agile Coach I am constantly running into teams and managers who say that Agile is flexible. In their view, they see that the team and managers can take what they like in Agile and dismiss what they don’t like. Fundamentals such as time boxed sprints, team commitment, point estimation, self-organized teams, 15 min stand-up instead of 1 hour status meeting, no re-prioritization within a sprint cannot be dismissed. How do you convince teams and managers that the fundamentals in Scrum/Kanban cannot be dropped or else it won’t work?”

Admit it or not, you probably have run into problems just like this before with your team. DOES agile mean the same as flexible? And what are the benefits? As with almost every issue there are two sides to this argument.

One the one hand, agile by design is supposed to be flexible and lightweight. This is to make sure that the goals can be accomplished within a fairly timely manner. A few elements of Scrum and Kanban definitely should not be dropped, and some elements if added might even slow down the process. The 15-daily meetings simply work well if used in the scrum model; status meetings are not as they mess up the whole flow of the project. On the other hand the scrum model actually does NOT dictate an estimation; that is the prerogative of the team or the team leader to make for themselves (with the approval of the product owner). In short, one view postulates that it is BEST to start from a pure scrum perspective when you start. But there is more:

The flip side of this view is that it is better to start from a pure scrum setup in the beginning, and then ADD elements of agile as seems good for the team. Although these elements must be carefully selected to make sure that they do not mess up the flow of the whole project. But wait; there is more. Let us add a THIRD view to this three-sided coin (I know it looks a little bit odd) and explore agile purists:

There are good reasons to want flexibility, and bad ones. You should NEVER allow your team to pursue a more agile process for the following reasons:

  1. To ignore a deep-seated organizational issue that is limiting your agility.
  2. To make it “easier,” which is often code for cutting corners.
  3. To support someone who is pursuing his or her own agenda.

None of these are good reasons to go after your own agenda in the process of development. All of these reasons are more self-serving than useful in the process. A team leader or coach must be very careful to look out for warning signs that someone is pushing for a more flexible model for selfish reasons: things to look for are a lack of good reasoning for wanting a more flexible model or belligerence to fellow co-workers.

In conclusion, it is probably better to focus on a more agile/scrum-oriented model for development, as most people’s reasons for wanting to pursue another model comes from a lack of real motivation. If there is a VERY good reason to use more flexible tactics that can be considered, but only should be considered IF the reasoning is excellent. Otherwise, stick to the model that was originally outlined!