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.
It’s amazing how time flies as it seemed like yesterday, but it’s now been 8 years. Must be that old adage as I’ve certainly been having a lot of fun here. When I’d finished my last post on this, Agile Baby Steps – Iteration 3 (2 & 1), I’d finished up in Australia and moved to the UK. By coincidence it was where my Agile journey got a bit of a Turbo-Boost
After a few months of being a tourist and “kinda looking for work” I finally ended up in Andover which is a nice “little” market town just over an hour out from London working with Lloyds TSB. The role was initially as a Service Designer, but due to some enlightened management there I was able to introduce Scrum. Remember that in Aus I’d only just used it with a Scrum Master to integrate with Rational Unified Process, so I’d only just started down this route. To do a proper implementation we ran training with about 15 people and a Scrum Alliance trainer. This was the first time I’d been exposed to “pure Scrum” and it absolutely blew my mind! During the time there we rolled Scrum out across the various projects in the Business Process Re-engineering programme, even scaling it. Probably the key reason things went so smoothly was that the programme was Agile in it’s BPR activities and there had been a Lean effort in the past. Also, the programme had the concept of “Daily Prayers” that were like a Scrum, only unstructured so Scrum was really just a refinement (as the DP’s weren’t scaling) and extension which made sense as the program was just starting.
Next along was TNT and I had no intent originally for any process work as I was just there to do some performance tuning and architectural refactoring. After a few weeks though, it emerged that the team they were building up was having problems keeping track of things. One of the lessons I learnt from the previous engagement was not to be too prescriptive, so I said I knew a simple technique that could help. I told them the basic rules of Scrum and had Backlog, Doing, Done but did not tell them what to put on the stick notes! In the beginning it was just the task but after the first retrospective someone suggested adding the person responsible – “great idea” I said ;-) After the next retrospective, they suggested adding time! They’d invented Scrum Sticky Notes! I think this is a great example of what happens when you trust people and let them own “the process solution”.
Even better, was the fact that this was integrated with their existing Project Management process as at the end of each sprint I gathered up all the sticky notes and gave them to my enlightened PM who then did whatever she did with Gantt charts, reports etc… As the Scrum Master, I worked hand-in-hand with my PM and it only took less than 1h per day for me as the PM handled all the issues. Oh, but it didn’t stop there – we had an offshore team also. Again, thanks to enlightened management, we had a number of devs from offshore being rotated in and the timing was perfect. After a few weeks some of them went back to India and because they knew the process (it was theirs after all) Scrums were quickly up and running over there. We’d then have a teleconference Scrum to sync everyone up which worked a treat.
The interesting thing about the TNT implementation was that the “pure Scrum” people would be frothing at the mouth as we’d probably broken a number of “rules” – e.g. estimating in time, rather than story points, bananas, etc… Yet, I’d regard this as on of my best Scrum implementation so far as we’d cracked two of the classic problems that people have:
- Working in a more conventional Project Management process and
- Working with offshore teams
Most of this was not to do with me, it was obviously the management chain running through 3 levels who all supported this as what they’d been doing obviously didn’t work as well – they were ripe for change.
After a “pure SOA Architect” role I then ended up in Agile Land, this time at Yell (RIP ;) which was an Agile environment – and I really mean this! They were running a whole BPR programme using Agile with some of the best coaches I’d worked with. Needless to say, I learnt a lot about the subtleties of Agile and was even able to contribute at the end in helping develop a more scaled version of agile based around Dean Leffingwell’s Scaling Software Agility for the entire enterprise. One of the key lessons though was that you can be “too agile” – at one stage, as an Agile SOA Architect, I was continually (every few weeks) altering service designs for the Implementation teams. In the end, they (nicely) screamed “Enough! We can’t absorb this much change!”. As a result of a retrospective workshop we did on this issue, it was agreed that there should be a bit more up-front work and broader investigation in order to minimise the change to the designs they were implementing.
Coming off the pure agile role, I landed in what was at one stage one of the largest Agile projects in Europe at British Gas. Due to it’s scale (we’re talking thousands of people) there were some waterfall elements to it, but the base rule was that wherever Agile made sense, we’d use it. Again, more amazing scum masters and even some of the ones from Yell. For me, this role followed on nicely from Yell to a place that had implemented Agile at scale. There has been a lot of debate as to how Agile their approach was, but from my perspective, I was at a transition point from Waterfall into Agile and it was working, but it wasn’t easy. There were some great features though, especially where they’d applied an “Agile Mindset” to a “Waterfall Mechanism” which resulted in a more people-centric and communicative process.
For a while though, I’d been reading and learning about this new “Kanban Thingy”. It certainly had an appeal and I realised that I’d actually been using some of it’s practices in Scrum, so I decided to start injecting some Kanban tools in to Scrum (this was before I’d heard of Scrumban). I then managed to use this approach successfully in two Enterprise Architecture assessments for global organisations topped off by an Agile implementation of Agile Governance for SOA a few years ago.
As I went through this beginning of my Scrumban phase (which I’m still technically in) I had a dawning realisation: there is quite a disconnect between the work I do in Solutions, SOA and Enterprise Architecture (where I’ve used Agile, Scrum, Lean and Kanban most of the time over the last decade) and what I was reading and hearing about in “Cool Agile Land” (that’s where all the cool hipsters are xDD’ing ;).
It was then that I realised that there was just as much of a need in these areas – the problem was that this was not where the majority of “activity” was happening and that in general the mindset was more waterfall. There were however, some mavericks (who both backed and worked with me) like my self who believed that there was a middle path – we could use Agile techniques in Architecture in Big Organisations without conflict and hopefully start a revolution…
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
So far, I’ve only given you the 100,000ft view (as one would have with a Scramjet :)
A personal exploration of the use of Kanban, Scrum and Lean Principles to create a Service Oriented Architecture within a large organisation.
What does that really mean though? Why should you keep reading or even tell your friends? Like anything I do, this will be iterative, lean and hopefully have a good feedback cycle (it’s appreciated whenever you want as a comment here or tweet to me).
My immediate plans are that there will be two arcs:
- A personal narrative about Fellowship and hopefully some use of Antimatter in working with and transforming a team*
- Notes and guidelines around the use of lean/agile that I observe or think of along the journey
Anything could happen as I have no real plan for this except for the vision of a Skramjet
*Disclaimer: Any resemblance between the company, team and any people described in this narrative are purely co-incidental ;-)
A scramjet (supersonic combusting ramjet) is a variant of a ramjet airbreathing jet engine in which combustion takes place in supersonic airflow.
A Skramjet (ScRuM, KAnban, lEan, Just in Time) is a process in which work takes place in a SuperPersonic flow state environment.
A personal exploration of the use of Kanban, Scrum and Lean Principles to create a Service Oriented Architecture within a large organisation.
These second day of the conference ended up being just as amazing as the first, building nicely on it. As I’m doing this on an iPad I can’t link to the other posts, but they’re just below
A great intro to how someone used Kanban in their organisation, warts and all with both cards and JIRA! Most of the common models and measures were covered with some great bits of advice like setting the WIP limit low on areas where you shouldn’t be doing too much so you get early indication if your system is putting too much work in to them.
Looks at Knowledge work on the assumption that humans are _not_ rational, which is not the assumption of many approaches. In this new and realistic light it is shown that the main value is not so much even the people, but the _relationships_ between the people. Mentions a whole interesting area called Social Capital Theory which seems worthy look.
Andy starts off with the conventional definitions, principles and methods in Kanban and strips them to the core, so you can even tweet them!
Change your viewpoint (lean flow paradigm):
See work as flow
Change your mindset (foundational principles):
Start from here and improve
Change your process continually (core practices):
Make work and policies visible; make validated improvements
This was the Big Ticket presentation of the conference from Jim Benson about his new book, of the same name. I think it was a great summary of where “The Leading Edge of the Post Agile (Lean/,Kanban?) Industry” is. It was certainly good enough to buy the book straight after ;-) For me, the takeaway quote was
“There is no recipie for success. There is a recipe for not likely failing”
What can I say? Hakan Foss, Lego – a winning combination. Hakan is a brilliant presenter and educator and for me personally, this was probably the best session for me personally as it consolidated so much of what I’d learnt during the conference.
This would of been better in it’s (originally) earlier slot as it was a quite dense and demanding presentation on forecasting (estimation+probability) for work by an absolutely brilliant Aussie :), Troy who brings a rigorous, mathematical and evidence-based approach to what is so often a “black (box) art”.
There were some great drinks after the conference and I may do a quick entry on these a bit later… Overall, I must say that Lean Kanban UK was an amazing conference – perfect if you’re a newbie or early in your journey of these methodologies as it will provide a boost to your existing experience &| learning,