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.

Print Friendly, PDF & Email

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

Print Friendly, PDF & Email

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

Print Friendly, PDF & Email

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

Print Friendly, PDF & Email

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.

My modest contribution was to share some things I have learned from several iterations of technical training I developed and delivered over the years. I have not done any for a while but I still have a few relevant neurons left. I was recently at a client and had the opportunity to share with some younger engineers the things I thought they should learn to be more successful in their careers. They granted me the modern honorific of OG. If you are of my generation, you may need to look that up.

In the Agile Open session, I sketched out a suggestion on what might make a good curriculum for Agile developers. Not much of this is new. I learned most of it more than a decade ago, some 2 decades ago. For what it is worth, here is my list, in a learning sequence that makes sense to me.

Suggested Agile Developer Curriculum

You can get a lot of this in a Scrum Alliance Certified Scrum Developer course. The list would also be a great self-study course for internal engineering groups. We did some of these when I worked at Microsoft in the early 2000s. In discussion with others at Agile Open, I threw out an guessthat engineers could learn these topics in 3 months with a half day/week study if they integrated the learning into their real work. I have introduced the first 3 topics to groups in a half-day of training at several clients.

You may notice that automated acceptance testing, or story testing, is not on this list. I consider that to be a complementary but separate topic because it is trivially easy to learn. I have also gotten teams started in that in a half day.


I have heard good things about Mob Programming but have not tried it myself. Well, maybe once long ago when there were four of us “pairing”.

My favorite book on TDD is Test Driven. It also introduces automated acceptance testing.

CSD Providers I know: ToBeAgile, AgileForAll

Book: Beyond Legacy Code from David Berstein

The topic list above has links to other resources.

So What?

Do what you like with this. Learn, get better at your craft and go home each night with full confidence that the work you did today was rock solid. It is a great feeling.


Print Friendly, PDF & Email