Friday, 3 July 2015

Tools don't make you Agile

So this is my mug from a recent assignment. We were all issued one within the Capability Team but it was supposed to remind us all that when we'd finished all our stand-ups, facilitation workshops and face to face interactions, that at the end of the day we needed to update our supporting toolset.

Keep calm and update Rally
Keep calm and update Rally
The challenge with adopting Agile is that you need to learn new agile values, and its not easy. Giving developers or technologists the choice of interacting with business people or playing about with a new toolset there is often a sway towards tools and insular practices.

In Agile, its all about the people interactions and conversations that make you more Agile, and you can get the most of them happening when you have an agile wall / 'radiator board'.  These walls tell their own story about the status of any project and will attract any interested parties like moths to a light bulb. If this board is in a collaborative space it will encourage the business and technology to openly engage with it and with each other.  The six conversations* you're going to have about each user story are easily enacted in this space with physical media (cards and pens) rather than a screen.

If you use desktop tools you promote people to look at their own screens rather than each other. I call desktop tools 'fridge's' as you've got to open them to see what's inside, unlike your Agile wall that is always radiating information. The human brain can happily manage about 150 items in view and in context on a wall, so only got for a supporting toolset if you're way over this amount, or you have specific geographical challenges you can't overcome with other means.

Any organisation that thinks rolling out Rally, Jira or whatever to their tech department is suddenly going to turn them Agile is starting off in the wrong direction.  Toolsets can help make your processes more efficient, but they don't make you "Agile".

*A user story is a placeholder for a conversation, one that will take place about six different times before the story gets played into a scrum team.

Friday, 29 May 2015

On the journey

So every journey begins with a single step..

Today I was running a session to elicit a list of potential projects with the business so that they could be further analysed by process and technology and then played back to the business again for a short-listing.

Its good to be back in the facilitator role again

Whilst we got the list of projects together in a reasonable time and some excellent debate was had, it was interesting to observe the worry in the room that there was not going to be a concensus on priority.  The concern seemed to be that either some "quick wins" that would be easy to deliver would make it in, or alternatively just a start on a more strategic journey that would deliver big benefit down the track, but not necessarily in the coming year.

Thankfully, I was able to speak to the concern using Weighted Shortest Job First (WSJF) and had printed out a copy of the formula and a description of the elements that make it up.  There seemed to be a real sense of calm coming back once I had explained the inputs and process and that there was an existing method to take stakeholders on a journey to a potential "straw man" priority list that they could then debate with some actaul "science" behind it.

I just hope they like the answer when I run the prioritisation workshop in a few weeks, I have yet to crack exactly how we are going to get an overall clear measure of "business benefit" here.

More to come..

Thursday, 7 May 2015

Back to Basics

So I've been away for a while.

Having persued the Agile path from its early beginings working with XP, FDD and RAD methods in the late nineties and then been on a journey all the way to the Scaled Agile Framework in 2013/14, I stepped off.

One of the interesting things in doing what I do is that once in a while it helps to go back to the other side of the fence and see what it looks like.  I'm now deeply involved in a global datawarehouse delivery for a large Financial Corporation and its all fixed price 3rd party work and waterfall documentation.  I've been here for a while, and have witnessed all the things that we tried to fix with Agile all over again.

Whats fascinating is what happened when things started to slip on the waterfall plan. The build phase in my project was being held up as design was late and still emerging. It somehow seemed really natural to fall back to Agile first principals and start short iterations of design, build, design review and test, within the waterfall process.  Also what was equally fascinating is how this "iterative" approach has been hailed as significant progress within the Department.

In this heavily silo'd and waterfall organisation there are so many ways that grass roots Agile can help sort out and fix problems and also give a framework to prioritisation.  Not by suddenly implementing scrum and making the business engage as product owners (they really aren't ready for that) but just by going back to some of the original Agile principals, like Keep it Simple, Evolve Designs and Reflect Regularly.

I have now been invited to run presentations and workshops to demonstrate what Agile can do for the Organisation and how the Agile principals can pave the way to more successful outcomes.

Here we go again :-)

Tuesday, 13 August 2013

Business Process Architecture in the Scaled Agile Framework (SAFe Framework) and where is Six Sigma and Lean ?

I read one of the Guidance Articles on the Safe framework website yesterday that describes Seven Principals of Agile Architecture that have proven to be effective in re-legitimizing the role of architecture, and by implication the System and Enterprise Architect in Agile at scale: Principles of Agile Architecture

Following on from that, by chance I ended up having a coffee with a Six Sigma Expert from our BPI team and we talked around the subject.  Strangely we spent the first few minutes trying to find a common point of reference as whenever I mentioned Enterprise Architect he had visions of a Business Process Architect, and I meant and Enterprise Solution Architect.

Once we got over that hurdle we came to the conclusion that actually, the concepts of intentional architecture and emerging architecture in the business process space seem to be somewhat overlooked or underplayed in the SAFe framework (current version 2.5) and that ultimately the work of the business analysts in requirements capture and backlog creation seem somehow to be anticipated to fill this gap.  I am not convinced; and the more time I spend looking at Lean and Six Sigma I think there is a chapter yet to be written in the SAFe framework to cater for this.

I will try and get hold of Dean Leffingwell or his colleagues and see if there is some collaborative work that can be done in this space (unless of course its already in hand) as I think there is an opportunity here to really tie the Business Process Architecture to the Solution Architecture within the Framework.

Thursday, 27 June 2013

Agile SAFe Framework - Agile Release Train Planning (ART) number 2. Largest in the UK (again)

Today was the end of the second Release Train Planning event to mark the start of the next 3 months worth of development within the Business.  This time we had two hundred and seventy people on the go, so seventy up on last time. still the biggest in the UK from all we are told.

This time round it was a bit slicker in the execution, with some truly excellent contributions at the start to give some context and to re-cap on the success and challenges of the last 3 months plus a bit of humour and a surprise or two along the way to keep spirits up.

I was again facilitating for the two days, this time working with one of the teams on a Supply Chain initiative.  The afternoon of Day 1 saw us reviewing a draft story set with our new product owner which sadly descended into a debate as to whether the story set was actually viable at all.  In the spirit of agile, we broke off and put the developers back into the "heartbeat" processes of the Safe ART and then four of us spent two hours with a whiteboard doing some rough and ready business analysis to get to the bottom of the actual requirement.

Day 2 had the four of us meeting up at 7.30am to write up a new set of stories from the work the afternoon before, and then we were able to re-engage the development team properly in the planning breakout session and get the whole thing planned out properly into the next six iterations (I know Dean Leffingwell suggests 4 iterations, but we're doing 6 per release train here).  Not the most perfect of ART planning days for us, but actually we got the right result and a good team confidence score in to the mix also, so all is well that ends well.

Now we just have to deliver what we committed to !

Thursday, 23 May 2013

Agile SAFe Training - the Facilitation bit.

Well I have been a bit busy of late being further trained up in the Scaled Agile Framework and also helping facilitate at the first UK SAFe Release Train Planning.  This event was also the largest SAFe Release Train planning event to be held in the World as of March 2013 with about 200 participants, and we are doing it all again in June.

We are being helped along the journey by Rally Software who have flown in consultants and trainers to help us up the SAFe "mountain" and the uptake and commitment by the teams inside the company has been impressive.

One such bit of help that Rally gave last week was a two day course in facilitation.  Now I don't think I'm too bad at facilitating but equally I know there are better people than me at it so an opportunity to pick up some new tips and techniques was a bonus so I enrolled.

I have to say that having done the course I now realise there is a bit of an Art to good facilitation and I learned a lot about the way to structure a productive workshop, how to prep, how to open it and more importantly how to close it.  There were practical exercises across both days and we all took away new skills that we put into practice immediately in the workplace.

Laura Burke - one of the Rally trainers on the Course

Ironically I had facilitated a retrospective a week earlier and been given a "Thank You" card for a "Brilliant retrospective" - now with hindsight and what I learned on the course I realise I could have done better, but that's all part of life learning.

What was clear from the course was that the larger you scale any Agile framework in any company, the more "value" you need to get from your meetings and workshops. There isn't the time to get groups of people together to go over the same points yet reach no conclusion, and ultimately if you are leaving a meeting without a decent set of actionable items or decisions, why did you have the meeting in the first place?

More on the Scaled Agile Framework to follow.

Thursday, 28 February 2013

The Benefit Delivery Model circa 2007

So in a fit of nostalgia I was going through some work I created back in 2007 and one slide within a pack on   a formal Quality Gate Process stuck in my mind.  Whilst a lot of the world has moved away from the formalised and regimented QMS / Gate structures and approval boards with endless paperwork having a stranglehold on project delivery, the underlying principal still stands:

Benefit comes from Process Improvement, not from IT.

Benefit comes from Process Improvement, not from IT.

I realise this is stating the obvious to some, but for me it was worth just mentally re-visiting that statement.  We can build the most technically elegant and "bleeding-edge" platforms, the most wonderful UI's and the fastest responding architecture in the land, however unless it is improving something tangible for the business, there is no real point in investing in it.

Whilst my slide above was for an audience in a Government organisation who liked Prince2 and SSADM type processes, it still stands up just as well in the Agile world.  Every single user story can be considered to be its own little business case (if written correctly) with the benefits clearly stated, and the acceptance criteria clearly defined - Benefit really does come from Process Improvement, not from IT.