Dhaval Panchal’s - Agile Blog

The term “bottleneck” refers to a point where after the flow or velocity perceptively reduces. It is metaphorically derived from flow of water through a narrow mouthed bottle where the flow of water is constrained by its neck. For drinking purposes it is a good thing as it regulates the flow of water through the bottle to the drinker, preventing wasteful spillage. Bottleneck’s though constraining can be both a good thing and a bad thing, depending on desirability from the system.

The scrum framework contains product backlog which is essentially a queue (stack ranked, one after the other) of product backlog items (PBI’s) that the scrum team has to complete. Queue’s/backlog’s don’t feel good. Think about the last time you were in a rush and had to go to a bank where you stood in a queue behind fifteen people before the teller addressed your needs. Or the time you had to stand in queue to board your daily commute bus - uncertain whether you will get a chance to board this bus before the driver declares “its full” and rides on. There is the frustration of waiting in a line and the uncertainty of whether you will make it. If PBI’s could feel, then I guess they would empathize with people stuck in queues.

IMO, inherent assumption within complex software product development efforts is that

the business will always have more concepts or requirements than the team’s capacity to transform these into potentially shippable product increments.

If this assumption holds true for you then your product backlog expresses the aggregate effect of bottlenecks that exists downstream in your system. In other words, if there were no bottlenecks or team had infinite capacity then the all the PBI’s will be transformed into potentially shippable product increments within a sprint. Velocity metric represents this constrained capacity of a scrum team. In scrum terms these bottlenecks and other blockers are commonly referred to as impediments. Impediments being a broad generic term, I’m focusing on bottlenecks - which are impediments that specifically cause reduction in flow at a systemic level over multiple sprints. (Nothing too revolutionary!)

Here are a few of such bottlenecks:

1. Ill-defined product backlog items

Top priority product backlog items are not well defined for the team to fill up at least their next sprint and start working.Too often this results in lengthy sprint planning meetings, and delay in terms of days before a scrum team makes sprint commitment and get going. In such cases the team spends the first few days of the sprint analyzing requirements, holding design sessions etc prior to making a sprint commitment. Sprints in this case go in fits and starts with a significant gap in software development efforts between the end of previous sprint and the start of new sprint. In this case the bottleneck is recognized as gaps between sprint end and start dates.

2. No product backlog items

In most cases, this situation is not an invalidation of the assumption that the business has more work than the team can do in a sprint. In fact too often the business has a pressing need to get many features out of the door. Flood of information, lack of agreement, “have to get it right the first time” has a paralyzing effect effectively boxing them in a state of limbo where PBI’s are not defined and the scrum team is left out to dry. Often the bottleneck in this case is upstream of the scrum development team causing either an abrupt end to sprint rhythm or a false start with frequently extended ’sprint 0′.

3. Not-Done product backlog items within a sprint

It is common understanding that PBI’s within a sprint are either Done or Not-Done as measured against their definition of done. PBI’s that get Done are counted towards team’s sprint velocity and the rest don’t. Teams that end their sprints with some or many Not-Done PBI’s find that their ability to pull in new PBI’s next sprint is bottle-necked. Following the mechanics of good scrum practices these teams present Not-Done PBI’s to Product Owner and estimate remaining work for prioritization in Product Backlog. In my observations it is most likely occurrence that the Product Owner will ask for Not-Done PBI’s to be completed in following sprint. Effectively the team carries forward Not-Done PBI’s from last sprint into the next sprint. In cases like these, it may feel like that there is a smooth flow from concept to realization however it ain’t true. Look at the worst case scenario, no new PBI’s are pulled from product backlog and the team spends the next sprint finishing up not-done work from previous sprint. In this worst case example it is easy to call out such a bottleneck, in real teams there are variations along the continuum of getting all committed PBI’s Done to getting none of committed PBI’s Done. It takes an experienced scrum team and/or ScrumMaster to recognize this pattern while its happening for real.

4. Insufficient infrastructure

Lack of staging environments, insufficient QA infrastructure and/or production ready environments stops the flow of developed features at some point before these features can be deemed production ready or ‘potentially shippable’. All these features pile up and aggregate until a sprint or two prior to release date. Then the teams make a major ‘push’ to release all of the developed functionality out of the door.

These last sprints are often called as ’stabilizing sprints’. And I have to say, I will start liking the term ‘Stabilizing sprint’ under the condition that all of the previous sprints are called destabilizing sprints. Each one of the previous sprints was destabilizing the product increment unpredictably. Sadly for me, most people interpret the term ‘Stabilizing Sprints’ as a good thing .

Tricky thing with all the hard stuff, like performance testing, regression testing etc, that could not be done within regular sprints is that the hard stuff does not get simpler if its left for last sprint. It gets even more harder. Causing a snowball effect. Take regression testing for example, if regression testing was not done in previous sprints then in the last stabelizing sprint potentially a lot of regression bugs can show up. If these bugs cannot be fixed in the last stabelizing sprint, these will then ideally fuel addition of PBI’s in product backlog. Leading to either lower quality product release or a delayed release date. In either case, there in lack of objective perception regarding both quality and predictable release date. This bottleneck is obvious to everyone, for there are features piling up every sprint waiting to be production ready however the exponential negative impact is still underappreciated.

Experience, Product Backlog, Uncategorized Definition of done, product backlog grooming, release, scrum, scrummaster, velocity

As an Agile coach I enjoy the opportunity to learn from people implementing scrum framework and incorporating Agile values and principles. In this process I come across interesting stories and metaphors. After an introductory training session with one team and some follow up coaching during sprint planning, Paul (team member) shared his impression of the situation the team was put-in with this new scrum and Agile thing -

Back on the farm, if a cow isn’t producing more milk than cost of the feed she eats, unless someone really likes scratching her between the ears as a pet, sooner or later she ends up as hamburger.

I must admit that when I heard of it for the first time, I felt very uneasy. It is a very blunt analogy getting straight to the primary design benefit of scrum - Maximize Return on Investment (ROI). If at the end of every sprint the organization does not believe it can get sufficient ROI over the cost of development, then there are “Or Else …” scenarios that the organization can pursue. Scrum does not tell you about what you should do, it simply brings transparency into the system and provides opportunities for early adjustments. The thing that concerned me was that the team had likened the “or else…” scenario with Betsy ending up on organization’s menu. At that time I expected the team to get over their initial fears and move forward with a more positive outlook. It was not to be so, a sprint later I saw a picture of cow-cuts on top their team task board.

Had this team drifted deeper and darker with Betsy’s supposed fate?

Successful cross-functional teams that I worked with, have a sense of identity that is separate from their job titles or departmental affiliations or other organizational chart bindings. As a coach, the simplest thing that I have done to trigger such a sense of identity, is to facilitate scrum teams through an exercise to help them create their team name. Although I floated this idea of creating a team name to the team described above, they did not feel it was necessary for them to do so. Instead this team had adopted Betsy as their team mascot and coalesced around the notion of saving Betsy from her predicament sprint after sprint after sprint.

Over the last 10 or so two week sprints, I have had the pleasure of working with this team intermittently and I have observed the team adopt Betsy into everything they do and innovate along the way.

Before I delve further, some context about this team is due. Each of the team members has a minimum of at-least 15 years of software industry experience. The team works for a well known insurance provider and does sustainment engineering for all business processing applications. They interact with customer account managers that are transferring big organizational health care insurance benefits to be managed by their company, customer service personal that are serving individual insurance beneficiaries and operations support that manages changes to production systems. Like many scrum teams they are in a very complex environment. Their complexity is compounded by the urgency of fixes requested from the business side and from the necessity of their operations and DBA group to ensure quality of fixes. They are not immune from challenges associated with organization silo’s wherein the DBA group cannot dedicate any member to the scrum team so as to form a truly cross-functional scrum team. On the plus side they have an excellent scrum team very well supported by their ScrumMaster and ably directed by their Product Owner, who is from the business side of the organization.

So what does it mean to save Betsy within their context? There are many dimensions to addressing this question.

• From a software delivery perspective, the team commits to delivering software product fixes and enhancements to production environment every sprint. I remember this interesting conversation where the team was discussing their definition of done. Question arose, whether they should commit against a definition of done when elements of done-ness, such as production database updates, are beyond the authorized scope of the team members (DBA group owns production updates). At the end of their dialogue every one in the team agreed that only software that is in use by end-users constitutes valuable software. Although they do not directly manage production updates, they believe it is their responsibility to shepherd updates into production environment. In effect, every sprint they committed against a definition of done that required product backlog items to be implemented in production environment. This required them to engage representative from DBA during their daily stand-up, working with the DBA group to work with their constraints, such as no production updates on Wednesdays & Fridays. Also building automation test scripts to validate quality prior to review by DBA’s, effectively reducing rework cycles.
• Engaging sustained participation from business. Prior to their scrum implementation customer issues and requests from business side were some times, lost in the ether. It was not unusual for the team to come across requests or tickets that were more than a year old. Through regular prioritization by the product owner the team was able to focus on the highest priority fixes that needed to be addressed. The ScrumMaster was very effective at challenging the team to change long held organizational-cultural habits. One such behaviour of their silo-ed environment was that of communicating ticket status through the bug tracking system. All too often tickets that were resolved and ready for functional acceptance were not looked at by the business person for closure. This resulted in delayed production updates for several resolved issues. Team members started interacting in face-to-face conversations with business people to better understand their tickets and following up with them to confirm functional acceptance. Such proactive steps drastically reduced wait times involved.
• Complete transparency. Here’s a snapshot of their task board :

• Being the only scrum team in their organization, sustaining healthy relationships within the team and with others who interact with the team is critical. One of their approaches is to manage this through recognition: Every sprint the team recognizes people who have contributed to save Betsy. This cute little award
  is given to people within the team or outside the team for their contribution towards saving Betsy.
• Addressing root cause for recurring issues. The team routinely analyzes commonly recurring issues and implements fixes that addresses the root cause for these issues.
• Having fun! team members flex their creative muscle every sprint by chronicling events of their sprints in news print format themed around Betsy, astutely weaving their sprint happenings with current affairs of the world at large. Hear are a few examples, . The team ScrumMaster, Stan’s favorite is this one where Betsy takes to skies. . The entire success with scrum is really due to his efforts and leadership. He has been very open minded and very smart, to let the team run with Betsy and see how it would play out with the team and the rest of the organization. Its one thing to float an idea, and quite another to really figure out what is going to work, and what might not be a good idea to fit in with the bigger picture.

This approach at recording sprint facts and events is sooo innovative/cool/awesome that my team used this technique to do our sprint retrospective. During our retrospective we formed pairs and spent 30 minutes each to create our own version of scrum times. After that we shared our impressions of the sprint via the news-prints that we had created. It was a fun exercise and the discussions were so much richer as each pair accentuated aspects of sprint dearer to them.

There are many other things that directly or indectly relate to saving Betsy.The thing I find most interesting is the emergence of a unique and compelling purpose within this team. It enables them to innovate in all areas: people, process, tools, software delivery. To sum it up in the words of Paul Opryszek

Betsy was born in rustic King county in mid 2008. Her dairy farmer was Paul Opryszek who was fortuitously struck by a bolt of Agile lightening that restored Vision as well as Belief in Truth, Beauty, and Resource Allocation sanity

Experience Betsy, culture, emergence, purpose, scrum, self-organization, team