As already announced in my last blog post, this post will highlight how we shortened our release cycle to two months. I will therefore explain the process we have established and how we live it.
Scaling agile is always a pain!
I won’t talk about all the obvious issues you face when trying to scale agile in a bigger environment. In the last years there have been ongoing discussions within the “agile community” about these problems.
Here are a few links to interesting talks:
- Jez Humble on the GOTO 2015: Why Scaling Agile Doesn’t Work
- Henrik Kniberg – Scaling @ Spotify: Part 1 and Part 2
- Dan North on the GOTO 2013: Why Agile doesn’t Scale & what you can do about it
In those talks you can learn a lot about what has worked and what has not. However, the most interesting message is that all of the processes out there (SAFe, LeSS, etc) are interesting, but you have to adapt them to your organization. In my opinion you can’t just use them in your particular organization, without any adaptations. The biggest mistake would be to take them as they are and apply them.
Our approach was to really look into the various processes out there, choose one that fits both our company and organizational culture the most and adapt it to our needs. We went on to pick SAFe and aligned it with existing processes. As you can see in the picture above, the process model we came up with is definitely comparable with SAFe, although there are still slight differences. One of the important aspects is, that we stick to our vocabulary. Confronting your team members with a new process is distracting either way, so you want to make sure that you don’t add additional complexity by introducing new words, phrases and abbreviations.
Another thought pattern we used was that we don’t take the process for solving all our scaling issues. If you just look at the process aspects, you will fail. You have to consider architectural issues, collaboration issues and many more aspects. For us the process (especially the requirements part to it) was just the starting point (you have to start somewhere, right? :-))
Requirements are the starting point
First issue we wanted to tackle was that the requirements (from customers or internal) where “in bad shape”. Very high-level, not written in user perspective and a big gap between the high and low level. Therefore, we restructured the way of documenting it – resulting in three different levels (Functionality Requests, Features and User Stories). Functionality Requests primarily focus on describing the business need of an idea on a quite high level whereas Features, which are already written in User Story format, are far more detailed and already contain acceptance criteria. The User Stories (of course with tasks, test cases etc) describe the concrete piece of functionality that needs to be implemented in detail. If you take a close look at the process illustration above, the evolution from idea to detailed User Story is displayed on the right-hand side.
Requirements are flying
Transforming promising ideas into shippable products can be quite a long route within most organizations. When you grow (as an organization) you are faced with a lot of admin tasks, corporate rules, processes etc. At PBS, we don’t want to constrain the creative potential of our development teams by confronting them with unnecessary and limiting barriers. We aim to be as “lean” as possible. Getting rid of all those barriers is of course an illusionary and unrealistic vision; instead we simply try to reduce them to a healthy and constructive amount. And as corny as it sounds, it all starts with transparency. If you start to get transparency into all the processes and procedures, it will help you in two ways:
- It leads to questions from people outside the process (but still being affected by it) and
- It leads to continuous improvements, as the questions are – most of the time – very good ones, which lead to change!
Therefore, we decided to not only show all the requirements on the Kanban Board but make it very transparent in general. Not only by writing it down but also by talking about it. Explaining it to all the development teams, all the stakeholders and also to our customers. They need to understand how the requirements fly, why they are moving from one column to the next one and so on. By the way, creating this dev blog is also a good example for that. This communication instrument is not only for external communication but for internal as well!
So, what’s the answer now?
The title of this post is: Can BIG be beautiful? I wouldn’t consider PBS as a BIG company. There are definitely bigger ones out there. Nevertheless, we are a fast growing one and therefore we are faced with constantly changing environments (which is of course a bit of a hassle as well). Having worked in bigger companies and in smaller ones, I can definitely say that some parts in software development are way easier (or more beautiful) in smaller businesses. Less processes, less bureaucracy, less distraction from the fun stuff. However, if you are transparent, listen to your people (what they say about processes) and try to get rid of the useless stuff …
BIG can be very beautiful!
What is your opinion about the topic?
I’d love getting some feedback from you – please write a comment or send an email!