Is there a White elephant in the Agile Camp?

So what is this White elephant in the Agile camp?

Well, I am thinking that all team based work-flows have components of process and practices. So, when it comes to Agile approaches why are some not more explicit about the process components? Let me explain.

In the webinar by Alan Shalloway, where he presented The Different Agile Approaches: First (XP, Scrum) and Second (Lean/Kanban) Generation Methods. On seeing the tabulated difference/similarities with Agile approaches (Scrum, XP, Kanban, Scrumban) a light bulb went on, especially when he was talking about TOC (Eli Goldratt).

So, for sometime I have been thinking based on my experience, when using Scrum approach in developing projects, and this doesn’t have to be limited to software projects only, that one looses sight of the critical path that is otherwise formally expressed if the project was to be planned out in detail based on the assumption that all requirements have been expressed, collected and analyzed. Now, I am not suggesting we go back to doing waterfall when it comes to software development just to gain what the critical path in the project is. However, what I am suggesting is that bottlenecks arise quite naturally in any team based work-flow, making team resources and/or the work area critical path and in the way of the flow. In fact this is common in any thing that exhibits network like behavior. So for instance you see bottlenecks on a daily basis on freeways or even at grocery check outs as capacity limits are reached at some points on the path. Based on this I realize the following:

In reality all team based work-flows have a process component and a practice component. So when it comes to getting things done (GTD, David Allen), the best approach is to deal with requests in small batches, tune the practice of work according to the flow experienced in the process with the purpose of maintaining a harmony between these two components. For software development the process steps are often just thought of as A.D.D.T, Analysis, Design, Develop, Test. Well actually the D.T process step, well the practice is intertwined especially if you adopt TDD, but lets just say there is a final acceptance test.

Now secretly but surely, lets all say it all together: This doesn’t make it waterfall development. As pointed out in Alan’s presentation that at the granular level you have to follow these steps and really its a matter of scale. Small batch, iterative development approach not waiting for all the project requirements have been nailed down first before coding is clearly the root for any Agile approach. Seriously though, its unfortunate that for quite some time the term waterfall is used as mud, often to harass scrum teams with. This is often by some layer of management and at times scrum masters, who are pushing for team velocity over say helping the team overcome systemic issues that an explicit process of steps would have helped uncover.

When it comes to the Kanban approach, and specifically WIP Limits. Well at the team level this expresses what is needed to get and maintain the practice in harmony with the process. In software development TDD, ATDD, CI & some of the XP practices are patterns that best help in creating a resonance between the practice and the process.

So what of orchestrating this at the enterprise level, which really means work of multiple teams where some have cross team dependencies, potentially dealing with multiple products and at times vying for constrained resources. I see each team has its own harmonic and the following questions came to mind:

[Q] How does one conduct such an orchestra?

- For instance with Scrum, its stated that there ought to be an SOS but as far as I know nothing else is spelled out about SOS. It’s assumed that this follows the pattern of Scrum, Fractal view of Scrum. However, in absence of any specific guide and best practice I’ve witnessed SOS being used to air out an issue log, with out the same level of accountability, transparency and expectation being prescribed as it is at the individual scrum team level. In fact the way I see it SOS team should have a prioritized backlog (in my thinking issue log expresses one level of acceptance criteria) representing the product|sprint backlog. This in turn helps with the business decision-making, including the business of product releases at the enterprise level as well as aligning elements of the business operations (marketing, sales, operations, finance, support etc.) to enable customers can attain the best value. I would say the paper on Enterprise Scrum by Dan Greening better expresses how to orchestrate this with a top-down approach at the enterprise level.

[Q] What is the process at this level?

- I can only think of the overall release process for the domain, in software environments this is some combination of (release engineering, support, marketing, sales, education …)

[Q] What are the patterns that can be called on to help reduce the impedance and create smooth flow at this level?

- Can’t think what this would be right now, but recognize that there must be patterns to deal with bottlenecks at this level too. I think what ever it is, must include “effective collaboration”, meaning things that need to get everyone on the same page and hopefully on a single glass pane.

Finally, as for TOC this is well recognized in critical chain planning, a technique used in traditionally planned projects to balance critical resource on a critical path. This leads to the other observation, that I think Alan was expressing, and I have seen frustration in both software and technical operations teams when it comes to Scrum. Whether its Scrum or XP, the frameworks don’t prescribe or guide the team to pick a process path that is best suited for their domain. Even worse is that most practitioners (scrum masters, coaches etc.) don’t see this hole and thus fail to guide teams in addressing this during the adoption phase, often resulting in the cargo cult behaviour, or as I call it monkey see monkey do. The way I see it, process expresses work-flow, transition states and interfaces for hand-offs in the chain of adding value to the product. For instance in technical operations I’ve seen poor handoff’s, and in a way I am sure this implies poorly defined or agreed upon acceptance criteria. There is no doubt in my mind that this was but one symptom of poorly expressed and agreed upon work-flow process that the Agile practice, in this case trying to bolt on the same Scrum framework that the development teams were using, helped expose. Alas in the same environment the core principle of the Agile practice, one of continuous improvement or Kaizen really meant just tinkering rather then seeing the whole work chain and recognizing the constraints for what they were.

So what does this all mean? and why does it matter? Well for one, which ever Agile framework you pick make sure you explicitly specify the process component that you want teams to subscribe to. This will help mature teams to become that much more self organizing and less dependent on manager types to make decisions for them when they hit bottlenecks (constraints) or when the team needs to set right level of expectations with other teams within the organization.

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