It’s about the Agile Team stupid!

It’s about the Agile Team stupid!

You are currently viewing It’s about the Agile Team stupid!

I attended the Mile High Agile conference in April. One of the keynotes was Michael Feathers. He did something interesting in the opening moments of his presentation.

https://www.youtube.com/watch?v=3AMzRAjA0-o

First, he asked how many non-coders there were in the audience. And about 80% of the group raised their hands. MHA was very well attended with approximately 850 folks – so that means about 600 folks raised their hands.

The second thing he did was show us some code on the screen. And he asked how many folks were uncomfortable with it. For example, showing it (code) in a sprint review. I think there were even more folks that raised their hands.

His point was that we (the agile community) are getting dangerously abstracted from the very thing (the code, software development, technology) that initiated the movement in the first place. And you know what, I think he’s right.

I was an early adopter of Extreme Programming practices at Lucent around 1999 – 2001. It was in the early days of the methodology and it was frankly being driven from a technology (developer) perspective. All of the practices made sense and the approaches were sound.

It was all about delivering code. It was all about technical approaches. And it was all about the team doing so. Ancillary roles such as manager, leader, project manager, etc, while they existed, were not the focus. Metrics and tracking were not the focus either.

It was about defining a software goal and then getting out of the way of the team and empowering them to deliver. It was about solving technical problems and customer challenges with solidly engineered and high-quality solutions.

I can’t explain how those early days felt within the teams. It was if we lit a spark within each team member and the results were fantastic. We had activated our greatest resource in building great software products…our teams.

And I think a lot of us have lost the point. We’ve gotten so wrapped up in:

  • Scrum flavor vs. Kanban flavor
  • Certifications, certifications, certifications…
  • Roles of Product Owner & Scrum Master
  • Fitting “managers” into agile
  • Agile Scaling Frameworks
  • Metrics & assessments
  • What is the new role for Project Managers, PMP’s
  • Being Agile without being agile

That we’ve forgotten something. We’ve forgotten the very energy, excitement, and value proposition that made agile so compelling in the beginning. It’s about developers writing code that solves customer problems.

In their latest newsletter. AgilePi co-founder Oscar Rodriguez shared this snippet from a recent Bob Martin keynote:

Are developers sitting on the sidelines? Agile, according to Uncle Bob, is currently being led by project managers who are using agile principles to drive process improvements with various frameworks including Scrum. While these process improvements are a necessary step in agile transformation, they do not address technical agility. When technologists stand on the sidelines, no one advocates for technical quality and solutions suffer. Developers need to get in the game! (The leadership game not foosball!) This need for technical leadership is driving the Software Craftsmanship and DevOps movements, but we don’t want the pendulum to swing too far in the other direction either…

This aligns incredibly well with what Michael Feathers was saying.

I think we’ve lost our way a bit and we need to get back on track. In a recent Meta-cast podcast, Josh Anderson and I discussed the question of whether “Agile”, as it was originally conceived, is dead?

My position was that it was declining in health and approaching life support. Josh had a much different and more optimistic perspective. His view was that it was at an inflection point. That the new wave of entrepreneurial companies were leveraging Lean Startup and Agile techniques increasingly to their competitive advantage.

That these companies were, by definition, going back to basics. They weren’t “doing” Scrum or SAFe. In fact, they didn’t really care about the methods per se. They were instead leveraging aspects of Scrum and other techniques simply because they helped deliver customer value.

Spotify is a shining example of this approach. Even though many pundits are referencing Spotify’s tactics, they simply keep doing “what works for them” and sharing them publicly.

As I listened to Josh in our Meta-cast, I became more hopeful. Perhaps there is a “back to basics” pivot in our future.

I’m also hopeful that other, more developer and team centric guidance is coming forward. For example, Andy Hunt and Jared Richardson are making much the same point as they define and champion their GROWS model for agile development.

I don’t know much about GROWS, but I want to find out more. If it places more emphasis on the developers, technology, the team, and code; then I’m all-in.

Stay agile my friends!

Bob.

Leave a Reply