Agile Transition—TL;DR
A hands-on, practical guide on how to kick-off an agile transition: Embrace the agile mindset and scale your engineering and product organization to harvest your organization’s full potential.
The Big Picture of an Agile Transition at a Fast-Growing Startup
Similar to all other journeys, transitioning to agile software development with Scrum starts with a first step: Creating Scrum team #1 from the existing engineering and product organization.
I have started this journey recently with a product delivery organization that is about 30 people strong. And I like to share some of my lessons learned along this path over the coming weeks.
This organization is part of a startup with great potential. This is reflected both in its growth, as well as in the quality of the investors, and its funding. However, like most other fast-growing startups, it hasn’t been a smooth ride all the time. And this effects both the engineering and product team on the one side, and the rest the of the startup organization on the other side.
One effect of scaling a product delivery organization quickly by hiring new members has proven to become particularly challenging:
The predictability of any product delivery is deteriorating, and allocating more manpower to the problem—without changing either mindset or processes—is not solving the issue.
This problem has led to the perception within the organization, for example, that the engineering and product team isn’t really aligned with the rest of the startup. And the consequence is well-known: “Us vs. them” silo thinking, local optimizations efforts, and politics.
And this is where the agile mindset comes into play. Contrary to today’s popular approach to introduce agile tools and processes primarily to increase efficiency, the intention of this startup’s management is a different one:
- Embrace self-organization and permanent improvement at team-level to enable a sustainable scaling of the organization
- Better the value proposition for the customers
- Further the organization’s future product discovery capabilities
- Advance the product delivery organization’s general standing with all other stakeholders by inclusion, transparency, and building trust.
Getting started with the Agile Transition: Identifying Patterns of Failure and Dysfunctions
Where to start then? A good rule of thumb for an agile transition is to go deep first, before you try to scale. My preferred choice is therefore being the observer and listener. I am participating in all meetings, and try to understand what has contributed to the current culture.
I also ask to have one-on-one interviews with as many team-members as possible, too. I intentionally don’t run a script during these interviews, but rather let the interviewees talk, and in some cases: rant.
I like to stress at the beginning of these interviews, that I am just taking some private notes, and that no one will ever get to read those. I also encourage my interviewees to “interrogate” me first, thus building a minimum level of thrust.
Interestingly, it seems to be a myth that engineers are uncomfortable with being part of that. On the contrary, they like to point straight at the problems of the organization.
If the interviews are evenly covering all roles—from engineers, QA, UX/UI, to product managers—it will take about 10 interviews before patterns of problems, failures, and dysfunctions appear.
Merge those patterns with the most pressing technical and business issues, and you end up identifying the most likely first objective for the agile transition. This could, for example, be a project or specific software release, that is late, or plagued with technical or functional issues.
If your stakeholders agree, it will be the problem that Scrum team #1 will be tackling.
Looking for Volunteers for Scrum Team #1
Dealing with organizational problems at such a level won’t work with people pressed into service—at least not to my experience.
You need volunteers instead, who fully understand the challenge ahead of them. Volunteers, who are eager to prove that there is a better way to reach the objective than being “managed” by someone from the hierarchy.
You need volunteers, who are willing to move out of their comfort zone, embrace the idea of self-organization, and accept accountability. You want those, who are aware today that focusing on delivering value will move the entire organization forward and create a scalable, competitive and sustainable business in the end.
So, set the stage for the creation of Scrum team #1 by inviting everyone from the product delivery organization, as well as your sponsor—probably the CTO— to a kick-off meeting. This meeting’s objective is to support the members of the engineering and product team to self-select a draft of Scrum team #1.
And here is the recipe that has been working for me several times by now:
- Choose a meeting room that can accommodate the attendees easily and allows to move freely in front a whiteboard.
- Time-box the meeting. The meeting, I am referring to in this post, took 60 minutes and was attended by 15 people. Prolonging the meeting—as I tried before at another project—will most likely only provide room to discuss minor team variations without providing radically new insights worthwhile this investment.
- Ask your sponsor to define the mission of Scrum team #1, and why this goal is so important for the company. (5 minutes should be sufficient for this prelude.)
- Then deliver the context of the agile mindset, self-organization, and the team’s autonomy on the one side, and the accountability of the team on the other side. (Don’t expect that everyone is already familiar with agile/lean principles.) Also, don’t be afraid to borrow from the DevOps “You build it, you ship it, you run it”-mantra to explain what they are getting into. The team needs to meet that standard in the future anyway. This sounds a bit like lecturing, but these 5-10 minutes are well invested to align everyone in the room with the “agile mindset”.
- Introduce all roles, that the team will need to cover: engineers, DevOps, UX/UI, or product owner, for example. If you assign a specific color to each of these roles, the selection process of the volunteers will become much simpler.
- Now ask all participants to write their names on one of the respectively colored Post-its and stick those to the whiteboard, if they want to volunteer for Scrum team #1. (In total, all of these preparations should consume no more than 15-20 minutes.)
- Now let the self-selection process start. Set the timer to 30 minutes and be surprised by the outcome. (Think George S. Patton: “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.”)
- During the closing stage of the meeting, wrap-up the goal of the future team, its autonomy and also its responsibility for the outcome.
- Point at the next steps for the team—agreeing on a Scrum ceremony schedule, create the first backlog, start the backlog refinement process, find a team name, to name the most important ones—and ask all participants to sleep a night over the first team draft.
- Also, sketch a transition roadmap for those team members, who did not make it into Scrum team #1. (Or didn’t want to be a part of it.)
- Check with your sponsor, whether the draft of Scrum team #1 is meeting her expectations.
- Last, but not least, if your sponsor supports the draft: Organize a follow-up meeting the next day and feel the pulse of the future team-members of Scrum team #1. During that meeting, revisit the next steps and agree on the further proceedings.
- If the draft of Scrum team #1 is not meeting your sponsor’s expectations, start over with the self-selection meeting.
Conclusion
Some of you may wonder, whether a meeting of 60 minutes is actually adequate, given the task and its implications. To my experience, it is. Let me explains this: On a former project, to which I contributed as a product owner, the team set-up was organized as a 2-days-workshop. While workshop was really fun, we practically ended up with the same team set-up we all expected beforehand.
So, according to Mr. Tuckman, my Scrum team #1 passed the forming stage. The storming, norming, and hopefully performing will happen one way or another along the team’s agile journey. More on that in one of the following posts.
(81)
