I mentioned in my last post that I was interviewing a lot of people as we look to expand the InvoiceFair technical team. One of the key roles we’re hiring is an Agile Coach, which those of you who know me will recognise as a role upon which I might have some specific opinions.
Not that I’m generally opinionated, but I’ll make an exception in this case (quiet down the back there).
I discussed my thoughts on what I believe agile to be in an earlier post “Agile – Just Not Flexible Enough?“. I won’t repeat too much, but simply put, agile methods have evolved to deal with projects that have ill defined or emerging requirements. But there is another perspective, which really goes to the heart of agile processes.
We use agile methodologies for one simple reason: it has the potential to be the best mechanism for increasing flow.
This should be the focus of every process we build, and borrows heavily from Lean development techniques. In that world, work in progress is limited and batch sizes are deliberately kept small to allow tasks to move through the process more quicky. There is an explicit intention of reducing and eliminating bottlenecks to keep the process as efficient as possible.
Maximise Flow
Flow is one of those words that has attracted a lot of attention, partially due to Mihaly Csikszentmihalyi’s excellent book Flow: The Psychology of Happiness. Many of the ideas discussed in the book will be quite familiar to people in the technology world. Its not unusual for us to lose hours while completely engrossed in some development activity or another.
It’s not unusual for us to lose hours watching completely useless videos on Youtube either, but that’s not flow just in case you get confused.
For our purposes, the kind of flow we’re seeking is a little easier to capture and define.
We simply want to create the shortest path by which a problem can be taken from inception to a released solution, and by released I mean in the hands of users where they can derive some value.
Diligent students of agile, or perhaps more accurately productivity, will recognise a possible contradiction between agile and this goal.
Is Agile the Shortest Path?
Lean and Agile advocate an approach that rapidly produces a solution that delivers value followed by a review where modifications and additional requirements are captured feeding the next iteration of the development.
Interestingly we see this same approach in Design Thinking, but the focus there is to agree on the right solution, not the fastest.
The problem with agile, to which many a budget owner will attest, is that projects can very quickly become never ending. Rather than being the shortest path, we end up on the yellow brick road to the emerald castle without ever arriving (sorry for the movie pun).
Building for Flow
For an organisation to maximise flow, everybody must be involved in the process, and the process must be a hybrid of the various methodologies, taking the useful aspects of each and blending them together into a tailored process.
The intention here is the same as that for Lean processes – eliminate waste. Equally when we look at high performance teams, we see the same waste elimination mindset; high performance teams hit a flow state quickly and stay there longer than their counterparts, and they do so by being efficient in every action they take.
The process we build has to start with the business, and progress through every team as effectively as possible. In building this process, we must avoid falling into the trap so often experienced by agile practitioners: focusing on the micro process.
We need to start with the macro view; to understand that we are building a flow that first and foremost is efficiently progressing towards an overall outcome. We must, as Franklin Covey suggested, begin with the end in mind. The process we build must take into account the unique circumstances we face with resources we have at this point in time, and then adjust over time as those circumstances change.
Whilst we might all aspire to a continuous delivery and deployment approach similar to the Netflix model we’ve read so much about, we may have other factors to consider. Can this model be operated effectively in a SOX compliant environment for example?
Not really.
This is what our macro perspective will quickly surface. How can we eliminate waste from every step in the process? Our thinking must include:
- How we gather requirements from the business in a manner that minimises the number of questions that will later arise – waterfall has plenty to educate our thinking here.
- How we structure an architecture that is both flexible and constraining, balancing the productivity gains acheived by minimising choice with the advantages of deferred commitment – some aspects of the Lean / MVP approach can offer insights here.
- How we prioritise and funnel features into the development pipeline to maximise the progress towards the ultimate destination, with a minimum of detours – look to Kanban, particuarly on its thinking on Work in Progress, and the pull method for inspiration here.
- How we operate the actual development process, to minimise the number of iterations required to produce the targetted outcome. How we build quality in early to reduce late emerging defects and subsequent rework – Test Driven and Behaviour Driven development techniques, taken in small doses can help here.
- How we keep the business engaged to ensure that the each iteration is producing what is expected all along the development process, not just at the end of iteration review – no system is particularly strong on this approach, we need to ensure that the process is owned by every team, not just the technical teams.
- How we transition from development to production while maintaining our security and compliance posture – DevOps and automation have facilities to offer here, but also the now emerging SecOps approach is worth reviewing.
No Silver Bullets
The revered Fred Brooks wrote a paper in 1986 (yes that is the last millennium) entitled “No Silver Bullet—Essence and Accident in Software Engineering” that opines that there is no single thing that will offer an order of magnitude improvement on productivity.
In the nearly fourty years since he wrote that piece, despite significant progress in language design, technologies, tools and management techniques the situation has not changed.
If the goal is flow, then like a river, we need to find the optimum path through our own particular landscape, and mature that process over time.
Support Ukraine
The invasion of Ukraine is an act of aggression that we should all oppose and speak out against. I will continue to Stand with Ukraine and its people until peace is restored.
Bows and Arrows 
Leave a Reply