Agile 2014 Conference Notes

I used to attend Agile and quality related conferences years ago and have saved notes from many of them. While some topics have become overtaken by events since then, there still seem to be some useful ideas that I’d like to pass along.

[I did not have extensive notes for Agile 2011–2013 (nor any for 2015), so I have skipped over those conferences due to lack of substantive content to offer. And, as I did not have notes for this one myself, what follows are from others.]

Thoughts from Rene Rosendahl

Being able to take notes on a light iPad with keyboard is a lifesaver! Gone are the days of shlepping around my laptop. Thanks Apple! I’ve been to a number of Agile conference over the years, but I ended up skipping the last 2 conferences. Now here I am at Agile 2014 in Orlando and these are my observations, in no particular order:

· DevOps is a hot topic, but not overwhelming. Personally I’m not sure what to think of it yet.

· SAFe remains somewhat controversial, depending on whom you talk to. Somewhat of a polarizing topic. Still seems quite prescriptive to me. Maybe I haven’t paid that much attention to the topic in the past, but for the first time I learned that there are a number of alternative approaches such as Disciplined Agile Delivery (DAD), Large-Scale Scrum (LeSS), the Spotify approach, etc. (Great session on Smart Scaling by Richard Dolman and Steven Spearman, BTW). One common denominator between most of the approaches seems to be a 3-level, tiered structure. Something we’ll need to think about more as well.

· I did enjoy hearing Scott Ambler. Interesting take on things. I will have to give DAD another look. Had a nice conversation with him before one of the sessions and discussed how to do this “governance” thing right. I like the pragmatic approach and how — without seeming too prescriptive — different choices are offered for each area without ignoring the cultural aspects of being Agile.

· Organizational agility and its cultural implications are something I will have to think about more. Easy to ignore and much easier to focus on practices at the team level.

· This conference is crowded and the sessions are filling up way early, often with standing room only. Do we need more room or fewer people? [This was my feeling back then as well. Too much going on of uneven quality as well.]

· I don’t hear much about Agile outside of software development any more. While always an edge case, I thought it came up more in the past. [This has changed since 2014 with more agile use in non-software situations. You’ll eventually read about some in my Scrum Gathering notes when I get to them.]

· There seem to be fewer techies here and while there are a decent number of sessions with technical focus, there seem to be fewer than there used to be. There are more leadership and management folks in attendance, less QA and developers (or so it seems). Overall the focus continues to shift away from Scrum and XP and is definitely more on scaling Agile, organizational agility, cultural shift, larger-scale transformations, sustainability, coaching, [And this became a complaint which has led to things like the Agile Technical Conferences.]

· Governance isn’t dead, but seen as needed, although the word itself still gives people the creeps. I guess it’s a different form of leadership needed in this area with lighter-touch approaches. Enablement, not control. Cool what some companies have done in this space, e.g., Salesforce. On that note, I see more discussion about coordinated coaching and Agile groups helping organizations internally.

· The word “coach” seems to come up more than Scrum Master and Product Owner nowadays. These other two aren’t mentioned directly as much any more. Product Management isn’t very prominent either. Lean Startup on the other hand appears to be a well-understood “standard” approach. Project management and project managers aren’t talked about much any more either. [And this has revered to some extent since 2014.]

· Metrics are tough, yet needed. Centralized, enterprise metrics remain challenging and inconsistent, also because of differences in teams’ practices. Less is more. Buy-in is needed. Bottom up is better than top down. hope so!Follow me on Twitter at @rrosendahl.

Insights at Agile 2014 by Alan Shalloway

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 [from one of Alan’s blogs]:

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 SAFeTM 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?