Working in software development space for just over 20 years, I have experienced more than a few paradigm shifts.
I guess, by now some might regard me as a dinosaur, in that I've been working in the industry longer than some of the entrants have been alive! I have to admit, in no way does that make me wiser, just a hell of a lot more crankier!
I've been around long enough to remember when the Waterfall methodology was actually being used and now I feel I am starting to witness the demise of its successor Agile!
In the intervening period I've witnessed many organisations try their hand at implementing various project management methodologies, frameworks and processes, and I have to admit I seen some pretty spectacular failures and false starts!
I have also seen a number of colleagues and friends make a good living becoming coaches, in some form of management practice. Mostly after reading a book or attending some 5 day certification boot camp!
I really have no objection to this and to be honest best of luck to them and well done!
Surveying the workspace from my vantage point, as a skills for hire contract/freelance software developer and packaging all my experience in a box and taking time to reflect, I can honestly say that nothing has really changed in the work place at all. I appreciate my viewpoint and perspectives maybe specifically constrained to the software development industry.
I would also be the first to admit, that I am also probably very cynical, but let's be honest as a self-employed individual I am obviously only going to be concerned about my own interests!
The cause of Agile's Demise
Despite Agile being nearly over 15 years of age, taking that we regard its birth date as February 11-13, 2001, the anniversary of that fateful meeting of minds at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah.
I feel it is now more of a misunderstood teenager, than it is a methodology for getting things done!
I came across this gem of quote on one of the many Websites, Forums etc that have now dedicated to this mystical art!
A highly collaborative and well-managed scrum team is ideal for agile software development. With values like: courage, openness, commitment, and respect, these scrum teams feature a more collaborative and transparent management style organized to best complete the tasks at hand.
The problem here is that this defines everything that Agile is not !
First off, the whole premise behind agile teams, is that they should be Self Managing , the very principle of this is that they should not require any management! Secondly collaboration is often a by-product of agility not necessarily a pre-requisite!
I have to be honest, I am struggling to appreciate why an Agile team needs courage! This may be referring to a small agile navy seals or SAS teams taking on a heavily fortified enemy compound.
Forgive me if I'm wrong, but I never feel that my life is in danger when I run my suite of unit tests or trigger off the continuous integration process. I should have to take more care in the future!
openness, commitment, and respect aren't values of an agile team, surely they should just be good old-fashioned human values! You donâ€™t need to be in a team or even some kind of framework to practice these, it should just be your standard operating procedure as a human being.
Why Projects Fail
Recently I came across a thread on LinkedIn , which simply asked the question :
Which generated a number of comments. Unfortunately the vast majority of the responses appeared to come right out of text books or just the result of herd mentality. Which included the typical tripe of poor Planning, Workmanship, Resources , Communication, Management, Control, Estimation etc.
Some were even bold enough to proclaim that all you need for a successful project is visionary leadership and ownership.
The truth is projects fail due to one thing and one thing only, itâ€™s the fact that they are regarded, treated, managed, resource-ed, visualised, planned . estimated and controlled as projects!
Projects fail, because they are never seen as a fundamental component as to how a business operates. They are always perceived as something that can be done on the side then brought into the business when itâ€™s complete! This is the fundamental flaw, in all project thinking!
Plans are worthless. Planning is everything.
I'm not the first, and I fear I will never be the last to bring up this clichÃ© quote from Dwight D Eisenhower. Yet, we will still experience lack lustre results from project planning.
If it were possible to go back in time to the D-Day invasion and we asked any one of the 425, 000 dead Allied and German troops, whether any of the plans executed on the day were successful ?
The moral of the story here, is that no matter how much detail or attention you pay to your plan. Your project is never going to execute according to plan. You are always going to have to deviate from your plan, the trick is how you handle the deviation.
No plan is ever going to be perfect and you will never execute flawlessly on a plan. However, this doesnâ€™t trivialise the need for a planning, but it does accentuate the need for executing a plan based on the knowledge that the plan is going to change.
Calibre of People
Yet another misnomer, is that all you need for a project success is the right calibre of people. You hear garbage slogans like:
its better to have A Players on a B plan than it is to have B Players on an A plan
This may sound great, but ultimately its a hollow and empty sound bite, providing absolutely zero value!
This may have been some tripe spouted by Steve Jobs and now it brandished about as if it came from the lips of God himself. The truth is, the calibre of your people is nothing compared to the culture needed for them to operate. After all, wasn't Jobs fired from his own company because he was once perceived as a less than desirable player ?
You could have a room full of geniuses, but yet still produce garbage. If you set out to polish a turd, all youâ€™ll end up with is a polished turd. Irrespective whether you hired the best polisher's money can buy.
One only has to review, the many examples of Job Descriptions and job adverts placed on most of the job boards out there looking for freelancers/ contractors or even permanent resources on project teams.
Lets take a look at an example that has hit my inbox, as I write this article
Are you looking for a new opportunity at the moment? The reason I ask, a technology driven company based in Central London following the LEAN methodology, embracing change and technical evangelism are looking for a number of Senior Software Engineers and Full Stack Developers to join their cross functional team.
Adopting new technology on a regular basis to systematically remove technical debt, they apply cutting edge techniques, best practices and methodologies while still upholding the principles of the Agile Manifesto and Test Driven Development to ensure code is clean, reusable and robust.
The project; to expand numerous product verticals in the business and are looking for their Senior Engineers and Developers to own these products with full technology choice, architectural responsibility from conception through to delivery.
The sills then are after:
- C# and the MVC framework;
- Good working knowledge of IOC and ORM systems;
- Continuous Integration (TeamCity or similar);
- TDD, BDD and SOLID principles;
- Kanban or Scrum or LEAN experience;
- Desirable: Experience with Jasmine JS Unit testing;
- Desirable: Knowledge of NoSQL databases.
You will get the opportunity to work cross functional teams using a range of tools. You will have the autonomy, freedom and all the responsibility available for you to build the platforms however you feel suitable using the technologies of your choice. On top of the technology, the client are able to offer a list of added benefits including free breakfasts, subsided gym membership, free massages, Cinema club and a company pension scheme.
If you are interested in this opportunity, please do not hesitate to get in touch with an updated copy of your CV. Alternatively, if this role isnâ€™t exactly what youâ€™re looking for we have a number of other positions which could be suitable.
This couldn't describe hell on earth any better!
Reading through this list, it's almost as if someone tried to take copies of:
- Clean Code
- The Lean Start-Up
- Essential Scrum
- Domain-driven Design
- The Phoenix Project
- The C# Player's Guide
Thrown in a table tennis table, given it a good shake in the hope of forming a project team!
There is not one mention of the type of problem that needs to solved, other than it's a Greenfield Project! Which despite it being labeled as a Greenfield project , they've already decided on the key skills required and the approach!
The above scenario plays out, as we need a circular shape but we're going to start out with 4 equal length sides! Which just brings us to the following example:
It is so short-sighted to say, all you need for a project to succeed is a team of good people.
For those of Football (Soccer) persuasion will only have to look at Leicester City, One season (2015 - 1016), they won the Premier League without losing a game, the following season exactly the same players and the same manager find themselves battling to avoid relegation and end up firing the same manager.
How does that exact same team go from excellent to poor ? The players skills and abilities didn't suddenly up and leave during the off-season. The gods of the premier league didn't sprinkle voodoo dust and cursed them!
What happened to that team, is that the culture and belief that permeated through the team and the club during their time at the top, just evaporated.
Obviously what was working before just stopped working. The trouble is nobody could quite identify what it was exactly was missing. They spent the rest of the season searching for it.
This scenario plays out in all sports and businesses everyday. Yet people still naÃ¯vely think is all you need for success is skilled players.
The season that Leicester City won the league, they were a team consisting of lesser value players compared to the big hitting clubs at the time. The combined values of the players of the Big Clubs like Manchester United, Manchester City, Arsenal, Chelsea, Liverpool combined their wealth is it possible they could buy 20 Leicester City's, yet they all failed in their bids to win the league that season.
Importance of culture
What I have witnessed time and again, what makes many projects fail has nothing to do with skills and abilities of the people. It has everything to do with culture.
Employ the best people is an empty sound bite. It literally means nothing. Most organisations recruitment processes aren't capable of only employing the best people. Even worse, most really don't have a definition of what makes the best people.
You could implement a policy of only employing University graduates, however there are more than enough examples of University and school drop-outs going on to be icons of success.
In fact, even the man who famously quoted for only employing A players, was in fact far less than a B player when it came to university stakes. There were a number of aspects of life in which he was a complete failure. Yet so many people revere him to be a deity.
In truth, at best a university degree is only a measure of mediocrity. Yet another empty soundbite is that Knowledge is power , it's what you actually do with that knowledge that is the true power.
One could possess all the knowledge in the world, to harness the power of the speed of light, but unless you execute and implement, that knowledge is utterly worthless.
You could employ a team full of geniuses but still achieve very little at best you may only achieve mediocrity. Based on the fact that you did not create the conditions for success.
My personal favourite book on Business Agility: Sustainable Prosperity in a Relentlessly Competitive World, the author time and again expresses the need for the organisation and it's people need to buy into ideas. This is where so many organisations go wrong with projects they never take time to truly foster the need, desire and will for a project to succeed.
Often when a project is kicked off, there are just simply empty sound bites, a worthless business case document and maybe an empty rallying email from the CEO.
Clear requirements don't matter
Those who argue that, all you need for a project to succeed are clear requirements, are only fooling themselves.
There could be no clearer requirements than Play 35 games, win all of them and win the league. If ever there were clear distinct and perfectly understandable set of requirements, these should be them. Yet 19 other teams in the league failed to deliver.
Process is not a saviour
Process in and of itself is no guarantee for success. You can't rely on a strict adherence to process to save you. Process is nothing more than a guide, yet so many organisations treat it as the one true way.
Projects start failing from the moment they are conceptualised. Primarily due the fact that at the point of conceptualization there just isn't enough information to base anything on. In most cases, despite the amount of effort into the planning, estimation, data collection etc., you will only ever truly find out if a project is a success until after it was implemented.
Even a failed project is a success, because you will have found out that the approach taken for that particular problem was indeed the wrong one. It doesn't mean that exactly the same team couldn't succeed trying an alternative approach. Conversely it doesn't mean just because a team succeeded on one project, it means they are likely to succeed on the next.
There is never, exactly one reason for failure. There are always going to be a multitude of reasons and these will be mostly down to the unknown unknowns that gradually become known