Scrum is just a tool! You choose when and how to use it. Don’t be a slave to it!

I really like the treatment that Henrik Kniberg has given when contrasting Kanban vs. Scrum. He expresses a dialog that is not too dis-similar to conversations I have heard especially in fire-fighting environments that are asked to shoehorn Scrum as this is best thing since sliced bread. Okay, that is a bit of a stretch, as I can do without Scrum but not without food!.

From what I have seen, this shoehorning occurs as usually the impetus is to conform to a mandate coming from a higher authority within an organization. This is usually management needing to use a common methodology by which all business operations that are delivering projects. This being most acute with groups that interface with Engineering teams, where Scrum is usually rolled out first. I’ll go out on a limb here and say Scrum isn’t a methodology. Sure it is a framework of iterative practices to deliver quality product (or services) in small batches. This is aimed to be in concert with the customer, so the customer gets exactly what they want and when they want it. The practices are one of team work and really fostered as bottoms-up approach to solving problems of delivering projects (products or services) that otherwise far often then not have failed to materialize value to the customer as either they are too late to market, at times the wrong thing at the wrong time, or just too costly to be of benefit.

The problem with the top-down approach suggested by mandates I refer to are – that they do not see the whole picture in terms of work flow within an environment. Sure this is a tactical issue of The how? as opposed to The why? when it comes to shoehorning any set of practices, including Scrum. By the way don’t get me wrong, mandates can be a good thing for kick starting change as much as getting everyone pulling the oar in the same direction, and hopefully the right direction. Scrum truly helps in this as it quickly surfaces issues that block team work and allows one to steer the team and potentially organization in the right direction if error is made in charting the wrong direction. I have also witnessed an initial shoehorning exercise where a divisional group lead would say “we just need to do is speak the same vernacular of Scrum that the Engineering teams were doing”, and by implication this will make the group Agile!. If this isn’t cargo cult behaviour then what is?

So you can see why I like the line Scrum is just a tool! You choose when and how to use it. Don’t be a slave to it! is the nub of what Henrik has stated. This is to say one may need to shape and customize how Scrum is practiced in your environment, this includes your Engineering environment and not just roll it out of the box. In order to customize this you’ll first need to identify and analyze some of the first order problems you are seeing in your environment and you wish to solve. It is not enough just to say “we want to deliver quality products or services first to market to our customers”. Tell me who doesn’t want to do that! Scratch this surface statement and ask what is it that is holding you back from doing this today, and which of the Agile work practices such as Scrum or Kanban (Scrum on steroids) mustered in software development environments by XP & TDD practices will best help overcome some of these impediments. Don’t kid yourself with tools of technology if fundamentally communication or timely decision making are the real problems. You’ll need to be honest to yourself at the team level, as well as at the organizational level when dealing with the gap in the Knowing & Doing of what are two critical components leading to less then stellar project work outcomes.

Based on my experience with software development and service operations teams I have to say the pull practices of Kanban, initially instrumented with WIP (work in progress) limits is a better starting point. To some this may be getting teams to swim in the deep end, in truth no more so than taking on a fresh graduate or a new employee and saying okay you are part of the following team. If there is no nurturing in the work practices in your particular environment then one only sees cargo cult behaviour when it comes to Scrum.

In conclusion, I firmly agree Scrum is just a tool!. You choose when and how to use it. Don’t be a slave to it!. Which means weave in team work practices such as Kanban and foster software development teams to adopt XP, TDD as part of the overall Agile framework that you need. The need being defined by the set of first order problems related to team work (individual) and Team Work (organizational) that you as part of a group are trying to solve.

As for the organizational team it will be of great help if you also map the value chain within your organization. This map addresses all the functions that are involved in product or service life cycle, from both the customer view point as well an internal view point. After all customer doesn’t see or experience all the pieces of the jigsaw that brings value to them. Use Lean principles to guide the Agile practices you are adopting and refine these based on your and the teams experience. After all much like a car engine that has to be tuned to match the organizational & team culture, with culture change being on a relatively slow time scale. Which means be patient with the teams and don’t rush to refine before you have some real evidence from the Teams in what is working and what isn’t. Most of all be pragmatic in your approach for nurturing Agile practices, and take great care not to read into the tea leaves of statistics of How well Teams (organizational level) are doing? based on a voting turn out in internal surveys that are lower then the turn out at a U.S election. I have witnessed this too, from those who have a vested interest in calling out the success of the fruits of their labor of rolling out Agile practices. Sure is difficult to be independent even in a Scrum and an Agile environment!.

As for pragmatic, I mean use base principles such as Lean to support the decision making and tune the Agile practices in your software development or otherwise work environment. These principles are tried and tested in many situations, from Lean manufacturing, construction to Lean Health care – and as such not unique for software development. Many have expressed the Lean principles, and currently I am using the following mnemonic D.E.A.D B.S.E (hey, this has nothing to do with the mad cow disease, far from it. It sure is a guide to preventing the effects of this within software development teams ):

• Dilver as fast as possible
• Eliminate Waste
• Amplify Learning
• Delay Decision making
• Build in Integrity
• See the Whole
• Empower the Team

as a reminder to help any team that has to make a decision on some issue that hasn’t been previously encountered and past experience and know how does not point to a clear choice amongst a selection of options. It allows the team to shape Scrum practices and frames a more constructive team discussion then does knowing and doing the Scrum practices alone.

Healthcare – Agile/Lean principles and Kanban/Scrum practices in ER

Yesterday I spent some 7 hours in a local Hospital attending a family member to the ER. That morning, I had quickly scanned through my copy of Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway & James R. Trott. This truly is a bible for Agile teams, note the operative word here is Teams. Anyways, this is my hindsight account of one persons Hospital ER experience, in particular how they have adopted Agile practices and Lean principles, proving to me that the current wave of Agile/Lean in Software development is actually behind the maturity curve of practices that have already been successfully adopted in what is otherwise Life or Death situation. I don’t say this lightly, given the hospital in question is also coping with the turmoil that building expansion brings to otherwise an operational environment.

When entering the ER, given that the family member was in a stable condition i.e not needing to be rushed to an OR theater, first we had to register the patient (register onto the backlog). I had come well prepared with as much detail regarding the patient, including details such as insurance details, age, height, weight, current prescription details, snapshot of test results collected in the past month and finally any changes seen in the past week leading up to the incident needing to rush him to ER. This was all recorded onto the electronic platform. There after we waited some 10-15 minutes to be seen by the Triage Nurse, I later learn from the attending nurse, the people filling in this role are really the overall ER team Product Owner/Champion and Scrum Master. Soon enough we were in ER exam room, as we made our way there I noticed few very large LCD displays along the two corridors that were the main artery through which Nurses, Doctors, Auxiliaries, Diagnosticians made there way when hustling between rooms (exam, medical dispensing store etc.)

During the next 6.5 hours from time to time I studied the LCD panels, and made out that these were really the Kanban/Scrum board – team work board. After the family member is seen to by couple of diagnosticians who performed a range of tests, such as temperature, BP, blood, urine, EKG, X-ray and CT Scan, each test being source of not just greater complexity for the lay person, but more important then this was how smoothly the flow was amongst all these people without ever conflicting in both time or space. As I later learned that all these on-goings was being updated on the Kanban board. Few hours into the ER exam room, when things had quietened down, I asked the attending Nurse:

[Q] How do they coordinate their work effort?
[Q] How should I read the board being displayed on the LCD display?
[Q] How is the board used?

I pointed out how fascinated I was at the smooth flow in work, remember this is an ER room, where the unexpected is the expected. She smiled and briefly explained that the Triage Nurses who take in the patients size the problem and assign resources based on the story. First the allocation is of the Nurse (Technical Champion/Business Analyst) and a Physician (Product Champion).
So I asked:

[Q] How do they ensure no one is gaming the system, and skipping out on the undesirable duties that may come there way?

She pointed out that when assignments are made, this is done based on complexity, number of patients being attended to and availability. The boards were a snapshot of state of the resources (rooms, health workers, diagnostics requested and completed). These boards represented the open and honest communication that allowed the smooth flow within the overall system of managing ER. She pointed out, for instance at sometime she may be attending only 1 or 2 patients, when compared to her colleagues who during that time may be attending to 4 of 5 patients. This really depends on how complex the needs of the patients are. There is a feedback loop on which the Nurses cycle back the size & complexity information to the overall product champion, the triage nurse who defines the assignments.

The interesting thing was the information on the Kanban board, I’ll call it that as this appeared to limit the Work-in-Process (WIP). This had a headline metrics of:
Waiting Room:2 Active Patients:19 Ready: 10 Dirty: 0 WTBS:0 TBADM:3 (the numbers are just part of a snapshot)
(WTBS – waiting to be seen, TBADM – to be admitted, Dirty – room is unoccupied but dirty from work on last patient)

The board by which the team managed its work had following elements (not all elements are listed here)

RN, MD, Gender, Age, Status, LOS, LAB …
(LOS – Length of Stay)

Here is a snapshot of the

ER Kanaban board

In addition to the Kanban board, the Nurse had informed me that when they need more details relating to the story, then they just logon to the system from any number of free standing terminals (on mobile platforms) and get to the centralized information. What was joy to watch, even in the circumstance of a family member in ER, was the sustainable and rhythmic flow of work (cadence). Contrast this to the work of Software Development environments that carry the baggage of being acclaimed with highly compensated information workers who often encounter a hard time with basics like having a open and honest communication channel, daily stand up meetings, decision making that optimizes the overall system, and critically Scrum or Kanban board to instrument smooth work flow by bringing visibility and transparency for the work of the team.

Outside the ER setting and on the ward I saw what I would call a Scrum board, this was a white board by Nurses station on the floor and it indicated assigned stories that a team of Nurses were working on. Some were co-owned and I can only assume that the physical need associated to taking care of the customers (patients) need being that much greater and called for collaboration. In addition to the Scrum board I noticed that the wards were equally dotted with free standing terminals which enabled the Nurses to get to the detailed information that was needed to support the work in progress against each story. I wonder if they routinely have retrospective meetings that promote Kaizen – continuous improvement.

Here let me share what I was thinking of while travelling between floors in the hospital. I put on my Product Champion hat on and figured the following products could greatly increase the efficiency with which each patient/story is managed and thus contribute to optimizing the whole – in this case the Healthcare system. So here are a set of stories (epics) I’d want to have my backlog and humbly say it would be great if:

• At check-in I am able to supply trend charts, in electronic format, for some of the routine snapshots in picture of health and well being. For instance common trend charts could be a time history of Temperature, Blood Pressure, Weight, Blood panel work, Xray etc. as measured at various visits during the course of prior 12 months. There may be trend charts for less frequently measured bio-information such as EKG, CT Scan, Ultrasound (Kidney, Heart etc.). All of this could better define the context and condition of the patient prior to the current event. The trend charts may lend themselves to detecting anomalies in condition and potentially allow for better preventative care.
• Diagnostic equipment (thermometers,blood pressure units, IV feeds) were smart sensors – lets say blue tooth and web services enabled. This follows the Lean principle of eliminating waste where by data is otherwise recorded today in analog form and maintained in a separate paper record system would now be digitally available and integrated within the overall patient record system. One can imagine health workers carrying a handheld device much like the FedEx/UPS delivery crew do, recording and transmitting information off the smart sensors corresponding to the patient in their charge. I have no doubt there are efficiencies of scale that will not only contribute to lowering healthcare cost through following the Lean principles of Optimize the whole (the patient, the resources), Deliver fast and in essence emphasis the two main categories, defined by as the authors of Lean-Agile Pocket Guide for Scrum Teams, as being central to the Lean principles and Agile practices – that of achieve fast flexible flow (A-F-F-F) and Discover what is needed (D-w-i-n).

As a foot note, with the Healthcare reform debate raging let me just add following statement when it comes to testing. In software development one part of the Quality Assurance strategy is to seek greater automation in testing. This is in line with the Lean principles of eliminating waste, deliver fast, optimize the whole and build quality into the software product. In healthcare much is made about over testing and often to the lay person there is a perception that much of the routine testing that one encounters is wasteful, especially if the same parameters are measured on frequent visits. Let me also add the disclaimer that providing trend charts, mentioned above, does not necessarily preclude the need to undertake some or all of the routine tests on each occasion. This data is just snapshots in time and when it comes to health systems I am reminded by the fine print from another health system of sorts, and that of DMV test report. This spells out that its just a snapshot and a pass does not provide mean an assurance against a failure in the near future, may be even on the same day.!