Return to site

Getting into the FLOW

Co-Creating Process One Day at A Time

· FLOW processes

By FIn Goulding and Haydn Shaughnessy

A number of technologies, or rather techniques, are coming together to make IT vastly more productive and customer-focused than ever before. Perhaps unknown to some people on the business side of the house these techniques also make IT more adaptive than ever. But they require new ways of working.

 

These new ways of working are a combination of adopting the new techniques (never easy), working in new types of teams (which takes careful management), and having better metrics to manage software’s contribution to the value we are all trying to create.

 

Often what gets lost when people talk about the software revolution going on today is another ingredient so mundane sounding that people overlook it - work breakdown. Who can get excited about work breakdown? Well, if you can’t then many of the new techniques will not work for you.

 

So what techniques are we talking about? DevOps, Automated Continuous Integration and Deployment, and Microservices are the ones most often talked about. These are important terms for IT professionals. They signal the ability of IT to continuously deliver new value to the business….at pace.

 

Behind these terms lies that new philosophy of work. We have called Flow in the book of the same name.

 

The critical advance of Flow lies in the breakdown of work into very small, discrete, adaptive tasks and the visualisation of the whole work process (including everything down to thanking people for good code!).

 

We will touch on visualisation elsewhere. Here we are talking work breakdown and it requires ‘real’, highly skilled Business Analysts. In order to understand the contribution of work breakdown we need to introduce another term that will be new to the non-IT professional: Cycle time.

 

Cycle time refers to the length of time it takes to complete a typical software task, or indeed any there task. In Flow we are trying to get our cycle time down to one or two days – or even quicker!

 

What is so important about this very short cycle time? In Agile environments cycle time can be as short as 20 days but as long as 80 to 100 days, mostly due to humongous story writing by Business Analysts looking for a Pulitzer prize.

 

Of course, in Agile, teams will have regular sprints in order to reach project milestones but very often the objective of sprints is to accelerate towards a goal that in Flow terms is just too large to be managed properly.

 

That’s an important point that is almost always overlooked. We tend to want to see the whole project planned out or at least scoped. If you do that, the chances are your teams will not function. They will always be trying to eat the elephant and you, the manager, will struggle to keep them from feeling overwhelmed or overambitious. Almost certainly you w8ll struggle to integrate their work at the end of each sprint. That’s why in FLOW we do away with sprints and scrums.

 

In order for software teams to be organised across a time span of anything from 20 - 100 days, teams will be working on branches of code that might take slightly different directions and hence need merging & integrating before being handed over to the operations team. Because of the size of a project, developers will have problems in understanding the role of their code in the overall plan. The pressure will be on to deliver on time, which invariably means that important elements of testing will be overlooked. Integrating the work of different teams can be a struggle in itself, requiring a lot of rework or churn, particularly if one team is late. Then all hell breaks loose.

 

The result is often that the code which is handed over by the development team is in a state that often causes operational problems. In all of this IT wraps itself in its own concerns and procedures and loses sight of the key goal - creating value for customers.

In most IT organisations, integration and handover are highly problematic at least some of the time. That has led to developer teams and operational teams having a fractious relationship. Dev wants to do new things; Ops needs stability and yet has to live with changes that may have been poorly delivered.

 

With Flow, it would appear that there is no branching. However, the integrations happen so quickly that in fact the branching is irrelevant and the team experiences no code collisions. If an issue appears, it’s much easier to back out the work of a few hours rather than a few weeks or even months.

Also, Businesses are now beginning to understand the benefits of close collaboration and

 

are trying to marry development and operations into DevOps teams, multidisciplinary experts that eliminate handover risk. While this is essential in its own right, there are other techniques (such as microservices and continuous deployment) which are making it much more likely to succeed. But we still contend that you need Flow with DevOps but not traditional Agile.

 

The analogy we make in the book Flow is with the movie industry. Before Woody Allen sets out to make a film, he envisages every single scene and camera angle first. This great creative act of filmmaking is in fact broken down into its smallest components before shooting begins. Why? Because every single professional on a movie set then understands what she has to do in relation to every other professional - makeup, photography, continuity, sound, lighting etc. That makes it far more likely than an editor will be piecing together scenes that are coherent from every single aspect. It makes post-production quicker and the finished product more watchable.

 

What we now have in business is a similar creative opportunity to work better together and produce great results, day after day. But we need to take this final step of imagining all the ways we can create value before work begins. That means:

  • More imagination applied to work breakdown

  • Identifying tasks that create value quickly

  • Cycle time of a day or two at most,

It is planning but not like we have known it. In place of the plan we have a process that is adaptive and quick to value. Every company needs it.

These new ways of working are a combination of adopting the new techniques (never easy), working in new types of teams (which takes careful management), and having better metrics to manage software’s contribution to the value we are all trying to create.

Often what gets lost when people talk about the software revolution going on today is another ingredient so mundane sounding that people overlook it - work breakdown. Who can get excited about work breakdown? Well, if you can’t then many of the new techniques will not work for you.

So what techniques are we talking about? DevOps, Automated Continuous Integration and Deployment, and Microservices are the ones most often talked about. These are important terms for IT professionals. They signal the ability of IT to continuously deliver new value to the business….at pace.

Behind these terms lies that new philosophy of work. We have called Flow in the book of the same name.

The critical advance of Flow lies in the breakdown of work into very small, discrete, adaptive tasks and the visualisation of the whole work process (including everything down to thanking people for good code!).

We will touch on visualisation elsewhere. Here we are talking work breakdown and it requires ‘real’, highly skilled Business Analysts. In order to understand the contribution of work breakdown we need to introduce another term that will be new to the non-IT professional: Cycle time.

Cycle time refers to the length of time it takes to complete a typical software task. In Flow we are trying to get our cycle time down to one or two days – or even quicker!

What is so important about this very short cycle time? In Agile environments cycle time can be as short as 20 days but as long as 80 to 100 days, mostly due to humongous story writing by Business Analysts looking for a Pulitzer prize.

Of course, in Agile, teams will have regular sprints in order to reach project milestones but very often the objective of sprints is to accelerate towards a goal that in Flow terms is just too large to be managed properly.

That’s an important point that is almost always overlooked. We tend to want to see the whole project planned out or at least scoped. If you do that, the chances are your teams will not function. They will always be trying to eat the elephant and you, the manager, will struggle to keep them from feeling overwhelmed or overambitious. Almost certainly you w8ll struggle to integrate their work at the end of each sprint. That’s why in FLOW we do away with sprints and scrums.

In order for software teams to be organised across a time span of anything from 20 - 100 days, teams will be working on branches of code that might take slightly different directions and hence need merging & integrating before being handed over to the operations team. Because of the size of a project, developers will have problems in understanding the role of their code in the overall plan. The pressure will be on to deliver on time, which invariably means that important elements of testing will be overlooked. Integrating the work of different teams can be a struggle in itself, requiring a lot of rework or churn, particularly if one team is late. Then all hell breaks loose.

The result is often that the code which is handed over by the development team is in a state that often causes operational problems. In all of this IT wraps itself in its own concerns and procedures and loses sight of the key goal - creating value for customers.

In most IT organisations, integration and handover are highly problematic at least some of the time. That has led to developer teams and operational teams having a fractious relationship. Dev wants to do new things; Ops needs stability and yet has to live with changes that may have been poorly delivered.

With Flow, it would appear that there is no branching. However, the integrations happen so quickly that in fact the branching is irrelevant and the team experiences no code collisions. If an issue appears, it’s much easier to back out the work of a few hours rather than a few weeks or even months.

Also, Businesses are now beginning to understand the benefits of close collaboration and

are trying to marry development and operations into DevOps teams, multidisciplinary experts that eliminate handover risk. While this is essential in its own right, there are other techniques (such as microservices and continuous deployment) which are making it much more likely to succeed. But we still contend that you need Flow with DevOps but not traditional Agile.

The analogy we make in the book Flow is with the movie industry. Before Woody Allen sets out to make a film, he envisages every single scene and camera angle first. This great creative act of filmmaking is in fact broken down into its smallest components before shooting begins. Why? Because every single professional on a movie set then understands what she has to do in relation to every other professional - makeup, photography, continuity, sound, lighting etc. That makes it far more likely than an editor will be piecing together scenes that are coherent from every single aspect. It makes post-production quicker and the finished product more watchable.

What we now have in business is a similar creative opportunity to work better together and produce great results, day after day. But we need to take this final step of imagining all the ways we can create value before work begins. That means:

  • More imagination applied to work breakdown

  • Identifying tasks that create value quickly

  • Cycle time of a day or two at most,

It is planning but not like we have known it. In place of the plan we have a process that is adaptive and quick to value. Every company needs it.

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly