I was originally going to talk about organizational change management, and about the challenges faced and how to break down barriers and help organizations mature and innovate. But everything I was writing came across so dry and textbook-like, that instead I sat back and thought of a story to tell.

So here it is.

There’s twice in my career that I tried to take an organization from “doing nothing” to doing full Sprint/Scrum/Kanban/Agile/Whatever.

The first time I didn’t really succeed. This was an organization where they did things like copied around zipballs of source code, did a lot of diffmerge, and just emailed each other with tasking and status updates. So what I tried to do when I came in as the Lead Developer was to install Jira and Mercurial and just move everyone right away to a full Sprint model. And a year later things weren’t much better.

Looking back, however, what I see in hindsight is that -some- things were better. Source code control was in use, and Jira was used to track who was doing what, and so things got better there. But full-speed sprint planning and retros never took hold. What I learned from there was:

• People will only do tasks if it makes their life easier
• Any “one-size-fits-all” model pretty much will never work

The second time (this was years later) I was more successful. I took a team from again, “doing nothing”, to a pretty good agile-based implementation. It took a long time, careful planning and orchestration, and some knowledgeable and willing people to help. Here’s what I did:

1. I started by just holding a weekly meeting (per team), usually on Friday right before lunch. At first, it was just going around the room, “ok, you’ve got two minutes, tell me what you’re working on”. We stayed in this phase for about 3-4 weeks. It was just to get everyone in the habit of having a ceremony and being able to talk out loud in front of other people.
2. Phase 2, the question evolved into, “ok, you’ve got two minutes, what did you accomplish this last week, and what are you planning on doing next week?”. This got everyone in the habit of being able to adjust from “talking out loud” to “talk intelligently about specific tasks and goals”. If someone started talking about implementation I would interrupt, just get them to focus on the outcome. “When you are done, what can the system/product/team do now that it couldn’t do before?” This gets everyone maturing to be able to think about things in terms of tasks and “definitions of done”. We stayed in this phase for 4-6 weeks.
3. In the next phase, here’s where implementation got tricky. I would keep careful notes of what everyone was saying. Then, when they took their turn, if they did not list what they got done last week with what they said the week before they were planning on doing, we would address that. I tried to put a lot of emphasis on no one was in trouble, I just wanted to know what happened. Did they underestimate? Got pulled into other tasks? We stayed here for a long time, like 6 weeks. This really helped everyone start to learn how to handle interruptions during the week, and how to get better at task decomposition and effort estimation.

Notice, at this point, we’re like 4-5 months in and still not really doing agile. But we are growing our organizational maturity and skillset, and moving along the right path.

So the next phase then, this was an “invisible yet magical” step. By taking notes from everyone and tracking it for them, I was able to put together some backlogs and sprint plans and show them how we were doing sprint already! When someone said they were going to do something next week, we could track it as an item for the sprint. I did some lightweight points/tshirt sizes (1 hour, 1 day, 1 sprint, multisprint) and over time was able to create historical data.

This was the turning point, right here. This is where someone could realize how sprints worked, and this was the point where the teams could break off and start doing their own thing. Some just stayed with 1-week sprints. Others moved into Kanban. And others decided agile still wasn’t for them.

The important takeaway here is that it took many months, and a managed, gradual approach, for the teams to get there. Simply sending everyone to a 1-week “Scrum Training” class and then expecting everyone to just “start doing it” is rather risky. But planning a phased rollout and migration can greatly increase your chances of success.