The State of Agile — Fowler’s Keynote Analysis and Thoughts

In this article, I’ll analyze and discuss Fowler’s keynote from Agile Australia 2018

I’ve finally gotten around to reading Martin Fowler’s “The State of Agile Software in 2018”, which was the transcription of his keynote at Agile Australia (https://martinfowler.com/articles/agile-aus-2018.html). It’s definitely a hefty article, but in summary he discusses three main points. Those points being:

1. Fighting the Agile Industrial Complex and its habit of imposing process upon teams
2. Raising the importance of technical excellence
3. Organizing our teams around products (rather than projects)

All three points of which I really love. In this article I’ll provide my insight into each of these topics as well as some of my own personal experiences in these areas at my company.

It’s all about agility! https://pixabay.com/en/dogs-agility-border-colly-1426679/

Individuals and Interactions over Processes and Tools

I strongly believe that the key to a product’s success is having the best team you can make. Having an amazing team doesn’t just mean they are the best coders. To me, it means the team is confident to ask questions, to go out of their way to understand the business needs and come up with kick-ass solutions. If the team wants to build some awesome component structure for a reusable UI, terrific! If the team wants to do scrum, great! What’s not great is telling the team they need to do scrum, and they need to build things a certain way, with certain technologies or processes.

Now I think Fowler goes a little overboard in the keynote. He states:

The Agile Industrial Complex and this imposition of one-best-way of doing things. That’s something we must fight against.

I agree and disagree with this statement, mainly because it’s so broad. What I’ve seen not work well and suffocate teams are groups named like “Enterprise Architecture” and “Enterprise Security”. These types of groups push top-down decision making and suffocate the creativity of teams. This “one-best-way” thinking is bad. On the other hand, I believe letting teams (or groups of teams) decide what all teams in that group should do to be a good mentality. For example, three teams work on one product, focusing on different parts of the user interface (UI). The teams should probably decide that there is one way to make a drop-down or a text box, or one security pattern for the application. Can these be challenged in the future? Sure, but it’s the teams deciding what is best for their application.

Quality First. Always.

This is the mantra on our teams, and we do not flex on it. Ever. This is another one of those things that I love about our culture and what makes amazing teams. We have rough estimates on our feature development, but out stakeholders understand that they are flexible because we need time to develop great software and stuff changes! Things come up, new requirements, something needs to be refactored, and that’s okay. It’s taken a lot of time and we’ve had to prove ourselves (IT) with successful releases, but now that we’ve built the trust between us and the business, they understand what type of product they’ll get when we deliver. They know that it’s going to be a high quality solution.

The second problem is the lack of recognition of the importance of technical excellence.

This is a huge problem to have, and it’s a hard problem to solve. It really comes down to culture here. Fowler makes some great observations about developers wanting to “get away from all the business people” and I think that’s just terrible! My teams make the best software when they really understand the customers and how to make their lives better. In turn, they make software that doesn’t have bugs, doesn’t need to be supported at midnight, that is just top of the line and makes people want to use it. More to come on this in the next section (as well as in my next article!)

https://pixabay.com/en/family-children-sunset-silhouette-730320/

Products Over Projects

This article, also by Fowler, has a lot of the main points in it, but here’s the high level of why I think it’s awesome. https://martinfowler.com/articles/products-over-projects.html

• Product teams are funded for an extended period of time, don’t have to worry about being re-scoped or get new funding for another “project” every 4 months.
• They are created in alignment with the business capability development. This ties into the notion of “how do we make our customer awesome” thought — I could talk about this for an entire article, more to come on this one!
• Prioritization happens within the product, no comparing apples to oranges here.
• Iterative development is much easier and can respond to feedback much faster than a project team.
• Code. Ownership. Teams that make a product and support that product don’t want to get the weekend or late night phone call for production support. So they make good stuff.

These are just a few of the awesome things about product teams. Obviously there is way more to this, such as making long running teams mesh together that I love. My teams at work are like my extended family. That’s why I hate the whole Netflix culture of “elite sports team” mentality. You can have an awesome high-performing team and also have it not be a cutthroat culture.

Fowler wraps up the talk by saying how excited he is for the future of agile development. And I’m with him on this. I think it’s very exciting that more and more people are interested in learning about agile and how to best leverage and evolve the practices. The fact that there are huge conferences and keynotes and blogs and videos on agile is fascinating and I can’t wait to continue my career in the agile software development world!

Opinions expressed are solely my own and do not express the views or opinions of my employer.

Connect with me! Find me on LinkedIn at https://www.linkedin.com/in/eric-andrews-ba2a405a/ and let me know what other topics I should cover!