I get a chance to meet lots of people who have a good exposure to the manufacturing industry either by work or education. If we take a look at the Cynefin framework, manufacturing industry fits in the ‘complicated’ quadrant. In this context if we are to create a wrist watch then there will be a clear design on how to create the parts and standard instructions on how to safely assemble the watch. This works in most of the cases and people will gain dexterity over time and will be able to assemble watches at a much faster pace. What is necessary here are the design and the standard instructions to assemble; incase someone else finds a better way then the standard instruction is updated with the new method.

Software work on the other hand is knowledge based and fits in the ‘Complex’ quadrant. There are some good practices for basic things like clean code, continuous integration etc but there is no defined way to approach it using the methods which apply to tasks in the ‘Complicated’  quadrant. If I am assembling a watch or a similar task, it is possible for me to split my work into 1 hour increments and produce output at a predictable pace. I can also stop doing the work in between, attend a meeting and resume work later on without much impact to productivity after resuming work.

Knowledge workers such as software developers cannot do this, their time increments are more like 3~4 hours. A break in the flow of work is bound to cause rework from scratch. Concentration of task at hand is of prime importance and if plans are made such a way that there is a meeting scheduled in between the 3~4 hour stretch of window, it will impact the productivity for sure. Also the power of context is too pronounced, the productivity will be much lower earlier in the development cycle and will progress much faster as common understanding of the system emerges. Plans usually consider only linear throughput and that adds pressure on the team to be at peak from the initial phases of the project.

What should we consider if we are dealing with knowledge work especially if we have been exposed to manufacturing or similar sector which fits the ‘Complicated’ quadrant in Cynefin framework?

Reflection

  • Plan for a progressive increase in throughput
  • Standard instructions and processes will not fit and may prove to be counter productive
  • Work requires thinking time, concentration at task comes with unbroken attention, plan for developer time in chunks of 4 hours
  • Reflection is as necessary hands on coding. Tasks like staring outside of the window, enjoying the coffee or doing nothing with eyes closed are not unproductive, it helps reflections which helps innvoation
  • A degree of autonomy is required, it is better to let the team evolve the design based on their experience than forcing an expert’s opinion on the team
  • There has to be avenues for continuous learning and sharing the learnings

Image courtesy of stock images / FreeDigitalPhotos.net

“The easy way out usually leads back in” – This is one of the eleven laws mentioned in the book ‘The Fifth Discpline’ by Peter Senge. I have observed this too many times at my work place where a solution was more of an evasive move, trying to avoid the problem or use a clever alternative which hits back at us when we least expect. Last weekend I was reading the newspaper about how cane toads where introduced in Australia to control the beetle population and the result of that after some decades. The people who were interested in controlling the beetle population had a narrow view of the Australian biodiversity and did not know the long term effects of introducing the cane toads. They introduced these toads from South America to Australia.

Stuck inside

What were the results? The cane toads were not able to control the beetle population as the beetles lived at the top of the sugarcanes in the fields. The toads were not able to climb the cane to feed on them, instead the native reptile population went down drastically as they fed on these toads which had a poison sac in them killing the predators. Without the intended effects this move has resulted in altering the biodiversity of Australia at a noticeable scale. Our workplace is no different, simple tactical moves which seemed to be clever choices will result in a bigger problem often for people who succeed in the roles. The only way to not get into these types of traps is ‘Systems thinking’ and to remember that if there is an easy way out then we will usually end up back in.

Image courtesy of [Master Isolated Images] / FreeDigitalPhotos.net

Last few years I observed that the biggest of all debates that occur during the course of a project is during the sizing of the stories. Most of the times in the teams I have worked we had fibonacci or t-shirt sizing and sometimes 1,2,4,8. We humans are not so good when we deal with numbers which are closely spaced. T-shirt sizes are also closely spaced S,M,L loosely translates to 38, 40, 42. This leads to people arguing whether some stories is of 2 or 3 points or Small or medium size and gets into tasking and implementation details to get the right size.

sizes

When I was thinking about a better method for sizing, I read in some feed that a person tried to use reptile sizes like gecko, iguana, alligator and komodo. Each different in size and class from the other. I thought, let me also give a try and then came up with Scooter, Car and Bus for the sizes with Bicycle and Trailer as outliers (similar to XS or XL in t-shirt sizes). To my surprise it was too easy for people to slot the stories into one of these sizes and there were very few arguments and a simple task break down of a story gave a picture of the size/complexity.  This worked much better than S,M,L or 1,2,3,5,8.