Post-Agilism

Business pragmatism is finally challenging the ‘Big Waterfall’ industry and acknowledging the need to adapt. Many businesses know that agile principles make sense, however, taking the leap has been made institutionally difficult, in many cases, ostensibly by the very people who promote Agile. The problem? For over a decade self-styled ‘coaches and consultants’ have been squabbling with almost religious pomposity to define what  ‘proper’ Agile looks like. Enter Post-Agilism.

Think of Post-Agilism as an era, it simply represents the part of the Agile industry as having undergone a period of evolution. An evolution which, by definition, has been brought about by a strong need to adapt. The by-products of adaptation are consistently mutations, and the era of Post Agilism will soon chronicle what survives and what is banished to the history books.

Either way I believe we are entering a Post-Agilism era where we responsibly execute precisely that which needs to be done in order to consistently become successful at achieving what we set out to do – Post-Agilism also means it’s not just for software anymore.

The team that wrote the Agile manifesto back in 2000 took a huge leap – their vision was to jerk the software world out of its lumbering and archaic ‘Big Waterfall’ mind-set. Lamentably, while Agile writhed to grow a head of credibility, many ‘high-priests’ got stuck in the tar pits of process doctrine. Classic agile innovation has arguably dried up somewhat over the past decade, however, this may have been a good thing. I believe this (period of low volatility) has allowed the risk-averse mind-sets of industry to catch up.

Businesses now seeking to upgrade from the ‘old ways’ will find it easier to modernise and make that big leap – away from the inefficiencies of ‘Big Waterfall’ into a new era of daring and innovation toward fiscal pragmatism and Post-Agilism.

Good ideas like Agile are usually adopted quickly, however by the time something becomes best practise, the competitive advantage is already past.. Consequently Post-Agilism is a chance for renewal, now it’s all about gaining a competitive advantage through proliferating more (and better) options and thankfully making better choices.

10 Tips for a post-Agilism world

Those that have failed to break loose from the single option of ‘Big Waterfall’ may well have fallen prey to Conway’s Law, which states, “…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” .

Thinking back over two decades of conducting transformations, I find that each time I perform due diligence before a programme, I discover that the biggest risks and barriers to success lie in full view – documented in the company’s organizational structure and operating model – each in its own right is a valuable tool which can help to direct ones thinking toward identifying revenue sapping inefficiencies.

Most management and staff will tell you they are flexible, and the majority are, the problem is that most projects span corporate tiers or matrices.  Let’s be blunt and call them silos and however which way one views them, these structures dictate that teams unfailingly expend an extraordinary amount of costly project time spent behind the scenes seeking ‘social permission’ and further adding to delays, obstacles and complexity to any process – complexity that is never budgeted for and therefore eats into the base cost of every project.

Tip 1

Ensure Transparency is a priority, to achieve this you will need to make decisions based on data. Ensure that all project data is visible and create one version of the truth’. Do and say what needs to be done and said, and direct communications in favour of the end user – root out selective transparency by banning private or sensitive reports in development environments. Measure and publish the cost of breakages, late delivery, bugs defects and returns. Make sure data is presented as measurement – do not use data to assign blame – find root causes for problems and address them using the 24 hour rule.

Tip 2

Redesign the Operating Model around on lean principles and monitor the 7 wastes. Treat each iteration of the model and structure like an experiment and review regularly – change what doesn’t work ruthlessly. The goal is to provide a space to support core teams – teams that are decentralised, self-governing, transparent, committed and adaptable. Ideally this starts right at the top but it will also work very well at Business Unit or even Department Level. A culture change is inevitable, and the fact that it is a community, means it relies on structure.

Tip 3

Restrict the working scope of any project. Break projects bigger than 90 days into smaller lean projects. This allows very rapid prioritisation and focussing on the task at hand. Precise forecasting on any project beyond 120 days is indistinguishable from astrology – rely on these ‘predictions’ at your peril. Following this tip alone, moves your team away from disaffected ‘should be OK’ or ‘just good enough’ thinking – it should strive for a test-for-quality or precise suitability for purpose approach – this will quickly uncover or highlight input which would ordinarily remain unrevealed until the latest possible moment where it costs you money in corrective action. Leveraging the data and intelligence that would ordinarily remain unseen until ‘way-too-late’ allows upcoming blind spots, side-effects and unclear inputs (or issues) to be addressed early or even up-front. It provides an almost magical way to uncover things we didn’t know we didn’t know about and it allows an organisation to slowly sneak away from the archaic ‘big waterfall’ approach to planning.

Tip 4

Big teams will invariably slow a project down. Restrict the size of a team to no more than 10 but no less that 2. Small teams avoid the need for the wasteful reporting governance and process which is often enforced simply to keep all members in the loop. Establish small tiger teams or run seasonal or impromptu hackathons where teams are encouraged to produce specific working outputs in 48 hours.

Tip 5

Look at your delivery lifecycle protocol. Is it a system where projects linger and die – suffocating in needless governance or is it an incorruptible enabler? Redesign the Organisational Structure based on lean principles and monitor the ‘7 wastes’. Ensure everyone treats each and every iteration of the operating model and structure like a lean experiment and review regularly – change what doesn’t work ruthlessly. The goal is to build support systems for core teams so that they can function in a decentralised, self-governing, transparent, committed and adaptable. Eliminate any silly rules that do not help deliver quality outputs. Ideally this starts right at the top but it will also work at Business Unit or even Department Level. A culture change is inevitable, it is about community means it relies on structure.

Tip 6

Remove all silos and hierarchies that operate under a top-down management. A few years ago, I found out the hard way, that hierarchies are effectively closed boxes or cells – they lose focus on ensuring the success of the project as a whole – instead they concentrate on preserving their role on the project and the value of their presence, effort and contribution. Silos and hierarchies are a creativity killer because they drive people away from co-operation and they focus on ‘defending’ their territory. The solution is a network model organised by expertise. Remove the ‘Alpha Experts’ and strip out the management layer (the career threats) then assign a lead who ensures focus on the success of the project and takes charge of the tight-knit team.

Tip 7

Build a ‘management test bed’ as a management simulator. Assigning a person as a project or tech or team lead is not an official promotion, it provides real empowerment, but, much like bringing a horse to water, it offers the person an opportunity to take charge and succeed, success here means the company has proven management material. In most companies it is sometimes impractical to increase salaries and promote outside of corporate HR remuneration cycles. This process is low risk from an opportunity perspective, however it is my experience that most directors and senior managers excelled as team leads at some point in their career.

Tip 8

Create a buddy system where each lead has a ‘shadow’. Ensure shadow leads are fully briefed and able to report credibly and take on the lead role in the event of sickness, or breakdown in the delivery process, or when switching as needed to feed into rotational assignments.

Tip 9

Rotate assignments by moving people around, rotating off one project and onto another. This is a great way to cut the inefficiencies of silos and provides a boost on slow moving projects. It provides a great energiser where management ‘habituation’ can lead to stuckness. Rotation will without doubt deliver a sit-up-and-take-notice energy to any team while everyone has to get to know (and trust) a new lead. Cross discipline rotations are good practise, they get architects to experience testing, and engineers and developers to understand that they are going to support what they develop.

Tip 10

Track everything or use a 246Q. Ensure you have a full view of your projects in 2, 4, 6, week and quarterly views. Keep a massive calendar on the wall visible to all to depict what is happening on all projects and who’s working on anything – it ensures key leads are assigned to one project at a time.  In many cases project engineers and architects split their time across projects. A big calendar helps to ensure that everything is visible no matter how big the projects.

Bonus Tip

Ruthlessly test your governance structure and security mechanisms for compliance and sensibility. These disciplines have a tendency to become ‘untouchable’ if they are not constantly and independently reviewed – wasteful procedures must be rigorously challenged for efficacy. Make sure everything is reviewed empirically – ensure there is evidence to back up ALL reasoning behind restrictive rules and governance. Promote compliance and governance via checklists and playlists that help drive and measure better for better decisions. Most governance and security frameworks that are older than 2 years will contain a lot of invalidated rules biased by working assertions which more often go unchallenged – test them and challenge them.

Finally a caveat around IT – core agile practice encourages teams to build and ship working code (quickly). Be aware of potential trip wire – one where the sole focus of shipping code is treated as the only priority. In many cases IT-centric priorities boost business productivity – in turn ‘vanity metric’ priorities can also violate the key metrics that move business decisions – frequently this is done pontifically in order to ‘educate’ the end user – it’s patronising, don’t do it! Do responsibly only what is right for the end user.

Remember rule number five:-  Prioritisation is about People, Process, Technology – in that order.

Sometimes I get told “this is special . . . our project is too big and complex for this sort of thinking because [add assertion here] and it sounds like these tips will only lead to duplicated effort”,  what this response often shows is that the project has imprisoned the ‘leader’, whereas a project should be led by a leader.

To break out of a narrow frame requires options, and one of the most fundamental ways to do this is to find somebody who has solved your problem.