In this blog post, I describe the way we currently work as a team to deliver our product (TimeRocket) to our users and customers. This reflects our current understanding of working in an agile* way that matches our needs and skills.
We are uncovering better ways of developing software by doing it and helping others do it.
Manifesto for Agile Software Development (agilemanifesto.org)
As the manifesto for Agile Software Development states, we continuously try to improve our way of working, so this is a description of the current state and probably will change.
Our approach differs from Scrum, Kanban and XP, so I hope you’ll find it interesting.
* maybe it would be better to call it feedback-based than agile because the word agile is misinterpreted heavily nowadays.
When we started working on TimeRocket, most team members were new to agile software development. So we began with Scrum because it is well documented. That simplified getting everybody on the same page and starting quickly.
After a while, we hit our heads at the limitations that Scrum had for us.
Our Problems with Scrum
When we start working on a new feature (for now, let’s call it a feature, that will change later), we often learn a lot in a short period. This learning often results in changes of our current plan – on what we want the feature to do and how we want to solve it. Frequently, these changes disturbed our Sprint Backlog. We didn’t want to cling to an outdated plan, so we had to change the Sprint Backlog, sometimes even the Sprint Goal.
In my experience, some people would object that our backlog items were not ready to be pulled into the Sprint. If the items would have been prepared better, there would be less change. That would be optimization in the wrong direction because it would increase task switching, lead time and feedback cycles. When we start working on something, we want to get it done as soon as possible, without idle time.
We got quickly better at delivering smaller increments more frequently. On average, we deploy a new version 1.7 times a day. That led us to our next problem with Scrum, reviewing all product increments at the end of the Sprint (Increment in the Scrum Guide) was just too slow. The changes were already in production. So we reviewed items when they were finished implementing (and testing of course) and then deployed them. There was nothing left to do in the Sprint Review because we did the activities continuously per item.
Here I often get the objection that this is not possible because the team cannot get all stakeholders together ad hoc. That is certainly true, but a single small increment often has only an impact on a few stakeholders. So just show the increment to them. And as a hint, it is not my problem when all people in your organisation are in meetings all day long! That is a different problem that needs solving.
We improved on making items small. We try to deliver increments that are as small as possible so that they still provide real value to at least a single user, not smaller. Some items are therefore really small, a couple of minutes of work, most are a couple of hours up to a few days, few are multiple days. The different granularity of the work items makes it hard to “fill” a Sprint. This one size fits all approach didn’t work for us. I’ll explain what we did about this later.
Regarding improvements, we quickly started solving impediments in our daily work immediately. We saw no value in waiting until the next Sprint Retrospective and having to deal with the problem till then. On the other hand, we seldom had enough time in our Sprint Retrospectives (which should be timeboxed to a maximum of three hours) to get to the bottom of our hard problems.
Finally, our Product Owner didn’t like the role’s description (as described in the Scrum Guide version of that time, today’s description is better). We as a team always strived for collective product ownership because the whole team can better predict the consequences of decisions made and can provide more diverse views on the product. Collective product ownership also resulted in team members being more engaged.
What we wanted to keep
So we experimented with different ways of working. But some things were important to us, and we didn’t want to lose them:
We liked the pillars of Scrum: Transparency, inspection, and adaptation. Transparency is essential for collaboration, and inspection and adaptation are fundamental for improvement.
We weren’t really aligned with the Scrum values (Commitment, Focus, Openness, Respect, Courage), but we found XP’s values a better match: Communication, Simplicity, Feedback, Courage, and Respect. Simplicity is the basis for being able to sustain a software product over many years, and Feedback is the core of working in an agile way.
We called what our experiments led us to the caretaker model.
The Caretaker Model
If I had to summarise agile working with a single concept, I’d say that higher agility means doing everything more continuously.
We don’t plan just once – called Waterfall – but very frequently, we get feedback as often as possible, we deliver a software update in small steps over and over again, and so on.
People over processes and tools
At the heart of the caretaker model are people. We develop and operate a service for people. Everything else should only help us and our users and is not a goal of its own.
Continuous Improvement Cycle
Whenever we stumble over a problem that impacts our ability to deliver features quickly and in good quality, we aim to remove it as quickly as possible. We don’t wait for a retrospective at the end of the Sprint. If it is a problem, we fix it now. It makes no sense to live with a problem that can be fixed now. Of course, we have a short discussion in the team about the value of a solution. If it is worth solving, we want to benefit as quickly as possible.
The continuous improvement cycle takes care of the problems we encounter while working on the product. But from time to time, we need to take a step back and look at how we work from a higher altitude. That’s what the retrospective cycle is for.
Retrospective Cycle
Every couple of months, we hold a retrospective to look at the big picture of how we work and look for improvements. We reserve at least half a day for this so that we don’t have a tight timebox lurking over our heads. Reserving doesn’t mean that we have to use up all the reserved time. Having enough time is important to get to the bottom of more wicked problems and find possible solutions.
Planning Cycle
We have a weekly planning meeting where we meet to plan ahead. This meeting consists of two phases.
In the feedback processing phase, we look at all the feedback we got during the past week. The feedback we got from our users or our telemetry. I’ll come back to how we gather feedback later. We discuss how we want to adapt to the feedback – do we want to implement anything? If yes, what’s the priority?
In the planning phase, we discuss what we want to work on this week once we finished the currently worked-on items. Note that this is not a Sprint, and things don’t have to be done by the end of the week. Things are done when they are done. No need to rush to meet an arbitrary deadline. But we want to be on the same page what we want to work on next.
We don’t plan User Stories or Items. We plan “problems”. Our service solves the problem of tracking attendance time (and many related aspects). This problem can be broken down into smaller problems** (how to track attendance, how to track sickness and vacation, how to plan duties and so on)
** If you break a problem into smaller sub-problems (analysis), please don’t forget to think about how you will combine the sub-solutions to build a consistent overall solution (synthesis). Many business, architectural and design problems arise from neglecting the synthesis part.
So we build our system by solving one small problem at a time. Iteratively (improving on the solution to the same problem) and incrementally (solving more problems or the same problem but for a larger user base).
At the end of the planning meeting, we know the top couple of problems we want to tackle next. We typically prioritize these problems by business value. What would help our users the most?
Estimation plays a very minor role in planning. We only estimate in the granularity of hours, days, weeks or months: “What are we talking about here? Do you think this can be solved in a couple of hours, or is it more a couple of weeks?” We regard anything else as a pure waste of our time. Estimation in software development simply does not work. But that is another blog post.
To help us focus, we have so-called milestones that describe a certain area in our application that we want to focus on for the next couple of months. A milestone has no date; we are there when we are there.
Collective Product Ownership
We don’t have a Product Owner (PO) anymore. We strive for collective product ownership. It’s like collective code ownership that encourages everybody to work and make changes to all code. With collective product ownership, everybody is encouraged to make product decisions. Of course, we cannot all make our own decisions and run in a different direction. There needs to be alignment and conversations. Everybody on the team needs a good understanding of the domain. But you never have to wait for a Product Owner to make a decision.
We aren’t afraid of making wrong decisions because – as our journey so far has told us – our decisions are always at least a bit wrong. When we learn more about the problem and its solution, we very likely find a better decision later. So we ensure that our software can easily be changed to adapt to the new learnings and updated decisions.
The caretakers
Whenever a developer finishes solving the current “problem”, he*** picks the next problem to work on and thus takes care that we deliver a solution to this problem to our users. He becomes the caretaker of the problem. If possible, the caretaker takes the topmost problem to be solved. However, this is not always possible because attendance time tracking and its related topics is a difficult domain. So sometimes, a developer picks the topmost problem he can effectively work on. As a caretaker, it helps a lot to have a good understanding of the business domain. In the rare case that there is nothing the developer could take care of, he would support another caretaker.
***we currently only have male developers
My duty as a caretaker is to take care of the problem by finding a plan on how to tackle the problem and how to deliver a solution to our users. Be aware that a caretaker is not a lone wolf developer doing everything by himself in isolation. It’s part of the job to think about how to best tackle the problem as a team. What can I do more efficiently alone? For which parts is pair or team/mob/ensemble programming a better fit? When do I need support from the team? A caretaker can rely on the support of the whole team. We value helping others higher than finishing our own stuff. This needs a high level of collaboration skills, but the results are worth climbing the learning curve.
The plan made by the caretaker is optimized for the current problem at hand.
Maybe the problem isn’t clear enough, and additional refinement is necessary. Maybe we should talk to the affected users? Maybe we have to analyse some telemetry data on how the current system is used and doesn’t solve the problem well enough.
Maybe we have to do some research on how the problem could be solved. What experiments could we do to find a good solution? What’s the value of the solution – how much time should we invest?
What could a solution look like? How would we design a solution? Are there several options? What are the advantages and disadvantages of these options?
Who will code, test and automate what?
Does the caretaker want a code review (sadly, I wrote Pull Request on the picture)? When?
And finally, what feedback cycles do we want to have for this problem? I’ll come back to feedback a bit later.
“Planning” on how to tackle the problem can be done in a couple of seconds for simple or typical problems, or it can take hours for more complex situations.
Continuous Release Cycle
Once a problem is solved, we release the solution to our live system for our customers and users to be used.
A couple of months back, I analysed our releases and found that we released a new version on average 1.7 times a day. On average means that there were days with multiple releases and weeks without a single release. Again, we release when we have solved a problem. Some problems are small, and some problems are hard.
Feedback Cycles
Quick and direct feedback is central to the caretaker model. As mentioned before, establishing feedback loops is an important part of the plan to get from the problem to a solution. Depending on the task at hand, the caretaker selects a matching set of feedback cycles. Examples are
- If we are unsure whether the solution is a good match for the domain, we get feedback from people within our company with deeper domain knowledge.
Note that the image says “PO”, but that is outdated. We don’t have a PO anymore. - We have peer challenge sessions to discuss solution approaches and architecture and design ideas.
- We practice Test-Driven Development for quick feedback in code.
- For most code changes, we ask a peer for a code review because only a person not involved in building the solution can give feedback on whether the solution is understandable on its own. I can’t remember what I wrote six months ago, so it is important that the code is understandable without much prior knowledge. Note that our reviews are not about syntax but about understandability. And from time to time, we find a potential defect as well.
- When we have a completely new area of features, we like to get feedback from beta users before we release the features to all our users. We use feature toggles to release a feature or set of features only to a specific target group.
- Finally, we have the feedback from all our users. Our customer supporters regularly ask about how they use our software and gather feedback.
The system itself can also provide plenty of feedback through monitoring and telemetry data:
- How long do the requests take? Do we need to invest in performance?
- What features do our users use? How do they use them?
- Is the system healthy?
- Can we detect issues by misconfiguration or wrong data entered by our users?
The reason we need a faster and more flexible approach than Scrum
The reason we focus so much on quick and direct feedback loops is that, despite being domain experts****, many detailed questions can only be answered by putting working software into the hands of our users and asking them if their needs are met. There are just too many company-specific variations. With a fast feedback cycle, we can solve our users’ problems efficiently and effectively, which results in low development costs. How else could we develop software in a high-price country like Switzerland?
**** We invest in our software developers to become domain experts so that we developers can decide as much as possible without the need to go ask a domain expert.
The focus changes from implementing a bunch of requirements to learning and understanding the specific problems our users have and iterating quickly on a solution.
Achievements
With the caretaker model – which is just a name I invented to talk about how we work – we found a way of working with very little overhead. Never before in my career I had so much time per week to code and work on solutions instead of sittings in meetings or events. We also have no synchronisation points (work waits on somebody or something, like Sprint ending) that would introduce a lot of lag into the process.
Our team members are all highly motivated. I think the reason for this is that everybody can be involved over the whole lifetime of a feature – from idea to operating it in the running system.
By choosing an approach per “problem”, we can reach verification of our hypothesis***** quickly.
***** Every potential solution to a problem is a hypothesis that has to be verified or falsified. The quicker this happens, the better.
Finally, this blog post describes – as best as I can – how we work. It’s not a guide or template for a process. So we wholeheartedly “follow” what is written here.
The caretaker model is where we are at the moment. The purpose of this blog post is not to convince you to adopt the caretaker model. Please take with you that there are indefinite ways of working. There is not just Scrum – although it often feels this way when reading posts in my social media bubble. Don’t let Scrum limit your thinking. Think outside the Scrum box! Find the way of working that matches your team and your context best.
All put together
Above is the picture of the whole caretaker model. I hope you can take some inspiration from our journey.
In the above picture, a couple of things are fixed compared to further up in the post.
Happy coding!
