Keeping Teams Aligned with Agile Workflow Design
|
When you hear the word “workflow” do you get excited, like you can’t wait to spend a day in front of a white board with a cross-departmental team and map out how you will all work together happily ever after?
Or, are you like most people and dread the thought of going through the process of designing and implementing a new workflow, no matter how badly you know your organization needs to change the way it works?
Anyone who’s been through an organizational change in how teams are to work together already knows this process is never easy. Just thinking about this may trigger thoughts of:
- Heavy, unmaintainable process that doesn’t scale
- Wasted time going around in circles trying to get buy-in from everyone involved
- Rigid rules that lead to impersonal interactions
- And maybe some overwhelming diagrams or documentation just to add salt to the wound
When the Product and Engineering teams here at Jama set out to establish a workflow between our two groups we had some of the same concerns. We were already productive, but we were growing quickly (and still are!) and we knew we needed to establish a formal way of communicating, one that would scale over time.
What makes a good workflow?
So the first question we had to answer for ourselves was, “What makes a good workflow?”
Simply put, the intent of any workflow is to help people better work together.
But people aren’t simple. And moreover, the products they produce aren’t simple, either. As a society we now rely on critical software and technology to run our economy, our military and to save lives. These products are, by definition, complex.
So as we developed our workflow at Jama we focused on the aspects that we knew would make us not only work faster, but better. Our Engineering and Product teams were already committed to Agile practices for its focus on people first, and even have an in-house coach. What we needed to improve was our communication to the Business, and also aligning all three groups around common goals—the “why” of what we’re building. So we decided to document and formalize our commitment to Agile by designing a workflow around these tenets:
- Facilitate fluid communications without a heavy-handed process
- Enable quick and confident decision-making
Getting Down to the Science (Behavioral Science, that is)
But we didn’t stop there. With my educational background in neuroscience and human behavior, I knew that groups can agree to a new workflow on paper and still fail to maintain it, especially in growth periods, which we were (and are!) definitely in.
We’d need something more than a beautiful flow chart. We needed to know what makes teams adopt new ways of working and stick with them.
I started investigating some of the latest research in how people work in teams and how they adapt to change. I found some gems that applied to workflows, as well as other struggles in my life, because really, what part of life isn’t about dealing with people and adapting to change?
There were two theories that I found particularly applicable to our team:
- Status Quo Bias
- Choice Overload
According to The Behavioral Economics Guide 2014, Status Quo Bias refers to the fact that “…people feel greater regret for bad outcomes that result from new actions taken than for bad consequences that are the consequence of inaction.”
People don’t like change. Not surprising. But what this research also says is that people are especially averse to change in work processes, even if what they’re currently doing isn’t working, because they’re worried that if the change leads to failure they’ll be liable and life will be worse than it is today.
Also, people will say that they like choices, but if they’re presented with too many options they become confused and overwhelmed and get choice overload. They need to have the right amount of information, at the right time, so they can evaluate and make a decision on a purposefully limited amount of criteria with just the right amount of, and right type, of data.
The Agile Workflow Design
Like I said above, a good workflow supports the people within it and improves their working relationships. So the first thing we did was get clear on who are the people who make up product development teams, what are they each responsible for in the process, and how can we support their communication with each other.
click to enlarge
This chart illustrates an example team, across departments, and the people who need to weigh in on strategy, plans and key decisions, and at what point in the product development cycle. This is a good, if simplified, representation of what our customers tell us about their teams’ compositions and dynamics, and also how we work at Jama.
click to enlarge
And this–finally!–is the Agile Workflow Design. If you’re familiar with Agile, you’ll recognize many of the steps. This chart also shows which tool holds which types of data, in our case, Jama and JIRA, indicated in the lower left corner.
Next, I’ll zoom in on the key steps in the Agile Workflow Design. The diagrams below don’t look exactly like the one above, and are designed to illustrate key points in the Workflow.
click to enlarge
Here the Product Manager or Product Owner documents the business need, or why we’re building this feature and who will use it and the value they’ll get out of it. This information is documented in Jama, indicated by the orange text.
click to enlarge
The Product Manager or Owner collaborates with Engineering—in this case, the Lead Developer—to understand the business need and develop Epics. You’ll notice two new things in this diagram. The first is the progress bar above the “Business Need” box, which indicates progress to completion. Right now we haven’t started development so it’s at “0%.” The second thing is the blue “Connected Users” icon. Right now there are 3 people involved in this project. Both of these indicators are taken directly from the Jama interface, where you can see current progress and the individual team members involved in a project, which is really useful especially if you have a global, distributed team, or, in our case, a growing company where you may not yet know everyone’s name!
click to enlarge
Now development work has begun. Epics have been broken down into stories in Jama, and that data has been synced, in this case, to JIRA (indicated in the blue text). Progress is tracked in JIRA and that data is synced with Jama. As indicated by the progress bar, we are now 15% complete in this work, and with the introduction of the developers, we now have 5 Connected Users.
click to enlarge
The QA team has been testing all along the way, but as we get closer to complete it’s a great time to confirm we’re still on track. We’re logging defects in Jama and syncing the status back to JIRA. We now have 15 Connected Users and we’re 65% complete in this work.
click to enlarge
Testing is complete and we’ve confirmed that this feature meets the business need. We’re now at 100% and ready for release!
And that’s the Agile Workflow Design, explained. Of course, for our team at Jama coming to this design was a gradual process, which included many conversations and agreements made. We’re always improving it and it’s been worth the effort. Now our teams are more connected to the business need behind our development plans, and other departments, such as Operations and Marketing have more insight into what we’re building, making it easier for those teams to do their jobs well.
Take This To Your Team
I want to leave you with a few useful things to guide you the next time you find yourself in a process meeting, or designing a workflow:
- Workflows should connect people first, and data second. After all, it’s people who actually get the work done. It doesn’t mean that codifying a series of steps and procedures is a bad idea, as many people are building very complex things and they may just need to account for twenty well-defined steps in order to get a quality product out the door. What I’m highlighting is the fact that at every touch point where people need to exchange information there’s an opportunity to make that interaction as smooth and productive as possible. When you focus on this you’ll have an easier time getting the group working together in a “flow” as much as possible.
- Remember the “why” of what you’re building. Stay connected to your original business goals, and build in opportunities to adapt to change as it inevitably arises. Don’t wait for people to protest since Status Quo bias inhibits that.
- Avoid Choice Overload by limiting the number of available options when a decision must be made.
Hear more about team collaboration in the recently recorded version of our Agile Workflow Design Webinar. We cover these concepts and more, in-depth, and answer questions from the webinar audience.
About the author:
Robin Calhoun is a product manager for Jama Software, as well as a certified ScrumMaster. Calhoun users her education in human behavior and economics to direct product decisions and team management, combing this expertise with the ever-evolving body of knowledge in Agile development practices. Before joining the Jama team Calhoun was a product manager at Tendril, defining data-driven Energy Service Management products. She holds a degree from Columbia University in Neuroscience and Behavior.
Robin Calhoun writes about requirements traceability, drawbacks of using legacy requirements management tools (like IBM DOORS), connect data, and aligning teams with an Agile workflow design.
Latest posts by Robin Calhoun (see all)