Dear System Developer. I have seen the agony and frustration in your face. The every day context switching and inability to concentrate on one task at the time. Many years ago I felt it myself, back when I also did programming. As project manager I want to help you. But, in order to achieve our common goal, you need to help me back. I need you to help the tester and myself create specifications that make tasks small and independent. Only then we can achieve our common goal of a continuous single flow of valuable features delivered to the customer. No more headaches.
In this blog article I would like to discuss the concept of flow in software development by sharing my experiences from a current assignment. I want to show you how our inability to define small, independent, functional requirements ends up with headaches and stress. Even though the concept of feedback loops is a central part of this, I will hand it to my good friend and colleague Rune Larsen to explain more about Knowing your feedback loop.
When you finish reading this article I want you to ask yourself this question: Can we deliver more and better if we slow down and do one thing at a time (per developer)?
Driving along the highway we often come over situations where we have to hit the breaks. It could be road maintainance. It could be an accident. What happens if this occurs during rush hour? If you´re not sure, you can google “Queueing theory”. We can relate the traffic situation to our project environment where a development team will only be able to handle so many features at a time, before they start queueing up on the board. The number of incoming and ongoing tasks are exceeding the capacity of the team (too many cars, too little road capacity). Suddenly you´re invited to two or three meetings – every day – because you need to clarify these issues. Everything is depending on everything… #contextswitching #fail #headaches
The reason we often end up with multiple tasks is because we in our society can´t stand the thought of not being productive. There is an established truth that productivity can be measured by the amount of time put into one task (even today I hear of stories about project managers reporting progress by documenting how many hours have been consumed according to plan. wtf?). People idling, doing nothing, is considered wasting time.
I have the power to hold new tasks at a distance, but only if we find a way to finish our previous feature and delivering them as a whole, Tom J. Bang.
Functional specifications – only valuable from the users point of view
First of all we need to specify our requirements from an end users point of view. For two reasons; a) business value can only be measured through experienced customer value and b) it´s the best way we to make sure we actually build what we specified (and nothing more).
In my current project we are building IT-support for selling and operating long haul flights from Oslo to New York and Bangkok. Let´s say we want to offer our customers the opportunity to buy a premium seat (being more comfortable than the standard seat):
As a customer
I want to book a better seat
So I get a more comfortable journey
When we break it down to what we want to implement, we describe acceptance criteria as more detailed specifications. This is done by tester and developer in co-operation (read: this is our goal, but not everyone is comfortable with this way of working)
Multi-tier systems full of dependencies
Our technical environment consists of many separate systems with a specific responsibility (pricing, booking process, back office, shipping data between systems etc). So when we break a functional requirement down to smaller acceptance criterias we still need to make changes to a minimum of three systems.
I present this functional requirement to my team and ask: – How can we implement this in independent and small steps – acceptance criteria by acceptance criteria? The response is often: – (Enterprise bus:) We are waiting for interface changes from back office. (portal:) We have to wait for interface changes from the enterprise data bus.
This is how we would specify one acceptance criteria for user story described above:
Given end user has chosen a long haul flight <origin> to <destination> with a 787 plane
When end user books a <ticket type> with <seat type>
Then the flight should cost <expected price> and seat should be placed in cabin <expected cabin>
My question is: Why can´t we sit down together, figure out the interface together and then implement it together? That way we can avoid the context switching and rework because some one assumed that it was OK for the other system to receive such a parameter in such a way.
I think the main problem here is that we fear sitting together with the other teams, because they might see weaknesses on our side of the system, System Developer.
The fear of missing something on the way
In order to reduce lead time we need to make the task or deliverable smaller so we can present it to the user or decision maker faster, and then again get quicker feedback so we can make adjustments and move on. This is hard to do if we can´t accept an approach where we deliver thin vertical slices of functionality, and use the feedback to learn and improve when we continue implementing new slices.
Even though it seems reasonable to build each software layer (UI, services, data, …) independently when we want to build common services, we end up trying to solve several problems at once.
In our next release we will reverse our specification process, and start by having developer and tester together define some test cases:
|| origin || destination || seat type || ticket type || expected price || expected cabin ||
| OSL | JFK | Premium | Restricted | 1000NOK | C cabin |
The best way to miss out on something is actually to avoid real feedback. Real feedback meaning putting your code or features to the test, by observing how the system or end user reacts to it. As they say: “The devil is in the detail” and “Assumption is the mother of all f… ups”
It is very clear to me that once we start of by sitting together and creating the first test cases and examples – that runs from the user interface, down through system interfaces and back up to the user again – we will be able to find ways of implementing independent slices of functionality. That will enable us to get real feedback earlier, learn faster and design the system as we work our way through the requirements. But when we stumble into an obstacle on our way, we must not be tempted to put aside the task and start a new while waiting. Then it´s better to simplify the acceptance criteria in order to deliver something valuable, before starting a new task.
When traffic increases, slow down in order to hold a sustainable pace in a single piece flow. No more unnecessary contexts witching, multiple meetings per day or headaches caused by stress.
Dear System Developer and tester; Can we work together to make this work?