Two weeks ago we started an experiment to test out how we can improve lead times of new features for one of our customer facing teams.
The team is responsible for three customer facing channels and publish new content on a regular basis to the different channels. There are no developers on the team, so for more complex changes they are dependant on developers working off-site. The process for developing new features have many hand-overs. As a consequence, the following problems occur:
- Long lead times
- Poor quality
In 2015 this represents a problem when you need to react to changing customer needs. Currently, there is a thick wall between the business side and the IT-department, which I believe is the root cause of the many handovers.
Our hypothesis is that if we get web developers in the team, co-located with the rest of the team and working closely together with them on a daily basis, then we will:
- Produce software with better quality
- Improve lead times for new features from 2 months to 1 week
Which will help increase customer satisfaction and better profitability (details needs to be left out).
Thus, we want to move from a project focus to a product focus. The team lives with the product from its inception to its end of life. We want to create a culture where people are truly responsible for the software they deliver:
So to test out this hypothesis we will run the team with three developers working together with the rest of the team. Two front end developers and one API developer (with expertise on continuous delivery).
Alignment and autonomy
Inspired by the work of Stephen Bungay and his Art of Action (recommended read) leaders have defined what we want to achieve and why we want to do so (creates alignment). The team is then responsible for how to meet the intent (autonomy). The things the team do should match the intent. More on this in a later blog post.
Story thus far
We started up two weeks ago, this is what we’ve done so far:
Week 1 – Understand the current condition
We started day 1 with some workshops about the experiment. What we want to achieve and why. At the end of day 1 we ran a Pre-Mortem workshop, which was a really intersting experiment. Blog post on that later.
On day 2 the team decided that the goal for the first week should be to try to understand as much as possible about the current situation and the current way of working. Understanding the current condition is critical if you want ro improve.
Week 2 – Stretching the system
For the second week, the team decided on a really ambitious goal:
“Deliver working software in a “production-like” environment with communication towards legacy systems we must integrate with”
An ambitious goal, and we knew it was a stretch. The thinking behind it was that while trying to achieve this, we would probably learn quite a few things about how the system currently works. So, we basically had three stories in progress:
- One new web page on new front end framework (ReactJS ++)
- An API server component serving mocked data (REST + Json)
- Provisioning test and production environment for deployment pipeline
Results first two weeks
We try to look at all the work we do as short experiments. This keeps us focus, moving in small steps towards our target condition. We managed to deliver a minimal version of 1) and 2) in list above. But due to slowness in setting up new environments (not totally unexpected), we were only able to deliver this in a test environment and not in a production environment. But we learned a few things in the process and hopefully we will be able to help improve the system.
After the second week we have a very simple working process in place. We have managed to avoid the temptation of trying to design a work process. Instead we want to evolve it gradually, so that it fits the way the work actually works. As we are still setting up our technical environment we have a lot of different types of tasks at our hand. At the moment we therefore have a very simple process, that will definitely evolve. Next week we will hopefully have our physical Kanban board in place, so that we can work with our visual management.