This is the first of three blogs I'll be posting daily (see bottom of post for the others).

Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened. - Winston Churchill

I have no special talents. I am only passionately curious. - Albert Einstein

Agile 2014 has come and gone.  Like most of the conferences I go to, I didn’t see one session other than the ones I (co-)led. But I was a busy guy, talking to clients, practitioners, other consultants (fans and  detractors).  Best way to think and check out ideas. Here’s a distillation of insights I got from the conference.

Scrum sprang from a simple situation – product development with nothing to maintain and no distractions. So it shouldn’t be surprising that it doesn’t tell us about how to deal with technical debt or working across teams.

The Kanban Method sprang from a maintenance situation where workload issues could be handled by managing WIP in the team and issues such as team structure and order of workflow were not significant. I’ve recently realized the Kanban Method is more Theory of Constraints implemented with kanban as a pull model than it is a lean approach. Not surprising since I was the Lean half of Lean-Kanban University and I'm no longer there.  But when I remember it sprang from a maintenance environment it is easier to understand why it ignores portfolio workloads, team structures and test-first.  These are orthogonal to maintenance even if they are not orthogonal to where the Kanban Method is mostly being applied.

There is great danger in applying these frameworks/methods out of where they were intended.  OK, not a new concept for me.  But the other half is how does one pick one's process.  My blog on Tuesday will discuss that.

Cross-functional Teams are a proxy to what we really want. What we really want is - presence, collaboration, synergy, and having the capabilities needed at the time they are needed.

There are many ways to improve flow.  These include:

• improving the workload hitting the teams
• improving the way the people doing the work are organized and how they collaborate (Scrum suggests cross-functional teams)
• improving the order the work is done in (e.g., test-first)
• automating testing
• continuous integration
• reducing technical debt
• managing the work-in-process within the team by using a kanban system

It is not a valid assumption that managing WIP is always the easiest or first thing to implement (Kanban Method's approach), especially given my earlier blog Resistance Is Not to Change.

Management is strongly influenced by the structure of the organization they are in.  This is not a surprise – this is basic systems thinking.  But the realization that the management system must be holistic or parts of it will work against itself was a new insight for me (one of those "doh!" (how did I not see this before) ones.

Culture is created by management decisions. Here’s a quote from David Mann in my blog Why Not to Focus on a Company’s Culture:

Annual reports proudly refer to company culture as an invaluable
asset, and so on.

Should a company target its culture in its efforts to transform its
production process and all the positions - high and low - associated
with it? It is tempting to answer: Yes! But, that would be a mistake.

Culture is no more likely a target than the air we breathe. It is
not something to target for change. Culture is an idea arising from
experience. That is, our idea of culture of a place or organization
is a result of what we experience there. In this way, a company's
culture is a result of its management system. The premise of this
book is that culture is critical, and to change it, you have to
change your management system.

So, focus on your management system, on targets you can see, such as
leader's behavior, specific expectations, tools, and routine
practices. Lean production systems make this easier, because they
emphasize explicitly defined processes and use visual controls.

Thus, the culture of a company is affected by the structure of the organization in that it affects management. As an aside, if a company’s management actions are consistent with its vision, a positive culture will be present.

Complexity implies that if we change part of a system without attending to all of the system, then we will get unintended results (although there is usually a pattern to these results). Complexity does not mean we can’t make reasonably accurate predictions about what our actions are going to produce.  It means that:

1. We can never be sure of our results so we must attend to what happens and adjust
2. Actions that attend to part of the system will have unpredictable results in other parts of our system if we only consider a section of our value stream.  For example, if we manage to lower the number of items hitting the team through portfolio management but don’t attend to other sources of work hitting the teams, the teams are likely to be given work other than what was approved by portfolio management (e.g., an increase in shoulder taps will ensue).
3. Issues that your consultant consider “orthogonal” to what you are doing will likely cause serious problems or have you miss out on significant opportunities.

Scope of a process and heaviness of a process are orthogonal issues.  You must attend to both, but one does not need to affect the other The fact that SAFe^TM is broad does not mean it has to be heavy. While it is possible to implement SAFe in an overly heavy way, it doesn’t have to be done that way. The power of SAFe is not in its heavy-handedness, it is that it provides default management agreements on:

• Workload management
• Preventing unwarranted interruptions to development teams
• Requiring all teams to have the same cadence so that they can synchronize frequently.
• Have the teams in a test-first manner

A light-weight implementation of SAFe provides a framework within which to do Kaizen to improve the structure of the organization as well as its management system.  Given that culture is a reflection of management and that complexity implies one must take an holistic approach, SAFe clearly is addressing something other current methods aren't.

Instead of arguing over Scrum or Kanban we should be settling on the right mindset to have.  There is huge evidence that this mindset should be Lean.  Unfortunately, Lean is not the underlying mindset of either Scrum or the Kanban Method as professed by its thought leaders.  When figuring out what to do at the team level, we should not be asking if we should do Scrum or Kanban, but rather, given the constraints of our situation, what are the best practices we should be doing that we are aware of?  And, when the team starts getting more competent with these practices, how do they move forward?

I will be expanding on these two topics in the following two blogs published in the next 2 days

• Agile 2014- Stuck in Shu – Time to Change How to Teach Scrum
• Agile 2014- Lean-Agile Development Team Process - a way to pick what to do and how to transition to better methods

If you are having troubles running Scrum or the Kanban Method, maybe it's because the approach you are trying is the right one for you.  Take a look at our New Team Process page.