My approach to agile* adoptions is based quite a bit around Tai Chi and Taoist philosophy which I won’t go in to as you can search about that on the net. There are a few principles worth noting from these:
To the mind that is still, the whole universe surrenders ~ Lao Tzu – 6th century, BCE
Empty your mind. Be formless, shapeless. Like water. You put water into a bottle and it becomes the bottle. You put in a teapot, it becomes the teapot. Water can flow, or it can crash. Be water, my friend! ~ Bruce Lee, 1971**
which are a good philosophical summary of my approach to agile adoptions (well, actually life in general ;)
This series of posts is not directly about philosophy, it’s about the day-to-day progress of an agile adoption: The Good, The Bad and The Interesting.
So stay tuned, check back and drop in if you’re interested as this is just the beginning…
* In this series I’ll use the term agile with a lower-case ‘a’ to indicate “real ‘good’ agile” which I’ll explain as we go, compared to “Industrial Agile”, “Consulting Agile” and “Corrupted Agile” which start with an upper-case ‘A’
It’s been quite a while since I’ve posted much, mainly due to a contract which requires me to drive on the M20 and M25 (aka “the carpark” for those outside the UK) and as a result, I just don’t seem to of had the time and energy…
I look forward to getting on something where someone else is doing the driving so I can use my time effectively
Amazingly, it seems like only 7% (4.5 Million) people in the UK use public transport. Given that nearly 1/3 (22 Million) live in the South-East, where transport is generally pretty good, that seems pretty low. No surprise given the number of people on the motorways – I’ll be happy to take one more off them next contract.
So what’s up for 2015 for me and this blog?
For one, I plan to start getting back in to a bit more of a rhythm, both with my posts and the associated (play) work (generally outside “real work”), and I will continue to post based on my experiences – recent and past…
- Lifestyle & Reviews
- Process & People & ScramJet
- Architecture, including Enterprise & SOA aspects
in no particular order. I won’t get in to specifics as much of it is not yet planned, or I’m working on it but don’t want to reveal it until I have enough meat on the the bones so I can be sure it will fly.
- Review of Bob Marshall’s “Thinking Different” happening last year
- Review of the: BMW i3 electric car; Samsung Galaxy Alpha
- Corporate Subversion – in a positive manner of course :-)
and that’s really just the “boring stuff” – there should be some very interesting posts coming as I hit my stride.
I hope you’ve all had a great XMas & New Year break and look forward to some great interactions in 2015!
After a finishing up my current contract, holidays and a bit of Bloggers Block, a chat with John Wenger about humanity and process a while ago has inspired me to do this post that I’ve had brewing for a while… Your first response may be a glib / tongue-in-cheek response “What, humanity and PMs, that’s an Oxymoron”. And therein lies the problem – I feel I almost need to point out that PMs are people too :-) Most of them are trying to do a good job in a probably difficult situation. They have families, lovers, pets: and they’re just at work like you – doing their best…
To tease this apart more, the first thing we need to do is separate the person from the role. With that, we can acknowledge that people are generally the same, so there should be no core difference between a PM and others in an org. Then we have the role – this is unfortunately where distortions can come in. Not only from the role, but the organisation and it’s view of that role which often puts them forward as “Managers”. I mostly see them as “Administrators”, though and I’m not saying this in a mean way – as an Architect (or any other core-IT role) I see them there to help me to build things for an organisation. Sure, they have their plans, but any good PM knows how to work the plan with the people and not the other way around.
In most of my engagements in large organisations, as a facilitator I’ve gotten along well with the PMs personally and professionally and they’ve always helped the project (well, there’s always the exception, but one can say that about almost anything). Strangely though, this seems to be the opposite of most of the “agile crowd” who seem to constantly complain about and want to get rid of PMs. What’s up? Have I just been lucky the last 15-20 years? I think not…
How would you feel if I came in to your work and told you I was a BoingBoing Master and that part of the BoingBoing Approach (tm :) I’d be replacing you, or if you were lucky would turn you in to a BoingBoing Apprentice where you’d have to start from the bottom again and work your way up?
Well that’s the attitude most agile people do! And then they wonder why PMs are so “difficult”…
As I touched on above, I acknowledge that while PM is not an essential role in agile, it can be accommodated. Part of this probably comes from my earlier work with (Iterative) RUP where PM is an acknowledged role. When I progressed to Scrum, it was using RUP Iterations, so again, the PMs were there – helping with Iteration and Project planning, while we ran the Scrums and handed most problems over to them to sort out.
This brings me to my current approach: As I mentioned, I view PMs as “skilled administrators” and “organisational facilitators” who are necessary in in large company. On that basis I help them understand how I can work with them as I’ll help the team focus on their work and maximising it, while they can help communicate this to the wider organisation and help remove obstacles that the team will be surfacing with them. This way, we both benefit, generally doing what we all enjoy.
Perfect? No, but it’s sure better than going in to a situation where you have exist with a powerful and combative “opponent” every day…
This approach also allows for what I’d call a “classic” Scrum/Kanban/… Facilitator, where this is not a full time job (which I can remember in the early days of agile and scrum). The rest of the time, I get to perform a team role (usually Architect, but it could really be any – e.g. (Business) Analyst, Developer, Tester, Infrastructure) which enables me to be deeply involved in the project and therefore not need “explanation sessions” where the team explains what they’re doing to someone who doesn’t really understand.
So is that it? Am I advocating we just sit back and not cause “too much trouble” for the entrenched system? NO! It’s quite the opposite as I’m suggest a campaign for Hearts and Minds conducted with Love and Compassion rather than the “Shock and Awe” campaigns that are often conducted by the Agile Extremists…
Before I get in to the guts of Skramjet, there was a final piece of philosophy that was missing. I couldn’t put my finger on it until recently whilst watching a brilliant PBS program The Buddha. One of the interesting facts I didn’t realise was how The Middle Way or Path was come up with – it was when he was attaining enlightenment.
After his initial life of total indulgence, then his Ascetic phase where he was almost dead (see right) that The Buddha realised that the way to enlightenment lay in between these two extremes:
Neither a life of self- indulgence, nor one of self-mortification can bring happiness. Only a middle path, avoiding these two extremes, leads to peace of mind, wisdom, and complete liberation from the dissatisfactions of life
An Agile Ascetic – well versed in Scrum, Kanban, TDD, BDD & NVC ;-)
THIS WAS THE MISSING LINK!
Most (if not all) agile processes, be they Lean, Scrum, Kanban or whatever assume usually quite a bit of discipline and adherenceto “the process” Don’t believe me? Try telling:
- A Lean / 6 Sigma adherent you won’t Define, Measure, Analyze, Improve, and Control
- A Scrum Master you’re not going to do the 3 questions or have a Product Owner
- A Kanban Kraftsperson you’re not going to limit WIP
In most cases, good luck with that… Does it have to be that way?
What is The Middle Way?
When I did my first official SDLC process training with Rational Unified Process, the 1st rule was “use the process to configure the process”. Unfortunately, many “agile people” don’t do this! They use a Waterfall process to configure an agile process. This, I suspect, is a key contributor to why many Agile adoptions fail. One of the lessons I learnt early on, after my first successful Scrum failure was to let the process emerge. My 2nd attempt was a dream run as we started with sticky notes and tasks – that’s all! No people against tasks and no estimates. The interesting thing is that the team added these two features in the next two retrospectives, which just shows that is you have faith and give control over to others in the “right context”, there shall be rewards.
Today I’m (@RiczWest) starting a new twitter account. It’s called ChangeArc. For those who follow me, you’ll recognise this as my “Blog Name” – so what’s the purpose?
Simple – when I started using Twitter, it was primarily as a bookmarking tool. To some extent I still use it as such, but also for so much more…
There’s one problem though – as I look at a lot of content, that means a lot of tweets, and not everyone likes that, including me! There are a number of great people I’d like to follow, but I can’t because they tweet too much.
To that end, I’m going to start a much lower volume (only a few tweets per day) account which is ChangeArc. So what can you expect apart from less tweets? Extremely high quality tweets that will include any posts I do.
I don’t know how this will evolve, but it will be interesting to see…
“The obligation of any component is to contribute its best to the system, not to maximize its own production, profit, or sales nor any other competitive measure. Some components may operate at a loss to themselves in order to optimize the whole system, including the components that take a loss.”
~ The New Economics, page 100, Dr. Deming
Deming wasn’t alone in talking about “Local Optimisations”, you’ll hear similar things from Ackoff, Argyris and Senge as pointed out by Matt Barcomb in his brilliantly named post: Stop B*tching About Local Optimizations.
Recently, I’ve had a similar realisation as Matt because like any good “radical agilist” I kind-of believed in the “party line” about local optimisations – i.e. bad. There’s one problem though – I have spent almost my entire career doing local optimisations!
Has it all been for nothing???
I’d like to hope not
In fact I think history is littered with examples that show otherwise. Take for example, the legendary Rosa Parks: “the first lady of civil rights”, “the mother of the freedom movement”. If she was worried about “local optimisations”, then she wouldn’t of refused to give up her seat for a white person. If she was thinking like Deming and Taiichi Ohno, she would of said “Oh, this whole bus seat thing would only be a local optimisation, so it won’t really make a difference – I should try and change the system overall rather than wasting my time here”
– Thank goodness she didn’t!
In some ways, we in the “real (software) change movement” are engaged in a similar battle – it’s the one that has always been waged and is probably a fundamental principle of the universe:
Control vs Self Organisation
There will always be “forces”, some of which are immutable and others mutable, that will be implicitly working against us. Just because we’re doing something in the corner of a corner of a corner ^ 10, does that mean we should give up?
and that’s where my call for heroes goes out – “our world” needs more heroes! Not people that are going are going to give up or try their absolute best because some other people said something about local optimisation…
Rosa Parks was actually one of many – others had taken similar steps, including Irene Morgan in 1946, Sarah Louise Keys in 1955, and the members of the Browder v. Gayle lawsuit (Claudette Colvin, Aurelia Browder, Susie McDonald, and Mary Louise Smith) who were arrested in Montgomery months before Parks. Your effort at introducing or changing whatever it is may not “succeed”, you may be a Mary Smith, or you could be a Rosa Parks!
Either way, you will of been someone who participated in a revolution and you can be proud of that – I bet Irene Morgan’s family, friends and community are – if you google her you’ll see there are still people that know she helped to progress a cause also.
Skramjet is designed to be done by hereos, or hopefully to help people become one because hey, we all want to make the world a better place :-)
Most people are probably familiar with Cognitive Biases, the things that can wreak havoc on people, relationships, teams, organisations – really anything where people are involved. If you’re not, you may want to read Cognitive Science: An Introduction/Biases and Reasoning Heuristics. To summarise and refresh your memory, here’s the list from that article*:
- Framing: Viewing a need in the real world as a “problem” you can work on solving Mistaking your view of the problem for the real need.
- Anchoring & Adjustment: Assuming a starting point and thinking about adjustments from there
- Status Quo: “Business as Usual”, “If it ain’t broke, don’t fix it”
- Sunk Cost: Treating the resources already spent on one alternative as an estimate of the resources you’ll have to spend all over again to start a new one
- Confirmation: If you’re leaning towards an action, see if you can prove it’s a good one
- Cognitive Overconfidence: Decisiveness & Refuseal to be haunted by doubt
- Prudent Estimation: “Conservative Estimates”
- Risk Aversion: “A bird in the hand is worth two in the bush”. Avoid probability of ruin
- Selective Perception: Knowing what you’re looking for
- Recallability (’’availability’’): If an idea doesn’t fit in with the obvious data, it’s surely suspect
- Guessing at Patterns: Quickly spotting the trend or the big picture
- Representativeness: “If it looks like a duck and walks like a duck and quacks like a duck”
- Most likely Scenario: Avoids wasting time on possibilities that probably won’t happen
- Optimism: Go for the gold!
- Pessimism: Avoid unpleasant surprises
It’s pretty easy to see how we all, personally and organisationally can fall in to these traps at varying degrees and frequency. I’d add one more, which I think is often a risk on software:
- Least likely Scenario: Obsesses over a scenario which is highly unlikely and probably won’t matter anyway
which is a tricky one. Part of our job is to explore the realm of exceptions in IT as anyone can design a system that works for “the happy path”. The real skill is designing a system that is “robust” and can withstand unusual paths. This is not the same as exploring every scenario, no matter how unlikely. A robust system should be able to handle error paths that no-one has even considered. To me, that’s where real Architecture and Design come in, but that’s a whole other post.
Back to the Skramjet context, I think it’s obvious that you need to be aware of (and hopefully correct) your own cognitive biases, but I’d add that the team also needs to be aware of it’s and the organisations cognitive biases. As people, with sufficient motivation we can change quite quickly, for organisations this is more difficult because of the “momentum” and the “Status Quo” bias that seems to exist in most organisations, even more “progressive” ones. This is not an easy path and to tread and to do this we need some heroes, so dust off your cape for the next post ;-)
* with a bit og googling you can find even more comprehensive list! Personally, I think these are enough for most activities