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


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.


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.


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

Kanban perfect flow- but at what cost?

Over the last few weeks we’ve been improving the flow of the team’s work by adopting Kanban. And to be fair with a significant amount of success, including the experimentation/testing of new ideas, suggestions and ideas from different work areas and/or disciplines. As part of this curiosity, one of the team members emailed me a link to this fascinating case-study from Japan. (This was originally featured in the Wall Street Journal).

The article is entitled:‘Japanese Firm Uses a Single-Worker System to Make Its Products’ with the strap-line stating that ‘With the Help of Digital Tools, Any Roland DG Employee Can Build Any Product’ which is I’ll think you’ll agree quite incredible! 

A bit of contextual information might be useful.

The firm is Roland DG. They are a small company with about $300 million in annual sales and just short of 1,000 employees. Roland DG have quite a broad range of products, and they make everything from billboard printers to machines that shape dental crowns! The key concept is what they refer to as the ‘D-shop’. 

The ‘D-shop’ method means that workers in single-person stalls assemble products from the total end-to-end flow or from start to finish. This is quite something to see in all fairness! Each solitary worker is carefully guided by 3-D graphics and to maximise flow parts are delivered automatically from a rotating rack. The article claims that each and every worker is capable of assembling any variation of the 50 products in their range or portfolio.

The picture (below) captures the sense of a Roland worker making an industrial printer. To this end the employee follows prompts provided on the computer (1), they in turn pull the identified pieces from the rotating parts rack (2) and with using digital screwdrivers (3) that track the precise number of turns and torque so as to ensure the product quality standards.

On a typical day you can find an employee assembling from scratch an industrial printer that ultimately would be more than twice her size and weigh almost 900 pounds. In a different cell, another co-worker was making a prototype milling machine. Then in a third pod or cell another was assembling the dental-crown milling machine. You can easily get the sense of just-in-time production methods fully integrated with the finest Kanban principles for maximising flow including reducing any hand-overs to other workers to zero! Quite incredible. It is reported that workers are rarely confused given the level of training. However,when they are, the design includes a button that when pressed will bring the floor manager running to help within a few seconds.

What do you make of this? For those of us with a professional interest in agile working including Kanban, Lean methods and value streaming etc we would have to concede that the ‘D-shop’ is impressive along a number of criteria. However, when I watch, listen and learn from my own team what is missing, for me, is the social interactions of team-working. I know this seems obvious, but it did strike my interest and chime with my own embodied (and Western) values.

This gives rise to certain questions such as:-

  • What motives us to work or different types of work?
  • What does not?
  • Where are the ‘trade-off’ points?
  • Are workers from Japan different from us in the West?

I’ll pick-up the evidence from the first three points and then lend some speculation to the final point.

In a recent survey 72% of employees ranked “respectful treatment of all employees at all levels” to be the most important factor in job satisfaction. #respect

After that the other factors were:-

  • trust between employees and senior management (64%)
  • benefits (63%)
  • compensation/pay (61%)
  • job security (59%).

(See the Society for Human Resource Management).

The most fascinating insight from the survey was that the actual work itself was ranked all the way down the list to number 11. Of course, if the sector in which you work has fairly stable levels of trust, benefits, pay and security; then by definition, the ways by which the work is organised and made satisfying become all the more important or relevant. This would hold all the more in sector where the supply side for key workers is short and current market demand is high. In this latter scenario work design and job satisfaction are key ingredients for talent recruitment strategies.

So what about our Japanese case-study? Evidently, in this labour market workers are attracted by such modern, clean, well paid and varied work. They seem satisfied with the work design and by that I mean by working in isolated cells or pods. There seems little room for individual or team creativity or innovation to me. And these are key characteristics of Agile.

So they seem to have maximised flow but at what cost? It seems to me the costs are the social and psychological costs that interesting and demanding work brings, and especially in high performing teams. Perhaps it is the history of Scrum within software development that means that I have framed it in this way?

Stated simply, it is evident that these Japanese workers have a qualitatively different psychological work contract to that which underscores our current Western notions of Agile working. It seems that there is then, after all, more to Agile working (and values) than (just?) maximising flow and having the optimal value stream?

Are we, in the main,  social beings that enjoy, delight and find satisfaction in working in teams? This seems to chime true to my experience to date. But I recognise that I have always lived and worked in the West. So there are limits to my experience.


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


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


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

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.