Thursday, 23 February 2017


Today I attended a full day training session on ‘Scrum’ - part of the Agile development methodology. The training was organised by our development team, and we in PIU were keen to attend to understand where similarities in approach between Lean and Agile could be useful, and where differences that could trip us up might lie.

The training was engaging and interesting, and our trainer Tom Sedge had extensive knowledge of the subject. He explained that there were considerable similarities between Lean and Agile, and he was not wrong.
I want to focus here, not on what Lean and Scrum are, but on the similarities between the approaches.


IMG_4289.jpgFirst up - the common nature of the problems Lean and Agile are designed to solve. Training attendees (most of them working in development in one way or another) produced a list remarkably similar to the one we see in our process improvement projects.


The ‘Agile mindset’ maps more or less directly on to concepts in lean to do with the ‘servant-leader’, respect for people’s skills knowledge and experience, and making decisions about the work as near as possible to the place and people where the work happens, and seeking continuous improvement in small increments,


In terms of structure and process, similarities exist between the ‘Daily Scrum’ where progress is checked and problems highlighted, and the daily improvement meeting in lean - designed for the same purpose and running (usually) for no more than 15 minutes. The ‘Scrum Master’ for the scrum meeting, and for the general running of the ‘sprints’ which is where the productive work happens, is seen not as a manager, but as a ‘servant’ to the development team. Lean specifically recognises that managers are ‘unproductive’ and their role is to support those who are ‘doing the real work’.
For our projects, the Project co-ordinator fulfills a similar role, and is chosen not for their management position, but for their facilitative and organisational skills.
Each ‘sprint’, running for two to four weeks, corresponds to the lean notion of implementing change in small, achievable, chunks.
The visual nature of the control mechanisms in place in the scrum method - The Kanban board - has a direct parallel in the lean world, and indeed the name comes from a lean term. We’re really keen on visual management in PIU, and I was delighted to see a representative from a software training consultancy arguing strongly for a simple solution based on a whiteboard rather than complicated software! Importantly the concept of ‘pulling the work’ is being used, rather than the traditional management push on to potentially overloaded workers.
I also noted that only two ‘sprints’ (or work packages) are ideally ready to be worked on at one time. This means that the work necessary in specifying the real work is kept to a minimum, done only when necessary, and replenished when necessary, again using the pull principle. This has two benefits:
  • It saves effort on development of work which may not be done in the near future (or ever if circumstances change)
  • It allows for greater understanding of the necessary work before it is attempted

Again, this is the Lean ‘Just in Time’ principle at work.

There was a lot more to the training - the concept of sprint burndown seemed to me to be similar to the concept of takt time for example, and the notion of quick decision-making in an uncertain and imperfect environment.


We  were asked at the end of the day what we  will implement as a result of the training - a really useful training technique to encourage people to think actively - and I came away thinking that we should consider whether to tighten up our implementation plans so that they resemble more the ‘sprints’ of scrum. It seems to me that this would have benefits in concentrating teams’ minds, and in producing work packages that provided real benefits in a short time.
I also really like the ‘planning poker’ cards - not really planning or poker but used to quickly estimate the time to do a piece of work. I’m sure we could make use of these and there’s evidently a ready supply in the department already.

More Work

I have some research to do as well. The ‘Stacey Matrix’ is a useful prioritisation tool, and I need to find out more about the Agile Manifesto.

Thursday, 2 February 2017

The Power of Observation

One of the value adding activities that PIU offers is facilitation of process improvement events and workshops. How do we evidence that this is value adding?

We always ask for feedback from our project teams about our facilitation, and have consistently score well – although I sometimes worry that the outcomes of the event bias the facilitation score (and I recognise these factors are not mutually exclusive.

We always try to co-facilitate our events and this helps our reflective practice. My concern is that sometimes there is a risk that we reinforce the wrong behaviour (with the best of intentions – we all like to be supportive colleagues, constructive feedback isn’t always easy).

Recently we have had two external people who kindly gave up their time to observe and feedback on PIU’s facilitation skills and practice.

One of the concepts we often talk to our project teams and training practitioners about is Gemba (going to where the work happens) and how powerful observing a process can be to get some data about performance. We also warn people that it is likely if this happens as a one off (or rare) activity this can effect how the process performs. Regular, informed and supportive gemba walks or observations need to be in place to truly gain insight into process performance.

The first observation happened last week when the Engineering Timetabling Team agreed to have an external in the room. We put in place a confidentiality agreement and the team were very clear that the focus was on PIU facilitation not their comments or behaviour. I found this quite daunting, even though it is an activity that I am confident in delivering.

For me it was essential that the person recognised that their role was peer-support, and they were keen to learn as well as give constructive feedback.

At first I was conscious that being observed did change my behaviour, I found myself making eye contact with them rather than the project team. However, it was a four day event and I soon forgot that they were in the room and focused on the task in hand. 

Did it change my practice? Probably. It had a positive effect on my facilitation of the event. I was more focused than usual on how I was running the event and probably a little more thorough with my preparation.

What did I learn?  The feedback was incredibly constructive (and positive) which was really helpful. I had time to discuss points that I had been concerned about how I had introduced a couple of activities and a couple of times when I may have misjudged the mood of the room E.g There was one point when they were very tired and I probably should have used the time differently.  Knowing that I was going to receive feedback absolutely made me reflect more on how I had performed.

Why agree to be observed a second time? Perhaps I’m a glutton for punishment, I had another external person observe a customer journey mapping workshop this week. This time the observer was from outside of Higher Education, I welcomed getting feedback from someone outside of the sector, lean principle no. 5 (pursue perfection) for me means constantly striving to be the very best. It is my view that learning from other sectors can help us look beyond our comfort zones and inform our vision with regard to perfection.

Would I agree to be observed again? Absolutely, I also highly recommend it to others!

I am grateful to the participants of the workshops for allowing an external person into the room. I also offer a big thank you to Paula and Simon for their time and constructive feedback.