The french parade - a highway road work flow system

I was impressed. Driving home from our vacation in beautiful France back to Germany I've seen something totally new to me: I saw the french highway flow system, a fast moving end-to-end road work, rebuilding one driving lane from start to end in under 8 km. Incredible, awesome and totally efficient. 

A parade in denmark. Photographed in © 2004 by Tomasz Sienicki CC-BY-2.5, via Wikimedia Commons

In Germany I am accustomed to long lasting road work. Germans process road work in large batches, process the big batches layer for layer - a big waste of time and we as a users we wait extra long unit the blockade is gone. Terrible annoying.

The french road work system I've seen was so different! They did not produce much waste. They rushed through the driving lane like a parade in full motion. In front there were the guys who secured the road - to me they looked like the jugglers in front of the parade, shouting loudly: "Here we come!". Right behind them followed a small group of artists, preparing the road for the big orchestra. The big orchestra made an ground-breaking sound, so guttural that the highway next to them was shaken and torn in peaces. After the big machines came the first dancers, swinging the dirt away. Right after the dancers followed the local craftsman guild, demonstrating how easily a new road surface is created. Within the last few kilometres one group marked the new lane markers and painted them. Then the jugglers again singing: "Bye bye" and the road work was over... sitting in the car and thinking about the economic impact of using a workflow system on a highway instead of wasting time, money and good feeling with big batches.


How to scale definition of done - When to do what?

A common question about definition of done is - "When should we do which activity?" A definition of done is usually about:

  • Done when the story is done
  • Done when the sprint is done
  • Done when the release is done

Usually you should strive to be done as soon as possible with the most activities, so do the most stuff at story level except there is a reason not do.  Here are several why you might scale your activity from story level to sprint or even release level.

Transaction costs, synergy or no demand

The result of adjusting focal distance while taking the picture. By  B166ER at the German language Wikipedia GFDL or CC-BY-SA-3.0, via Wikimedia Commons

Some activities should be done for all stories and it is cheaper to execute them together, usually activities for non functional requirements fit here. Take for example performance testing or testing with data from live systems. If you do it once a sprint it might be enough. Moreover, there are different opinions about how much e. g. security is required per story, this happens per stakeholder. Sometimes there might be no demand to do the activity per story.

Minimum viable product and experiment

Sometimes you want to experiment functionality. You develop it without making things nice and layout it the way it fits into the GUI design. This approach is fairly okay, because you want feedback, you wanted to test your idea. This is often when you go for a minimum valuable product. You might run a few sprints with making it run and before the release, after you said - "this is it" - you make it nice and fast. 

Low performance, too many restrictions or impatient stakeholders or customers

If you spent too much time with developing one story and you cannot get enough features done. Then you might suspend some activities for later. This is also recommendable if you've got impatient stakeholders or customers. Show that it works and then make it nice and fast.



Transparency - Sure you can deal with it?

Enterprise, you want to go agile - sure you want?

If you honestly do so, ask yourself, as somebody in charge, the question: "Can we handle the effects of transparency?"

Then split the we and insert instead:

Management, people and culture

The effects of transparency spread wide but are deeply routed in your corporate culture. It is about how you deal with problems: Will you welcome them, will you deny them or even worse will you surrender saying: "That is like the way it works - accept it." 

Furthermore it is about how long will it take to solve problems and when does frustration start how will your people deal with it? Key question still is: will you be able to learn how to improve fast enough, before your system gets to annoyed of transparency?

Some questions to sting yourself

By ZooFari (Own work) CC-BY-SA-3.0, via Wikimedia Commons

  • The unsolvable problems will be addressed - will you spend the time and effort in making the impossible possible?
  • Will you take every problem serious that will be addressed?
  • How patient is the culture of your organisation?
  • How long will people wait before they get annoyed by all the problems perceivable?
  • What if your people are stuck, will they solve problems on their own? 
  • What if people are stuck and get frustrated about the amount of problems every day? 
  • What if your people fear or realize that they archive too little?
  • How will your culture handle and react when problems are addressed?
  • How will you react if people are part of the problem? 
  • What if you as a manager are part of the problem? 
  • Are your people comfortable being naked in business? 

There is a lot more to ask, but if you do feel uncomfortable with this rethink your intend about an agile transition. If you do say, transparency is no problem at all, then you might have a great organisation or you've lost touch with the culture of your organisation. 

The only thing I can highly recommend is: Go to the people who work, get firsthand awareness about how work is really done, ask for the problems and get a keen appreciation about improvements. Be humble and help them!


read it in German: click

Definition of ready - Your sword in the shield wall

The definition

A definition of ready is used to produce story readiness. A story which is ready for development needs to meet criteria. Thus criteria defined is required to accomplish a story. The definition of ready is an activity of the development team to state everything what's required before development begins. It is also a contract between development team, product owner and stakeholders. A development team has to contribute that the criteria is meet as far as possible. If criteria is missing from stakeholders or product owner the team should deny to start the work or close the gaps with own decisions and suggestions. The definition of ready is a tool to make explicit and transparent what is needed to start a story and can be used for developers as last line of defence.

The sprint

The goal of a sprint is to deliver working software in the state of done. The delivery is called potential shippable product increment also known as usable software ready for installation.

The battleground

To deliver a full working software due to your definition of done there are preconditions to be met before you can start your work. E. g. you might need several documents in advance like text, math and formulas, design and so on. On the other hand you as a development team need to specify which criteria has to be met to validate that you build the right software.

The battle and the sword

A Seax photographed by Bullenwächter, GFDL or CC-BY-SA-3.0, via Wikimedia Commons

In order to complete a story within a sprint every part of the story must be delivered in time, otherwise the team might be wasting time with waiting during a sprint, will not deliver or will have to adjust the delivery later on. Furthermore, to avoid waste of specifying stories too early the timeframe of making work ready is set very close to development. To dissolve those contrary interests - that is the battle. Like in a shield wall you have to push forward and should not loose ground.

Cutting through dependencies in a tight schedule between preparing the work and implementing it is tough. On the one side you shield yourself against getting blocked and deny work which is not ready for action, on the other side you have to contribute to get the work ready and must be aware what is required to start. Both sides are the cutting edges of your sword. 



Different projects in a sprint - Juggling with knives

There is often the question: Different projects in a sprint - does it work? The answer is either yes or no! 

Yes, it works

When you use sprints, you might use Scrum. Scrum is a framework. You take it and put the work in that frame a sprint is offering you. Once your work is in that frame, you can work on it, no matter if it you are delivering for one project or serveral. You might loose focus because the projects are tearing you apart, but as long as you are able to stabilise the priority of you work during your iteration there is chance to succeed. And you still got a ScrumMaster to support you.

No, it does not work

By David Shankbone (David Shankbone (own work)) CC-BY-2.5, via Wikimedia Commons

It will not work, if you do not put all of your work into that frame. Leaving work out of your sprint will lead to distraction and waste. Usually while there is work happening outside that is pulling your attention, this work is not weighted against the work in your sprint. There will be waste through discussions about priority and unfinished work to resume. On the other hand when there is to much ad-hoc work you will run into trouble too. Ad-hoc work is similar to work which is not framed - and yet a little bit different. A sprint is also under policy: do not disturb the people working. If your workplace produces too much ad-hoc work the process you've selected will be under constant need of maintainance, so the system will need other desire paths than your process might provide, unable to heal itself.

There is still hope

You can learn about your environment and work situation. Just make your work visible, put your work on a taskboard and follow its flow from introduction to done. Visualize the problems and impediments you encounter and improve around all mistakes that happen. It might be a hard road and it is worth it. Usually this is true: "Only what is visible can be improved."

Different projects in a sprint - it's like juggling with knives, it might work or it might hurt... 


A self healing system - Desire paths

A self healing system

We are good at setting standards, but do we take them as a baseline for improvement or do we end up in bureaucracy? Standardization means automation. We take our insights and wire them to procedures. Step 1 followed by step 2 in exactly the order we prescribed: entirely deterministic, but perfect?

What about when we are all wrong? What about if we build up a wrong standard? Good for us, but useless for our customers? What if they desire another path, perfectly sane, but our system does not provide it? Should we keep it with: "We are sorry, this action is not provided"?

Parks in Finland

In Finland, planners are known to visit their parks immediately after the first snowfall, when the existing paths are not visible. People naturally choose desire lines, which are then clearly indicated by their footprints and can be used to guide the routing of new purpose built paths.  (Desire path, Wikipedia, 19th of June 2013)

A desire path (right) merges with a footpath (center) in Helsinki, Finland (Wikipedia)

Wrong standards are business bugs. Get over it! They do not meet customer needs, instead they show an opportunity to learn or worse - your ignorance.

So what to do now?

Automate less complex, learn from existing data, ask your frontline staff.

Automate less complex

Da Vinci said: "Simplicity is the ultimate form of sophistication." So if you automate a process, simplify it first. Do not blindly automate everything, question it. Prefer an simple implementation over one with lots of different scenarios. A simple scenario can go for itself - they can be healed, complex scenarios tend to be waste and difficult to use and exclude everything which was not considered by its builders.

Reconsider automation of systems with a lot of ad-hoc-racy. Determinism might lead to a lot of maintainance of the automation you want to provide. 

Learn from existing data

You always got data - learn from it. Have a look at which way data is used, what behaviour is associated to it? What does surprise you while looking at it? What is fascinating? What interesting? Learn from the real world. Iterate, prototype, gather feedback from customers. You got no contact to them - step out of the door, insights are waiting:

"You step onto the road, and if you don't keep your feet, there's no knowing where you might be swept off to." (Lord of the rings, Tolkien) 

Ask your frontline staff

Whenever you have touchpoints within your service, you will have frontline staff who is in close contact with customers. These people know the paths who are unable to go and cannot be healed within the system. 


Where to start?

You know what work needs to be done, but don't know where to start?

That state is very common and not per se bad, because you've got a lot of opportunities within your complex system and decision important and by no means easy. 

As said, there are a lot of ways to prioritize your backlog:

  • highest risk first
  • biggest expected value
  • most urgency or deadline
  • feature deprecation
  • market opportunity
  • caustic curve

These ones are rather good, but will they give you the hint were to start? Usually your experience will. 

Personally I trust my gut very well and I am impatient about all the sensitives around biggest value and all discussion about unknown future. I like to gather feedback. 

Space shuttle Columbia launching - By NASA [Public domain], via Wikimedia Commons

People who are shifting from classic to agile still got huge problems with starting, so I recommend: start with the work which is ready for development. Only work in ready state will get done without being blocked and is able to finish within a short period of time. So stick with this: "There is little point in paying attention to prioritization when there is no predictability in delivery. Why waste effort trying to order the input when there is no predictability in delivery?" (David J. Anderson, KANBAN, 2010, p. 31). 

You should focus on improving your ability to deliver and the predictability in delivery - this starts with making work ready for development and not with doing estimates, preinvestigation. This is where you should start.