During a recent conversation with members of a Scrum team about the concept of modelling workflows as a knowledge discovery process, one of the developers voiced a common objection: "this looks like very waterfall! we are Agile, and do all those things within our sprints".
He then proceeded to the whiteboard and drew a sketch of their tracking board:
"During Sprint Planning," he explained, "we select the stories we're going to take into the sprint, and then we proceed to identify the tasks for each. On the board, each story gets a lane, with its tasks lined up in the To Do column. As we start work on the story, we move the corresponding cards into the In Progress column, and later to the Done column when we finish the task. When all the tasks get to Done, the story is completed. As you can see here, we can do programming, business analysis and testing tasks in parallel."
In the Beginning....
"Interesting," I said, "where do the stories come from?"
"From the backlog, of course", he replied.
I took another marker and added a column to his sketch: "so, we could represent that backlog as another column, like this perhaps?":
"Sure," he said, "looks about right."
"OK", I inquired, "and how did the stories get there?"
"Well, we create them during Grooming meetings." He then explained in more detail: "When the Product Owner has a new idea, or when we identify a new requirement, we create an Epic in the backlog. Then, twice a week, we have a Grooming meeting where we talk about the new epic, and we split it into smaller stories. We have a 'Definition of Ready' that tells us things like the maximum size for stories that can be taken into the sprint, and the minimum of acceptance criteria we need before we can take the story to Sprint Planning."
"All right," I replied, taking my marker again, "so what if we visualize that like this:"
"Now that I think of it," he said, "after grooming but before sprint planning, we work with the UX team to finalize the wireframes for the UI. That's also part of our Definition of Ready, but it happens after Grooming."
"I see," I replied, "so what if we visualize it like this:"
Life Beyond Done
"What happens when stories get to the DONE column? does that mean they are in production, and in the hands of your users?", I asked then.
"Hmmm....not really...," the developer said, "we only deploy to production once a month. The stories wait in the DONE column until we have a production deployment window. We then do full regression testing of the application, and after fixing all the issues, we deploy."
"I see," was my reply, "so that means that there is another process after that, which we could also visualize as separate columns:"
"One more question," I then asked, "I've heard that frequently you implement the new features with feature toggles, can you tell me more about that?"
"Sure!", he said, "we normally release features to production but only visible to a small group of people (often, members of our staff), as a pilot. Once we're happy the features work how we want, we flip the toggles and they become available to the general public."
"Is that just flipping a switch, or does it take some additional work?", I asked.
"Well, it's not a lot of work, but it's not completely automated" he replied, "after changing the settings in the config files, we work with the testers to do some final sanity check, and then we make an announcement to our users to inform them of general availability."
"Understood," I replied, "so what about adding that to the visualization too?"
The End-to-End Workflow: Is this "Waterfall"?
At the end of the conversation, the sketch on the whiteboard looked like this:
What started as a "simple" depiction of the work happening "within" the sprint was now showing a richer workflow, covering the entire, end-to-end lifecycle for a piece of work.
The developer's initial observation that "they do all the activities within the sprint" is correct, but doesn't tell the whole story. Healthy agile teams collaborate across disciplines during their sprints to produce a piece of working software, and that collaboration often time takes place in parallel, rather than strict sequences. However, from the perspective of a given piece of work, some other activities happen "before" and "after" the sprint, usually in collaborative fashion as well. That's the "knowledge discovery process" we had been talking about: collaborative in nature, with a sequence of "dominant activities" that take centre stage while the others adopt a supporting role.
Does that mean that the team is not "really agile", and operating under a "waterfall" model? The reality is, you can't answer that question just by looking at the layout of the board. As discussed in "How Agile Are We?", the agility of a service is a measure of different concerns. Things like:
How frequently are new Epics added to this board? How frequently are they selected to move out of the first column, and into the rest of the workflow?
How fast do items traverse the board, end-to-end? How predictable is that journey?
How frequently are new features released to production?
More importantly, however, we'd need to also know the answer to the question of: how fit for purpose is this process? how well does it satisfy the needs of customers, users, and other stakeholders (including not only the service delivery metrics listed above, but questions about whether the work delivered is "the right work" for the people who consume it.)
The design of your board, can help you "unhide" some perhaps "inconvenient truths" about your process, and that may guide you to think about introducing changes to make it "more agile" over time.