Agile Coach Journal

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…)

Agile Developer Curriculum

I know, long time since the last post. Life is rich. Thanks for asking.

I was at Agile Open San Diego last week. Thi sis annual event where smart people get together to learn from each other. I highly recommend it for next year. There are other Agile Opens in Orange County, San Francisco and Seattle.

I attended a session to discuss training for developers on Agile Teams. It was a small, passionate group. There were people from Net Objectives, a great source of technical resources and enterprise Agile transition, and Rocket Nine Solutions, an Agile consultancy I have been working with over the past year. (more…)

Defining Business Value

I held a workshop at Scrum Gathering San Diego today on how to define business value. I promise, promise to post some narrative around it in the near future.

Thanks to all who attended. I am honored and humbled.

The slides are here.

The exercise is here.

« Previous