Agile 2017 (Part II)

So, Agile 2017 is over. It’s actually been over for a while now, but I decided to wait a bit before writing this final blog post about the conference in order to share more learnings.

Closing keynote

The closing keynote was another highlight. Though a large amount of people had already left, there were still plenty around to fill the (very large) room and listen to Denise Jacobs. Banish Your Inner Critic 2.0 was a very open, honest and insightful presentation about the journey Denise has made linked to that inner critic inside all of us.

During the keynote Denise challenged the audience to think about their inner critic and share this with those sitting at the same table. It turned out to be comforting to know that everybody has that inner critic and we all faced the same challenge, a challenge we will have to keep facing, but for which there are plenty of things to do to overcome it.

Conference highlights

The biggest highlights from the conference for me were, in no specific order:

  • The amount of people present that all wanted to achieve the same thing (a more agile, customer-focused organization) and were willing to share that with whomever they were talking to;
  • The vast amount of experience that was represented, both by speakers and conference visitors alike. If you’re in an Agile environment, this event is one to attend;
  • The variety of sessions was overwhelming, with 19 parallel tracks and all those topics to choose from the conference could have gone on for another week;
  • The openness of the people, with some willing to open up themselves beyond what would have been required in sessions, in order to let others learn from their experiences.


With the conference now over for about 10 days I’m still thinking about what an amazing time I had and how great it would be to go back there. Luckily, there’s videos of part of the conference available on the Agile 2017 web page (some content is only available to Agile Alliance members).

All in all, this has been the best conference I’ve been to so far and I hope to be part of Agile 2018 as well.

Agile 2017 (Part I)

This week I’m at Agile 2017, both as a speaker and as an attendee. Since I’m having such a great time I thought I’d share some of my experiences from the conference.

The conference

Agile 2017 takes place in Orlando, Florida this year and is a 5-day event with agilists from all over the world gathering to share experiences and learn.

I’d like to start off by highlighting what an open and welcoming conference this is. While I haven’t been to hundreds of these things, I have seen my fair share and Agile 2017 is unique in several ways. It’s a big conference to start with, with over 2200 people attending this year. Even with that large number of people, it’s surprisingly low-key. People are open to chat and mingle, are kind and show lots of respect. Finally, even though there’s groups of people from a large number of companies, they’re all very inclusive and open to others joining them. I’ve never before experienced this kind of atmosphere, not even at smaller conferences.

Major highlights

The major highlights from the conference so far were the keynotes from David Marquet and Jez Humble.

David kicked off the conference on Monday when he spoke about his experiences from his book ‘Turn this Ship Around’. It was an inspiring presentation about self-organization and leadership and engagement at every level of the organization.

Jez spoke about continuous delivery and while interesting to see up-to-date facts and figures (like that Amazon releases every 11.6 seconds on weekdays) most of it was familiar to me. Until he started with his bonus material: a 15-minute session in which he totally annihilated James Damore’s “manifesto” and highlighted some of the most important contributions women have made in IT. The audience was in full and total agreement, having given several rounds of applause and leaving some in tears.


I am a speaker at this conference, which I consider to be a great honor. Wednesday afternoon (3:45pm) was my turn and even though it was the third day of the conference at the end of the day, a sizeable crowd showed up to my presentation. The presentation went reasonable well (I made some last minute changes which, at certain moments, made it a little uncomfortable for me as I had to look up what I had planned next), interaction was good and I got some great feedback to improve the presentation even further for future speaking opportunities.

After having lived to this moment for months, after it being over me and a colleague celebrated (he had become a PST – Professional Scrum Trainer – that day) with a nice drink in the bar. Major milestone reached, up to the next one!


The conference is still ongoing with at least two great sessions still coming up. The sponsor area has just closed, which is a shame really as it was a great place to meet people and talk about this, but with the conference party coming up later today there should be no shortage of opportunities to mingle.

Once the conference is over I’ll share part two, so stay tuned for that.

SAFe: Scaled Agile Framework – or is it?

Last week I’ve had the pleasure of taking part in a Leading and Implementing SAFe course. During this four-day course I would be introduced to the Scaled Agile Framework, learn how to implement it, and learn how to share it with others.

To summarize the outcome of course in just one line: it sucked.

How is SAFe a framework?

To me, a framework is a light-weight set of boundaries within which there is a lot freedom to do as one sees fit. If you see the SAFe Big Picture you’ll understand my initial skepticism at the term ‘framework’. Nonetheless, I was looking forward to having my skepticism rebuked and to learn how to see and use SAFe as a framework. All this in order to be able to better help organizations that need scaling scale.

Whether organizations actually need scaling or a scaling framework is an interesting discussion. I think that if you need scaling you should first look at your products and your architecture. Self-organizing teams with the help of a clear vision and a good architecture can get a long way.

Unfortunately, the way I interpreted the way SAFe was put down this week was as a methodology. These are small selection of some of the concerns I have after having taken the course.

Let’s start with the roles: Release Train Engineer, our “facilitating” Super Scrum Master; Release Management, the Super Product Owner of the Release Train; System Architect, who together with the RTE and PM act like the steering committee of the Release Train (also, drawn above the teams, like hierarchically superior). All set and ready to go, all required.

The format in which work should be sent to the teams is also set for you: User Stories coming from Features or Enablers, coming from Epics; Enablers that are used for work supporting other User Stories or Features; and if you open the Value Stream level there’s something called Capabilities as well. Additionally, there’s a selection of templates available for most of these items to fill out. All having been done during the course and available from ScaledAgile’s website for your day-to-day use.

My biggest concern, however, was the ‘Agile Release Train’. Calling a Release Train ‘Agile’ when the recommended time-box is 10 weeks is beyond me. Sure, teams could release more frequently (and I quote, because of “individuals and interactions over processes and tools, and stuff”). But once you’ve seen the monstrous PI planning board with all its dependencies between teams you may wonder how that could ever happen.

In other words: my skepticism was not only not rebuked, it was definitely reaffirmed and has even worsened.

SAFe the way I would have liked to see it

If SAFe really is a framework, I would have loved to see it like that. Perhaps with a various complementary practices that would make it work for specific scenarios, in which alternatives to certain practices would have also been discussed.

The power of SAFe to me is keeping synchronized across teams and Release Trains in a larger organization, in which each release train is an independent part of the organization focusing on a specific product or value stream. There would be direct contact between the customer(s) and the teams in each release train, where each release train would have their own tools and practices to handle how work comes in. Whatever works for the teams should be the practice, not whatever someone else tells them to.

I love the end-of-increment Inspect and Adapt opportunity, but without all the practices that SAFe introduces and without the compulsory interval of 8 to 12 weeks. It’s great to inspect and adapt with a bunch of teams working on the same product or value stream, serving the same customers. Just like the PI planning: a high-level “planning” event which can be used to identify dependencies and remove them on the spot. I’d call it PI refinement rather than planning and I would never give commitment to finishing a list of work or reaching certain objectives for the next 10 weeks. I’d be doing my customer a disservice in nailing down what we’re going to do for 10 weeks rather than giving them the opportunity to take a different course at a shorter interval. But I like the synchronization nonetheless.

I’d have loved to see SAFe as an enabler for Agile at scale, because that is what organizations need. Practices come from experience and that’s where coaches come in: to help an organization find a practice that works from them, in which there is multiple practices to be compared. That is what SAFe (or any other scaling framework) should enable.


Looking at this constructively, I see SAFe as an intermediary step for very large and very traditional organizations towards true agility. I think it’s loads better than sticking to a waterfall-approach and if an organization implements SAFe the way I heard it, they’d be far better off.

To reach true agility you’d need to take a lot of additional steps. Mostly you’d need to experiment, see what works for your organization, your teams, keep inspecting and adapting and changing things if they make more sense. And to me, that’s the danger of a methodology over a framework: it makes things fixed rather than up for change. Whereas a framework should give you those boundaries in which your organization can shine.

© 2021 mpkossen.com

Theme by Anders NorénUp ↑