The Cynical Project Manager @thecynicalpm-blog - Tumblr Blog

Maslow’s Hierarchy of Needs - for a ScrumMaster / Agile Lead.. :)

Splitting hairs with the Agile Manifesto

This text has been shamelessly stolen from a company’s in-house Agile conference - hence all names have been removed. However, it makes some very important points, so I couldn’t resist but post it here.

All credit to the original author who, sadly, can’t be named here..

“This week I was bullied into a lightning talk slot for our Agile Mini-Conference.

This gave me a chance to put into focus a few thoughts that have been bumbling around my head for more than a little while now. Specifically thoughts on how the Agile Manifesto has been interpreted (or misinterpreted) as part of the journey that teams embark on in their quest to Become More Agile. The conference was a great success, but now I've come down from the adrenaline surge I thought I might be able to put some of those thoughts to paper in a slightly more orderly fashion than on the night.

I won't repeat the Agile Manifesto here, but for some strange reason feel compelled to provide a link (http://agilemanifesto.org/) in case for some inexplicable reason readers don't know where it is or can't find their way to it themselves.

First things first - the Agile Manifesto isn't new. Nothing of the sort. It was written 16 years ago, and the thinking behind it predates it further. When we talk about being Agile - at least in the sense of being compliant with the manifesto - we're talking about a set of practices and principles that were initially established some 20 years ago (or even further back). What is remarkable is that in such a fast-moving industry the manifesto and associated principles still stand up to scrutiny and are still held in such high regard.

Secondly - the Agile Manifesto was the result of 17 of the great minds in our industry agreeing with each other and agreeing to put their names to it. I don't know about you, but I have a hard time getting three smart people to agree with each other. Let alone six, or ten, or seventeen. From this I can only conclude they thought about the wording pretty darn carefully. This being the case, it behooves us to read the thing just as carefully. And this is where I start to split hairs.

"there is value in the items on the right"

The manifesto identifies 8 valuable facets, but places additional weighting/value on 4 of those facets (on the left). This provides guidance as to where we should balance our investment of effort, or for those cases where some constraint or edge case forces us to choose between them. From what I've seen in my career so far organisations or teams embarking on this journey tend to adopt this weighting in two ways:

Some teams take the status quo and place additional emphasis on individuals & interactions, working software, collaboration and their approach to handling change.

Some teams take the status quo and reduce their emphasis (or even discard) their existing approaches to processes & tools, documentation and planning (changing attitudes to contracts being largely non-negotiable).

Although it's not really as black-and-white as this - the teams that tend towards the first category make a decent transition to Agile working, while those in the second category often throw away the things that they've done well in the past and then wonder why they are suddenly less successful when following an Agile approach.

"over following a plan"

The Agile Manifesto says nothing about making plans. Planning is helpful. Planning helps me get an indication of how long things might take, how much it might cost, how many people I might need, what my dependencies are, and what drives my critical path. This is all useful information to me.

The problem is that most plans are wrong before the proverbial ink is dry.

Plans are based on (erroneous) estimations, (incorrect) assumptions, (uncontrolled) dependencies and (changing) requirements. Producing a plan provides information that guides our decision making.

Following a plan necessitates a certain suspension of disbelief (because the plan is probably wrong), and the dogmatic following of a plan that you know to be wrong is just plain dumb. But it happens. A lot.

However, to misquote Churchill, whilst plans are useless, Planning is VITAL.

"comprehensive documentation"

Comprehensive documentation is one of the thornier areas to deal with, as one person's "comprehensive" is another person's "too much". What's clear to me is that documentation falls into two broad categories - useful documentation and not useful documentation.

Documentation aimed at specific people (or groups) is often great - we know the reader, it serves a purpose, and it can be focused. Developer guides, ops guides, new starter guides, architecture overviews - I know who these are aimed at and what they need.

The problem is often when documentation is there solely as a deliverable to tick a box in a plan or a contract somewhere. When written without a specific reader (or intent) then that comprehensive documentation can rapidly become "too much".

In any case, a bunch of documentation (even great, focused, pithy documentation) with no working software (or even working software that never reaches the intended users) isn't much use.

A contrast to this is those cases where working software might be available, but I have no idea how to consume it because the documentation isn't there or up to scratch.

"individuals and interactions over processes and tools"

For most of this post I've focused on my agreement with the careful wording of the manifesto. This last point is one where I'm not quite so sure. For most of the facets there is a degree of natural tension between the left and right hand side...

"Do I invest my time in coding or documentation?"

"Do I seek to reach a collaborative solution where the contractual terms are not being met?"

"Do I embrace a change or do I push back on it for a time to meet existing commitments?"

...but I'm not sure the same level of tension exists between "individuals and interactions" and "processes and tools". Good processes and tools can facilitate better interactions with individuals, and interaction with individuals can lead to improved processes and better tools. If I squint then this might apply to bad processes and over-reliance on tools precluding the human interaction angle, but I do have to squint.

Some processes and tools have become to be implicitly associated with the Agile movement - Continuous Integration, Wikis, Retrospectives - and I'm not sure I'd downplay the value of these.

Secretly I suspect that the authors wanted to emphasise the importance of individuals and interactions, and keep the catchy X over Y metre.

But only secretly...”

Handy training all in one place for Atlassian's JIRA, for those of us who have to use it but are struggling to get usable guidance as to what it can do.

#jira #atlassian #agile

How to emphasise the value of advance Risk Mitigation

I came across this article on LinkedIn from Phil Jacklin of , and thought it was worth sharing.

I’ve cut-and-paste it here for readability, but include the link to the original for correctness and to give appropriate credit!

“I see many projects where risk management is a paperwork exercise. The risks are logged and reported on. But the response by the stakeholder community is either silence, apathy or simply hoping that the risk will not materialise. Often, little is done to manage the risks.

Here's a little technique I'd like to share that might engage stakeholders in more active risk management.

A few years ago I was at a conference on business strategy and the presenter gave us an exercise to do during one of the breaks. It went something like this.

In your organisation, or your team, you have a star employee. Someone you rely on. Someone you can't do without. You've probably already brought the name of that employee to mind. Imagine, during the break, that they call you. You take the call and they tell you that they are resigning. This is a crisis point for you. You can't afford to lose this employee. What would you do to keep them? Our exercise during the break was to answer this question.

The audience came up with a wealth of ideas - increasing pay, giving more holidays, reducing workload, giving promotions, providing more opportunities, moving on to better projects, more training, etc. The presenter than challenged us that if we were prepared to do all of that to keep the employee, maybe we should be offering all those things right now. Maybe it was worth offering those things right now to avoid the resignation situation. Because if the employee resigned, offering those things after the event probably wouldn't stop the employee leaving. If you were prepared to offer these things to stop the resignation, offer them now and that would stop the resignation from even materialising.

Why not use the same technique to manage the risks on our projects?

Take a key risk on your project and ask your stakeholders to imagine that the risk has materialised. Paint the picture of what effect that is now likely to have on the project - delays, increased costs, reduced benefits, non-delivered features, etc. Then ask them to list what they would be prepared to do in order to manage this new situation. This is done best in a group session so that people feed off each others' ideas and you get a better list of responses they would be prepared to take.

Next you simply offer the provocation - if you would be prepared to do all of those things if the risk materialised, what is it worth doing now so that the risk doesn't materialise? What is it worth doing now to avoid the risk-response-workload that the group have just planned?

Have a few items up your sleeve to help move the conversation along if needed. Start with some easy ones the group are likely to agree to and progress to the more challenging ones. Get the group to come up with ideas too. You want to use the session both to get a better response to your current risk, but also to help the group develop their own abilities to think about risk management differently.

Even if the collective agree there is nothing new they are prepared to do to manage the risk, you still have an agreed plan of what will be required if the risk happens and you can now start factoring that in to your schedule. That's more than you had before. But in all likelihood, you will have an agreed set of actions that the project can start taking right now. Your stakeholders have just proactively started managing your project risks.

This works best on your key risks (ones that will have a large negative effect if they happen) and you need to take care not to over-use this technique. But many projects have key risks that stakeholders are not actively engaged with; risks that could derail the project. In those situations, this is another tool you can use to actively manage those risks.”

#riskmitigation #stakeholders

#agile #snakeoil

Less Evangelists, more Champions

Evangelist (n) : Psychotic denier of realities other than their own; Delusional Fanatic; Totalitarian; Hegemonist

From the Oxford Cynics Dictionary, 1st ed.

Mao Tse-Tung was an evangelist. Jim Jones was an evangelist. I'm pretty sure Pol Pot was an evangelist. NONE OF THAT IS GOOD.

So why is the IT industry swooning to a new horde of evangelists, in ill-fitting suits, a manic gleam in their eye, and promising the cure to all ills? I am, of course, speaking of the Agile Evangelist, which is now such a ubiquitous term on C.V.s I think it now counts as some un-awarded qualification alongside university degree, Microsoft Professional, and holder of that stage three badge in swimming that you earned when you were ten.

By definition, an evangelist is someone who has THE ANSWER. Logically, as it is THE answer, all other answers are sure to be wrong. Anyone who dares suggest that the smoking wreckage left behind from the last time they attempted THE ANSWER was perhaps, possibly, just maybe because it wasn’t THE answer either clearly :

a) Didn't understand it b) Didn't apply it as prescribed ( admittedly somewhat vaguely ) by the gilt bound foot-thick official book ( £39.99 RRP ) or the exhaustively promoted and hugely entertaining presentation / training course / seminary / indoctrination session ( £300 - £1,500 available at all local faith outlets )

Can you see where I'm going with this?

Don't get me wrong - I really like Agile. It was genuinely revolutionary, unlike all the other areas it stole most of it's ideas from ( Lean Manufacturing, DSDM, JAD.. ). Its aims are noble, some of it's approaches pretty clever, and on occasion it works. It means, in theory, the team manage themselves and I get to do what I should be doing, and even better they actually put a couple of people in charge of the team, in the form of Product Owners and SCRUMMasters. It enforces regular reviews and checkpoints and makes it very, very clear that if what's built isn't what's expected it's purely because the end user walked away and left us to it.

But - it doesn't deliver A WHOLE PROJECT quicker ( just the first bits earlier ). It’s got rough edges which don't always work ( Story Points, anyone? ). It fits some scenarios a LOT better than others ( I will NEVER board an aircraft that was CONSTRUCTED on Agile Principles ) and it will not - and let me stress this - cure world hunger, eliminate poverty, cure cancer or.. solve all and every problem on your project.

And.. let me just whisper it.. It is NOT a PROJECT MANAGEMENT APPROACH.

( yes, there’re a lot of AgilePM and PRINCE2 Agile things out there.. but notice how there’re no how-to-run-your-project-using-SCRUM options..? )

Yes, you heard me right. It's a production method, like Adam Smith's pin factory or Ford's rolling production line, or even the Toyota Production System. Great for incrementally delivering functionality, involving the customer and creating a regular flow of code delivery which, in theory should be relatively simply to track. Not so hot when it comes to brain surgery.

Stating that a methodology which has no native support for task dependencies, shuns upfront design, risk identification and mitigation or planning, and can't be sure where it sets off towards is where it'll end up is not, I propose, an approach I'd take to building anything safety critical. Or a house, for that matter.

Add to that the more frothing-mouthed lunatic fringe letting loose the imagination of rabid coders everywhere that now Estimates Are Meaningless and should *never* be provided except on pain of death ( that was genuinely the training that was rolled out company-wide, and which has taken many, many VERY PAINFUL MONTHS to undo ) or that Documentation Is Evil, and a tsunami of half-arsed implementations swept companies nationwide, causing untold havoc and high blood-alcohol levels in Project Managers everywhere.

Could we please lead away the more demented evangelists to nice plush, padding-lined homes somewhere safe and away from loud noises, and bring forth the champions instead?

It's an old term, but the word itself implies competition and that it's not a lone voice, but one among many. Maybe even one that can learn from others, or recognise that other ideas could in fact support, or complement it, and don't in fact need to be pounded into submission as a fundamental threat to THE ANSWER.

And then maybe we could ditch the hype, do what we do with every other methodology, look at all the good stuff and use that... as well as use all the other good stuff from the other approaches too, as one of those huge sexy SnapFix toolboxes stuffed full of good ideas we can pick and choose from so as to apply what works best for the problem in hand?

And then we can maybe get on with the job without having a unionised uprising anytime we suggest we do something not officially endorsed by Mike Cohn?

</rant>

The long lost Systems Analyst

Back in the heady days of SSADM ( anyone remember that? ) and for a short while after, there existed a rare beast known as a Systems Analyst. These were generally intelligent individuals with a degree of common sense and some technical skills, who could ask useful questions of customers, propose designs, guide projects towards what was feasible and practicable, and bridge the gap between code and client.

These were supported by able Analyst Programmers, who worked at the sharp end to create what was needed but also - as the title implied - were expected to provide some thinking too.

Unfortunately, with SSADM being in effect the Maastricht Treaty approach to agreeing requirements and producing designs, their actual ability could never be fully applied, and on occasion they unwittingly ( and often unfairly ) took the blame for many inevitable disasters wrought in the name of 'process'.

Those roles were largely abandoned towards the mid-to-late 1990s, when business realised that multi-skilled personnel were both difficult to source and expensive, and that technical people tended to scare the more flappable business customers by asking such unsettling questions as "why?".

It was much cheaper instead to employ battery farms of obedient code monkeys, and draft in Business Analysts - sometimes from the same dark realms within which Consultants lurk, waiting to prey on the unwitting - who could talk to the suits in their own language and not daunt them with any worrying technicalities largely due to their being completely ignorant about IT.

This struggled along with varying degrees of success, largely through developers ignoring the analysts and everyone pretending that what was delivered was actually what had been asked for or, in some cases, was even what was expected.

When the disaster ratio stubbornly refused to decrease, and it was discovered that anything more complicated than Notepad appeared to be delivered both laden with technical debt, unable to integrate with anything else, and already legacy before it was actually deployed, the industry looked at itself in puzzlement and decided Something Must Be Done (tm). At the same time, some of the older programmers reaching their technical ceiling of ability or at the end of any desire to move into either Management or Business Analysis were looking around for something new to do.

This led to the introduction of Technical Architects ( or Solutions Architects if they knew even less than that ), a role that to this day amuses and entertains generations of software professionals through its complete lack of any distinction or definition within the industry.

As a rule, these are ( or were ) highly technically skilled personnel who were either getting a little long in the tooth or distinctly bored with writing yet-another-database-system and so were instead elevated to supervise their peers. They were excused the need to deal with anything as trivial as details, but could instead loftily bridge the gap between the Business Analysts and Developers, whilst at the same time getting to draw hugely intricate, colourful and beguiling diagrams which no-one understood and which the coders would again ignore as either being a) unfathomable b) unfeasible c) hugely over-engineered.

And everyone was happy.

#solutionarchitect #systemsanalyst #analystprogrammer #codemonkey #businessanalyst

I’m saying nothing...

Day 1 in the blogosphere

Hello, and welcome to the Cynical Project Manager.

To introduce myself, I am a Cynical P.M.(tm), weary and battle scarred through decades of abuse from managers, project teams, corporate politics, various half-crazed and ambition-addled industry regulators and life in general, all the while naively entertaining the hope that someday project utopia will be reached and Things Will Just Work.

When it finally dawns on me that day will never happen, I’ll probably just jack it all in and setup shop as a hamster farmer, or in some other industry that actually makes sense.

Project Management must be the sole career whereby, by rights, it shouldn’t be needed. Co-ordinator, maybe. General crisis manager, definitely. Possibly even just simple Planning Assistance.

But...

..if the scope is clear, the design is right, the estimates ( approximately ) correct, everyone knows their job, has the necessary skills and resources, and actually does it...

..we’d all be redundant overnight.

But shhh, don’t tell anyone. There’s an industry depending on it.. :)

Trending Blogs

Recently Viewed Blogs

The Cynical Project Manager