Appreciating the value of SAFe

SAFe4.0_transparent_background 8.5x11

Over the last few days I have been taking the time to carefully reflect on the reasons why I really appreciate the SAFe framework. I’ve put the link in here for you SAfe 4 and there are a number of case-studies detailed in here SAFe case studies

I will neatly ‘side-step’ the positivist hierarchy of evidence question for the time-being as I think that might muddy the proverbial waters in terms of my appreciating what it offers, for me, and perhaps for you. Stated simply, case-studies offer three things for the interested professional:

  1. Credibility. Many Senior Executives find it helpful.
  2. Insights and Learning: The Case-Studies and CoP help foster respectful collaboration
  3. Evidence. Many large public and private organisations want underpinning evidence for the ‘case for change’ or an associated business case for validation.

But this does not really capture what I have in mind and this is the consultancy cycle approach to incremental change. It is fair to say that I’ve been using this model for over 16-years now. Stated simply, it starts with a problem that needs to be solved. It also sets aside any notion of a prescribed methodology, or indeed methodologies, and instead actively seeks out the established ‘evidence-base’ for what has effectively worked in similar situations/contexts or what we might call case-studies?

To make my point a little more ‘real’ let me provide three hypothetical scenarios and the ways by which the SAFe framework would, perhaps, offer something of value, insight and help.

Remember, of course, that one of the foundations of the agile movement is all around incremental change. That is to say, that we are looking to make small, testable improvements from the current state to the desired future state. We collect data/evidence as we test our hypothesis to this end.

Also, remember that SAFe is a framework and therefore you can select the parts that you wish to test as hypothesis to help you gain more agility.

Scenario One:

The organisation wants to empower its teams to use the most appropriate methodology and associated tools so that they can take seriously the ideas of the self-empowered or organising team.

One of the strengths of SAFe is the operational ease by which each team can adopt, test and refine its own lean-based methods such as Scrum, Kanban, ScrumBan or any refinement that the team makes as part of its own individual agility maturity. We don’t need, anticipate or expect that innovation is quashed by ‘corporate policy’ or the illusion that if every team used the same tools then life would be simpler! SAFe is ace in this regard!

Scenario Two:

There is significant technical debt because projects are being stopped and started. The dependencies are out of synchronisation, and even completed projects are left on the shelf completed without any genuine business value being realised.

Thankfully SAFe has lots to offer in the ‘strategic portfolio operational’ space. At the Enterprise there are key strategic themes. In turn at the Portfolio there is a ‘work-in-progress’ limit to the number of projects that are in the Portfolio strategic pipeline. Thus, the value stream per theme is clear; with enabler projects and Epics being clearly worked up and approved in a ‘light: tight’ governance role. This simply means that the business value of working software is known prior to it being started. SAFe also has a very realistic portfolio budgeting method that lends itself to ‘light: tight’ financial planning. This model is very similar to that advocated the National Audit Office for financial budgets that have a range of variables and costs with the assumptions (and sensitivity analysis) explicit.

Notice though, that if any project has emergent problems and has to stop whilst those problems are solved, that the WiP ensures that there is a worked-up (i.e. ready to go) project for that team. Thus, there are no idle, redundant or sunk costs due to poor sequencing or Portfolio synchronisation. SAFe is first-class in this area!

Scenario Three:

In a word the next problem is all around system improvements. Consider a context with SOA architecture and three projects needing to ‘call’ various SOA services before the transition to a fully production/live services.

In this regard SAFe has lots to offer! Consider the cadence or rhythm of the software (fully tested and system Demo to all stakeholders including the business Users). The neat release train ensures that all the teams know when to have their Epics completed to ‘hit the next train’. This makes System Assurance testing co-ordination that much simpler too. In effect the Business Users have shippable working software more frequently and better tested across the Enterprise.

SAFe also has a very sensible 10 or 12-weeks planning session for all the teams, or silos, within IT or ‘brand IT’. In this way it ensures that the front-line staff across the whole of IT all have co-created a plan that they are all equally aligned with and committed to. (I’ve blogged previously about systemic alignment).

For me, this is very powerful. It shifts the thinking from silo or ‘part’ to the ‘us’ or the ‘whole’ IT family or system. I love this for the collaborative hope that it offers. And given the significant number of businesses across a range of Industries that have, and are, successfully using SAFe this is encouraging to me.


I hope that I’ve demonstrated the rationale for why I can appreciate the SAFe framework when we are seeking to improve our agile maturity? I hope that whilst you may prefer a different scaled framework, or none at all, given your specific/particular circumstances or contextual factors, that for others SAFe is both a fab place to start that journey, or indeed help the maturity?

Take care, Jason


Jason is a Certified Scrum Professional; as well as a Business Psychologist and Agile Project Manager. 

Scrum-Professional-Seal-sm whatisbp






Agile Testing: The Test Flight.

There is something really #Agile about the ways by which this successful and very extreme testing resonates with me as a Scrum Master and Certified Scrum Professional.

This film is worth watching as you can see and hear the ways by which Boeing test pilots have subjected the new 747-8 Freighter to extreme testing.

Watch and you can see, hear and experience the ways that the plane has been dragged, dropped, soaked, forced to hover, shudder and flutter. This testing has costs millions of pounds. The testing takes the plane to the most extreme limits of what is to be expected when in the real world, or in software terms, the ‘live environment’.

Interestingly, there are a number of  what in software development we call ‘negative Use Cases’ such as deliberate stalls and flutter tests. The testing from what in Agile we call beta testing. Way before live!


It might be worthwhile where I am ‘coming from’. I work in the civil service and we have this fab team at the GDS that undertake the research and shape policy so that we can be the most effective in delivery. To this end, we are all Agile teams most of us use Scrum, Kanban or Scrumban.

Government Digital Service: UK Policy

Beta Outputs

Notice the similarity with the testing of the plane and the UK Government policy around what constitutes the end of the beta phase:

  • delivered an end-to-end prototype of the service (including SIT, stress and performance testing)
  • a collection of prioritised work to be done (your Product backlog)
  • a user testing plan (UAT)
  • accurate metrics and measurements to monitor your KPIs (given the above for performance, stress and integration)
  • fully tested the assisted digital support for your service
  • a working system that can be used, for real, by end users

Because it is an #Agile design notice that component testing, performance, load, stress and continuous integration run all the way through the software product lifecycle. We would also ensure a full regression test at the end of the cycle.

This is because we want to identify and fix any bug as part of continuous agile improvements and not wait until the end of all the software development has been finished and have a large ‘testing phase’ at the end delaying delivery and be reliant upon a small team rather than having those skills (and availability of automated technologies) in each and every Scrum team.

Once you have this concept, then notice the shift as we Go Live:

Going live

To provide a fully resilient service to all end users the service should now meet all security and performance standards. You have configured your analytics to accurately monitor the key performance indicators identified in the building of your service.

I write this in the hope of looking forward we can get a deeper sense and appreciation of the fantastic ways by which Agile (when understood and implemented properly) ensures the highest quality. It also ensures the most effective use of resources and flexible responses to feedback from customers- this ensuring that time, quality and costs (the ‘holy trinity’) are maximised.

Take care Jason



What we learned from our last successful Show and Tell.

This week we held a successful show and tell. We learned a number of lessons along the way and this weeks blog is our attempt to share our learning.


The first point is an obvious one but worth a gentle reminder and that is making ‘design’ choices to meet the different needs, learning styles and interests of the different stakeholders.

To this end we created 5 personas. These helped us to think through and then ‘design-in’ key insights and learning-points, so that they could make a meaningful connection to the session.

  1. The first was the senior manager ‘Lucy’. She was very busy working across the portfolio and wanted to understand and appreciate the strategic ‘big picture’ and then the ways by which this particular project stage (as expressed in the Show and Tell or Demo) neatly weaved together in the overall project’s narrative. For ‘Lucy’ we created a colourful and metaphoric visual poster. The poster expressed the narrative of an exploration ‘discovery ship’ taking their journey; and whilst doing so stopping-off at various ‘treasure’ islands before reaching ‘The New World’ that signified the project end date in December. Lucy would also want to understand the ways by which the functions and services shape the product. 
  2. The next persona was ‘Keith’. Keith understands his professional world from diagrams and work-flows as well as appreciating the logical parts between the key sequences. Keith is an Agile Architect. To meet his needs we had a ten minute slot from our Architect that provided first-class diagrams and an excellent explanation alongside.
  3. Next, we imagined that Jack ‘saw’ the project from the customer’s functional and experiential perspectives. Examples came to mind from marketing, customer insight, sales and other external or customer facing departments. For ‘Jack’ we had a ten minute slot from our UX team member. She very neatly weaved the functionality with the User Interface screens with the end-to-end clicks. She also provided evidence from her applied research with Users and the ways by which UX insights are shaping and have shaped the iterative product development in exciting, fresh and innovative ways.
  4. ‘Tony’ was interested in the detailed technical side of things. We saw Tony as a .net developer with interests in BDD and UX. We hoped that his needs would be met by a blend or combination of all the ten minute slots; but perhaps more especially by the UX and Architectual slots.
  5. Lastly,  was imagined that ‘Tom’ was an analyst. For his needs we shared the insights from our team leader BA. She also included what we had delivered to date, as well as highlighting the work that was out of the current scope. Her upbeat and engaging report noted what work packages would be picked-up in the portfolio/programme at some future point.  To bring a sense of ‘wholeness’ or Gestalt to the Show and Tell, our final speaker was our Product Owner. He deliberately selected a simple, clear but very poignant and powerful message that clarified the ways by which the project’s capability enabled transformation in two important ways. Firstly, for customer centricity and lastly, for enabling the changes needed for the businesses operating model.

The next lesson is the need to practice and gain feedback. We did this in three ways. Firstly, as a team we filmed ourselves and gave each other candid feedback. Next, we did a second ‘dry-run’ in the same room that we were using for the Show and Tell.  We did this as we wanted to test the IT equipment to ensure that everything was working as we hoped. Of course, if there were any last-minute glitches then these could be resolved in a timely manner. Lastly, after we finished the Show and Tell we also invited participant feedback using ‘post-it’ notes.

It is fair to say that this has been our most successful Show and Tell to date. The team have received life-affirming feedback both formal and informal; which is reassuring as we made a short film by way of dissemination for those stakeholders that could not make the date/time. It is our team’s hope that by sharing what worked for us that this may give rise to questions for you, and perhaps your team, in terms of the ‘design features’ that might work for you and your various stakeholders.

Take care, Jason


The Scrum Master: Appreciating the Reticulist.

This week my attention has been turned to, and reflecting on, systemic influence and the ways by which as Scrum Masters we are seeking to develop relationships of mutual trust, respect and with that foundation or ‘ground’ firmly in place that we can effectively seek to co-create more Agile organisations. These thoughts returned me to something that has shaped my professional practice, or praxis; and this is called the boundary spanner.

It is fair to say that the traditional way of describing the boundary spanner is an ‘agent’ that works collaboratively across multi-organisations, or agencies, so as to improve customer experiences through redesign etc. However, to what extent can ‘system influencers’ that work across different departments, Divisions, or service areas gain insights from this applied model? What can Scrum Masters learn, if anything?

Boundary Spanner

One of the core competencies of the boundary spanner is the notion of the Reticulist. Stated simply, this is the wisdom of the network and the judgement of how to best (and by best I mean ethically) influence and make judgement about the ways to which to influence a complex network of other actors or humans.

Friend et al (1974) rightly notes that such judgments are fraught with personal and professional tension because they are bound up in personal, professional and organizational concerns. Questions arise such as:

  • What is the best intervention?
  • At what level?
  • And in what form?

Of course, as the Agile Manifesto makes clear for Scrum Masters we value ‘relationships over process’ and there is an important clue!

Friend (p.365) goes on to say that such actions or interventions will need to be“guided by other motives at the more personal level such as the desire to be liked or esteemed by his associates” thus adding to the complexity! I have found it best that as a maxim we must be kind- but not colluding, if less effective methods and/or decisions are being made that run counter to our ends in mind.. aka #Agile.

Next, it is fair to say that the evidence-base suggests that reticulists are expected to deploy political skills which Friend strongly advises “must include a sure grasp of modes of behaviour relevant to different types of relationship between agencies and between actors”. An added value insight.

Degeling (1995) suggests that reticulists should command an appreciation of the interstices of power; so as to appreciate the systemic coupling, interdependencies and where fissures are likely to occur. Thus there is a call for us to be ethical as well as skilled at identifying the strategic points wherein intervention and influence are best placed. Thus, and this is key it seems to me, Scrum Masters (as a professional group or community or collegiate) will combine a strong commitment to change through the cultivation of linkages between key individuals with common interests and power, rather than adopt a passive/aggressive role of organizational representative. Reticulists are “individuals who engage in networking tasks and employ methods of coordination and task integration across organizational boundaries”. 

Next, Alter and Hage, (1993) note that large-scale change needs strategically placed individuals who use their interpersonal skills and relationships to keep pathways open at all levels in the hierarchy. It seems to me that ‘evolution trumps revolution’ (I cant stand the sight of blood!) and that we are therefore looking to develop relationships whereby we can ‘bring people with us on the Agile transformational journey’?

Consequently, Large-Scale Scrum it logically seems to imply requires experience and practical understanding of organisational power-relations. Thus, to be successful a collegiate set of Scrum Masters need the proverbial ‘wisdom of Solomon’ to ethically build coalitions between strategically located players who are committed to finding new ways forward on specific Agile concerns, ideas and ways forward.

Challis et al (1988) note that such people are not located at the top of the formal organizational hierarchy, but typically, have good access to it. Thus, the implication is that for Scrum Masters to be successful they will need to keep a ‘tight:light’ praxis that enables them to be “less bound by normal and accepted channels of organizational behaviour and are encouraged to be a little unconventional”.

Challis then also adds this as a kind but equally important word of warning- their “position and status within the hierarchy is such that they do not represent an explicit threat to top management, but are tolerated in the expectation that they can deliver solutions to complex problems“.  Of course, Scrum Masters need to deliver solutions. It is in our very DNA! To this end, it would be fair to say that describing a problem is for analysis…solving it requires a Scrum Master(s).

Take care.


Appreciative Inquiry. Releasing positive conversations in organisational life.

We know from a comprehensive evidence-base that based on the topics that they select to study, focus-on and have the courage to address that organisations enact and construct worlds of their own making that in turn act back on them. To that reality appreciative inquiry is based on the simple but equally powerful premise that organisations give life, energy, resources, conversations and myths to this end.


What we choose to build and how we go about it stated simply will and does matter. It takes genuine courage, focus and openness to look at what works well and build upon it. Interestingly, within software development this reality has been hardwired or designed in from the outset. Consider the Sprint Retrospective? Are the team invited to focus on what did not work and ensure this does not happen again? The answer is a definite ‘NO’. The team focus on what went well and taking that forward. This is the premise of appreciative inquiry. We build-on, we focus on, and we celebrate what works. As we say the ‘front door of enthusiasm’ has always been the front door for high performing teams.

But hang-on just one minute a more cynical mind may ask: ‘But we do ask what did not go well as part of a Retrospective? So you’re not quite right!’

This is a most misunderstood point around new entrants to appreciative inquiry: we are not suggesting that we are like Pollyanna. We don’t inhabit physical, mental and team worlds wherein there is not an added value role for contested voices, or for values-based dialogue (I use that term rather than challenge purposefully). We don’t deny reality. In fact appreciative inquiry has been used more successfully in important areas like third-world hunger, global warming, poverty, and military conflict than other change management methods.

We are not looking to silence, shut-down, ‘pretend things are different from what or how they actually are’…rather we are seeking to ‘open-up space’ for genuine conversation. But, and this is very important, we are looking to ensure that more than one binary of the ‘positive: negative’ is also justly recognised. Negative is just one choice. There is another.

The problem with an organisation that does not have both sides of the binary as possibilities of discussion and dialogue is that “once a binary has been established, the critics voice operates so as to reify the terms of the binary and thereby silence other voices” (p.190).

(Please see the excellent Chapter on Appreciative Inquiry by Ludema et al in the Handbook of Action Research Reason and Bradbury 2001).

It is fascinating to introduce appreciative inquiry as a fresh, new possibility and then pay attention to, and in turn analyse, the touch-points of resistance. Try adopting appreciative inquiry in your team or organisation and see the ways by which the negative binary seeks to close-down its competing new partner. Fascinating.

For those of us working in Agile methods appreciative inquiry will seem like your hand has been especially crafted for a new, beautiful glove; it will be a genuine fit.

Thankfully appreciative inquiry is taking traction in many organisations including the private, public and voluntary sectors. Asking purposeful questions for teams around what strengths they have; what they want to build/develop on; what works; and what should be taken forward in the next Sprint- further creates organisational circles of dialogue with obvious/natural links to more Agile, innovative, imaginative and life affirming places of work.

If we spend our focus on what is faulty/wrong; if we can only create conversations that critique and challenge; if all our organisation discussions rightly pin-point problems; then I would suggest that we lose. We are the losers! We co-create a workplace that loses its ability to see new possibilities, new spaces for innovation and new forms of conversation and dialogue.

So we can build-on what work has gone on before us. Recognising that such work took team effort, time and judgement. Then we choose to refine it; further develop it and improve it. There is an underlying theme of recognition; celebration and respect.

Another alternative is more negative. I will not go into that here. I am sure you are as tired of that approach as I am!

Take care, Jason


Jason is a Business Psychologist and a Scrum Master.

Lewis Hamilton winning the Grand Prix: Lessons for Agile teams?

We all like to win! And I am no exception! There’s something thrilling and life affirming about beating the odds; winning despite genuine difficulties and overcoming set-backs to finally win at something that’s important to us. Some would argue that one of the things that ‘defines’ winners is their personal resilience. Next their humility is also key as many commentators note that when exceptional sports people lose they learn how to ‘dig in deep’ and learn from their failures. This deep learning is important for future success.

So with this ‘winning’ theme this week it was Lewis Hamilton that gained my attention (and many others too!). There is no doubt that he is a very talented race driver. This week I saw him win the Bahrain Grand Prix with an impressive victory. Behind the winning driver there is, of course, a whole team helping him to win.


From the outset this includes the car design itself which often includes new innovations and cutting-edge technologies. Next, there are the ways by which the innovative design is ‘converted’ into a robust and agile build. Next, there is of course the plethora of testing to ensure that the car is reliable, stable and so on.

Once we get the car ‘on the race track with the driver content that it meets his requirements and expectations we have the team that ensure that once he’s ‘on the road’ that he has every possibility of success this is the all important pit team. Each and every millisecond (quite literally) ‘counts’ as the significant difference between success and defeat.

Take the last race as a case in point:


In terms of the race history and analysis it seems to me that there are three key facts.

Firstly, the two laps between Vettel’s first stop and Hamilton’s meant that the world champion rejoined the track with Rosberg and Vettel right behind him! This naturally prompted Hamilton to rightly ask: “What the heck happened to my lead?”

Next, the answer to his question adds weight to my previous point around the importance of the pit team; as the harsh reality was that Hamilton had a slow pit stop. When we combine the slow pit stop with the advantage of new tyres for his opponents or what we refer to as ‘fresh rubber’ -that these two factors had allowed Rosberg and Vettel to make up time on Hamilton and this was the reason the ‘gap’ had closed in on him. This in the racing world is known as the ‘undercut’.

To his credit Hamilton did not let this closing gap in his lead to frustrate him, so that he lost his focus, energy or determination quite the opposite in fact, as again, he skillfully and steadily built-up his lead until the next set of pit stops. At this stage in the race, Team Mercedes took the rightful tactic to stop Hamilton first so as to ensure there was no threat from behind, as in the previous scenario. Hamilton then went on to win!

High performance teams! They truly underpin innovative and cutting-edge products and services.

I’d like to share seven ways by which collaborative teams communicate qualitatively   differently when compared to less effective teams. Now to be fair these are broad themes/examples taken from my own empirical observations, but none-the-less, I hope that they are added value and thereby worth sharing in this method.

It seems to me that individuals, or team members, from high performance teams, can be often heard to say things like these when they are seeking to improve what they are doing together as a team:-

  1. I’d like to add to what Peter has said by adding that…
  2. I think we can take what Jane and Jack have shared so far and by bringing their insights together I think this would help us to…
  3. Kalee’s insight is important for us and I think we can develop this further by…
  4. Az we all recognise that you have expertise in this area; can you be our ‘critical friend’ and gently tease-out what our assumptions have been and see what this helps us to learn?
  5. I find Aaron’s contribution really exciting and I think he’s on to something here; I can’t contribute right now but just need a short time to reflect on this idea for a minute or two
  6. Can we draw a diagram of Rachel’s idea and play with it for a short while? I need to ‘see it’ so I can add value to her contribution…
  7. Mo is on to something really quite important the best way that I can connect with this emergent idea is by sharing the one drawback so we can co-create this development further

As you can quickly see this style of communication is under-written by a type of appreciation for one another. Each team member recognises, values and collaborates with others. They further develop their emergent ideas. Even when they are acting as ‘critical friends’ it is framed in a collaborative way. Next, some team members seem skillful in ‘connecting’ different ideas from various team members and further integrating or synthesising them. Lastly, this is no room for ‘group-think’ in here. The framing/espoused or ‘first’ principles of honesty, respect and commitment are evidently embodied personal values by which the team co-create grounded solutions.

Take care Jason.