It’s not about being Agile, it’s about implementing practices that provide flexibility
I have posted before about what is Agile Methodology, but in this post I will discuss some of the most common side effects and failures I have experienced when the Agile Methodology has been completely mis-implemented in the enterprise .
Many organisations are considering adopting and transforming their software development teams to agile units, all swayed by stories of how other organisations have been able to respond faster to changing market conditions by delivering higher quality software and improving their competitive edge. Yes! Agile has gone mainstream, but is it really successful?
During the course of my career, I have seen many hype trains rumble through town. Some leave their mark, very few leaving the desired effects. Agile is definitely displaying all the hallmarks, exhibited by previous hype trains. This includes the cottage industries that sprout out, a bit like fungi germinating from the decaying tree trunks. There are a plethora of Agile Experts, Coaches, consultancies, tools, platforms, not to mention the many new frameworks and methodologies that ensure the successful implementation of the agile methodology.
Sadly, as with most things that go undergo mass adoption, it all starts to lose its shine, miss-implemented, misunderstood and finally diluted beyond all recognition. Since 2012 / 2013, a number of thought leaders in the software development industry have been mooting the idea that Agile is dead. In short, Agile is no longer the trendy new kid on the block, but it is now the misunderstood teenager.
I personally don’t consider myself to be a member of any of the project management cults, i.e. I wouldn’t call myself an Agilist, Waterfallist, PRINCE-ist , Kanbanist, Leanist or whatever . I’m more of a “Get sh*t done” guy. In reality I don’t think any of these frameworks or methodologies help to get sh*t done, they just seem to add further complication to getting sh*t done.
I’ve lost count of the number of organisations I have worked in over the years, when at the start of the engagement the always produce some sort of declaration of what type of organisation they are. i.e “We’re an Agile organisation”, or “We follow SCRUM” , or “Our methodology is based on PRINCE2” or ever more seldom these days “We’re traditional and we’re very much a Waterfall driven”. The reality is, as the weeks or days go by, most organisations tend to display exactly the same set of characteristics without fail.
Rabbits in the headlights
The reality is that the vast majority of projects are run by simply following the “rabbits in the headlights” approach. They can see the project coming towards them, it’s going to make impact, in all likelihood there are going to be casualties, it’s going to be messy and probability of success is between 10 – 15% . The intervening stages are littered with meetings and gatherings of people in rooms trying to make some sense of it all, and the generation of some documents. This all coincides with the delivery of a software product.
Delivering on time
The irony that one project success criteria is defined by successfully hitting a time window, based on complete guesses. We try kid ourselves that these guesses are based on either on experience or some data gathered from a similar type of project with a team based on a similar type of skill-set, it took a period of time. This inevitably consists of placing a yardstick out at anywhere between 6 – 18 months, and then calculating how many 2-4 week timescales are within that period of time, we’ll now call them iterations or sprints. During these iterations we’re going to try and cram as much business functionality as possible within each of the iterations with the hope of an ever increasing burn down rate and a team with an ever increasing velocity.
In general the vast majority of projects end up with the familiar burn down chart.
I can’t tell you how many project meetings, I’ve been involved in that have gone under guise of “Catch Up meetings”. Essentially these are spaced anywhere between every 2 – 4 weeks during a project lifecycle, and generally involve various people from the different disciplines that form the project team i.e. Project Management, Business Analysts, Quality Assurance and Development. Apparently these meetings are arranged so all can get an update on the projects progress. The theory behind these meetings is sound, but in practice what happens is that it all starts turning into a web of false promises and action items. The end results are a load of Chinese whispers end up circulating. Often the result of good intentions poorly executed. Tribes within teams form, and it all turns into an us against them vendetta.
If your organisation needs to have a Project catch up meeting, then it’s a sure sign that there is a smell within your project communication channels. Often this is a symptom of too many tools not enough synchronization. For instance, your development team is using, Team Foundation server (TFS) to store development tasks, your Quality Assurance have ventured out and brought HP Application Life-cycle Management (HP ALM) ( a.k.a Quality Center), Business analysts have decided that JIRA or Doors is the tool for them and your Project Management Office have decided that Sharepoint is a great place to store Spreadsheets, Project plans, Documents and Power Points.
The problem here is that nobody actually knows how it all relates, because in all the management wisdom, we’ve split the departments up due to an efficiency drive project that was executed at a previous point in time. Each of these new departments, have created their own patterns and practices to how communication on a “project level” is executed. The issue is that when the need to communicate within the project these patterns and practices don’t work so well. In order for a project to have a good chance of success, its necessary for all communication to be clear on concise, with minimal interferrence or any chance of miscommunication.
Snot and tears
I have been in organisations where the conventional wisdom is that it would be a great idea for all departments to use one common system. i.e. All departments to use TFS, or JIRA or whichever tool. The problem with this approach, is that each tool has it’s own strength and weaknesses and unique features. However much hype each of the vendors attribute to their individual products or platforms the sad reality is they don’t necessarily cater for each need or desire adequately. It always ends up with a square pegs and round holes, and from my experience a lot of snot and tears from all stakeholders.
Synchronization is key
One of the best approaches I have experienced is to ensure all crucial data is synchronised between whichever tools are chosen, by leveraging a tool like Tasktop Sync to synchronize all the relevant data required by all the management applications within the organisation.
To build a good software solution, we need a clear vision and shared purpose of what success looks like. This unfortunately is alot easier said than done, primarily because different stakeholders often have different ideas of success. All to often, software projects are broken up into smaller units of work across multiple “vendors”, each vendor will have it’s own definition of success, these usually have nothing to do with users actually using the software, but will have more to do with fulfilling terms of contracts and getting paid on time.
All to often, the primary definitions of success for a lot of projects, are defined as either ;
- NOT to end up in court with the Vendor
- NOT to end up in court with the Customer
If a project teams safely navigate this first hurdle on managing expectations, it’s essential that they actually establish well understood high level goals, and not focus on the detail of how they will achieve those goals. There is a natural tendency for project teams to fill a project backlog with tasks and trying to provide time estimates to ensure they sync up linearly with the delivery date.
The organisation is broken
For any methodology to be successful, it requires the full support of the organisation as a whole. Whether that organisation be a small software development team or a large multi national company. The entire organisation needs to be committed to the adoption and implementation of any framework. Sadly, this is not the case for the majority of situations I have witnessed, they proclaim “We’re Agile BUT…..” or “We’re PRINCE2 BUT……” . There is always a reason why they haven’t taken on the full methodology, this is partly due to the fact that most methodologies state in the opening chapters of their text-book, that it is not always necessary to implement the full methodology to be successful, and that most organisations can be successful by selecting parts of the process to suit them.
Unfortunately, what predominantly happens is most organisations pick some good and easy parts of the new methodology to implement and attempt to mix them in with the really bad parts of their existing approach.
Agile In Name Only
The reality is that they are not truly agile, they are what is labelled as Agile In Name Only (AINO), at best most of them work in Iterative Waterfalls with daily stand ups. They work in fortnightly sprints only to meet hazy objectives, with the hope that it will finally develop into a cohesive product at a predefined point in time.
I’ve worked in truly Agile organisations, and experienced the benefits and expected results. However, these organisations were developed from the ground up to be lean. Resources were constrained and the whole attitude within the organisation was focused on truly doing more with less. Work was carried out in truly agile and lean practices , not by choice but rather because it was the only way. The organisations never viewed themselves as Agile but rather as Start Ups.