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..

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 :-)

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.