Agile Coaches / Scrum Masters Shall be Technically Excellent or understand the importance of…

Simple, Effective and much less Stressful Software Management.

A recent tweet by Elon Musk sparked a debate about whether managers should be technically excellent, not just technically competent. In particular, Elon singled out “Managers in software must write great software”.

I agree with Elon! I will share my understanding and experience on this.

You might have noticed that there is a trend in software development: several new roles have been added to a software team, such as Agile Coach and Scrum Master (for simplicity, I will group these similar roles as ‘Agile Coach’). In these software teams, a large percentage of software development management activities have been shifted to Agile Coaches. The role of software managers is now mostly to provide support to the team, such as getting resources and liaising with various stakeholders.

According to Elon Musk, a good software manager needs to be a great software developer. However, the reality is that many software managers are talkers, and don’t code or test. They tend to exercise their power by wasting the team’s time on Jira or silly activities such as “estimating user story points for velocity”.

A large percentage of successful soccer coaches themselves are great players.

The fundamental reason is that a real understanding of software development is mostly gained by doing hands-on work for a long period. Therefore, I consider myself a 100X programmer after mastering Test Automation and Continuous Testing, and developing a handful of highly claimed my own apps in my spare time, such as TestWise, ClinicWise, SiteWise, BuildWise and WhenWise.

If a software manager can successfully introduce good technical practices of 10X or 100X developers to the team, surely the project will do well, and you don’t need to worry about velocity at all. Sadly in real life, managers often lead team members to do useless/simple activities (so-called agile ceremonies, which made Kent Beck, father of Agile, cry. see below) that even a child can perform, such as ‘Velocity Tracking’ and Retrospectives. The most harmful and childish (yet very common) one is ‘estimating user stories for velocity’ which fosters unnecessary stress. I recommend Allen Holub’s keynote “#NoEstimates” presentation.

“I was in South Africa, at Agile Africa, and somebody came up to me and said “Well, we want to do software development, but we just can’t stand all this ceremony and Agile stuff. We just want to write some programs.” And tears came into my eyes…like…how can it be that we who set out to refocus development on essentials and get rid of stuff that didn’t matter, how can it be that we’re right back where we were 20 years ago? Like how can it be that ‘this is too much ceremony’? … No, this is wrong. I don’t know what to do about it. ”
– Kent Beck, Father of Agile, in an interview (2019–10–15)

Here is what I learned:

The holy grail of software development is Continuous Testing that runs a suite of Automated End-to-End UI tests as regression testing in a CT server multiple times day.

If a technically not-so-good manager could truly understand the above, he/she can be great too!

A Story of a good software manager/Agile Coach who is not technically excellent

Jon is the best software manager I have worked with. He did programming in university and then worked as a system analyst for a long time. In other words, Jon was not technically hands-on.

When I learned Automated End-to-End Testing and Continuous Integration from a real Agile coach (a world-renowned programmer) back in 2005, Jon was in my team as a system analyst. He noticed the great benefits of Test Automation and CI.

A few years after we parted, he invited me to join his team within the public sector where he was a manager. Together, we implemented a real Agile/DevOps in a government project between 2008–2010. Our team had the capability to push updates to production daily, and this capability was enabled by Automated End-to-End Regression Testing.

At that time, there were no Agile Coaches or Scrum Masters. Jon’s management style was super simple:

• Only he used Jira, all other team members communicated via user story cards (physical index cards)

• After implementing a user story, a developer must show him an execution of automated tests that verify it.

• New automated tests were added to the existing regression suite which ran at least twice daily.

• If there was a broken build, freezing on new check-ins until it was resolved. Fixing broken builds was the team’s №1 priority. All meetings were cancelled if the red lava lamp (indicating a broken build) had been on for over a day.

Some astute readers might say: “I read similar stuff on books/Internet as well. It sounds theoretical, however, few developers can do automated end-to-end testing well. Also, maintenance of those automated UI tests (which tend to be brittle) is much harder than creating them”.

Yes, very good points. That was where I would come in as the tech lead of the team. Besides the usual (classic lead programmer role) work, I

• trained all developers on automated testing
  as well as business analysts (Yes, it is possible for business analysts to do automated tests). We wrote test scripts in easy-to-read Ruby scripting language and used a dedicated testing tool TestWise

• set up and maintained a Continuous Testing server
  Check out this article: My Continuous Testing Journey.

• maintained all tests green (or valid), every day
  Yes, it was very hard and under-appreciated work. It meant that I often needed to fix others’ code (as well as test scripts) that had introduced regression errors.

Some might ask: “how will this manager do reporting then?” Frankly, we (the team member) did not know or care. Developers/BA/Testers only interacted with individual user story (physical) cards. Our main focus was the build status of the Continuous Testing server.

A pair of lava lamps were connected to the CI server, next to my desk

In summary, Jon’s management style was simple and effective. In fact, when I think back, I believe it is more like what was described in the classic management book: “One Minute Manager”. Alike the one-minute manager in the book, Jon seemed not busy at work. In fact, he brought a Golf-Putting-Set to the office to practise his golf skills. A developer often interrupted Jon’s playing: “Jon, I finished this user story”. Jon stopped practising and happily replied: “Good, now show me the automated tests!”

There were good reasons why Jon’s management style worked well. He was not technically excellent, but he understood the fundamentals of software development:

• Code is interrelated.
  changing one place might affect others.

• Change is constant.
  therefore, a process to prevent introducing regression errors is essential.

• Developers make mistakes (a lot of them actually), which leads to tech debt.
  The earlier we can detect them, the easier and much cheaper to fix them. A classic software engineering principle.

• Tech debts lead to many issues
  “Broken Windows” theory.

• Defect tracking is not effective
  We have automated end-to-end tests for most user stories. For any issue/defect reported, we added/updated automated tests. Therefore, defect tracking is not necessary.

• The best method to keep high team morale: release daily
  Team members can go home with pride.

All the above cannot be solved by meetings or coding conventions, but only by Automated End-to-End (via UI) Regression Testing.

A senior software project manager who worked with me for quite a while once said: “Seeing how you work, I wouldn’t mind my two boys working in the software industry when they grow up”.