Abstract: After three years as a Scrum Master and Agile coach, I hit a wall coaching a team that did not want to try popular Agile engineering techniques such as TDD and pair programming. I had become a Scrum Master after four years working on the business analysis and account ownership side of things and could not speak from personal experience about engineering practices. In order to get some first-hand experience and to gain a new perspective, I chose to spend a year or two as a software developer on a Scrum team.
The experience has been eye-opening. I experienced a tremendous cognitive load working with a wide array of technologies; this pulled my attention away from many of the collaborative and process-oriented activities I cared about as a Scrum Master. I was surprised to feel strong pressure to complete work quickly, cutting corners, even when the Product Owner and Scrum Master were not asking me to. When this pressure was explicit, it usually came from my fellow developers. On the other hand, there is real joy in writing code and seeing a system do something worthwhile that it wasn't doing before. My outlook has changed tremendously and is something I want to share with anyone who works with development teams, especially Scrum Masters and other coaches. I am still enjoying my time as a developer, but I'm looking forward to returning to coaching and incorporating this experience into my approach.
Lessons Learned from Your Experience: - Modern full-stack Agile software development places a heavy cognitive load on developers. This can be directly helped by scripting, automating, and building custom tools. Refactoring and improving code quality also reduces this load and should be supported. The team's norms and workflow processes may be just a bit too much for developers to memorize and embody. This can be helped by taking the burden off of team members, such as by writing up the rules for stand-up or Scrum ceremonies on posters that hang in the room where the meeting occurs. Adding checklists and templates where possible serves as a reminder and ready-reference for the Definition of Ready or Definition of Done.
- It is easy for a team/project culture to make developers feel like they should hurry and cut corners. Discussions about velocity, cycle time, expected completion of a feature, burn-up charts, and so forth all lean toward doing more faster. It is also rarely in the product owner's wheelhouse to recommend slowing down and being more careful and thorough. It was important for the team to explicitly talk about how we wanted to do our work well, to celebrate it in each other, and to have the explicit support of our Scrum Master, product owner, and others.
- Writing code is fun. Getting code to work is a rapid and rewarding feedback loop. No other part of the job has the same immediate payoff. While writing automated tests can be part of the fun and frequently pays off, there are many aspects of it that are frustrating and not rewarding. Explicitly adopting team-wide approaches to automated tests and celebrating accomplishments with standing up or fixing test frameworks serve as good and positive reminders to push through. Similarly, being involved in backlog refinement and other planning activities feels like a short-term sacrifice for a long-term gain. Some people are naturally more likely to volunteer for "chores," so to avoid burn-out and unfair conditions, systems that rotate through everyone spread out the responsibility.
- Many good practices, like good habits, take real, intentional effort to form. Even if people recognize pair-programming and TDD as good practices, it takes a lot more to become comfortable and skilled such that they succeed and come naturally.
Attachments:
