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.

Kanban – Definition in post twitter age of 140 characters or less

Agile Blog Define Kanban in 130 Characters or Less — Can You Do It? http://ow.ly/16nSrq

Here is how I see Kanban -

Managed & visualized team work practices and work flow, reducing bottlenecks at a sustainable team rhythm, continuously adding value to customers

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 practices in a hospital

Since my last posting on this subject, with a family member having been admitted into care in a hospital I was able to talk to other health professionals who particpated in the care giving. For the past two weeks, I had the impression of smooth flow and wait free attendance of the care and auxiliary staff who needed to attend to the care and recovery of one particular patient at hand. I had sampled the Nursing staff who were explicitly assigned on the ward when sharing what I had observed.

However, its quite possible I have conveyed skewed perspective given that my daily visits were around the same time window between 12:00 – 2:30 pm. I managed to discuss my observation of what appeared to be smooth flow in providing the patient with the daily need in care (medicine, meals, clean up, exercise etc.) with couple of the aides who came in to give a breathing treatment, this usually lasting no more then 15 minutes. It works out that not every task, even the medical treatment task, appears on the ward Scrum board that I had previously mentioned. In fact he pointed out that his daily orders of which patients to attend to for this particular type of treatment appeared from the Pharmacy. He pointed out, more often than appearances had so far led me to believe, there would be a bottle neck in the patients room with number of care personal trying to serve one need or another. This resulted in waiting and lining up similar to the lines we see at a grocery check out – his exact statement. Fortunately they have some slack and really freedom to coordinate their time, so often they’d go to a nearest patient needing service and return there after. No doubt there are others who may not be permanent fixtures to the ward but do provide service to it that have similar experience, and waiting may not be the only waste that they see or experience.

Clearly, there is room for improvement that can lead to better coordination and collaboration amongst all the care providers. In the ideal case having a shared and common information system, Scrum or Kanban board at the ward level would be of great value. In general I would say at the strategic level there is an opportunity to work at the ward level with all the care staff to Train, Map and Check on Lean principles, in particular their role in helping identify and eliminate waste. I say do this at the ward level, as in my mind this is the effort of a team. Though I consider Lean thinking to take place a many levels, including individual, role as well as team based. I like the following example 8 Wastes with Healthcare examples (ref: Lean Healthcare Exchange).

I also realize that the Paul Levy‘s recent blog Kaizen Corner – standardized work was in part addressing this and the opportunity of better coordination in order to deliver value to the customer. His blog is aptly called Running a Hospital.

Healthcare – Agile/Lean principles and Kanban practices in a hospital ward

Well its been a week since I last reported, with the family member admitted to the ward and the use of 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.

Week 2, things have moved along. They have just today started using the electronic board, more along the lines of the Kanban board that ER. There appeared no fuss in with this change. Didn’t see anyone having kittens about this change, a far cry from what I had observed with some software engineering and/or tech operations teams teams. Clearly the mission of saving or mending lives is a greater leveler in the relative mundane changes with use of new tools and presentation of information. It was late this evening so I didn’t get the opportunity to ask the Nurses what they made of the changes. I will get to this during my next visit and may be even ask the patient coordinator if they have been on any training relating to Lean principles.

I also came across interesting sites/articles relating to Lean in Healthcare

• site: Lean Healthcare Exchange
• blog: Kaizen Corner – standardized work

The blog on standardized work is by a CEO of a large Boston hospital.When I first read this I wasn’t convinced that there is a call for standardized work. You see the work performed by Health care workers is one that touches people when they are most fragile and really some variability is desired by both the care giver and the patient alike. In software engineering there are standards that the coding and testing practices are measured to, but the standards adopted by an organization are used as a framework within which teams are expected to deliver their product. So no two people, though equally trained, will approach laying down the track of code the same way. Within this there is great deal of variability due mainly to style and level of experience.

Besides this standardized work as seen on a Toyota production line is not a comparison one wants to make when addressing Healthcare. For one machines have no cognition nor expectations. My biggest objection with a call for standardized work in health care is that this will replace the rational thinking that is needed, you know the act of doing as it is in the standards. I am sure there is fine balance between standardized work and what may be micro-management.

However, having said this and seeing at first hand the investment in information technology that has been made, I do see the opportunity of standardized process and work flow, as an example the nurses Kanban board. This no doubt can help with better coordination in services the patient receives, such that there is an order in which a particular set of services are best received. This last point is critical idea of standardized work that is addressed in the article. In fact, I realize the article does talk about benefits that can be achieved through standardized process by which work is gated and within which learning occurs. It also points out how visual cues/flags can help signal and thus avoid errors.

…… returning to my original thoughts – I still wonder if they routinely have retrospective meetings that promote Kaizen – continuous improvement.

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

Scrum and XP from the Trenches – a great Scrum Master & Scrum Team notebook, pragmatic with common sense practice for using Scrum

Well, I just finished reading Scrum and XP from the Trenches, by Henrik Kniberg. I found my experience resonated with all the practices that is documented in this scrum masters notebook - a common sense approach to the tactical work of Scrum. I highly recommend this those new to Agile and specifically Scrum. You don’t have to be a Scrum Master to make use of this. Its a fast read with a journey into how Henrik and his teams practiced Scrum. He expresses situations they encountered and what they experimented with. he is good enough to share what was thought of but hadn’t been tried out at the time. The good part of a lightweight framework and practice of Scrum is that you can adapt it to your environment, and as the situation changes tailor the practice to best suit your needs. You don’t have to worry about the Scrum Police, mind you like everything else in life there are purist who insist on practices that they consider a must, of course this contradicts Agile. You can use Lean to assert the Scrum practices that your team is successfully using and living up to the need for transparency, continuous learning and improvement as a result, rapid delivery of what the customer values.

I have no doubt in my mind that you will pick some good practices, as for the best practices well that is for you to work out with your team taking into account your environment (company and team culture, business needs etc.) – context is everything!

As for the must haves (listed below), they are indeed a best practice. The thing about a best practice is that there is no time like now! to start doing

• The Product Owner must have a Product Backlog with estimates created by the team
• The team must have a Burndown chart and know their velocity

Is this a requirement for Scrum ? – A must have ….. Part II

So here is the Part II, a continuation to Part I, where I raised the couple of must haves that have been expressed in Scrum as measured by the iterative Nokia standards – ref: Scrum and XP from the Trenches, by Henrik Kniberg. Just as a reminder the two must haves were stated as:

• The Product Owner must have a Product Backlog with estimates created by the team
• The team must have a Burndown chart and know their velocity

The first of these was dealt with in Part I, so:

• What of the team must have a Burndown chart and know their velocity?

Burndown charts are unique to a team, given the mix of talent and experience, and in reality they are not forward looking – which is to say allowing one to project what is expected in the next sprint based on current burndown chart. They really are a record of past performance and really a barometer in highlighting the anomalies that may have occurred during the sprint that blocked the team achieving what they had planned. During the sprint it is used to signal to the team to make decisions of reallocating resources within the team, doubling down on the most difficult area as well as having the reality check in terms of scope that was targeted for the sprint. This is after all agile in practice, making good sound decisions to support what needs to be done in order to get the team back on its course to meet its commitments. Really I’d like to say such occasions are rare, but the truth is far from this. Lets remind ourselves that the endeavor of software and system development, and really the realm that knowledge and creative workers play in is not a production line, often there are managers who loose sight of this. So at times like this, when decisions are being made, it is helpful for the team to think lean. Ideally one wants the team to think lean through out all iterations, but in particular get into the practice of putting their hat of lean thinking when ever weighing up decisions to address how can the team best to reach the goals that they have committed to. As I said sometimes this may mean doubling down with resources from within the team on a particular task at other times the hard reality may be that the team has overloaded the plate and can’t possibly consume all that in time boxed for the current iteration. The hard reality of decision making may mean delaying the release, this may be especially true if the rhythm of release in your environment is of high frequency, say every week or two weeks versus every three or four months.

So what about knowing your velocity. Let me start by some basic physics, velocity is a vector, it has a direction and magnitude. The magnitude is measured as speed – you know in m/s. Fundamentally given my Engineering and Physics background I have a problem with the loose use of this term to connote what a team is capable of accomplishing as number of story points delivered per iteration or in the macro view story points delivered per release. Aside this objection, one wants to be smart about using this metric in predicting and really looking forward as to what the team is capable of accomplishing. I say smart, as far to often variables that have a strong bearing on this metric may have changed. For instance my experience has been that the team complement changes after one of two releases, or for that matter the release cycle changes, and or most critically one hasn’t sized the backlog to the same standard. After all this is not the repeat cycle of building the same widget over and over. For the greater part there is variability in developing something different but for only using similar patterns that one may have encountered when developing earlier items of the backlog. Even when this is the case there may be new set of complexities that were just not present previously. Far too often stakeholders do a linear intra/extrapolation and then confront the team with the 64,000 dollar question – why not as much as previous releases? Some see it as holding the teams feet to the fire, thats one way to make stew!

My good sense says be pragmatic with use of this metric; first monitor it over a reasonable period of time. Then use statistical methods of measuring standard deviation about the mean that the team should try to achieve. One can set the lower and upper limits that are 6 sigma from the mean in this metric as the boundary points for the pessimistic and optimistic with the mean value representing the most likely in size for delivery during a release. Over time, with the team maturing as a work unit the tolerance may be narrowed down to 3 sigma thus giving higher fidelity in the estimates of what the deliverables are going to look like. In essence work with the team to establish this metric pointing out the use it is going to be put to as there are supporting cast besides the Product Owner, such as Sales, Marketing and Capacity planning, who are in the business of drumming up more customers for the product as well as setting expectations to existing customers.

Fundamentally, are these truly must haves, sure for high performing teams, but such teams are not build in a day or by virtue of few days spent in training on Scrum or one other Agile practices. Truth be told more often then not it is both the organizational and/or team culture that one has to foster in order to achieve teams to become high performing teams in nature. Let me know which team doesn’t want to become high performing and is this even a willful act on the part of the team? – Possibly in an environment that has fostered the wrong culture, but for most part these must haves are a work in progress. By the way these must haves are not the only metrics of measure to assert a team with the title of high performing in nature. I will save this topic for another day.

Is this a requirement for Scrum ? – A must have ….. Part I

I am reading Scrum and XP from the Trenches, by Henrik Kniberg. This is the online edition, written couple of years ago, so I am catching up on some reading what can I say?. Anyways, in a forward for the book, Jeff Sutherland conveys a story from a London conference where there was a discussion about Google’s implementation of Scrum. By the sounds of this discussion this is not Google specific, as there were others who must have participated in this discussion. Jeff had asked questions relating to how many were doing Scrum and really iterative development by Nokia standards. This standard apparently asserts, amongst other things:

• The Product Owner must have a Product Backlog with estimates created by the team
• The team must have a Burndown chart and know their velocity

These two must haves in Scrum as measured by the iterative Nokia standard are interesting, and I will address these in 2 parts, as they open up the following questions:

• When is the Product Backlog considered to be true backlog given that estimates from the team are required to make it so?

Surely the role of the Product Owner is responsible in developing a meaningful product backlog that has been prioritized. When I say meaningful, it means this has been written in a form of User stories (including epics). This backlog is prioritized based on the following needs:

• expressed by customer(s)
• identified as gaps in the market place that not only differentiates the product amongst its competitors, but critically appear on the product roadmap as having strategic value

In a sense the backlog is providing the scope horizon for the product. Clearly in the A, B, C of steps to follow, the items of highest priority on the product backlog will have been reviewed by the team, broken down further if need be and sized with estimates on an arbitrary number scale that the team has agreed on to represent as a common measure. This is a relative scale uniquely representative for this team, it expresses the mix of skills, experience and appetite for risk that this team has – which by the way is unlikely to be represented exactly in the same way by another team. So, during the sizing exercise, which usually takes place during formal planning meetings but there is no reason why a Scrum team can’t decide to size a story one or or more (based on some agreed rule by the team) per week during the current sprint. When ever needed I encourage this practice with the mindset that “a story or two sized keeps long planning sessions at bay” – okay it isn’t as good as an apple a day keeps a dentist away.

Based on my experience to date I have found this practice has been a sustainable approach to having a backlog that is primed for the next sprint. Don’t get me wrong, I am not advocating a long head with detailed planned backlog, clearly this would not be lean not to mention as a process it doesn’t bind the team with commitment in mind either. Lets say, just do enough planning to help prime part of the next sprint. In the mean time the Product Owner, who after all has been interfacing with the customers and has identified what is being valued and needed in the market place can seed the remaining backlog with estimates for size. This helps express the target of what can be expected that is of value for the next release, and in turn allowing other stakeholders from such quarters as engineering, operations, support, sales and marketing to influence and help refine this target. One can expect to have discussions, where you have multiple product teams, around cross dependencies that are going to impact teams and as a result having to reset priorities or refine the product backlog in order to mitigate the impact.

When it comes to estimates for size, it is well known from traditional Project Management techniques that using single point estimates for sizing just doesn’t work. It is far better to make use of statistical estimation, using 3 point estimates and if need be Z scores for % of confidence level to support the basis of the estimate. In the 3 point estimate one can cover the bases of pessimistic, optimistic and most likely estimates accounting for the expert viewpoint, the individual who is committing to do the work and the voice of caution addressing the risks be it in terms of resources available to accomplish all the testing that may be needed to verify and validate the functionality.

So really the conclusion I, and really many others have long ago come to is that the Product backlog is to be imagined as a pebble being dropped in a pool of water. When this occurs, it creates a set of waves some of these are of relative high amplitude, marking close proximity to the center, and then others of relative low amplitude further away you are from the center. The larger ripples closer to the point of drop means greater information being made available, this information has higher fidelity of knowledge supporting it and in contrast to ripples at the edge of the echo where information is imprecise and of low fidelity. Yes the Product backlog is a mix, with higher priority items floating to the top and as these float up they are adorned with more information, including decomposing epic level backlog into component backlog as well as having attributes such as acceptance criterion’s that customers will measure their need being satisfied to.

As for the second must have I will address this in the follow on article.

Coordinating dependencies across teams following Agile or Lean practices

When one is following Agile or Lean practices – using Scrum or Kanban framework, on occasions I have encountered what appears to be gray area when it comes to cross team dependencies. The question that comes to mind, when first encountering this situation – What is the best way to coordinate dependencies across teams and there by ensure that the right and left leg are marching in right, left, right, left … rhythm? (or left, right, left, right … rhythm)

We all know hind sight is 20-20, and having been blind sided at least once, I can say that this has a fair chance of recurring when the dependency is one way. Sure its always easier when dependencies are bi-directional as there is the give and take as both sides have something the other wants. I say blind sided, as often priorities or commitments to deliver do not match across teams. If one is aware of this at the outset then its best to negotiate early. However, in the end it is a matter of good faith or in the interest of maintaining good citizenry that the sprint/cadence for delivering the dependency and the dependent feature are synced up as desired. Of course, my intention is not to sidestep the question, which is rephrased here as –

What are the best 3 practices that can help better coordinate dependencies across teams is the question?

1. Start with good and reliable information in the form of directed dependency graph for the software packages in the system. This helps with the object of the discussion in terms of how many dependencies exist and thus what else is likely to be at risk that may remain hidden to the team that is the provider of the package or service. I doubt if the team is unawares of the direct dependencies, though its possible given the team churn and appearance of new team members who have a relatively short history with the underlying codebase.
2. Develop common information radiators that provide clear visibility to both client & supplier teams relating to the dependency. What constitutes information radiators?. For starters dashboards that capture the view of the product and sprint backlog, defects in the pipeline and really any trend charts capturing a time history in team accomplishments such as story points fulfilled, defects cured. It would be nice to map complexity of ideas accomplished as this can be a better measure for size of story, however quantifying complexity is difficult to do. Critically having a shared rating of the business and/or customer value that is to be delivered as a result of the dependency being fulfilled, as a component in one of the information radiators, is a powerful reminder to the teams when grooming the backlog and readying for a sprint.
3. Have a schedule of facilitated Scrum of Scrum’s (SOS), where the standing agenda is to discuss progress and issues around dependencies, and the participants in these meetings are focused on how best to narrow the critical path seen by the one team or another as a result of the dependency and sprint priority.

As for the directed dependency graph, this is unlikely to be readily available as most development environments are running at a fever pitch to make their next release. This requires a culture of looking ahead which doesn’t come easy to those who ought to be responsible for this, namely the development management team. Often they are too busy being upwardly mobile as opposed to working with developers & architects fostering best practices that lead to such artifacts.

There is the school of thought and misplaced in my humble opinion that being Agile means you don’t need such artifacts as there is little of direct value to the end customers. However, if you evaluate the true value stream that the customer has a perspective on, then on average the cycle time for the right feature includes a portion of time spent with support as well as some time needed to repair the identified defect. In this context, time spent developing and maintaining such artifacts can only help reduce the overall cycle time. Another way of looking at this, and sticking to my earlier metaphor – would you travel on the London Underground or New York metro without a map?

Okay, really its never too late to start – have each team draft up what they believe they see the package related directed dependency graph, this will clear up the cob webs and put the teams on a better footing of common understanding. If you are starting this process from scratch then please don’t do what I have witnessed most recently – which was to get some 45-60 engineering managers, product managers and program managers in a big conference room and then ask them to map out the dependency graph for the planned work of their next release. Yep, there was no real starting point as there was no baseline to work from, and it also broke the cardinal rule for meetings – keep it no more then 7-9 people if you want it to be productive with a reasonable set of communications pathways.

Well as you can imagine 45-60 people that just ended up being a fish market and nothing useful came out of this exercise. Sure we sketched out a dependency graph of sorts, but not one which was useful as their was no integrity as to the basis of what was mapped out. Also be wary of the cargo-cult agilitas, as was the case on this occasion. They surely claimed great success for this event, based on the metric that people were seen talking. If memory serves me right this meeting went on for about 2 hours or so, with most people scrambling to put something up on the white board – very little of what was on the board had basis that you could take away from the room. This may seem consistent with the lean practice of delaying commitment until the last responsible moment, alas this was not about decision making but developing a common set graphs to tee up future discussions on synchronizing and prioritizing foundation work for dependencies.

Ideally the dependency graph should be acyclic, however this is unlikely, especially in a code-base that has evolved over time. By the way there are nice open source tools that can generate UML charts, given your current code-base as input. Of course this will be spaghetti graphs that you may have to filter through in order to have a baseline as far as current dependency graph is concerned.