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.

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 !

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.

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.

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.

Product Owner Problems

In my current project the business faces an interesting conundrum with Product Owners.

We are specifying and [hopefully] building a Demand Forecasting solution for a large Supply Chain and there is ultimately a large amount of complexity within it.  The complexity comes from the integration of Demand, Supply and Inventory data and the ability to accurately forecast and model future Demand at SKU level upwards, then turn that into Supply and Inventory forecasts (let alone optimize them).

Thankfully I have a good bunch of talented Supply Chain individuals who understand their subject and can give me requirements in a granular and Agile manner (I have a 300 Epic backlog so far). These people can define at an intricate level how they need their system to work in a Supply Chain context and what they expect from their product.

So why is this a problem?  Ultimately a Demand Forecasting solution has very little to do with Supply Chain and an awful lot to do with Analytics, Algorithms and Data.  I have a Product Owner who can tell me in detail what he needs his demand forecast chart to look like and how it is to behave, but can tell me very little about how it is actually calculated from an underlying analytical perspective.

Suddenly a conversation about what does "best fit" or "most appropriate calculation" opens the doors to a need to understand Simple Moving Average, Geometric Moving Average, Triangular Moving Average, Parabolic Moving Average, Double Moving Average, Exponential Moving Average, Holt's Double Exponential, Holt Winter's Additive, Holt Winter's Multiplicative, Additive Decomposition, Multiplicative Decomposition, Sparse Series Croston's Exponential, Economic Time-series Forecasting, Linear Trend / Regression, Linear Trend And Additive Seasonality, Wavelet Forecasting, Polynomial, Haar Denoising, Fractal Projection, and Fourier Transforms.

My Supply Chain Product Owner now needs to be a Statistician from Cranfield University! Simple sounding user stories suddenly have a deep weight of underlying mathematical understanding needed and the "emerging architecture" becomes one of building a statistical analysis package rather than something for planning how many widgets to buy.

Today I do not have an answer to this one, however the first development iteration is in three weeks time so I've got some time to get an approach sorted out.

The Olympic Sharpie - Pen of Agile Champions

I have to admit, the humble Sharpie does not often get a mention in the Agile press but it is the pen that ensures visible, easily readable story cards with not too many words on them.  If you can't fit your story on an A6 card written clearly in a Sharpie then the story is too complicated.

And now we have the Bronze, Silver and Gold standard:

These little beauties were a gift from my wife and have been excellent in a new process I have been running in Agile requirements workshops lately to categorise Epic level stories, I wouldn't say I invented the process, but I think I may be the first to have enhanced it with the use of these pens.

Seemingly product owners and other business stakeholders like shiney things, so if you give them shiney pens to add a priority category to their stories it seems to work well.

I have been using the following scale and asking the workshop participants to add a splash of colour to the cards as follows:

• Gold - Must have in initial release (minimum shippable product)
• Silver - Must have in later release(s)
• Bronze - Would like in later releases
• Blue - Don't really need it any more

I have told the group that if in doubt or if there is debate, to always pick the lowest colour.  These colours are not specifically indicating an order of play or individual priority however quickly enable the targetting of resource to the Gold cards for breakdown into Actionable User Stories therefore minimising waste, Silver and Bronze to follow.

Long live the Sharpie!

Weighted Shortest Job First / WSJF - a bit of the SAFe Framework (Scaled Agile Framework)

Today I was in the SAFe Agile Training Course (Scaled Agile Framework by Dean Leffingwell) run by Rally Software and they introduced the concpt of prioritisation using the Weighted Shortest Job First (WSJF) Method. This is something that came out in 2009 in work by Don Reinersten.

Normally we prioritise based on business drivers from Senior Stakeholders, Product Owners, already known critical paths, what makes "sense" to us as a Project Manager, or who is shouting the loudest.  The WSJF Method however gives another dimenstion to this by exploring the opportunity of multiple factors of value being combined together into a formula to give an implementation order.

As an intro some basic concepts such as "shortest job first" and "highest cost of delay first" can be combined to give a weighted cost of delay to enable quick prioritisation to reduce overall cost of delay.  The Feature with the highest weighting by dividing CoD by Time should be done first, and if there is a tie, then the shortest job should be done first by default to deliver value faster.

CoD / Time (effort) = Weighted Cost of Delay

How cost of delay is actually defined is somewhat arbitary. It could be based on lost revenue, loss of potential earnings, market share, competitor advantage, reputation or a range of other factors.  What is important is that a standardised approach is taken to giving it a value,  Just like complexity the 1,2,3,5,8,13 scores seem to work well, with 1 being the least cost, and 13 being the most.



To step into the full calcuation for Weighted Shortest Job First (WSJF) and the cost of delay some further thoughts need consideration:

"User / Business Value" - what is the relative value of the Feature in the eyes of the business or the customer (again 1,2,3,5,8,13 is a good scale with 1 being low value and 13 being high). This can include revenue impacts or penalty costs if appropriate.

"Time Value". This measure deals with the "need" of delivering something in a timescale.  For example, if you were replacing the bathroom your own house, it may well be prudent to get a toilet in quickly and less urgent to fit a basin if there was a sink in the kitchen that could be used for washing in the short-term.  There are a range of similar scenarios in the business world where Features can be considered in a similar way (albeit with potential loss of contract earnings, or loss of customers as the repercussion instead) and again the 1,2,3,5,8,13 scale works well with 1 being a low "need" and 13 being highest "need".

"Risk Reduction & Opportunity Enablement Value"
This is the last part of the calculation input and gives a relative value for the need of a business to eliminate risks earlier or the potential for new business opportunity to be derived from the Feature (therefore not having its own discrete "business value" but enabling it elsewhere), and therefore gives some credit to the value of the risk elimination (1,2,3,5,8,13 scale again).  Ultimately, some projects have low financial value themselves however have significant influence on lowering risk to the business or enabling future opportunity, this is what this one is about.

"Job Size"
This one is straightforward - the estimate of length of time needed to implement the Feature (again can be a relative estimate using 1,2,3,5,8,13 or a real value in Months perhaps if it is easier).

The formula for Weighted Shortest Job First (WSJF) is as follows:

.               User Value + Time + RR&OE Value

WSJF =   ----------------------------------------

.            Job Size (length)

The resulting WSJF scores can then be taken as a proposal for implementation priority order (Highest result number first) and will in some circumstances show otherwise hidden or not considered implications within the Feature-set (or Epics) to be implemented. The idea behind all of this is to deliver the lowest Cost of Delay to the business for features, epics, and even stories.

I have my reservations about how far down a Programme of work this can cascade. I can see it being a really useful tool at a portfolio level and also in the emerging Business Model Generation World.  I think at an implementation level, decisions will have been made within the themes and high epics, and by the time it hits a Scrum team this will simply be a priority number in the backlog.

More on the Scaled Agile Framework to follow..