Agile Coach Journal

Agile Coaching in the Age of COVID-19

On August 18, 2020 I joined some colleagues for a MeetUp session on the Business of Agile Coaching. I have done similar sessions on this topic over the years. This was one of an annual series presented by the San Diego chapter of the Agile Coaching Exchange. You can find out more about the group and the session here. (ACE is a great group with local chapters in the US and UK.) Slide decks from some of my prior sessions can be found here. My friends on the panel were Alicia McClain, John Eisenschmidt and Brandon Raines.

In this year’s session, we wanted to add some commentary around the current state of affairs, how the COVID-19 lockdown has impacted business for most of us in the US and many beyond. Since my personal response was to just step back from my one active client and let my fellow coaches do the real work, I did not have a lot to offer myself. So I went to one of my strongest sources, the Scrum Alliance™ Certified Team Coach® and Certified Enterprise Coach® community for lessons learned. This community is close to my heart, having been a founding team member for both programs. (more…)

Why Hire an Agile Coach?

I was honored to present at the Scrum Alliance(r) Austin Scrum Gathering in the Champions of Agile Track on May 23, 2019. My topic was “Why Hire an Agile Coach?”.

The slides from my talk are available here.

I don’t think anyone recorded the talk and I don’t know a good way to condense 45 minutes of information (and informed opinion) into text, so I will just summarize the objectives and conclusions here:

(more…)

Agile Agency: State of the Art 2018

I did some Scrum training for a creative agency earlier this year. The workflow at this company is not an obvious fit to Scrum as originally designed for software. To help find the best fit, I did a survey of how other agencies are applying Agile/Lean principles and frameworks to their work. A summary of my findings, with references, is in this deck at SlideShare.

Just Say No

Scrum is, by design, a “pull system” rather than a “push system”. The Scrum Team determines how much work they will pull in to each Sprint. The Product Owner determines what items are ready to be pulled in according to priority.

There are legacy forces that work against pull systems, trying to push work into both Product and Sprint Backlogs. These include stakeholder requests, maintenance fixes and client feature changes. Scrum is designed to absorb feature requests and changes by buffering them into the Product Backlog. Maintenance work is buffered by defining a set percentage of Sprint time for fixes and paying down technical debt. Ideally, a new product is built using Agile engineering practices that make maintenance virtually unnecessary.

There are times, however, when the legacy forces overpower the Scrum machine. (more…)

Maintenance Patterns for Scrum Teams

Try as we might, software products are never perfect. Coding styles, legacy bugs, tight deadlines, changing frameworks and evolving languages all contribute to the error potential of complex systems. Scrum Teams are often faced with the choice of working on new features or fixing problems, especially with aged systems. Even greenfield products can quickly accumulate technical debt if XP practices are not in use. (more…)

Creating a Team of Experts

In the software world, there are principles that can be applied to make an architecture more agile. One of these is “design for change”. Because change is inevitable, a robust design will anticipate change in a way that minimizes impact to the existing system. A related design practice is to encapsulate what might change behind an interface (API). And a good practice for software in general is to hide the implementation of whatever happens behind the API so that code that relies on the functionality does not have to change its messaging or expectations when the hidden functionality is changed. (more…)

« Previous