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…
I’ve been meaning to write about for a while about my first serious use of “Kanban”* and what’s more, it’s a usage outside of the standard patterns we hear about, mainly programming. I was working for a high-end niche consultancy to a global corporation doing an assessment and some pattern harvesting that had an extremely tight deadline. We had a small team (me and two other people) who were all highly trained and proficient, but there was one problem – the deadline, planning and tracking of our activities. We also needed a “process” that was not a Process – enter Kanban!
It just felt intuitively right – even though I’d never “seriously” used it. I had played around with Personal Kanban and I sensed that if we used no process (ie CMM1 / Ad Hoc) then near the end we’d find out we forgot things or didn’t adequately cover some risks, some of which would manifest and it would all end in tears. None of us wanted that, so I proposed to my colleagues that we use Kanban – freely admitting that I hadn’t used it fully, but that I was a Certified Scrum Master and had “Agile” experience of over 10 years. I added that we’d be doing weekly retrospectives and that if they thought it was not an effective use of our time, then we could just stop using it. On that basis I had agreement and some buy in, but we’ll get to that later…
To start off with, we did a brainstorming session for an hour, went back to work (we had no time to waste and knew initially what to do) then spent an hour at the end of the day making a Kanban
I’ve obviously had to blank out some information for confidentiality, but hopefully this is readable enough to show our thoughts, process and the fact that this was a very high level, i.e. typical EA, piece of work. One thing to note is that at the top we had “BACKLOG” but realised that we were existing within a Project Managed environment, so we had to have some sort of plan which we of course did with sticky notes ;-) Our Project Manager (who had about 5 other streams of work going on overall) was very happy as we had not only given him a realistic plan, but if he or anyone else who was interested wanted to know what we were really doing, it was all there at any time.
Also, you can see that on the right, we have a fairly typical Kanban / Scrum board and in the left is an open area where we started to group things which we’d eventually put in to the backlog. Again, the emphasis was on spending a minimum amount of time to structure and track the things that were important initially, knowing that we’d be tidying this up within a week. You can also see a bunch of stickies in the bottom left. These were things that had come out of our brainstorm, but were not currently important and that we did not have time to properly analyse and group. If you look carefully, there is a task in stalled for me to arrange sorting these out.
With that, we were off and running, with a plan which “the management” was happy with and enough structure to know what to do once we had contacted the right people in the right countries, for the information we needed. We monitored this using a spreadsheet as it was a simple process, would not take long and proved useful to show which countries were responding and in scope and which were not. And as you can see above, we also had an IRA log with sticky notes :-)
* Note: I’ve said “Kanban” as in the time since, I’ve realised there was a lot of things we didn’t do, more on that in the Meta Retrospective
My last post on the topic (Let’s not Travelodge software development) may have seemed anti-Lean/Agile. It’s actually the opposite! It’s because I’m so passionate about them that I wrote that post to try and get people thinking where we are going with all this. I used Travelodge as an example of Lean / Agile taken too far, and as I’ve hinted, I see this in my work occasionally… So what’s the answer? Not surprisingly, Lean and Agile, but from a different view.
As I hinted in that post, personally I’ll be doing B&B’s again, and it’s the answer in so many ways. How? Do you like the B&B in the above photo? You should – it’s rated the number one in Horsham, only gets 5* feedback on TripAdvisor and costs about the same as that Travelodge I stayed in! It’s only a few minutes out of Horsham, but it would easily be worth a cab fare extra.
If you follow the analogy back to Software, I’m “The Business”. I have a need, accommodation that I need to solve at a reasonable price. Given a choice in what seems to me an unknown field, I go with a brand but am disappointed as I find a product which has been BadAgiled out of existence to the “threshold of revolution” – i.e. it’s quality is just good enough to stop me cancelling the contract (hey – my ego’s at stake here).
This is where “The Real Business” and I split. I know I made a mistake and am not afraid to publicly talk about it, acknowledge it and learn from it. TRB though have a (probably quite large group) ego though, so they can’t admit that they were wrong – there’s so much at stake on the table… So, they do what Einstein defined as insanity – the same thing, expecting a different result. Sometimes they’ll try a different outsourcer to give the illusion of action, but they’ll still have the same process and flawed thinking in place so I don’t need to explain what will happen.
Back to our B&B’s – good one’s are mostly quite Lean and Agile, for the simple reason that they directly relate to the owners income, and that the owners generally want a reasonable lifestyle, which means not spending too much time running the B&B.
Enter a Lean / Agile process!
If you watch the way a good B&B works, they have developed their own systems, limit WIP (especially for breakfast), have good feedback loops and quite often have Information Radiators. Their processes are tailored for their establishment and aligned to their personal brand. Looking at the bedroom shot, you can see that the owner, house and brand are all aligned – it’s the truth.
Now, let’s remind ourselves of the TL equivalent. Is there any comparison? @JenniferSertl made a very good point regarding branding and process, namely that Bic and Mont Blanc could both use Agile / Lean successfully with their own brands, which is correct.
However, if we look at part of Travelodge’s Mission statement:
The reason that more people don’t stay in hotels is simple – they just can’t find a good quality hotel where they want to stay, at a price that’s right for them. Travelodge’s objective is to make hotels available to everyone by consistently offering our customers great value hotels where they want to stay.
So to follow up the second paragraph, to me (totally subjective) that hotel was not great value. To be great value, would of been £40-50 and I’m sure they still could of made a profit. Given what you know now though about B&B’s in Horsham, would you really want to stay there?
NOTE: One thing I should note is that the staff at the Travelodge were very helpful and positive and really turned what could of been a horrible stay in to a tolerable one – that wasn’t due to them though, it was due to poorly gathered requirements, using a bad process to transform them in to a bad “architecture”, carefully nurtured by a total lack of feedback from staff and probably guests to form a distorted implementation of their brand. Sound familiar? ;-)
Finally, to answer Jennifer’s point re pens – I don’t have a problem with Bic making pens using Lean / Agile or any other process. What I do have a problem with is Parker making them L/A and allowing(?) the mechanism to distort their quality to those of Bic or even worse!
As I tweeted last night, I’m currently staying at the Travelodge for some business. I must admit that I have fond memories of it as a child. Well, there’s another childhood perception blown away! Or not, as it was 40 years ago and I’d like to think they really were better then.
Anyway, to now when I checked in. The first thing that hit me was the smell! It was kind of like mouldy carpet mixed with cheap perfume… I went to the front desk and asked for them to check the room and was told it was the “Travelodge Smell” and perfectly normal, so stayed there. The funny thing was that I managed to get another room today and met the cleaner. I asked her not to “Travelodge Smell” my room (which now doesn’t smell i.e. is quite normal :) – she said no problems and remarked that it smelt like “Old People’s Home” to her anyway. How did they get it so wrong?
So, to the main subject, which is software and process. When I woke in the morning I was thinking how they must of worked out the absolute minimum that people would tolerate: soap that was mostly not soap, toilet paper that was cheaper than cheap, minimum cheap furniture and shelves made from MDF with the tackiest faux wood grain pattern plastic veneer…
THEN IT HIT ME! This was an Lean / Agile hotel room! The customer was not me, it was a corporation that wanted to maximise profit. The only thing they cared about was that I didn’t walk out, but couldn’t give a crap if I enjoyed my stay. How could you in a room like this? Talking with a colleague who was a local about this, he remarked the this place had just had a fit-out, which would explain the amazing space in the rooms. They were built for a previous era, but that had all been rationalised in to a cheap, sterile “sleeping place”. Unfortunately for them, I’ll never book Travelodge again – I normally stay at B&B’s, but fell for a brand that probably decayed a decade or more ago.
So this is mostly what I see in my work – things going to the lowest bidder, supposedly expending the minimal possible effort (but that’s a false economy) to achieve the minimal necessary solution (that’s usually less than adequate) in the minimal time (but that either slips or crucial features are thrown out) with the maximum quality (yeah, right!). But it’s not bad enough for most people to leave whoever it is. They tolerate it because the “competitors” probably have similar crap anyway.
After this rather extensive but passionate rant, I ask the question : “Where are the Quality Hotels in Software ?” What are the Mandarin’s, Four Seasons, Andaz, Armani, Bulgari and Park Hyatt? Whereas you can easily find quality hotels the world over, can we do the same for Software? Apart from Apple, who else comes to mind for quality software? Yes, there are other places like the good ‘ol Aussie Atlassian, but it’s a struggle… Most software for brands is average and probably heading towards Travelodge – is that what we really want?
PS I’m well aware of Agile / Lean practices in theory, but I’m commenting on the reality. Your experience may differ and more power to you if it does! ;-)
A recent article and discussion got me thinking about egolessness. It was when I was studying at Uni that I was exposed to “egoless programming”. It certainly makes sense as when you’re at Uni, unless you’re an egomaniac, one cannot help but realise how much there is to learn. And therefore how much you don’t know…
Once your in an “egoless space”, the benefit is of course that it becomes easy to talk about the strengths and weaknesses of a program, architecture, process, whatever… It’s just like critiquing a piece of art in a gallery.
In the contract I’m currently in, I’m lucky enough to exist in a relatively egoless team. We have leaders who are quiet, purposeful and supportive. My fellows are all of similar ability, with skills in different areas and we seem to complement each other nicely. There’s obviously enough overlap so we can critique each others work, but no one has their ego in it. We’re all on a journey to learn and grow!
As a contractor I realise that this is not usual at at the moment am just relishing it – like a refreshing dip in a mountain lake
For this next part, we now enter in to the .com boom where I was engaged to develop XSIQ, a hybrid media system for the education of schoolchildren. This was just on the edge of the Internet revolution, when we were still using modems and broadband was non-existent, with the closest thing being ISDN phone connections for the fortunate few. As a result, whereas today you’d just do this as an online application, due to the bandwidth restrictions at the time, the material would be contained on both CD and the Internet, which made for quite a complex system that resulted in patent applications. Again, I used iterative development with a small team of around 5. We were closely engaged with the VP, who I quickly taught to read Use Cases so we could talk with him about our high level requirements. We weren’t doing Scrum, but we did:
- Have a “demonstration server” that the VP and other management could use at any time – even the CEO used it and would sometimes give us feedback
- Do iteration planning and had “cycles” that lasted 1-2 weeks
- Get together pretty much every morning to talk about what we were going to do for the day
- Pair up to program or meet when necessary to work through any tough design problems
The deployment was successful, reliable and never had any performance problems. It was also on time and budget – it had to be as there was a national advertising campaign linked in to the whole thing!
Being a contractor though, I was off to the next big thing, which was developing a publishing system for Encyclopaedia Britannica, that involved a lot of Flash and was a lot more static than the XSIQ system. The project was started, but slowly flying off the rails, so the first thing I did (as the Technical Architect) was ask the PM (who was pretty young and inexperienced) if he minded if I re-cut his plan. To his credit, he said yes and about a week later, we had a plan with iterations (of about a month). Around this time, I came in to contact with Feature Driven Design from Jeff De Luca, which certainly helped achieve a successful implementation of the the project. All this was done in the context of a fully traceable and round-tripped design modeled in Together/J, which enabled me to do my “real job” – that of a Technical / Application Architect.
After a quick trip back to XSIQ the .com crash happened and it looked like all bets were off. Luckily, there were still a number of smaller companies doing some very interesting work, one of which was Jumbuck, who were only just starting their efforts in the Chat space using WAP (remember, this was 2000 – oh how quickly things have changed!). They had developed a prototype, but needed to take this to a commercial level for deployment to a major Telco in the United States. Due to the collapse of XSIQ I was then able to nab one of the best developers I’ve ever worked with to join me in this aggressively time-boxed task (2 months). Again, being “pre officially agile” we decided to go with what we knew, which was iterative development with a “cycle time” of a week. After a quick week of “drains up” (and some refactoring of some low-hanging code) on the existing code (which was totally non-scaleable) we were then able to come up with with a system that not only performed to a level so the guy could get his funding, but also to a level that we bought down the WAP gateway infrastructure of a major US Telco!
With the .com crash – I’m not sure how it happened in US, but in Australia it was more a “wind down”. It’s not like there was no work the next week, it’s just that there was less and less of it for fewer people. Luckily, as a coding Technical Architect, I could pretty much turn my hand to anything and the last “.com” era contract set the scene for what was to come. The company was WebM3dia and the project was using Flash with Web Services, before it was even out! Mike, the programmer from the previous project had run across these people and bought me in as the TA, but I ended up doing more than that. Technically, it was my first exposure to JBoss, which I did quite a bit of work with later and as mentioned, we were hooking it up to Flash before it really had Web Services capability to product one of the most amazing email and productivity apps I’ve ever seen! These guys were whizzes with flash and everything was pseudo 3-d with folders that “exploded” out your emails, stacks of items that compressed and expanded like accordions. Boy it was cool, but there was only one problem – no one really wanted it, plain old boring outlook and web mail was good enough.
It was the path to the slow death of WM that was interesting for me as I did two other things – I wrote about 150 pages of requirements for the system using Use Cases (my one and only time as a “real” BA) and I did some work with their development process, which was the really interesting thing. WM had a quite mature, “Agile like” process for doing their creative work and with their new predicted direction, wanted to incorporate software builds in to it. Using my knowledge of RUP, it seemed to make sense to incorporate an iterative approach to software and have client engagement as after all, that was what they did with their creative and advertising work. The actual process itself was graphically beautiful too as one of their lead designers had worked on it, so I just reused all the graphic elements for my extensions. I wish I had a copy of it somewhere, but like WebM3dia it too is lost in the sands of time. I had however gotten the “process bug” – I think I’d finally drifted in to the realisation that to fix the problems I was getting as a Lead / Architect it would be worth it to get a bit more serious as you’ll see in the next part…
PS Missed the first part? Read Agile Baby Steps – Iteration 1
So I’ve probably spent a bit too much time over the weekend looking at “Hitler Bunker Videos”. If you’re not familiar with them, there’s a classic scene from the movie Downfall, which strangely enough is about the last ten days of Hitler’s reign. There’s a huge community doing subtitles about various subjects over this scene (just Google). For my subject, I chose one close to my heart – SOA Architecture and Governance. Have a look, but it does have some swearing in it (which is pretty obligatory in HBV’s):
I suppose the other thing I should note is that my current contract is great and that the work I’m doing there is nothing like this or in that sort of environment. Also, I have tremendous respect for Thomas Erl and Gregor Hohpe, using material from them in much of my work. The video is more a compilation of the worst behaviors and attitudes that I’ve seen over the years I’ve been involved with SOA, Governance Committees and Senior Stakeholders ;-)
Finally, if you are interested in doing you’re own HBV, then the best starting point is this classic “Hitler and Friends Explain How to Make a Hitler Parody”
and that’s pretty much it! I did mine on a Mac and the instructions are pretty much the same but using iMovie. I put mine up on Vimeo as YouTube will give you a warning because they can match the clip to the movie and they’re pretty evil anyway. At one stage they did threaten to take down all the HBV’s. There is no problem with posting these though as something like this constitutes “fair use”.