Tagged: enterprise architecture

Welcome 2015!

London Fireworks 2015M25 Carpark

It’s been quite a while since I’ve posted much, mainly due to a contract which requires me to drive on the M20 and M25 (aka “the carpark” for those outside the UK) and as a result, I just don’t seem to of had the time and energy…

Javelin TrainOh, how I long for those lovely trains, and will never complain about a 30 or even 60 minute delay – the worst I’ve had in a car is a 1h trip taking 4h!!!

I look forward to getting on something where someone else is doing the driving so I can use my time effectively

Amazingly, it seems like only 7% (4.5 Million) people in the UK use public transport. Given that nearly 1/3 (22 Million) live in the South-East, where transport is generally pretty good, that seems pretty low. No surprise given the number of people on the motorways – I’ll be happy to take one more off them next contract.

So what’s up for 2015 for me and this blog?

For one, I plan to start getting back in to a bit more of a rhythm, both with my posts and the associated (play) work (generally outside “real work”), and I will continue to post based on my experiences – recent and past…

theme : ecologyWhat are the themes though? Here’s a list of where I’d like to go:

  • Lifestyle & Reviews
  • Process & People & ScramJet
  • Clojure
  • Architecture, including Enterprise & SOA aspects

in no particular order. I won’t get in to specifics as much of it is not yet planned, or I’m working on it but don’t want to reveal it until I have enough meat on the the bones so I can be sure it will fly.

teaserHere’s a few teasers though based on posts I know I’ll write or have in draft form:

  • Review of Bob Marshall’s “Thinking Different” happening last year
  • Review of the: BMW i3 electric car; Samsung Galaxy Alpha
  • Corporate Subversion – in a positive manner of course :-)

and that’s really just the “boring stuff” – there should be some very interesting posts coming as I hit my stride.

I hope you’ve all had a great XMas & New Year break and look forward to some great interactions in 2015!

Agile Baby Steps – Iteration 4

Baby Step 4Return to the Motherland ;-)

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:

  1. Working in a more conventional Project Management process and
  2. 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…

skramjetThis,
was
the
beginning
of
Skramjet

Enterprise Kanban Part 1

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

EntKanban-1

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.

EntKanban-1-risksWith 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