Why We Don’t Do Scrum for Time Cockpit

Image source: https://flic.kr/p/8QjDJy, under Creative Commons License

We did Scrum years ago for the initial development of time cockpit. Granted, there were times where we managed to do Scrum nearly by the book but sometimes we got a bit lazy. Nevertheless, it worked perfectly fine for us. Now we don’t do Scrum anymore. In this blog article I want to describe why we turned away from it and how we manage our development process today.

If Scrum is new for you, I recommend reading the Scrum Guide which is available for free.

What Scrum is Good For

Regularly, customers in the software development industry ask us to do consulting work independent of time cockpit. Sometimes they need technical advice and sometimes they have just problems with their business processes. Over the years I have recommended Scrum to many development teams during that consulting workshops.

The reason is that in my opinion Scrum is a great solution for teams with all or some of the following problems:

• The team builds infrequent, big releases. Rolling them out is a pain.
• Developers tend to start working on many different topics but struggle to complete them (and I really mean complete including documentation, tests, etc.).
• Developers spend more time filling gaps in specifications – if specs exist at all – than programming.
• Prioritization of work happens by accident or based on the HiPPO principle (Highest Paid Person’s Opinion).
• The resulting software has stability problems as quality assurance loses in favor of new features.
• Team members are latent unhappy because of hurdles like inappropriate development tools, organizational chaos, missing sense of achievement, etc.

Scrum Isn’t Chaos, It’s A Strictly Defined Process

Although Scrum is an agile development method, it clearly defines process rules and responsibilities that can potentially solve problems like the ones mentioned above. Many teams that come from a seemingly waterfall-like process think that with Scrum they have to drop all process guidelines.

The contrary is the case. In my experience, teams are typically surprised by the strict process that Scrum imposes on them.

So What’s the Problem with Scrum?

Necessity for Shared Responsibility

At software architects, we are a small team of currently seven people. Being small gives us the possibility to be more flexible than our large competitors. Otherwise we would not have a chance to succeed. One of our most important principles in that regard is shared responsibility not only for code (as in XP’s Collective Code Ownership) but also for processes, support, customer projects, etc. Sentences like “I don’t care for support tickets because I am a developer” or “my colleagues are drowning in time cockpit implementation projects but as a developer that’s not my problem” would be a no-go in our team.

Development Time is Hard to Predict

A side effect of that shared responsibility approach is that planning available development time is pretty hard. One week, an urgent support case or the need for assistance in an urgent and critical customer project might rob us many days. Another week we might be surprised that we could focus much more on development than we thought we could. Of course we know that this kind of multi-tasking is not the most efficient way of working.

However, you have to embrace versatility and flexibility as this is how life goes in small companies in practice.

Unstable Velocity Leads to Problems

The lack of predictable development time leads to problems with Scrum. How should the team plan the sprint backlog for e.g. a one-month horizon given the unstable velocity?

• Should it be rather conservative to have a chance to often reach the sprint goal? In my experience this approach frequently leads to over-engineering in sprints with spare time.
• Or should the team members set bold goals to make sure that they don’t run out of work in the middle of the sprint? I have seen teams being constantly frustrated as they regularly miss sprint targets.

We have been in this situation once we got more and more time cockpit customers. So we had to find a different approach.

Enter: Kanban

We decided to free ourselves from the corset of sprints as defined by Scrum. Instead, we decided to follow the Kanban method.

If Kanban is new for you and you want to learn more, we recommend reading the book Kanban by David J. Anderson.

Making Kanban Work for Us

In order to make Kanban work for us, we defined the following basic principles:

1. Following the Kaizen principle, we welcome change and want to continuously improve our product as well as our processes.
2. We limit our work in progress. Once we start a task, we complete and ship it as soon as possible so that our customers can benefit from it.
3. We value what we have built in the past (software, processes) and aim for bold goals by taking a stepwise approach.
4. As company owners, we follow the servant leadership practices. We only specify the overall strategy and high-level goals. Defining and implementing all the small improvements necessary to reach our long-term goals is a team effort.
5. We invite people inside and outside (e.g. partners, suppliers, customers, etc.) our organization to participate in our improvement process.

No Sprints but Still a Predictable Release Cadence

For time cockpit development, we have been working without sprints of predefined length and structure for quite a while now. However, for customers and partners we need some predictability. Therefore, we have established a constant rhythm of one production release per month. We only deliver out-of-band releases for hotfixes and preview versions.

We cannot exactly predict the features that will make it into the next release. By setting priorities right, we make sure that the things that customers and we care most will probably be in. However, there is no guarantee.

What’s in is in, what not, not. There will always be a next month with another release in which we can continue to improve.

Kanban Software

For everyday work, we manage our workflow using JIRA Agile’s Kanban board. Of course we integrated JIRA with time cockpit so that we can track our working time per work item. Additionally, we integrated JIRA with Zendesk, the software we use for customer service.

When Scrum? When Kanban?

In my experience, Scrum is great if agile development is new for your team. Scrum provides clear guidance for the process and responsibilities. This helps a lot when switching from waterfall to agile. Scum also is great if you are working in a larger organization and your team can concentrate on development. Other teams might be responsible for tasks like support, customer projects, etc.

For us, the Kanban approach fits much better to our way of working. It enables us to deliver constant innovation to our customers while giving us the necessary flexibility that a small team like ours needs.