Moving away from Agile

For the work that isn’t agile

Not all engineering work is right for Agile. And this is true for every framework. To kick start and encourage momentum for programming projects, work, and products, frameworks include code, guidelines, and assumptions for how projects are worked on. In a previous blog post, I shared more about Agile frameworks and the default features of those frameworks. After working in agile environments for many years, guiding my teams through it, and finally moving away from it, this blog post shares how to manage work without Agile.

Here’s what that means:

• We do not have sprints,
• Our work is tied to target outcomes and conditions,
• The team identifies the next steps as target outcomes and conditions are understood,
• Accomplished work milestones are shared, celebrated, discussed, reflected upon, and defined.

We do not have sprints.

That’s right. We do not have agile sprints. Work is managed with a Lean approach, known as the improvement kata.

Understand direction, grasp current condition, establish target condition, iterate towards target condition. (https://medium.com/@kelsy/method-the-improvement-kata-1b96b020138b)

Status updates are explained through completed, ongoing work and will work on next, and we outline the target outcome/result given the completion of the work. Retrospectives on the work are held throughout the week in our 1:1 or engineering meetings with each other. Team leads share status, releases, and announcements based on target outcomes, products, projects, and work.

Example summary from a Standup (/status update) meeting.

Engineering Health Checks serves as the official quarterly team retrospective, where we look at a total of 10 pillars of health and discuss where we are, what went well, what didn’t, and what could be improved upon. Action Items are assigned if necessary, and everyone works together to ensure the success and growth of the team.

Product launch dates and roadmap dates drive our deliverables and delivery rate. Our sprints do not drive it.

The process of how we work is ever-changing. As we adopt a versioning style and pattern, product releases are delivered as minor and major version updates described through changelogs.

Engineering Health Checks are commonly held across all engineering teams as a pulse check.

Sample notes from a discussion of the mission health check pillar in our last Engineering Health check.

Why does this work for the team?

1. We’re a product team. We develop data products that help stakeholders and audiences scale on first-party data. The scope of this work is full-stack data and requires differing practices and disciplines. Validation and testing require more nuance than parts of the product delivery lifecycle. Some work items don’t fit traditional one or two-week sprint cadences.
2. We tried Agile. The team initially followed a hybrid kanban scrum mixture to process data support tickets from stakeholders and the development of data products. We moved from a two-week to a one-month sprint before moving to the kata approach. Each change helped supplement the growth of research and development (R&D) work on machine learning models as data support tickets died down with the introduction of support data teams.
3. No unnecessary overhead when lacking project management and product management input. We’re a lean team of engineers and did not have a dedicated project manager or product manager/owner on our team. There’s overhead in managing sprints, writing user stories, posting updates, and following the framework. It didn’t make sense to follow a traditional scrum model where we would pull in a product owner to prioritize all the work contributing across various business lines and stakeholders. It didn’t make sense to replicate multiple scrums with each product owner for every product and project owned by the team.

In closing

The Kata process allowed us to organize our work based on the projects in progress without demanding busy team members to serve multiple functions or roles outside their main responsibilities. This blog post gives some inside into what improvement kata. Hundreds of frameworks could work for your teams, and I noticed that there weren’t too many descriptions or recountings of how this works in practice, so here it is. I started this work model with my team in November, so we’ve been using this process for two months. I think it ultimately led to a better understanding of what our team supports. If you have any questions, feel free to comment on this post!