I recently had first-hand experience of my local hospital’s Accident and Emergency department. Luckily it was nothing serious. Just another case of a grown man who should know better.

My local hospital, like many in the UK is very busy. People turn up to A&E departments with relatively minor injury’s like myself, through to urgent and life threatening conditions.  Work comes into the department in various ways, whether that be someone simply turning up off the street, a referral from a GP or the 111 service or in an ambulance. The nurses, doctors and support staff in the department are finite resources and the department is also under pressure to see all patients within 4 hrs.

In order to deal with unpredictable workload the A&E department uses a triage process to quickly assess all new patients. Here the patient’s condition is assessed. Sometimes information is already known because the patient has been referred or it comes from the paramedic crews.  In other cases the patient has to answer a number of questions and may have to be examined.  The result is a priority ordered queue where the most serious cases are at the top and the less urgent at the bottom. I was interested to note that the department provided dedicated resources for the triage process ensuring work was prioritised as quickly as possible.  I also could see that the team had a feed of inbound emergency cases with what I assumed was a brief description of the case. I guess that this would give the department enough time to scale up its resources in the case of a serious emergency situation with multiple casualties.

A person walking up to the A&E reception is like new work coming into an Agile delivery team. Work needs to be captured, understood and prioritised quickly. It would be surprising if the new work coming into an Agile team was a constant flow so it is usually unnecessary to have a permanent triage process but it is important to recognise one is required and to establish a routine for assessing new work. The result of the triage process is an item in the project backlog. Its position represents its priority. In incremental Agile models that work could be a candidate for the next sprint. In a pure pull model it could be at the top of the backlog and the next item the team deals with once someone is free.

In an incremental model the underlying assumption is that you can always wait for the next sprint to deal with the new work. Adding new work to the current sprint is an exception rather than a rule because the sprint boundary is intended to provide a calm and tranquil space for the team. Changing priority can be disruptive and reduces team effectiveness. Pull models deals with this better because you only have to wait until someone in the team is free. The time to wait is a function of the average time to complete work items. Therefore it follows, the smaller the size of the work item, the lower the wait time.

But what about the serious emergency cases where time is of the essence? It may be the case that waiting for a member of the team to be free is too long. In IT this might be represented by a critical live issue reported by your best customer. Here you might not be able to wait for two, three or four weeks for a sprint to end. Going back to my observations at the hospital it was clear the department was split into two. Major and minor cases were physically separated. I can only speculate at this point but I am guessing that there are two resource pools dealing with major and minor cases separately. This mirrors the way that some organisations have dedicated teams that deal with support fixes and others that deal with new features.

When setting up a single team you have to choose a methodology based on the types of changes that are coming through. If you are building a new product and you have limited customers there is a small window for major issues to occur so an incremental model could be a good fit. Major issues are rare and an exception and are treated as such. However if support issues are the bulk of the team’s work than a pure pull model may be better. As your product develops you may change from an incremental model to a pure pull model or you may set up different teams working in different ways.

The final thing I want to highlight is the way that work is allocated. It is obvious that in the A&E situation the team must be able to deal with any case. It would be unacceptable if a serious  case was not looked at simply because the next available team member couldn’t work that case. In some situations the team might have to self-organise to ensure the right team member is working the right cases but re-organisation is focused around priority order and not personal preference. A team member coming free doesn’t browse the backlog looking for a case they’d like to do, they do the next one. And finally when in the middle of a procedure with a patient a doctor doesn’t stop what they are doing to start working on something else. They keep work in progress minimised and finish the procedure they started. This is fundamental to ensuring work flows and the team is effective.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s