Agile is being implemented in organizations across the globe, in every industry, because of its promise to create high performance and sustainable success. Every business is looking for that competitive edge. With the uncertain financial climates and market trends towards people-centric work environments, new ways of working are now commonplace.
When implementing Agile as a new process and structure within an organization, the number one thing to think about is Agile workflow. Agile workflow means moving to a different kind of process – a different way of undertaking and performing work.
The counterpoint to Agile workflow is Waterfall, which is a very structured, rigid, step-by-step process that leads to a lot of challenges and rework. The Agile workflow is adaptive.
What Is Agile Workflow?
Agile workflow can be confusing because Agile is not one thing. Agile is a movement towards lighter weight, adaptive ways of working. Agile involves principles, such as collaboration with teams, different roles, and non-traditional work processes. All of Agile requires that people have an “Agile Mindset” – a non-traditional worldview and perspective about new ways of working.
When we talk about Agile workflow, we’re not talking about a single structure. The whole point of Agile is to customize the workflow based on the needs of the team and the environment to deliver the most amazing products possible.
The two most common variants of Agile workflow are Scrum and Kanban. Our view is that both Scrum and Kanban are useful and that a team should pick and choose what works for them. We use both together and what we’ll describe is a unified understanding of how these two can work together that is applicable regardless of what context you are coming from.
There are two ways to understand the flow. The first one is around understanding project launch, and what’s called “backlog grooming” or revising one’s intentions or plans. The other part is about execution.
In this article, we’ll walk you through the agile workflow step-by-step.
Agile Workflow Stage 1: Planning
Here’s how to get started:
Step 1: Vision
Step one is to clarify the vision for your project or product. We recommend creating a lightweight project charter, which is called the Agile Inception Deck. This is a really cool slide deck that can really be used to create a powerful vision, to create the alignment you need in order to have an effective project.
Step 2: Story Writing
Step two is called story writing. The purpose of this is to clarify the nature of the scope. Not the actual scope in terms of effort, but the nature of the work that the project is really about.
In story writing, we identify all the work that needs to get done to complete the project. It’s called story writing because it’s based on user stories. We write the stories from the perspective of the user or customer – the person who will get the benefit.
In old-school project delivery, we’d write it based on what the tactical people think needs to get done. What stories do is keep people focused on what is the outcome and the benefit of this part of the project. What is this delivery really all about?
Of course, you can go down a user story rabbit hole, and we suggest that you do. There are a lot of courses and articles that can help. We also recommend training in facilitation, which will be helpful (we say so you can be an Agile rock star!) when working with Agile workflow and teams. Below you will find a pro tip on a different way to create user stories.
Once you’ve identified all the pieces of work from the user’s perspective and created these stories, the next step is going on to sizing.
Pro Tip: Use the INVEST Protocol for Story Writing
The famous trap is that you write it from the user perspective – a good story format has a short title of 2 to 3 words and has a description that is meaningful for the team. And it lines up with the INVEST Protocol.
For example…
(Context: Extending an existing application)
Title: Change Address with Tax Rules
Size: 5 points
Description: Adapt the existing Change Address functionality to include custom business rules to check for changes of state of residence so that the tax engine can be notified of changes so that correct taxes are charged.
Step 3: Lightweight Sizing Estimates
Sizing is where we say, “Well, hey, how big are these things?” In a traditional project, people spend weeks or sometimes even months putting together detailed sizings. The Agile way to do it is to view very quick, lightweight sizing estimates, because it turns out someone’s gut feel is usually just about as accurate as spending a week estimating something. Our best advice is to use a technology called Story Points to estimate how big each story is in points.
Pro Tip: Story Sizing Is About the Process
Here’s the deal: it’s not just about getting the size of the stories. It’s more important to have a conversation about what the scope of work is. Open communication with the team and the customer is important. Get to know the reality of your organization, who is expecting what, how, and why. Questions reveal, what does the story really contain, does it contain a whole bunch of things or is it very specific and focused? It’s a great way to clarify scope between the customer and the delivery team.
Step 4: Plan
The next step is to create a plan. The best plans are created by sorting stories based on value and risk. When we sort by value and risk, we get a clear picture: what we should do now, because it’s risky? What do we do in the mid-term? And what should we do even later so that the team can focus on building the most important features first?
The reason we want to prioritize by risk is that that will de-risk the project. If we want to have a successful project, we’re going to tackle the risks early. It could be a technical risk, it could be a business risk. It could be a schedule risk where we want to make sure that a certain piece is done by a certain date. It’s really about, what does the team need to learn to be successful?
Step 5: Estimate
One of the important things that people always want to know is, when will I get it done? This is a bit tricky. If you have a new team that’s just getting started on this, you don’t have any idea of exactly how many points worth of work you can get done each week. The best way to estimate is to have everyone guesstimate how many months they think it’ll take to get the project completed based on completing a certain set of stories.
If you take the weighted average of everyone’s guess, that’s probably the best estimate that can be done at that time. Now, of course, people will always want to have a better estimate. The best thing we can do to get a better estimate is to get started on the project and tackle those risks. This will clarify the team’s understanding of the work that needs to be done and we actually have some real data to make forecasts. And that moves us onto the next phase, which is delivery.
Pro Tip: Considerations for Estimates
How well can you read your team? Do you know how to read or listen to your system? People will try to over-deliver or underestimate how long projects will take to complete. Be realistic and know how to read your system for the reality of projections and workflow. Do people in your organization have enough psychological safety to tell the truth about the project delivery? Does your team know their workload and understand the reality of how they can manage time and commitments? Have you estimated for delays and other projects or emergencies?
Agile Workflow Stage 2: Delivery
The delivery phase is when the team moves from planning mode and starts getting work done. There are a few different ways of doing this stage. First, let’s look at the Scrum Flow.
Planning
The very first step is planning – taking a story from the backlog or the list of things we want to work on. Often, we’ll take a story and we’ll break it down into tasks. If you’re using Scrum as your process, you’ll have what’s called a sprint planning meeting where the team will get together, they’ll go through story by story and they’ll break each story into tasks.
The story is the big piece of functionality that we’re trying to build, sized so we can get it done within two weeks. If it’s too big, we actually want to go back over the planning side of the board and break that story down into smaller pieces. That’s important so that we’re only pulling in work that the team thinks they can achieve within the sprint timeline.
When we go from the story or the user perspective down to tasks, now we’re talking about what the team needs to actually do. What are the pieces of the software or activities the team needs to complete to fully complete the story? Tasks might include things like programming activities, testing activities, user requirement clarification activities, and design meetings.
In Progress
Every time someone starts on a task, they move it to the “in progress” column so that everyone can see. People’s names or avatars are in there. You can see, “Joe’s working on this, Mary’s working on this.” It’s really clear what every team member is working on.
Done
When we complete the task, we move it to “done”. What we’ll see is all the tasks slowly migrating their way to “done”. And when all the tasks are done, the team will check and say, “Hey, is this story complete? Is everything we said we were going to do done?” If it is, the team moves the story over to the “done” side.
Pro Tip: What Does “Done” Mean?
Make sure that there is a very clear understanding of what “done” means. When you have clarity of what “done” means before you begin the project, then there are no surprises or unclear expectations from anyone.
Review
Usually, at the end of a sprint, people will do a review or a demo session where they’ll show, “Hey, this is the working software we built, or there’s the working products we created.” There’s a critiquing review to make sure everything was completed as planned. If it doesn’t meet the requirements or it doesn’t work, it gets added back to the beginning of the queue for the next sprint.
Retrospective
The one thing that’s common to any kind of Agile workflow is that there’s a retrospective. During a retrospective, the team takes time to look at how they functioned as a team in the last period.
They say, “Hey, for the next hour, the next two hours, we promise not to do any work. Instead, what we’re going to do is look at how we can function better so our performance will improve in the next cycle.” Out of that retrospective, the team will gain ideas for working together differently. This also improves communication and creates a better working relationship.
Sometimes teams also come up with what we call improvement stories. Improvement stories are about items the team needs to sit down and work on. These are similar to a user story, but these are about improving the team environment. It can be related to the technical infrastructure or the approach to testing. It could mean agreeing on standards that will allow the team to function better or revising the definition of “done”. It will also include improvements on working together as a team.
Over time, the team won’t just be working on features for building products, they’ll also be working on features for improving the environment. They will be working on their production capability, which means that productivity will go up and up over time.
Daily Standup
What actually happens in the daily standup? In healthy Agile teams there’s a physical or virtual board, where everyone can look at all the work that’s going on.
There’s a boring standup version which is, answer the three questions: What did you do yesterday? What are you going to do today? And what issues do you have? We don’t recommend that.
What we recommend is the team just talk to each other as people. They say, “Hey, in order for us to be the most successful team today, what do we need to talk about? Is everyone working on the right things? Are there any blocks?”
It’s more like a football huddle. Like, “Hey guys, what are we going to do on this next play?” That’s a great daily standup. Not people answering boring questions and reporting to either the Scrum Master or the Product Owner, but team members who are talking to each other and figuring out how to be an amazing team today.
Pro Tip: Standups
We highly recommend using some sort of check-in protocol. We like the Core Protocols. In our courses and on our own team we have added our version of a check-in.
“Close your eyes, take 3 deep breaths and connect into how you are in this moment. What are your intentions for being here? Reminding yourself that your success depends on the success of everyone else in this group and that we are here together to learn, grow and support each other to be successful…” (or something like this).
For most organizations, closing the eyes is too weird. A simplified, non weird move would be; “Say your name and one word for how you are feeling.” The key here is that everyone has their voice heard and it will increase the likelihood of people sharing by 70%.
What’s Different in Kanban Flow?
I’ve described the Scrum flow above. In Kanban, it’s the same thing. We have the same meetings, but we do them in smaller pieces. For example, we’ll meet on a story-by-story basis, review on a story-by-story basis, and as stories are completed, we’ll start pulling in new stories. We don’t have this regular cadence of a week, two weeks and so on, like a Scrum Sprint. We’ll just pull new stories as the team has capacity to work on things.
Product Owner in a Nutshell
There’s a recommended resource we have for people, which is to watch a video called Product Owner in a Nutshell. It’s a really great summary of the entire Scrum process flow.
The Trap of the Agile Workflow
Here’s the big trap that most people fall into: everyone thinks that Agile is a change of process. But that’s only half true. When we move to an Agile way of working, we’re talking about completely changing the workflow. Most teams, given sufficient training, coaching, and on the job mentoring, are able to handle this.
The big gap is that the top leadership of the company hasn’t made the shift to an Agile mindset. So even though the teams are ready to start moving to a new way of working, the leadership and the managers are getting left behind. We call this the Agile Leadership Gap.
What we’ve discovered is that leaders actually need very specialized training for them to learn how they can be an Agile manager – what we call an Agile Leader.
This is a very intense learning journey, managers must learn what this new way of working is and how it differs from traditional ways of working. Managers will also be learning how to kick the command-and-control habit, because Agile is about invitation and collaboration.
Most people aren’t even aware of how deeply trained they are in the command and control habit. The “traditional” way of working affects everyday decision-making and interactions. And Agile is a totally new set of structures and processes that do not align with traditional structures.
We’ve actually created a whole program of training, the Certified Agile Leadership Training, as well as our Evolutionary Leadership work, to help leaders learn how to work in these new ways of working. We’ve found that this type of training is the only way to actually create an environment where an Agile workflow will function. For a primer on how to be an Agile Leader, check out our Agile Transformation Keys whitepaper.
