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…
This post is the result of a tweet to @flowchainsensei about a month ago about Scrum projects, where I said I really should blog about my experiences in “Agile Land”, so here it is:
My “Agile background” began back in 1997 (yes, I know that was technically before Agile began) when I started reading about iterative development and was on a project where the management was getting a bit “edgy” about the project and its delivery. It was a large organisation, with too much money and a lot of politics. At the time I was the lead for a sub-project which was responsible for the back-end interface and I recommended to the overall lead that we set up a server and do weekly or bi-weekly deployments on to it, so at least people could see the good work that was being done. Unfortunately, he was a “waterfall guy” and completely ignored the suggestion…
In the mean time, I came in to contact with the “useability people”. They had the whole setup (which was unusual at the time) with multiple cameras, mirrored windows etc… I didn’t use that though, instead using one of the early Java GUI builders to rapidly prototype interfaces which I then printed out (their (great) suggestion) and talked through it with them. Yep – that was paper prototyping and it worked well. Eventually after a number of major re-designs and total restructurings we ended up with something that seemed quite reasonable so we started using that for our weekly sessions. It was working against a set of “Mock Object” interfaces (we used to call them stubs ;) that people could play around with, so we’d go through various scenarios.
In the background, I had the team of 4 working on the connectivity to the main system as we knew the information that we needed to maintain, just not the visual interface and we adjusted things as we went along and sync’d with any minor updates to the data model, which was against an Object-Oriented (oops, NoSQL nowadays) database. Finally, we ended up with an interface that everyone was happy with. In fact the Users said it was the best internal maintenance system that they’d ever used! For me, as a contractor, it was off and on to the next big thing as I’d built and successfully deployed my part. Unfortunately, for the project, it was cancelled a few months later as they’d never demonstrated much of their (front end web) functionality to their users and the whole project was canned only a few months before they would of finished!!! That’s in a 2 year project, because they thought the waterfall model was fine – what’s wrong with demonstrating a 2 year development project after 2 years? ;-)
For me it was a huge lesson – there seemed to be something to this “iterative development” and I was curious . . . I can’t remember exactly what I was reading around then, but I think it was mostly around the RUP and I remember Royce’s book on “Software Project Management – A Unified Framework”. About a year later I was bought on to a project that had a fixed deadline, which was going to make or break their funding. People were just generally freaking out because it seemed out of control and no-one really knew what to do. Using what I’d learnt so far, I suggested we write down all the product features that had to be built and prioritize them, paying attention to put the “risky” ones first (as that’s a key rule for RUP). We had about 2 months and I think we had about 30 product features. Funny thing, is I remember keeping the list on a whiteboard where we’d cross them out when done and make any key notes regarding them. This was about 10 years before I learnt about Scrum – the only thing we were missing was the moving of stickies, but still it was an “information radiator”. Apart from the first week planning, architecting and prototyping technologies, for the most of this project I was really a coding architect. The other thing we did was weekly demos (it just seemed natural as we only had two months to complete this, so even a monthly iteration wouldn’t of made sense) and discussed the progression of the project and adjusted any estimates for the features as we progressed. In the end, we built about 25, but obviously the remaining 5 were really “nice to haves”. Another job successfully done and on to more projects, but you’ll have to wait for the next Iteration of this to hear about that . . .