Alasdair's Blog - Alasdair's insights into how Agile & Scrum works in our world. - agile

Showcase, Show & Tell or Sprint Review

18 October, 2018

The topic of my blog today is another one that is common on client's sites especially large scale agile delivery transformations using Scrum as the delivery Framework of choice. In this situation, there is likely to be a broad mix of people fulfilling the role of Scrum Master within the Scrum teams. These could be client staff both with previous experience and those being skilled to take on the role long term with no previous experience. It will likely include permanent staff from at least one of the big Technology Consultancies or System Integrators as well as a range of short-term contract staff engaged directly or through one of the other suppliers.
With this range of backgrounds and experience, it is no surprise that not everyone will be using a common terminology but will adopt the terminology from the cultures where they have already implemented agile or scrum. However, it is disappointing that many words have become synonymous for a critical event in Scrum which requires clear and specific outcomes from the event that ensure the Scrum Team can progress forward with the product delivery in an effective manner.
Firstly, there is nothing wrong with any of the specific events whether a Show & Tell, Showcase or Sprint Review when used correctly to achieve the desired and intended outcome from each event. This does not make them equal to each other as events, that are interchangeable and precisely the same in nature. At a time when it is quite important that there is a similar message being delivered across teams that include client staff, we should endeavour to create a shared language within the organisation or delivery centre. By doing so, this will enable those who are recipients of knowledge transfer in the transition of practices and development of new skills so that they organisationally embed while being continued once the supplier change agents leave.
My overall view on this has been formulated and adapted from working in many of these environments with many different people who are certified across all the options available in agile & scrum. My specific view as a PST is that in scrum we should use the language of Scrum and avoid this mashup of terminology that has somehow morphed into the agile methodology. That said mainly the agreed view from the communities I have worked with matches the use of terms in the Scrum Guide so does not conflict with any training based on this while at the same time giving extra tools/events that can be used to share information.
There is a specific intent to the event at the end of a sprint that serves as an inspect and adapt point for the scrum team and stakeholders to assess delivery of the product. If the intent of this event to be a shared inspect and adapt point by the Scrum Team, Stakeholders and other feedback or interested parties that the Product Owner feels are correct to gain insights from. Then the intent of the session is not being fulfilled, and this is not a correct implementation of Scrum or an effective way to gain feedback on the product. Words have meanings and are interpreted by those who receive them, and we have found that although Show & Tells, as well as Showcasing, are excellent events to impart messages to an audience they imply a one-way conversation. From experience the majority of Scrum implementations where the Sprint Review is run as a Show & Tell or a Showcase then this is the format of event that the team delivers to itself and interested stakeholders. This can result in a failure of the team to self-inspect the delivered product regarding the stakeholder's expectations and the belief that the stakeholders have been invited only as interested parties without any real right to comment. In turn this leads to demands by inexperienced teams to protect them from critical comments by stakeholders during this time while welcoming any comments that praise the work they have delivered as if they were unreasonable demands by senior management to give input out with the process of scrum by speaking to the Development Team instead of the Product Owner.
It is crucial to the Scrum Teams development as a team that they understand that the Sprint Review as the actual inspect and adapt event is a two-way process and the best opportunity they have to take feedback directly from wider stakeholders. Without having to add additional events that would take them away from work being delivered during the sprint. It is also essential for the Scrum Team to understand that in showing a working solution during the Sprint Review what the stakeholders see may cause them to have further insights or for knowledge about the product to emerge. The straightforward explanation of this is that in the beginning, it may seem right to have a design that includes a black background with white text on it. However a Scrum Team utilising user research correctly would quickly find out that many people have issues trying to read the content and would likely lead them to review this and discuss with the Product Owner the reasons to change this to something which users would find more comfortable to engage with and therefore drive more use of the solution. If this is acceptable emerging knowledge for the Development Team to expose during the Sprint and the Product Owner is happy to accept the change based on the explanation. Then why would this be any different if it was the wider stakeholders during the Sprint Review that gave this feedback? This is the intent of the Sprint Review to inspect the delivered increment as a product along with the Product Backlog as an artefact to inspect if the contents and ordering are still relevant given the inspection of the Done Increment being reviewed.
Show & Tells along with Showcases are beneficial events to run during the Sprint when the Scrum Team is engaging with more extensive interested parties who may fall under the traditional RACI theory of interested party. If the Scrum Team wants some quick feedback on a work item being delivered, then a Show & Tell to the selected parties they believe can give that feedback is an excellent choice to make. If the delivery centre or its management wants to make information on the products, it is delivering known to its full community or wider organisation communities. Then Showcasing is a great event to use at this point to let people know what is being worked on and available with the details of the team to contact should they require more detailed information.
The short snappy answer to this that many of my colleagues have agreed with over the years is that "The Sprint Review may contain a Show & Tell, however a Show & Tell on its own does not fulfil the requirement of the Sprint Review".

Agility in a healthcare environment

15 October, 2018

One of the frequently repeating questions within Agile Business Transformation coaching centres around stakeholders questioning how agile can be applied to business processes as it is supposedly a software development methodology. Excluding the obvious errors in this assumption starting from the point there is no "Agile Methodology".  I thought it would be good to show how as a customer I went through a non-software development process this summer where the organisation has applied Lean Thinking and some Kanban practices to deliver a more customer-focused service.

So on to the main content and points of the blog. Unfortunately, in July this year 2018, I was given the diagnosis of Lung Cancer with a tumour in my right lung, uppermost lobe. My initial thoughts after this were influenced by the empirical evidence of personal experience in the past. I was not expecting a quick response from the existing health system. However, my expectations could not have been further from reality at least in the Health Trust area I currently live in South Tees. Within two weeks I was being brought into specialist clinics, and the options explained based on a very much Test Driven Triage system.

The test route is shown below in figure 1, but it starts from the identification of a tumour, is it a single instance within one lobe of the lung, is it Non small cell cancer or Small cell lung cancer (type), is it far enough away from the windpipe or other significant medical risk and has it spread to the lymph nodes. If after the first two have been identified as positive the others test as negative, then in South Tees the person will be a candidate for surgery and find themselves in a whirlwind of events to prove this and expedite the process to get the person to treatment as efficiently and effectively as possible.

Figure 1;



These test events on average I understand from discussions with my consultants are one per week although I did have to stall a couple until a second week myself to allow for conflicts I had with work commitments. They were accommodating in a couple of instances this happened and even taking account of that the lead time up to the surgery event or ‘Doing' in basic Kanban board terms was only six weeks.
Depending on how much the person involved is discussing with their consultants and treatment team. The person will soon figure out that a whole multi-disciplinary team has been considering the best routes to a favourable prognosis as an outcome even before the person was first given the diagnosis. This is to enable the Test Driven Triage process but also if at any point the person drops out of this expedite lane they are ready to support the person with alternative treatments.

If after completing the triage the person remains a candidate for surgery, they will undergo two procedures the first being a bronchoscopy/mediastinoscopy as a final check on the Lymph nodes and if this is clear the next will be the selected treatment surgery to remove the cancer. On turning up at the ward where the operation will take place the signs of Lean Principles and Kanban are evident. The person is met by their direct care team who will settle the person in and carry out the final checks for any allergies to the equipment and supplies that will be used in the surgery process.

Once this is complete, they are finished with the Planning phase of the workflow and as a work item are now ready to progress into the Doing of the treatment process. Depending on where the person is on the schedule the next phase is to be taken to the surgical theatre and once this is complete to the High Dependency part of the Ward for initial recovery. Then once in a stable condition returned to the normal rooms in the ward and over to the recovery care team who will look after the person until being discharged. Due to the nature of healthcare being 24 hrs it is not possible for a single set of people to form the care team for that whole period. Therefore, one of the standard practices in Kanban the Daily Stand Up is held at shift change over time. At this time the people assigned to the person for that shift will talk to each other directly within the overall group using the automatically and manually collected data to address any concerns or signify that the person is ready for discharge.

Just as in the Test Driven Triage there are test criteria that indicate successful outcomes after the surgery and some of these are automated while others require the care team to collect and interpret. These include such things as basic vitals blood pressure and oxygen rates both of which if the person is connected to the monitoring machines are automatically monitored by the central care team. Others such as air in the lung cavity, chest x-ray, physical movement and daily activities to take care of yourself are observed by the care team and questioned if they are happening when they take the support readings to the automated monitoring system.

Just as in Test Driven Development where a failing test is written that the developer must satisfy with a coded solution until the test passes. Initially, the tests are considered similar to failing as in the person hasn’t passed yet to get home. As the results improve and stabilise these Red Tests turn Green. When the care team consider the critical set of tests to be passed the persons' current treatment, e.g. the surgery is considered ‘Done’ as in Kanban terms for that particular work item.

It was interesting how they used the ward, rooms and bed almost as a physical Kanban Board with the person being moved around during each of the phases of treatment delivery. In addition, a blue folder is maintained with each person attached to the bed. This forms the single source of truth for every decision, treatment activity or outcome during the treatment. This blue folder stays with the person and their bed everywhere they go within the ward, and all results are added.

I started this blog from the position that the topic of adapting agile "software development" principles, methodologies and frameworks to non IT business departments is one of the common questions and myths. In the assumption that these are specific to software development and can't be adopted within business domains. This is even more prevalent when the organisations are in regulated sectors of the economy. If there are any readers of this blog article, who are currently facing the issues of adopting change within their organisation and considering how this can be achieved. Hopefully, this will give at least one example of how a transformation to a more agile in meeting customer needs way of working can be achieved.

It should be noted though that Business Transformation whether considering agile or otherwise is not identifying the correct new methodology which the organisation picks parts that allow them to continue working in the existing ways they have always worked. It requires identification of what value means to the customer and the organisation. So that organisationally the principles & practices that will deliver this value can be adopted to ensure the organisation continues to maximise its opportunities to the benefit of its customers and the organisation itself.

The underlying topic of the content and service provided can be somewhat emotional and may have affected people reading this in a negative manner. Therefore, I would ask everyone to focus on the application of Lean & Kanban as part of a transformation to being more agile in how they serve their customers and not add comments based directly on the medical condition itself. For those who know me and would like to send a personal comment, there is a multitude of ways to get in touch such as telephone, email or social media otherwise I will consider that all readers would send best wishes. I would also highlight that I can only comment on my route to and through treatment as that is what I have experience of. Although I expect that the decision making and process framework as being described is likely to have a similar structure.

The ultimate positive for all is that as the service provider moves more towards this way of customer centred delivery of treatment and a lot more treatments are coming online to allow them to do this. It will enable them to personalise outcomes to the need of the user in the same way the software development community has done with UCD and UX focused development.
If anyone requires further information on any of the specific topics related to cancer and its treatment, please consult with your medical practitioner and relevant information on Cancer Research UK.