Firstly, this post is not really mine, it’s more an “ad” for a workshop coming up in the UK during the Software Architect Conference in London in October presented by the legendary @RuthMalan who was behind the Visual Architecting Process
I’ll be going to the conference and Ruth’s workshop – if you’re in to Architecture , you may want to check out the conference and workshops. Now, over to Ruth:
Abstract: We will spend time with the usual suspects — (re)factoring, dependencies, naming, forces, trade-offs, mechanism design, system and component boundaries and interaction surfaces… And some sketchy ones — making the system design visual and drawing people in. We will take some silver bullets* — relationships of goodwill and commitment to objectivity — to heart, and be playful, exploring (the interaction between) the various facets of architectural design:
- strategic and structural significance: identifying strategic outcomes and defining challenges; design of system capabilities and system structure; system qualities and mechanism design;
- decision scope: decisions at broader scopes (system, mechanism, service) and decisions at narrow or local scopes (units) considering intentionality and emergence;
- timing of decisions: clearing the fog of uncertainty/putting ground under the feet and the “last responsible moment”, iteration and evolution
And we will take our fallibilities, biases, foibles into account. How? That is indeed it. Our focus will be on how. We will use creating a draft (set of views of the) software architecture to situate our discussions and practice system thinking and modeling, strategic thinking (understanding what is shapingly important in the user context and business and technology space), and design improvement strategies. Our orientation is to co-creation of systems that have desired structural integrity properties, including resilience, but also design integrity and dynamic unity.
Our goal is to surface key matters of architectural judgment, drawing out myths and misconceptions, and sharing, positioning and connecting useful conceptions, strategies and techniques, and laws, principles, heuristics and other guidance.
Pre-requisites: The main prerequisite is to be open, playful and engaged. I facilitate moving through really vital shifts in perception and put useful tools in the architect’s toolbelt, but we have to throw our lots in together, co-create together, playing when it is time to play — to explore and get options on the table — and, when it is time, getting serious and making strategically significant decisions the group coheres around.
About: Having worked in the software architecture field since the mid-90’s, Ruth Malan has arguably played a pioneering role, helping to define architectures and the process by which they are created and evolved, and helping to shape the role of the software, systems and enterprise architect. She and Dana Bredemeyer created the Visual Architecting Process which is recognised by the Open Group and emphasizes: architecting for business agility, system integrity and economic, technical, organizational and environmental sustainability. Creating architectures that are good, right and successful, where:
- good: technically sound;
- right: meets stakeholders goals and fits context and purpose; and
- successful: actually delivers strategic outcomes.
Translating business strategy into technical strategy and leading the implementation of that strategy. Applying guiding principles like:
- extraordinary moment
- minimalist architecture
So we can Be Agile and Create Options…
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…
“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
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?”