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.

Summary

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

 

Association_for_Project_Management_(logo)

 

 

 

Systemic Leadership: How do we acknowledge what is?

This blog is more a reflective piece as I don’t have the answers. My question is: How does a systemic leader successfully acknowledge ‘what is’ or the truth of the situation and at the same time take a holistic view of the impact of recognising that some things have not gone as well as we would have liked?

Let me share where I am coming from and what factors are shaping my inquiry. Can I first state that this is an inquiry is systemic. A systemic or holistic perspective considers that all parts of the system affect one another (see Tarnas, 1991). In other words, release processes affect the development/Scrum team. Next, the quality of testing from the development team also affects the anxieties and concerns of business as usual, and so on. I personally also extend this view to see that the success of one team delivering a key project also highlights collaboration across the system too. And, if one project has not delivered in the ways that we first imagined or fantasized; then this too will have both direct team impacts and as importantly systemic ones too. Agreed?

One of the most important roles of a systemic leader is to ‘acknowledge what is’. John Whittington for example says that in terms of systemic coaching that “standing in what is, the truth of the system, settles (the client) and opens doors to fresh resolutions” (p.83). The advice goes on to note that in this coaching role at the individual level it is important for the coach to remain “neutral” which is a gift that the client can benefit from.

Stepping inside a new leaders role and reviewing the last years highlights, progress and areas for improvement certainly resonates with this central idea of needing to acknowledge what is. This resonates around sincerity, candor and transparency and there are neat links in here for Scrum values. “This has not gone as well as we had planned”. Why is this important? If we have genuine concerns that things might be a little ‘happy clappy’ then looking from this perspective (or walking in this leaders shoes) one can have some empathy.

For example Tuckett & Taffler (2008) report that in some organisations there can be a culture that co-creates a ‘bubble of euphoria’. In this bubble (think of the banking crisis) everyone implicitly colludes in a process that everything is OK and all the people get “separated from reality”. The longer this continues the more the risks that actual events get glossed-over, spun and even re-defined to the a degree that we enter a ‘perverted reality’. Newcomers then have three choices: collude, exit or seek to facilitate change. In some cases this creates a systemic cycle of key roles that do indeed ‘exit’ for whatever reason(s), creating what is referred to as the ‘ejector seat syndrome’. This of course, is unsettling systemically.

However, there is a tension in here for me. And this is my inquiry question. In what ways or to what extent should we as systemic leaders, that recognise both positive and negative feedback loops on the system, acknowledge what is: whilst recognising that ‘bursting the bubble” will create pain? We will witness ‘exits’. We will see and feel hurts, disappointments and a sense of mourning.

It is my experience that in most complex systems there will a multi-factoral model and lessons to not only learn from but also not repeat. That’s a genuine learning edge. To this end, the leader’s communication would need a sensitive (neutral?) systemic language. To be seen to attribute (or worst still ‘blame’) a ‘part’ of the ‘whole’ would, in my experiences, only unsettle.. as it does not resonate as the ‘truth of the system’. This is no easy task and I would not profess to always get this right. The leaders would need a ‘heightened awareness’ of their own systemic entanglements and loyalties some of which may well be divided. Developing this awareness; now that’s a different story…

As leaders we would need to be able to understand our own stories (see Geoff Mead, 2011) and the ways by which these stories flow through and sometimes how we get trapped by them. My own inquiry in this has taken to Theory U and I’ll blog on that at some future point.

For the time being, my recent experiences with a constellation with Ed Rowland has helped me to experience the systemic in fresh, insightful and fascinating ways . I experienced and witnessed some of the ways by which formative familial constellations can get re-played in organisations. (see The Whole Partnership).

“Some things have not gone as well as we would have hoped”. There is truth in these words. Is it fair to posit that a bubble may have burst? Is our system maybe hearing a new truth? If so, then let’s be sure that we have a systems assessment; and that any lessons are indeed systemic and do not reveal any invisible loyalties, or personal defences/ protections.

Personally, I am committed to a more morphic model of transformation as this is beautifully systemic and relies on the forming and shaping of new organisational forms through organic changes. In this way we see merging and being merged in new ways; thus ensuring that the organisational is fit to evolve in light off its changing environment. This is fab transformational language.

Personally over the last few months I have been fragmented, disoriented and held contradictory feelings of both excitement/joy as well as genuine sadness/ disappointment as I’ve worked across two teams that are in very different ‘places’.  I’ve wondered whether this has been systemic valency? In other words the ‘micro’ in the ‘macro’ and whether unconsciously I’ve taken-up a role on behalf of the system? I wonder if my divided loyalties between first-class projects as a profession and excellent Scrum teams have been a ‘symptom’ of something wider, something much more systemic? All organisations have defences, and mine is not any different in this regard.

So my question is this: What systemic language speaks truth but at the same time speaks from a respectful place?

To end with a favourite quote of mine from Geoff Mead:-

We must learn how to differentiate between narratives that are self-interested and self-serving (and thereby diminishing of others) and those that come from a place of greater mutuality and genuine engagement (and thereby life enhancing) (p.117)

Quote taken from ‘The Heart and Soul of Leadership’.

 

Agile types within the community?

Over the last few years I have been undertaking some action research around Agility and what we might possibly mean by the claim of an ‘Agile community’? Are there, like most other professional/social communities distinct sub-communities? Can we trace or recognise smaller grouping(s) that seek to collectively make sense of the notion of ‘Agility’ in its broadest sense? And does this naturally mean that Agility is understood in different and even competing ways? And, if so, how can we, and do we, make sense of that multiplicity of meaning-making, for want of a better term? What method lends itself to understanding?

One approach I like is that proposed by Carl Jung and his use of ‘types’. This is a first-class resource for those wanting to read/study a little more http://jungiancenter.org

Stated simply, Jung made the claim that humanity share a collective unconscious. Our collective unconscious was inhabited by a range of characters that he called archetypes. I guess then, I am wondering if these characters are shared symbolically by the agile community? Can you recognise any of them? Do they resonate? We each then using this framework can be ‘activiated’ by an archetype and act-out in the ways described. Of course, this would be unconsciously, rather than consciously given the nature of an archetype. What types can we recognise?

On Method
Following quite extensive individual and small group interviews; and then reading primary and secondary resources, I think I’m in the position to postulate the following typology. I have attempted to condense the complexity to a rather simplified 4 core types, but of course, I am in the process of making-sense of my own, rather limited, direct lived experience. There are therefore, I am certain, more that can be re-searched and shared, expounded and I hope, in a life affirming manner, debated too.

For each of the 4 types I have attempted to analyse sameness and difference. I’ve also looked at some of the main metaphors that resonate for each type. Next I’ve looked at some of the main ways by which they tend to ‘act-out’ in terms of power-relations. Lastly, I’ve examined some of the unconscious ‘shadow side’ of the types so as to provide psychological space for humility, reflection, insight, and possibly more self-awareness.

As I write that last sentence I make the candid declaration that I am a ‘flawed human’ with a need for my own ongoing ‘inner work’. I am grateful for my coach, mentor and friends to this end.

What are the 4 types?
I have carefully traced the following 4 types:
• The Radical
• The Reticularist
• The Retro
• The Romantic
I’ll address each in turn and then a short summary table for ease of reference etc.

The Radical.
With the Radical type of character there is an inherent impatience with the rate, or pace, of progress. If their dreams were actually realised; then there would be a massive, unmeasured and rapid change to their ‘way’. They seem to desire an over-idealised Agile image that forever seems just ‘out of reach’. Consequently, their preferred modus operandi is the on-going challenge, the critique. This is what Cooperrider refers to as ‘the deficit model’. They have ‘weapons of mass destruction’ and they are willing to deploy them if deemed necessary. Their preferred metaphors for Agile teams are ‘squads’ based on a military/conflict model. Thus, they speak and think in terms of war; fighting; and competition. For them to win then others must lose on their imagined Agile ‘Crusade’.

Their psychological narrative is binary: good/bad; in/out; friend/foe. They prefer in-groups where all the members share their future ‘end game’ when, presumably, they have ‘won’ and anyone that does not share their own (rather narrow view) of organisational Agility has lost? Thus, Agile ‘coaches’ caught-out by this character might spend over 80% of their time, energy and persuasion on ‘challenging the status quo’. As you might have guessed the Radical struggles with multiple, competing interpretations of reality. Thus, he sees things in a single-minded manner. They are very stubborn and fixed.

Of course, there is as with all types more positive aspects to this type. They have deep personal resource ‘wells’ of energy, resilience and massive drive. This role can be seen in some circles as a ‘necessary mavericks’ and by a smaller number as ‘heroes’ taking forward and representing the Agile cause with ‘passion’.

When things are not moving as fast as they deem realistic then their impatience reveals their shadow-side. This shadow-side includes all the military undertones of actual warfare: propaganda, guerrilla attacks, and psychological injuries. Next, given that they often have strong group boundary norms they can be given-over to darkened shades of group-think. The advice? To keep this in check this sub-community would do well to keep connected with other sub-groups and more especially the Romantics. (NB:- They would need to be careful with the Reticularist as the latter may simply be seen as an ‘intelligence source’ for their next ‘campaign’).

The Reticularist
I’ve blogged previously around the role of the Reticularist. Stated simply, the Reticularist is sometimes referred to as a ‘boundary spanner’. This Agile archetype is a ‘whole systems’ actor, thinker and planner. Therefore, within the organisation (and more especially the IT department) she/he is seeking to understand work flow. Questions arise such as: How does work flow through the organisation from product conception right through to the release stage? Where are the blockers to flow?
With whom do I need to make allies with and, quite literally, ‘see’ work from their perspective in an appreciative way? The Reticularist seeks to co-create with others incremental improvements to flow, and so share successes across teams.

The guiding metaphor for them is an organic or ‘living’ system. This is because such systems move, change, shift and therefore, new patterns emerge from the interactions of the parts. In this way, the Reticularist is a collaborator par excellence as they act on and with the ‘edges’ of different interfacing teams and departments. As an example: If product releasing is a current challenge- then a collaborative group would seek to co-create a solution.

Whereas for the Radical the temptation would be to challenge and then release the product from the direct Scrum team and then more simply watch and ‘see what happens’ which could well include fall-out and tensions…the Reticularist would systemically foresee the tensions arising from such unilateral decision-making and seek to circumvent it via a more collaborative method (e.g. a small cross-group experiment).
The shadow-side for the boundary spanner is gossiping. This is because when you are seeking to understand all the ‘parts of the whole’ of necessity this means engaging with the teams within those parts.

Consequently, there is a genuine risk of information-sharing for understanding in transit/translation, losing its ethical value, as gossip. The downside of gossiping are likely to include damaging trust, as well as negating possible future relational reciprocity. To mitigate this risk, one ought to state one’s own intentions for Agile improvement as the contextual discussion background. Thus, you cannot be ‘all things to all people’ if this means in professional practice you are left without any ethical ‘grounding’ from which others can evaluate you intentions for good or ill.

The Retro.
According to the online urban dictionary the Retro is a ‘contemporary style containing elements but not the replication of a previous era’. Thus, there is a sense of looking back in time or history, for the Retro. They hold in especial respect and regard the ‘Founding Fathers’ of the Agile movement. The Retro often have applied longevity with the application of Agile methods in various types of organisations. Many of them are seen as current leaders themselves. A smaller sub-set have taken the opportunity to incrementally develop, refine and market new tools, techniques and methods. The Retro has a deep and genuine sense of respect for the ‘Giants of the Past’. They will have taken the considered care and time to study their words and often memorised their key concepts and suggestions, and applied them too.

Whereas for the Retro there is respect and even reverence for the Founding Fathers this is often at the business or logical level. The Retro deeply understands marketing, branding and profit margins. This can be contrasted with the Radical as the latter actively seek to challenge the ‘Old Timers’ for even better methods; innovative breakthroughs and new models.

The shadow-side for the Retro is most often witnessed by a degree of arrogance, pride and a somewhat ‘closed mind’. Therefore, on many dimensions the Retro can be contrasted with the Radical. Whereas for the Retro ‘wisdom’ is a core value; for the Radical disruptive innovation is of a higher need/value. Many current and previous Agile community arguments can thus be framed using this interpretative lens or schema.

The guiding metaphor for the Retro type is honouring the wisdom of the collective past as incremental improvements are made moving towards the visionary future. The future vision, of course, would seem consistent with the Founding Fathers, whilst accepting and even celebrating a sense of building on their foundations.
Key words: vision, values and wisdom. In terms of power-relations the Retro views power and residing in the empirical evidence-base underpinning their Craft. Therefore, they look back to the philosophical Greeks not just for wisdom; but also for their technical Craft or techne. They are keen to learn the ways by which to persuade, cajole and bring others along in a relatively harmonious way to a more Agile organisation.

The Romantic.
For the Romantic type the Agility journey must engage meaning. It is essential for the Romantic they can see their role and the ways by which this is connected to the Agile journey for the organisation. For the Romantic, Agility has everything to do with increased job and team satisfaction; a more life affirming and innovative work-place. Whilst they appreciate all the empirical data ‘under the sun’ such as: efficiency, effectiveness, productivity and outcomes; the Romantic longs for something more: meaning. Therefore, and this is very important their emotions must be engaged.

The Romantic will have emotionally internalised the Scrum values, for example, and seek to work and be ethically guided by them as part of their working intuition. They may even internalise them as self-embodied values within other areas or life domains. Thus, they will enjoy experimenting with agility in their personal lives. Thus, when these values are ‘crossed’ there will be a deep sense of disappointment and even shame and regret. The Romantics are therefore, captured by a participative ‘Mission’ that must have an ethical sense of direction.

The Romantics are looking to carefully, and at times, patiently build the ‘Agile City set on a Hill’. Given their need for emotional connection and meaning; when senior leaders fail to make their connection for them by organisational discourse, metaphor and mission statement the Romantics symbolically (and perhaps in reality) ‘lose heart’ and they consequently disengage. The Romantics are deeply connected, on an emotional level, with the ‘Founding Fathers’ and they are seeking to be as true to those initial values as the Founders were. Respect is a key word in their psychological lexicon. Indeed, they are less interested per se, in new ‘brands’ or emergent markets, but rather to co-create new idea, and to solve new problems if and only if, they are underscored by the correct set of values.

Their shadow-side is revealed not be naked resistance (as marked-out so obviously by a Radical), but rather, by ‘going through the motions’. When the shadow falls over the Romantic they somehow seem emotionally ‘hollow’ to their team mates and wider colleagues. It is this sense of an accompanying emotional numbness that psychologically signifies the denial/rejection of things that really do matter (deep down in their soul) to them.

Summary
In this blog I have sought to explore and understand the notion of an Agile community and posited that there might be a number of Agile sub-communities. Why? I have done so in the hope that by articulating the ‘contested space’ of Agility that more harmony, collaboration and legitimacy can be taken-up by different ways of living and indeed being Agile.

It is beyond the scope of this current blog to work through how many of each type are the optimal ‘mix’ given any organisational agile journey. I would imagine that the organisational culture is a key factor?

Jason is a Certified Scrum Professional. He is also a Business Psychologist, as well as a full member of the Association of Project Managers.

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.

agile

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

whatisbpAssociation_for_Project_Management_(logo)

Fixing the project deadline: Agile choices.

There are legitimate reasons why a project would need to have a fixed deadline and although the Agile community would rightly counter this with a range of sensible reasons why you might want a more flexible approach, on occasion a fixed deadline is a non-negotiable contractual characteristic.

What is fascinating is that Scrum, as a method, seems to me to be more effective when there are relatively known quantities (such as Requirements or Features) and then during the course of a number of short iterations and shipping of completed and usable/working code empirical comparisons can be made between expectations and actual. Of course, we can make this comparative analysis between actual and forecast costs in both types: capital and revenue as part of budget analysis.

One of the headlines that grabbed my attention this week was this one:New British Airways direct flight from London Gatwick to New York’. This is good news for those of us that have friends, family and colleagues in New York. It is fair to say that the BA have turned the proverbial corner with the latest fiscal analysis suggesting that AG (the firm that to all intents and purposes own BA) have reported a 25% rise in profits to a new level of some £315 million for the 3-months (quarter) up to 30th June 2015. This is an impressive set of business results.

plane

Chief executive Willie Walsh told the BBC that the impressive changes to the airlines operating model highlighted the “underlying strength of the airlines” which is encouraging.

But what about agile working? How does this fit? Does it play a part?

We need to go back in time to make sense of the Agile change. Back in 2009 BA were facing a horrendous situation and the time for tough and testing decisions to be made. At that time BA CIO made the statement that both “lean and Agile as part of continuous improvement will help us beat the downturn”also expressed as the global recession.

BA then cut around 2,500 jobs in 2009. It then addressed an outdated operating model that was fit-for-purpose historically, but was found ‘lacking’ in these new and testing times. Interestingly, in 2010 Paul Coby, the CIO when addressing a business conference in London made the following key announcement and observation “We need smart innovation and smart change leveraged by technology. Lean and Agile are becoming key enablers”. Notice that back in 2010 and then read again the rise in 25% quarterly profits. There is something close to prophetic in Paul’s words. #leadership.

But what of the staff that had to be re-trained, coached, and deployed in Lean and Agile methods. A few years later the new Head of IT delivery, Mike Croucher made two observations of their journey of transformation that created a more flexible, agile and successful business operating model enabled by IT:

“The first thing I’d point to is the value that we’ve driven for the company, because that’s the reason why we’re in business.

And the second thing is the way it has motivated many of our people in IT. Some have said it has changed their lives.” #changedlives

What many people are less aware of is that BA typically run fixed-term projects of around 6-months. This helps co-ordination as well as ensuring that the ‘time-boxed’ Sprint philosophy runs all the way down into the governance framework and light touch paperwork across the portfolio. #light:tight

In this way, the maximum business value and wider benefits are the central discussion point. The Agile team via the Product Owners prioritization of the Stories are focused on value. Let’s get the maximum value or return on our investment (ROI). Release management is a little easier to co-ordinate too. This has built confidence in Agile across all the business units and within the wider culture.

Can you imagine the conversations that start with: How do we maximise the ROI? That is an exciting place to contribute… that’s where the edge truly is.

I enjoy those conversations in my own work-place. I’ve witnessed the changes in behaviour, attitudes and collaboration when conversations are ‘framed’ in this way. From the largest Epic down to the smallest and elegantly sliced Story let’s ensure ROI is up front and central. Agile is all about value. And if we need to fix the deadline to help our thinking then let’s do just that.

fixed

As this important case-study has demonstrated having a fixed project deadline can be a successful methods for implementation and co-ordination for IT transformational programmes and projects.

Take care Jason

Business Agility: What’s the added value of Senior Management Coaching?

The role of senior management in setting the business strategic design, development and implementation is well researched with a firm evidence-base. What is less well-known are the ways by which cultural change is enabled by coaching when it comes to a stated aim to become ‘more agile’.

51NwqclfWbL._SX331_BO1,204,203,200_

Thankfully there are resources which add insight, challenge and case-studies from which we can learn. But before that it is worth briefly stating the subtle difference between an espoused value and an actual value. In the past I have worked in organisations were there is a total contradiction between the two which creates all manner of professional headaches. Consider a healthcare provider claiming that they genuinely care for their patients; and then receive patient complaints and feedback that in reality they are consistently rude, dismissive and unkind.  That’s a contradiction.

I’ve also worked in organisations where there is a distinctive, but more of a degree, of difference between their espoused and lived values. For example, several years ago one organisation claimed that our people are our most valuable asset and yet their staff satisfaction surveys were in the lower quartile of their industry benchmark. In this case, there was an organisational development programme to ‘close the gap’ between the desired and actual state. This, to be fair, is not uncommon. It is why cultural transformation for genuine practitioners takes time. There is no ‘quick fix’.

But what of agility? There is little doubt in my mind that agility might well be, or yet become, another management fad or fashion. There are several reasons for this possibility, and I will address one. In a previous blog I have looked back and traced various management ‘fads and fashions’ as well as shifts and movements in management theory, practice and aims. I will not be repeating that analysis in here. However, just to make the point that a stated aim is not reality. Cultural analysis aka Edgar Schein (1987) makes the point that one of the key points of analysis is the actual business policies, practices and staff attitudes.

How do we go about improving agility? Having trained Scrum Masters and teams is without doubt a significant investment with identifiable and quantifiable returns. That’s one key intervention.

The next has to be senior management as their role (leadership) as key ‘influencers and shapers’ of cultural change has, in my professional experience, a three-fold impact when compared to team investment alone. Yes three-fold! If you are looking to increase understanding, practice, pace and collaboration across all business Divisions or Units-then this is an intervention worthy of merit and serious consideration.

(If you happen to be a public sector organisation then I’ve also had a Non-Executive Agile Lead. This is also a good idea. It can complement the Coaching).

But what of the leadership coaching approach? What are the leadership behaviours? Thankfully, there is a first-class resource by Brian Wernham that has, through careful and considered case-study research, identified a set of 9 leadership behaviours that can add value to any Coach.

I have found these to have face validity and genuine added-value practice. Well worth a serious study and reflection. There is also this fab webinar that the APM invited Brian to discuss some of his key ideas in:-

So if you are looking to ‘close the gap’ between your strategic values and your current business operating model/practices what is stopping you? Is it time for senior management Coaching?

Take care Jason

whatisbpAssociation_for_Project_Management_(logo)

Jason is a Business Psychologist, Scrum Master and Registered Project Manager.