Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Agile and Beyond conference recap: 5 practical takeaways

Matthew Heusser Managing Consultant, Excelon Development
Hiking trail sign that says

Last week I attended and spoke at Agile & Beyond 2017, which made TechBeacon's list of must-attend conferences this year. The most popular talks were people, process, and scale, and that's where I spent most of my time.

Here are the five key things I learned—the key takeaways—from the sessions. 


1. Cross-functional should go further than you think

Catherine Swetel says you should visualize your value stream and remove the blocks, queues, and wait-state.

Catherine Swetel, a scientist with PraxisFlow, ran a session on “Why Your Agile Can’t Scale (and What to Do about It).” She asked for a show of hands as to who had cross-functional teams, and then asked who had the following roles embedded in their teams:

  • QA
  • Operations
  • Finance
  • Security and compliance
  • Customer support
  • Marketing and corporate communications
  • Distribution and supply chain
  • Executive strategy

By the time she got to customer support, every hand had lowered. That means the teams have dependencies, which is natural. But the problem with dependencies has to do with priority. If Team A is relying on Team B for one hour of work to get something done, but that something is a low priority for Team B, and if team B is relying on one hour of work to get its first priority done, but it is low, then nothing will ever get done.

Repeat this process throughout dozens of teams, and you have a prescription for agile adoption to fail, or what Ron Jeffries calls “We tried agile and it doesn’t work.”

To fix this, she recommended Catchball, a process where people understand the strategy, then work with peers and a superior to get alignment. In this way, they can make sure they are working on the right things to accomplish the strategy.

Moving dependencies are key, something LeadingAgile CEO and founder Mike Cottmeyer mentioned in his presentation, "The Executive’s Guide to Agile Transformation."

2. Agile is for executives

Cottmeyer pointed out that for teams to know how long things will take, they need to have a consistent velocity. Dependencies outside of the team make that impossible, so the team cannot predict when it will be done.

What happens, said Cottmeyer, is we train executives in Scrum, which is the wrong thing to do; tell them to trust the team; refuse to make any commitments on dates; and wonder why they haven't bought into agile transformation.

When you look at things this way, the unpredictable dependencies are the problem. The answer to “How do we do Scrum with part-time DBAs outside of the team who work through tickets that take weeks?” is either “You don’t” or “You can’t.” The solution for this is not to work around, but to see that as the problem. The people empowered to fix this are senior management.

That means agile can’t be something bought, installed, and then inflicted on teams. Instead, executives should be involved. They should set expectations and create incentives, process, and training to encourage the right behaviors.

Cottmeyer’s talk hammered home the point that organizational delay, or constraints, are often outside of software development.

3. The organizational constraint is often external to development

In my session, I talked about the barriers to continuous delivery. For example, in regulated industries, getting signoff for audit compliance could slow down the multiple-releases-per-day ideal.

The conversation reminded me of Jeff Sutherland’s case study of the PUB Team (page 110), a team that was so productive that it ran out of work! The product owner couldn't keep up; he couldn't write requirements fast enough to keep the team busy.

In that case, the constraint had moved out of the team (in classic Scrum, the product owner is not considered a member of the technical team). In the case of audits and dependencies, for such things as security or database changes, the thing slowing down delivery is outside of the team. Perhaps it always was, but agile makes it visible.

Too many teams are under constant pressure to go faster. Moving the constraint outside of development changes the game; “working harder” will not have a meaningful effect. This symbolically passes the baton to senior management, as I mentioned in takeaway #2 above.  To paraphrase Roman emperor Marcus Aurelius, what we perceive as the obstacle is actually the way to improvement.

4. The term "servant-leadership" is its own worst enemy

Michael “Doc” Norton, former director of engineering culture at Groupon turned consultant, led the keynote on the second day. His talk, “Leadership Starts with an Invitation,” turned the classic models of leadership (“lord” and “servant”) on its head.

The seven pillars of Robert Greenleaf’s servant-leader model includes:

  • Person of character
  • Puts people first
  • Skilled communicator
  • Compassionate collaborator
  • Has foresight
  • Systems thinker
  • Leads with moral authority

He looked at these attributes through the lens of the “lord” — someone who worked hard, was promoted, and now commands the people below him. The lord believes he earned the promotion, thus bestowing moral authority and communication skills. The lord is a leader, the one whom the organization chose. Therefore, he must have foresight and character and be a systems thinker.

In other words, it is easy for a lord-leader, or classic demanding boss, to look at the seven pillars and think, “Yeah, I got that.”

Instead of the lord/servant dichotomy, however, think of a leader as a “host.” A host can be an initiator, inviter, space creator, gatekeeper, connector, or co-participant. Instead of focusing on attributes, or elements of the character of a host, these focus on what leaders actually do.

Doc Norton presented to a packed house at Agile & Beyond.

Anyone can play these roles, from the newest hire in the rear rank to the CEO, and Norton challenges you to find ways to play each of these roles, including coaches.

This helped me realize that there are many ways to coach, as well.

5. There’s more than one way to slice agile coaching

There was a wide variety of coaches in attendance at Agile & Beyond, and I engaged in a few serious conversations about what coaching means. Anja Stiedl’s session discussed solution-focused agile coaching. At least three speakers were certified as co-active coaches. This is a life coaching method that focuses on the whole person. Co-active coaches don’t provide answers; they ask questions to guide the learners to make their own best decision. The Co-Active website goes so far as to claim that its “Co-Active Coach Training Program will prepare you to coach anyone, on any topic.”

That’s a far cry from the classic technical coaching approach I use, which requires coaches to have skills that can be demonstrated and taught through exercises and skills development.

In addition to personal coaches and technical coaches, there were process coaches, business-strategy coaches, organizational design experts, lean improvement coaches, and a host of experts and consultants at the conference, plus various brands of coaching. Solution-focused coaching imagines that a person has already solved the problem and then looks back at how he or she did it. It focuses on leveraging strengths rather than weaknesses.

As one person said during the conference party, "If your organization has 10 different coaches in a coaching team, you’re likely to have 20 different philosophies of coaching."

Allison Pollard’s session, “Talking and Not Talking—Find Balance as a Coach,” included a simulation where you ask the person being coached how he or she would like to engage.

So before you jump in, find out what the coach is thinking. If you’re the coach, clarify the intent and the process. There may be more than one way to do it, but there’s no reason that everyone needs to be confused.

Lessons and takeaways

So here's what I learned—and all of the actionable advice you need to know about Agile & Beyond—in a nutshell: You have to understand the need for inclusive cross-functional roles that cross departmental boundaries; many constraints in agile lie outside of development; senior management engagement is critical; leadership is more effective when managers see their role more as a host than a lord/servant relationship; and there's no one singular way to approach agile coaching. 

What were your thoughts and experiences from the conference? Can you relate to the advice offered by the presenters? Post your thoughts and comments below.

Keep learning

Read more articles about: App Dev & TestingAgile