In the book FLOW we introduce a number of working methods that have been developed, tried and tested by highly engaged and passionate engineering groups, mostly in Dublin and which we call Flow-Agile as distinct from Scrum-Agile.
That’s not to say FLOW is an All Ireland affair. These techniques are the destination that many people arrive at when they go in search of digital transformation. FLOW is really a global movement but Dublin can take a good share of credit for being at the forefront.
They’re the kind of methods that people arrive at when the BS stops and the real joy of being an engineer begins - when you can say: We are going into work to today invent something new, at the very least a new way to work.
The techniques began in IT but they are transferable to other areas of business. As an example of broader applicability, when social media began around 2007, marketers, inspired by bloggers who were completely immersed in new ways of writing, had to find ways to channel brand messages through the canals and by-ways of very personal forms of communications.
Many companies got the etiquette of digital communications wrong and many still do. They were used to outsourcing all of their branding and communications to agencies.
But those who were prepared to explore new ways of work (what Fin happily calls the WOW effect!!), discovered new processes and, indeed, a new sensibility that allowed them to communicate more authentically and effectively.
To do this they too will have used the work methods we outline below, drawing on the experience of Paddy Power. The fluidity in work processes we will describe is the only way to do recurrent and continuous innovation and Paddy Power remains an innovator in new ways of work.
Paddy Power Betfair is an online betting site that initiated a completely new system of open, visual and collaborative project and process design from 2012 onwards as it prepared to become a mobile-first company. Paddy Power serves more than 3.5 billion application program interface (API) requests every day—a number similar to Netflix, eBay, Facebook, or Twitter, according to infrastructure provider RedHat.
It handles around 130 million transactions daily—more than 10 times the number of daily transactions at the London Stock Exchange. These levels of performance are supported by the Flow-Agile philosophy we are describing here.
To get I'm the flow you need to reject traditional project management techniques. In traditional project management, planners use a work breakdown structure (WBS) to organise project work. Here's how that is defined:
A work-breakdown structure (WBS), also referred to as "Contract Work Breakdown Structure " or "CWBS," in project management and systems engineering, is a deliverable-oriented breakdown of a project into smaller components. A work breakdown structure is a key project deliverable that organizes the team's work into manageable sections. The Project Management Body of Knowledge (PMBOK 5) defines the work breakdown structure as a "A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables."
These ideas stem from the US Department of Defence and US Navy from the 1950s. It consists of the hierarchy, as stated above, which includes various levels of detail on the "deliverables" that ultimately deliver the project.
Don't know about you but I doubt I could enjoy working in that type of environment. For some years I worked with technology projects that followed a similar template. Work packages, divided into activities and tasks, all with a deliverable attached. Nonetheless these ideas and procedures have an enormous influence on how we set projects out and how projects are reported.
These concepts influenced the old way of doing software, the Waterfall method. Waterfall projects were enormous pre-planned schedules of hierarchically designed work. Perhaps the giveaway lies in the idea of software architecture. It was akin to doing construction work.
This is what Agile principles were reasonably successful at undermining. In some critical sense though Agile has changed the language without changing the behaviour. In Agile, projects are broken down into Epics and Stories, which is surely a project hierarchy by another name. And in Scrum these Epics and Stories are delivered in Sprints that come together in periodic Scrums. They are supervised by Scrum Masters (reminiscent to me of gang masters!).
Sprints are shorter cycles of work than would typically be found in a Waterfall project. But sprints cause their own problems, typically because people teams develop their part of a project in the way they see fit, only to find it doesn't actually fit with what other people are doing!
The constant pressure to ensure that teams arrive back more or less on schedule often means that important testing work is overlooked. Integrating different branches of work is more of a collision that elision. It needs rework and causes more delay. People go off and do other tasks while they wait and the chop and change culture this creates leads to more problems.
Epics and Stories present another difficulty. They become over-formalised and overstate the different user perspectives. They rarely integrate customers into the process of work definition and they are limited as a way of defining what work really has value.
The overall Agile system has retrospectives that tend to be a venue for blaming people whereas what is needed is a way for learning to accumulate. And the search for optimisation as a reflective activity is also missing. These are the shortcomings we try to address with Flow but we have to say Flow goes beyond just rectifying weaknesses iN Agile. It has a totally different cultural perspective centred on interaction and collective intelligence.
We are anti-project and to some degree anti-plan because we don't believe these techniques answer today's work needs - though bodies like the Project Management Institute continue to argue that they are valuable.
Formal project management techniques make more sense when they are applied to projects with materials and multiple parties involved.
For example if you have a construction project where deliveries of certain components, like concrete, underfloor plumbing, aggregate, electrical conduits and so on, all have to be delivered, then you have a very tight set of dependencies and a clear critical path.
It would be foolish not to set these out. On the other hand, those dependencies and the critical path don't change much from project to project. Once set out they only need adapting.
In manufacturing projects there is something of the same inherent order and predictability. There are materials, suppliers and a process for bring these together into a product. That process can be complex when components arrive from all over the world but again it is relatively predictable (even acknowledging political and weather related risks).
Formal project management techniques in these environments make sense but even in manufacturing we have seen over the past three decades, particularly in semiconductors, that being able to improve a process, relentlessly, is a key to being competitive. Many of these environments carry a steep learning curve, so Lean or Six Sigma is a valuable way to get ahead of the competition.
Where products are intangible, we have a very different set of problems. In online betting or in insurance or, say, book sales or increasingly in any area of service that may or may not have a tangible product involved the problem or challenge has to be stated differently and dealt with more imaginatively:
In the array of service possibilities that modern technology and service architecture opens up, and taking account of the desire of customers to have services and products tailored precisely to their needs, how can we create a consistent flow of innovations that adds to customers' success and builds their appreciation of us in a sustainable way (economically, environmentally and morally)?
In these situations we are not waiting on materials being supplied to us and nor are any of the dependencies so tight. All units of work have some connection with others but it is rare for one piece of work to absolutely prevent other units taking place. The critical path is not a big bold line.
In place of formal schedules for receipt of goods and work commencement, we have us. We have people that we hope are talented enough to come up with great solutions; we have experience; we have a constant flow of information (customer data, customer feedback, new tools and techniques, case studies, everybody's past projects) and we have team dynamics.
Many formal project management techniques, even those of Agile, can kill our ability or willingness to pitch in with all our talents. So too can poorly applied relationship skills. So on top of having some way to solve problems we also need some way to manage relationships effectively and enjoyably.
Not MVP and Not Lean
Flow functions through texture, feel, gut instinct and peer oversight. It may be anti-project but it is pro-value.
What Flow practitioners do with work processes is to make them much more social. The goal of the system or method is to allow people to organise work in ways that increases good social interaction. That's not to say there is no discipline. We demand that people are identifying and delivering value much more frequently and we aim for a new kind of Pareto Efficiency (the one where any new optimisation to one unit of work, will diminish optimisation elsewhere).
As well as all that we emphasise that it is good to. take some pleasure in swapping out the grand plan for a very detailed understanding of where innovations really matter and what should be delivered to customers.
Over the past few years there has been quite a surge in interest in Lean principles as well as concepts such as minimum viable product (MVP). In the Eric Ries book Lean Startup, and in the writings of Steve Blank, there is a lot of good sense written about how entrepreneurs should function. But there's also a lack of understanding of how some large enterprises function.
There is an assumption that by osmosis large corporations will absorb these ideas and
act in a startup kind of way.
But being realistic for a second, 95% of technology startups fail. And nobody has really managed to nail down what makes the 5% of successes so vastly different. It is something to do with personality and resource management, the quality of an idea or invention, a bit of dog in the founder and so on.
It would be fruitless to transfer a nebulous set of ideas to large enterprises, though the lean startup movement believes it is possible. As Fin pointed out recently, large companies are rarely in the position of seeking brand-new customers for a brand-new product. They have customers, they have a huge amount of work-in- progress, they have to introduce new technologies, and they will probably have some form of transformation
Introducing ideas like MVP to this environment can cause a host of issues:
The key is to keep work fluid - hence FLOW. It means accepting there are few boundaries in work structure. However, the minute you accept that then you have to rely on the talent and commitment of the people who do the work!
As an example of that idea of work having fewer boundaries, in preparing this article I interviewed Sean Twomey of PaddyPower BetFair. Sean is one of the originators of FLOW. In his view you cannot talk about doing “projects”.
Projects have a beginning, middle and end, with budgets, predefined outcomes and workflow. Those process disciplines no longer give you the outcomes you want. Focusing instead on business goals and outcomes and whatever units of work it takes to deliver those is the best boundary you can set.
Work breakdown is your best friend
This boundless form of working requires new techniques. Visualisation puts work in everybody’s visual field and that gives it a different type of malleable structure. More social interaction introduces checks, balances, and ingenuity. We are going to give yo a more formal description of work breakdown in the next Step (Step6) but for now we want to concentrate on how new ways to break work down arose.
A lot of what is good in FLOW rests on how good the work breakdown is, on what goes up on the wall. Sounds kind of daft, doesn’t it? Who cares about work breakdown and wall visualisation?
Well, we make the point in FLOW that most work environments have been built on the assumption that if you do the same task often enough you become really good at it. You might be bored out of your mind but you have a certain kind of expertise. That expertise might even help you think of new ways to perform your tasks. In a way, you would be an innovator.
The problem with that formula today is the sheer volume of new things we have to do. There isn’t the opportunity to set up a sequence of processes where people get to do the same thing repetitively and then hand on to the next person. Nor do we get the chance to iterate in a lean cycle. We need people to invent and we need them to do it dozens of times a week.
Layer on top of all this the thorny question of whether or not you can accomplish continuous innovation by thinking like a startup.
We are going to hear a whole lot more about that startup idea now that Lean Startup author Eric Ries is publishing a book on startup thinking for large enterprises.
The reality is you don’t want to copy much of what startups do and, let’s face it, few people know how to call the successes ahead of time. But one over-riding advantage a startup has is its intense level of social interaction between its members. There are no barriers to talking, showing, justifying and course-correcting.
We argue that an important feature of breaking work down, so that you see value and add it to the process, is the quality of social interaction that goes with a much shorter cycle time. Shorter cycle times force people to interact more. No more hiding in the warren of cubicles!
To get to the bottom of really good work breakdown…. Well that’s why we spoke with Sean Twomey, from technology delivery at Paddy Power Betfair, and an early evangelist of FLOW.
“Flow started for us,” Sean explains, “when we had a requirement for a new platform and a very short deadline. We had about three months over the summer to get something really significant done. But it was clear we weren’t going to meet all of the business objectives set out for us.
That put us in a position where we had to make critical decisions about what actually to do. And we had to act fast.
We drew out on one of the walls everything that we felt had to be built, at a high level, which led to mapping up a series of goals, each of which represented a significant independent deliverable to achieve a business outcome. That meant what we were doing was very visual. Being visual facilitated some decision making, which we needed because we couldn’t achieve everything asked of us. By getting it out there we could socialise it between us.
When we had the goals we began translating those into projects, loosely defined in the sense of being a series of work units rather than anything in a project management plan. We also started to do some work breakdown, specifically what we could achieve within a week so we didn’t go wandering
down blind alleys. We didn’t try to break all the work down, but just enough to get us going and get us to some demos.
What was very powerful was that this visual, the goals and the initial breakdown of work, was something that every business analyst, developer, and tester had to walk past several times every day. It wasn’t about a group of us doing this in isolation. Everybody could see it.
They could also see what was coming at them and they had a chance to contribute to it too. People don’t always take that opportunity but it’s there and it helps, especially if they see work that they have some experience of or know how to shape.
And that’s what some like to do. For us, the wall evolved so that it became like a kind of a progress bar too.
The project nearest the door, where the developers went into the workspace, were the ones with the most detailed breakdowns. That’s where they could note down their next tasks and take it in to get the work done.
Further along, the walls were really more freeform. We had some comments, notes, and diagrams up there, a few ideas but nothing that would bog us down.
What’s interesting about that is we still try to hold off the work breakdown until late in the process. We don’t want to be taking teams away from delivery. What we prefer to do is wait until we need to pitch the work to developers as “this is what’s coming next.” Join us and work it out, sort of
Often that means you have to take decisions about how much to put into a feature. If you can’t demo in a week then you maybe need to break the work down further. That means you have a better chance of seeing where the value lies.
If you are going to demo maybe you demo a minimum viable feature and only develop the enhanced feature the following week or later. Or maybe in building the minimum viable feature you find it has no real value for customers so you can drop it.”
From what Sean is saying you start to get the picture. Work becomes fluid. It is a set of interactions around how to break work down, how to identify value, going back to work breakdown if value is not clear, trying a feature but being able to drop it out if necessary, calling on developer groups to join sessions where the work breakdown affects them.
Constantly aiming for a shorter cycle time so that the interaction of ideas, work and value is out in front of everybody.
The work breakdown process in a nutshell
Here’s a summary of the process Sean is describing and how it relates to conventional work practices, before we move onto how people interact in Flow environments. It’s important to stress that the interaction is all important. What we are giving you here are the practical steps but how people contribute their expertise is just as critical.
On top of this in FLOW we suggest a number of support walls around risks and issues, job sharing, appreciation learning and so on.
An example of high level goals
In the book we describe some of this sequencing by referring to a business
objective like: We want to use drones for inspecting insurance incidents.
This is a very high level objective: Discovering how do we best make use of drones
Assume for the sake of illustration that we can keep this objective relatively
simple and deliver it within five goals.
We have deliberately extended the range of goals well beyond what the IT shop would look after.
In FLOW we say that there needs to be strategy walls that bring IT and the business together, especially with significant new projects. So in this particular case we are looking across the business.
The first is to improve our conceptual grasp of how drones function and their long term value; that might also include sub-projects such as:
Goal 2: Brand Communications
A similar breakdown for brand communications. Brands get good value out of being perceived as innovators. It can raise stock price and create a feel good factor internally and externally. Break that project down.
Goal 3: The base station design. Now we are getting into the technical domain. How will an insurance company manage base stations? Will it use a third party? How will it integrated base station communications into its own systems. This starts to become a quite significant set of projects.
Goal 4: Communications protocols. Very relevant to goal 3, what will be the protocols that allow drones to communicate information that could be decisive in settlements that could run into hundreds of thousands of Euros or pounds? This is partly a technical question - what kinds of image compression, which networks, and partly a legal question: what constitutes proof when it is acquired by a robotics technology?
Goal 5: Security. Finally this whole project will come to nothing if the security and overall integrity of the data is not as close to foolproof as possible. That means compliance with standards and so on.
If you take any one of these goals and projects, they can go onto a wall so that people can socialise around the many technical, communications, legal, supply and process issues that will emerge. They can map those issues out and, over a short span of time, they can bring order to them. In turn, they can be broken down into a smaller units of work that individuals and teams can be tasked with bringing to a demo stage or a set of
minimum sustainable features.
The priority as Sean said, is to see where the value lies. Who gains from a drone video of a crash site and how can we begin to express that value through the work breakdown?
That might lead a team to prioritise understanding work at the site of an accident, how to direct cameras on the drone to capture significant images, what degree of AI image processing would be needed to ensure image standardisation or disambiguation, how to protect the images from interference on site, how the images can best be streamed into the data centre, what types of compression and storage to use and so on, as well as
how to interface with emergency services, which may or may not have arrived, and what degree of anonymity is prudent for people at the site.
These could be projects that would add value, maybe by being an early warning of critical injuries or of visual information prior to rain or other adverse weather conditions that might affect evidence, or to protect the parties to an accident when tempers are running high.
What we say in FLOW is that no single brain can figure this out. And nobody can be sure of how to source all the facets of expertise needed to do good planning.
What we do know is that if everybody is looking at the problem we stand a
higher chance of:
And of course all of this is a work in progress.
Good decisions from good social interaction
Back to Sean and work breakdown. The way that engineers had been used to working was for the business side of the house to push their requirements to the business analysts who would then document requirements for development teams to work on.
Some of that is traditional waterfall project development but even in Agile there is a sense in which the two sides, business and IT, have separate domains and don’t really come together.
“The business was always tempted to stuff a document with everything they could think of because they never knew what the implications were, budget, timescales etc,” says Sean.
“Now the business specifies the goals and participates in defining and reviewing how goals are met. It can mean the business reordering their priorities on the fly as the development process shows us that some features are not going to work or some need prioritising.
We’ve also empowered developers to ask what is the business value of what I am producing whereas they used to be inclined to just get on with the work.
Because we break the work down as late as possible we can also bring the latest context to that.
Typically when we start out on a new project or goal our cycle times are longer, like 2-3 weeks. But as delivery gains momentum we get that down. We’re learning. That learning provides context for the next breakdown and it improves our dependencies’ identification.
We also make sure we do at least one breakdown or review session a week where all the domain specific skills are in the room or at the wall.
We’ve learned not to do work breakdown in a technical language and technical steps. It’s really about finding a way to capture user-journeys or work-flows and therefore breakdown the work into vertical slices of incremental deliverables.
You can use the Agile techniques like User Stories but we tend to think of a story as anything we’re being told by customers or anything that captures their needs, so the story can be a narrative, an example, or set of examples, a drawing or it can be a formal document, but it’s whatever works.
By creating formal documents you tend to have people go away and do their interpretation of what was said and then a week or so later you’re potentially stuck arguing over whether that’s the right interpretation - maybe your interpretation is wrong! So it’s about whatever technique you have that can immediately capture that sense of creating value, something we’ve had a conversation about and decided on.”
FLOW is a set of methods that lets you drop formal techniques in favour of
The primary drivers are:
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly