)
About the author: Olaf Schuhmann joined sennder in May 2020 as agile coach & delivery lead. He has been part of the agile community since 2011, and he’s worked with a wide range of companies from 5-people startups to small-medium enterprises to international corporations. He focuses on empowering diverse teams through training courses, guidance, and mentorship.
At sennder, he works with multiple teams within the business area of Operations & Finance.
Setting the stage
sennder is a scaleup undergoing an exciting phase of hypergrowth. As of Q2, 2021, we have grown 5.5x bigger than we were one year before, and we plan to be almost 8x as big by the end of 2021. To maintain an effective and successful business operation while growing this rapidly, we need a healthy base and common agreements on how to operate.
In early 2020, product and tech teams were working together the best they could with the knowledge and tools available at that time. People were working effectively and an established process was in place, but it was definitely not set up for scale. That’s where agile organization came into play.
The freedom of choice
Within sennder’s vision of agility, every team has the freedom to choose the operational model that fits them best as long as we all agree on our common values, principles, purpose of existence, and how success is measured.
Considering these points, a team establishes its mission and working agreements. Many teams chose to work with a digital Kanban board. Others went a step further and established work-in-progress limits, measured cycle time, and started working on effective workflows. This has helped teams stay focused, avoid context switching, and deliver within shorter time frames.
Other sennder teams chose Scrum as their preferred method, and some work with a mix of methods. We encourage every team to find their own way. However, this only works thanks to our common base, regular cadence, and stakeholder alignments.
Defining the north star
Product teams in sennder tech host sessions where we create working agreements and define some key aspects of our work. These key aspects include the common base (foundational principles and values), the north star (a guiding vision), the direction (where we are going), and the reason for existence (why we are important).
I work with my teams along two different tracks to set up the agreements.
The first track is about teaching the concept of agility and why it’s important. We talk about the modern agile movement, organizational structures, and team topology. We also talk about sennder’s favored dual track agile model, and about artifacts to make sure everybody understands the context before we take it and make it our own.
The second track is more inward facing, and it involves the most important aspects that influence change. We talk about values, what we consider important for a healthy work atmosphere, principles, and our mission. Ultimately, this is our north star. Lastly, we focus on practices. We come up with and agree on ceremonies, our value creation flow, and our unique definition of when something is done and ready.
Even after this process is done, it’s not set in stone. We constantly work on our agreements, reviewing and amending them if needed.
An example of a Miro board used for the working agreements sessions at sennder.
Dual track agile
One of the important concepts we talk about in our working agreements is the dual track agile approach. Product teams split the product delivery process into two tracks to create a streamlined and effective development cycle:
- A discovery track
- A delivery track
The discovery track focuses on quickly generating valid product ideas for the backlog, and the delivery track focuses on turning those ideas into releasable software for our users.
Both tracks exist next to each other and are codependent.
It's all about collaboration and working together on every level each step of the way. Most simply put, the idea is to release, measure, and learn in a constant cycle. Discovery and delivery track running parallel in dual track agile approach.
Measuring & learning
At sennder one of our core values is trusting in data. Likewise when it comes to implementing agile practices, we also need to trust in data. We take careful measurements to ensure our data is trust-worthy, then we look at our measurements and see what there is to learn.
As an example, with our Kanban teams we measure cycle time, which is the time we spend on an item after it leaves the discovery phase, so pure delivery time. We focus on cycle time at the moment as it is easy to measure. Next steps would be to also measure lead time, which includes all of the discovery activities. For this we’ll be working closely with both the product and design teams to understand every aspect that should be included in the measurement.
When we first implemented the Kanban principles at sennder, we decreased our cycle time by 50% in one team and 40% in another within 2 months, which resulted in faster product delivery and higher customer satisfaction. We also identified various bottlenecks, such as distributed code review and backend-frontend dependencies in our development process.
For some of the teams we even changed the way we do our daily standups. We found that by only focusing on items on the board, we could maintain a more streamlined view of what is happening with our product delivery.
Of course, aspects outside of the team also play an important role in influencing the cycle time. Some of these factors include: CI/CD pipeline, code review, and dependencies by other teams. We’re trying to factor in all those aspects as well.
Throughout this process we keep in mind that every team is different. We strongly believe in empowering our teams by acknowledging individual strengths and working on weaknesses. This allows us to sustainably improve product delivery.
Pitfalls and things to watch out for
We don’t live in a perfect world and what works for one team might not work for another. We strive to create a safe environment to fail, measure, and learn.
To be an effective and agile leader, one needs to be flexible about the time needed to complete tasks. Avoid pressuring teams, and remember we’re working with human beings. It’s helpful to set the expectations in the very beginning, and allow each individual to check in and adjust every now and then. Eliminating WIP limits may allow your team to be faster from the start, but the team needs to understand why and how to adjust those limits later on its own. Creating a product is a process, and the team needs to learn together.
Finally, don’t forget to think about the big picture. How is your organization set up? What about team topology? Does the structure allow teams to be as autonomous as possible? Having all of this in mind, you’re good to go. Be ready to fail, and then learn from your mistakes.
)
)
)