It was great having Andy Hunt of Pragmatic Programmer do an AMA on our Slack community for engineering managers 🙂

Below are some of the questions and answers. Super insightful!

 

Eimantas Vaičiūnas, Engineering Manager at Trafi, asks:

In my experience (and as many books I’ve read) on doing Agile development (XP practices, Scrum, etc.) every product in regards to introducing Agile seems to miss the introductory part.

From my experience – it’s not agile that is hard, but adaptation and even before that – getting buy-in from different parties (even from engineers in the team in question).

Please share your tricks to sell Agile (for the buy-in part) and a few “Adoption/adaptation of Agile 101” bullet points.

Andy Hunt, the co-author of Pragmatic Programmer and Agile Manifesto, answers:

First of all, never buy agile as a “product.” It is not.

The very first line of the manifesto asserts that we should prioritize people and interactions. So let’s start with that.

You want to “do agile.” Why? The first question any executive or developer will ask (aloud or not) is, “What’s In It For Me?” As it should be. So we need to answer that as well.

Why do you want to introduce agile to this organization; what problem are you trying to solve? Usually the answer hits three main areas: get software out the door, make sure it doesn’t suck, and more-or-less helps the user do what they need to do.

I find it best to start with immediate, concrete problems that are causing obvious pain points. Almost all of the time this means a first step of getting reliable CI/CD in place. Right there that can be a show-stopper for a lot of organizations. But if you can’t reliably build and quickly ship, then what’s the point of doing anything else?

Once you can ship reliably and on a moment’s notice, maybe start writing better code. Start trying TDD, make sure you have automated low-level (unit) testing, etc. Now some uninformed executives will balk at this and claim it’s a waste of time and money. They are incorrect. It’s part of the job. When a plumber or an electrician completes their work, _they test it._ Doctors follow up on treatments with tests. And charge for it. It’s part of the work, period.

If you’re already doing that well, investigate pair or mob programming.

Now that you’re writing perhaps better code and can ship it, work on a closer relationship with the end users. Cut out the middleman. Remember, people and interactions over processes and tools.

With solid CI/CD in place, some level of automated testing, and an ongoing dialog with users, you can enjoy fast feedback, and can quickly respond to changes and errors.

That’s how you win. You don’t need Scrum, you don’t any “canonical agile” (lol, what an oxymoron) product or certification. What you need is fast feedback, solid technical practices, and a close relationship with actual users of your software.

So to answer, “What’s in it for me?” Feedback. You’ll get feedback so you know that you’re right, and if you’re not right, be able to correct things quickly and cheaply and make it right. That’s as true for executives as it is for developers.

 

Juergen Eger, Front End Team Lead at Ebury, asks:

Got a controversial one.. How would you best measure the performance of a team?

 

Andy Hunt, the co-author of Pragmatic Programmer and Agile Manifesto, answers:

Okay, I have a controversial reply. I’d survey the following: User health and happiness, team health and happiness, and leadership health and happiness.

Now granted these aren’t necessarily as quantifiable as some BS hard metric, but they get to the heart of the matter.

Health includes sustainability and growth. Happiness includes the sense that these parties are accomplishing their goals to their level of satisfaction (and getting the business value the sponsors expect).

And I’d include all three viewpoints—end users, the teammembers themselves, and the leadership. You can easily game productivity metrics and have miserable users (or leaders).

Editor note: there was a lengthy discussion on this topic under the thread. Join the community to read it 🙂 

Dhruv Agarwal, Engineering Manager at Shuttl, asks:

What different management styles have you tried with your team? Which one has been your natural way amongst them?

 

Andy Hunt, the co-author of Pragmatic Programmer and Agile Manifesto, answers:

Thanks for asking this question, because I think it exposes a very popular and common misconception. For the most part, skilled teams should be autonomous. Not “managed” in the common sense. “People and Interactions…” over management.

Instead of thinking in terms of “managers” and “the managed” (which has a very disturbing provenance), think in terms of collaboration and facilitation.

For a less-skilled or novice team, you’d think in terms of mentorship, growth and education. After coding for almost 40 years now, it still amazes me how much process, management technique and tools we invest in and put into place all to avoid just having a conversation with the relevant parties.

Remove middlemen, remove proxies, and connect the people doing the work to the people who want the work. That’s the style I recommend 😉 

Juergen Eger, Front End Team Lead at Ebury, asks:

Another one coming up after talking with one of our developers about “The Pragmatic Programmer”: In your book, you write: What to say when asked for an estimate[?] You say “I’ll get back to you” More than 20 years later, we’d like to know what is your opinion about estimates and the effects they can cause in the code quality.

Andy Hunt, the co-author of Pragmatic Programmer and Agile Manifesto, answers:

This one will really frost your doughnut. Estimates are a proxy for working, deliverable code. In other words, if you can deliver code daily, you don’t need estimates.

There have been multiple studies that show that story points are basically useless. In many cases, the time spent arguing over estimating the story points could be put to productive use in creating a solution straight away.

So if you have a solid CI/CD environment and can integrate code changes into the main branch several times a day to deliver a release suitable for testing/demo, then just do it. That will build trust in the team far better than other approaches.

“But what if we get it wrong?” You will. But with it out there and usable by the user population (perhaps behind a feature switch, etc.), you’ll get feedback right away so can tweak it or re-do it. Remember, it’s not important to get it right the first time, it’s important to get it right the last time.

Giuseppe Turitto, Director of Engineering at Stealth Mode, asks:

How do you improve inter teams communications regarding common technical issues? It get’s really annoying and is cause for future confusion find two different solutions to the same technical problem, when a simple conversation between team leads, or teams will have come up with a unique robust solution once and for all.

Andy Hunt, the co-author of Pragmatic Programmer and Agile Manifesto, answers:

Talk to each other. Have lunch&learns to discuss legacy issues or cutting-edge tech you want to try, common problems, etc. Now, that’s easy to say, but of course this approach (as well as the other stuff I’ve said above) relies on a sense of Psychological Safety amongst the team members and leadership (and users, for the matter).

At a minimum, everyone needs to feel safe in expressing their ideas, and not be afraid of being called “stupid.”

Even stupid ideas can make hundreds of millions of dollars (c.f. “Sharknado”). The organization as a whole should lean toward the “Generative” side as outlined in the Westrum Continuum. In a “Pathological” organization, which suffers from information hoarding, there’s a distinct lack of safety and communication is actively discouraged. These orgs will fail, ultimately.

Andy Hunt, the co-author of Pragmatic Programmer and Agile Manifesto, answers:

Also and FYI, my next novel is coming out shortly. It’s about a haunted house set in the near future, after the US Second Civil War. There’s drones involved.

Editor: You can signup for notification of the book here.