When SW developers needs to leave the scrum board

Today’s SW developers use a lot of agile methods like scrum and kanban boards.
The reason is simple, it works and it works well!
The SW community creates products that are incredibly complicated, with literally thousands of dependencies in the code.
It does not take long before SW is really complicated to analyze and work with.
SW developers have their coding tools and systems for tracking work and issues. These are great tools and really help the team to focus their work were it matters the most.

There is however not always easy to use the scrum or kanban boards. The boards are designed to visualize and streamline the work process for developing software. And in most cases SW follow a really simple process. (The software developed is however not simple)
The simple process makes it easy to visualize on a board and also easy to understand.
But in order for the simple process to be useful the architecture of the software needs to be in place. Dependencies in the process have to be few, if any.

When we start a new SW project from scratch we need to develop the architecture, we need to design the modules, the information pathways and what logic goes into HW and SW. Are we going to use a RTOS or a standard OS? What IDE are we going to use? What language are we using? On what CPU shall we base the product?… There are a lot of different questions that needs to be solved before we are in a good state, suitable for the kanban board.

What tools do we use if we are trained on scrum boards, but needs to do something that does not really fit the tool? Well some use the scrum board anyway; others turn to other lean tools and agile methods to adapt to the situation. I prefer to analyze the situation to find the hard decisions that we regret if we make wrong first.

Let’s look at the OS selection, say we take a quick decision to go with ”Windows CE” and spend 9 months trying to build our product. If we then would like to change to Linux, we would be likely to have to scrap a lot of work in the process. These kinds of decisions are excellent candidates for a set based design approach. The tool is a method to evaluate a set of possible solutions simultaneously and weed out the weakest solutions from different perspectives. Kind of like the TV show ”Idol”.

Another tool that brings value in this situation is modular design. Try to figure out the building blocks that we will need to build our product. Visualize the building blocks and their relations. Break them down into smaller blocks and try to find synergies. Then build a roadmap to illustrate how a single module needs to be evolved to meet the increasing complexity of the product. The trick is not to try to do everything from start, but still have a structured thinking process about how to build the complex product over time. If you read Eric Rise book ”The lean startup” you understand that experimenting is essential regardless of company size. It is an excellent way to get a product released that customers actually will feel delighted to use.

If you work with SW that has a lot of dependencies to HW, you are likely to find that the kanban board don’t help you as much as it usually does. When the process is complicated due to the fact that you need to coordinate your releases with HW releases and experiments, you are in need of a tool that supports dependencies and complex processes. PLAYBOOK lets you model all the tasks on a very detailed level leading up to a joint delivery of both SW and HW to provide a useful product.

As the program calculates the number of days due for each task before it becomes critical, you have all the visibility you need to take the right decisions. You will see when decisions needs to be closed in order for the product to be delivered in the shortest time possible. If you combine this with the set based design, modular roadmap and Eric R. concept of minimum viable products, the end result is likely to come out with a product a lot faster, and more useful, than if you stick to the kanban/scrum, just because you used to it.

Make complicated things as easy as possible to understand, make everything visible and trust your team to do the right thing!

Want to know more?