• Home
  • Category: agile

on agile transformation… train, coach, do

As part of an agile tranformation team  I would like to have a regular standup so that we can absolutely align our efforts across the framework, practice what we preach and create corporate utopia for our customers with our superpowers. Well maybe not the last bit.

Some candidate acceptance criteria:

  • I’d suggest weekly to start in order to show some form of rythm and urgency to the client – keep it under 30 minutes if possible!
  • The team to discuss impediments/priorities in the areas they represent but with focus on the customer vision/problem statement.
  • High value and low hanging priorities to be aligned across training, coaching and executing to ensure the same message is being communicated at all levels and through all channels.
  • Should be private, safe, honest and respectful.
  • Output should be highly visible to interested stakeholders

Agile games – are they too much fun?

I’m here again, coaching – and trying my best to ensure I meet my commitment of making the transition ‘fun’.   I got to thinking about some of my fellow coaches and Agilist’s and the use of games-like events and realised that often the efforts in setting up and playing such games doesn’t result in any kind of value for the business.  (XP Game excluded of course- this is an essential for delivery teams)

Games are fun and may provide some feeling of Agility however I’m coming to the realisation that my preferred way to coach is by example in a delivery type situation.  I find (as do my clients) excessive games puerile and usually have identified more valuable work I could be doing for my clients where I can make some actual difference to their business vision.

In the past I’ve coached under the guise of Delivery Manager to Lead BA and found that setting examples, doing the job and growing the folks around you is more effective and cost efficient than having a coach sit around, giving advice, sometimes being ignored and in general not really contributing to the production of working software. Perhaps this is because clients often don’t know how to leverage coaching skills and experience, not setting the role or expectations properly within the organisation we are trying to coach?

Also standalone Agile coaching often detracts from delivery – we forget that coaching is not an end unto itself, indeed most clients these days simply want to ‘be Agile’ without fully understanding why, or indeed what it means in terms of commitment to change.

In the future I’m sticking with a real job title and getting rid of ‘Agile Coach’ which has become synonymous with ‘Cheerleader/trainer’ – Pigs Unite!

I’ve hit a snag

So I’ve got the Agile Enablement Backlog in place, all geared to retain the current DSDM standards whilst adding valuable new practices. I’ve even got an initial priority on these, based on several sources of information…including a miserable attempt at a passive organisational retrospective using clustering and goodies.

just wait til the next time someone says ‘on our last project xxx was crap’ – why do people believe it is important to spout casually but not to be part of an organised attempt to make things better 🙁
moan over

Back to the point, my client fancies using timeboxes for our agile transofrmation. Fine I think, we can plan on that basis but how can I tell when it’s ‘Done Done’?

  • Is it ‘Done’ when one team start it?
  • When all teams start it?
  • When one team is consistently doing it?

Imho it’s when the practice becomes embedded in an organisation, when it’s no longer perceived as a practice or technique and is simply part of what is done.

So, how can I use timeboxing to plan and complete a cultural shift? My initial thought is to use project focused increments, with levels of implementation…for example project a project b and project c combined with standups happening most days, standups happening all days, standups happening every day and attended by everyone including business, standups as above and under 15 minutes, and so forth.

Seems like an awful lot of preparing for not much return – I’m leaning towards a simple prioritisation of items and focusing on 2 or 3 until they are embedded then taking stock …

The customer?

I’m just pondering what this really means.  It seems that most IT folks consider ‘the business’ to be their customer, perhaps it’s the divisive nature of this statement that makes me uncomfortable. For every organisation surely our ultimate customer is the ‘real’ customer – without whom there would be no business!  Where does that put our business stakeholders then?

In my humble opinion I would say they are simply part of a team.  (Perhaps this is one of the reasons I find comfort in Agile practices, although in my experience most orgnisations struggle to implement the concept of a cross-functional team of tech and business.)  Calling your business stakeholders ‘customers’ imply that the IT functions are there to serve – this doesn’t tend to encourage business-driven solutions, it almost certainly impedes the combined team effort that’s required to deliver software that satisfies everyone, including our ‘real’ customers.

No no no no no

Dontcha just hate this phrase.  Whilst discussing how we plan to attack a fairly large Agile project one of our experienced CSM’s, who happened to disagree with some suggestions I made – something I applaud and appreciate – used this phrase in a controlling way – as in ‘No, no, no you have to do it this way’.

Of course I asked politely that he didn’t do that again to me and reminded him we should be collaborating and this phrase is such a forceful and negative one to use.  (Meanwhile I’m quite nervous now about our team possibly being subjected to the same – we really need them to be cajoled and encouraged to deliver this)

As it’s the end of my first week at this gig I can only hope I didn’t push it too far too soon 🙂