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.
About a month ago when I returned from a month in Aus, I had a few things to do in a day which combined to get me thinking about simplification as it seems that despite all our wonderful “web technology” (what are we on – 3.0?) we seem to reaching the stage where we are making things that worked about a year ago complex and harder to use for no reason! For illustration, here are the two web based tasks I had that day:
- Reserve an item in store at Curry’s
- Reset a password for a Google account
Sounds simple enough? As mentioned, a year ago each of these would have taken max 5 mins each. Instead, each took 1/2h! What’s going on???
1. Reserve an item in store at Curry’s
Sounds so simple, doesn’t it? Last time I did it, it was – you clicked reserve & collect, entered your postcode, selected a store, input your name, email and that was it! You’d get a confirmation email with reservation number and the item was held for 24 hours for you. Just go and pick it up :-)
What went wrong this time? You click Reserve & Collect and are given a message that it’s available for Reserve & Collect! Really? I’d hope so, but my money says there are some items where you click on this link and are told it’s not available for R&C…
Anyway, I persisted and was now asked also for my phone number (which I input a false one for – it’s wasn’t relevant) – why? After declining the privilege of being contact by Currys and various 3rd Party organisations I then tried to reserve the item – nothing, nada, nicht!
OK, I’ll try phoning the number on the web site. After being led down 2 IVR blind paths I gave up and drove to my local store. I noticed that there was a B&Q (hardware store) nearby and went there first, so I took some “consumer action” – they had the item and I was happy, but after a long and tortuous route I would have preferred not to take.
2. Reset your Google Password
In the afternoon, I was doing some “IT Support” for my 80 year old neighbour and he forgot his password for Google. “No problemo” said I (naively). I then went to the appropriate link where you’re asked for the email address and put it in. Last time I did this, you got a “check your email” message and off you go. Now, I got a security question (his cars numberplate) – ok, they’re beefing up security a bit – that’s good…
NO IT WASN’T! They’d beefed up security so much that we were asked another 5 or so questions about which Google products he used, when he started using them and even how much he used them! Although we were told that the system would allow for some mistakes, we were both sweating as we attempted to prove that Ken was indeed Ken!
Unlike the store, we couldn’t just go somewhere else, so after (what seemed like) 10-15 minutes looking up various bits and nervously waiting for Google’s assessment of his “Ken-ness” we finally PASSED – WOOHOO! I now have a backup record of his password, as neither of us want to go through that again…
What just happened? My two consumer type actions on the web in one day were a disaster! They wouldn’t have been a year ago…
Both systems seemed fine, but have now been bureaucratically engineered beyond their intent and optimal usability. If this keeps going on, we really will have computers like in Brazil
After too many years working for such organisations, I can take a pretty good guess at why both “enhancements” were done:
- The original R&C was probably a side project which worked great. But either the great Hammer of IT or EA came down and demanded compliance with their CRM strategy. This would have demanded more information be collected so they could “engage” aka annoy their customers. The system was obviously not fully working and the IVR, well that was probably a disaster (as are most) from the get-go.
- Due to increased identity fraud etc, there is clearly a need for increased security, especially around password resets. Unfortunately, some CRM / Security people got involved and thought of a whole bunch of questions which only they could answer. Us mere mortals never stood a chance :-(
With quite a bit of Solution Architecture experience, I’m going to put my SA hat on and suggest some potential low impact solutions to both these ?
- If it ain’t broke, don’t fix it! This system should have been left as is as it was the minimum usable implementation. “But we need to populate our CRM system” you may say. Well, in that case do it, but progressively. Give people the option and motivation to give you information and respect their choice if they choose not to (which is a subject of a whole other post).
- Stop being so damn “smart”, because it’s not really! Google have a history of only hiring the “best and brightest” and this is one of their products, so no real surprise here. There are so many dimensions of information that Google have on people. Create questions that people (and not machines or people who are like machines ;) can relate to. Use information such as IP’s, location to reduce the need for the “20 genius questions”.
There’s a common theme here
– both solutions were supposedly “improving” a system. Both had a common problem of an over and mechanistic engineering of the solution. Maybe part of the problem is the implicit “continual growth” in capitalism. Why can’t we sometimes just leave parts of a system as they are because everyone is happy with them?
Furthermore, if we do have to change something, how about we do it in a humane way? As the Antimatter Principle from @flowchainsensei would say, being sensitive to the needs of the real user rather than some abstract entity cooked up for the convenience of analysts, technologists or even worse, the business or their CRM system!
If you are ever in the position of dealing with a system which interfaces with people, then assuming you want it to be “nice” ask some questions like this: “Would I personally want to use a system like this?”, “Would my partner and children want to use this system?”, “If the CEO of the company used this system” (which they rarely do, but that’s another problem ;) “what would they think?”
If you’re in the position of allocating funds / priorities for systems, you may want to ask questions like “What is this doing for our customers?”, “Is it making their lives better / easier?”, “Politics aside, is this really the best way to spend the companies money?”, “What would happen if we didn’t do this change?”, “Is there something else in the organisation which could make better use of the money if we didn’t do this project?”