Adopting Agile as a Second Language

With my clients the first job is always adopting or improving Agile.  My methodology is named, “Agile Agile: The Agile adoption of Agile methodologies”.  This piece is about the first steps, winning support and starting to sprint with minimum disruption.

Winning support always requires some evangelism. The prospect of change meets with reluctance. Two common concerns I hear a lot:

“We can’t start engineering until we have a complete spec.”
“We don’t have time to write user stories and attend meetings.”

You might find it surprising that I hear both concerns at the same time. And I hear them from both Waterfall teams in big organizations and very young nimble teams in early-stage startups.

From another perspective it’s not surprising. All development teams need to know their ultimate goal. They need to know what product they’re shipping. Management pushes for a spec, viewed as completely describing the goal and product.

And every person on every team is ridiculously busy. Adding processes like sprint planning, daily stand-ups, reviews and retrospectives isn’t possible. No features are developed in these meetings and no bugs fixed. Everyone has more important work and no time for user stories and meetings. Time for learning a new Agile tool? Never!

So here’s what I do

Agile is like learning a second language for these teams. Teach it the same way English is taught to migrants as a second language. Teach teams to function better than they did, in the same environment, with the same goals, but a new language and additional benefits. Minimize change and take steps toward Agile without changing existing priorities and without unnecessary process change.

I encourage writing specs as a planning process. Teams should adopt a shared vision for their product and an MVP (Minimum Viable Product) list of features. Typically in a spreadsheet. Also user experience designs and project plans showing dependencies and milestones. These create visibility on resource requirements so teams can adapt and grow with the best mix of skills and experience.

Specs are never finished. It’s impossible to cover every detail in every aspect. Not possible to design every detail of every visual and interactive design element. Can’t measure every performance requirement or optimize every Microservice before engineering starts. Also plans change and specs need to be maintained.

Focus on ensuring the best use of time for all team members. Use the artifacts from the spec to set priorities and save time writing user stories that describe work. This is the best way to start Agile as a second language. Show the quickest benefits with the minimum change and minimum disruption.

The concrete details

Start with the MVP spreadsheet. If you don’t already have it, add a column for priority and rank the features. Make a second column for prerequisites. Use this column to identify the features that have the fewest prerequisites. These are the features for which work can start immediately. Prerequisites could be other features, hiring a new developer, licensing a tool, completing a design, fixing certain bugs or anything else. It doesn’t matter if you name the prerequisites or give a number to the size of the prerequisite or just put an asterisk next to features with no prerequisites.

Now you can sort the MVP spreadsheet based on priority first and prerequisite second. Let’s focus on the top priority features with the least prerequisites. I’ll whisper a secret, this is the backlog for the first sprint.

But not so fast

We’re not really sprinting yet and we don’t have support for Agile adoption. What we have done is identify which features should be developed now. We’re confident these are the top features so we can invest in describing the work thoroughly.

Describe each feature. Gather all available artifacts. This includes algorithms, schemas, interfaces, designs, performance requirements and test plans. Identify which missing artifacts are required before work can start.

Assign an owner or two owners to each feature. Have them write a very brief overview of the feature and a bullet list of tasks to execute. The first tasks should address any missing artifacts. Once this is complete for every feature, you have the first sprint plan.

The summaries, task lists and pointers to artifacts should be stored in a single online-accessible repository. I recommend both ZenKit and Trello boards. Each feature can be a card or each feature a list with cards for each task. Any purpose-built Agile tool will support this too, but not required at this point. For very small teams, a simple spreadsheet or document would suffice.

As work progresses, the repository should be updated. Links should be added for new artifacts. Tasks updated as they are completed. New tasks added and obsolete tasks tagged or deleted. Do this for 2 weeks. Redo the entire exercise after 2 weeks, starting with the next priorities and prerequisites in the MVP spreadsheet. Also carry over any unfinished work from the first 2 weeks. Now you are ready for the second sprint.

Every subsequent sprint will be easier to plan. Each sprint should address the top remaining priorities in the MVP spreadsheet. If the product vision changes, the MVP spreadsheet will change accordingly. The process of planning sprints remains the same.

The benefits

The MVP can now be ranked and sorted to show the top priority and most achievable features. This is the most important work to be accomplished in the next 2 week sprint. The team has a repository which is a system of record showing top work for the team. The repository is online so it’s visible to all management and other stakeholders. As work is completed, forward progress is visible to everyone.

This is the first stage of Agile Agile, the Agile adoption of Agile methodologies. We’ve leveraged existing process and artifacts. We’ve minimized disruption and change. The team has an online system of record visible to management and all stakeholders. We can see immediate benefits of visibility, adhering to priorities and the potential for measurable progress.

In future posts I’ll present the next steps for easiest Agile adoption with maximum benefits.