Uncategorized
Scrum Collage
Jan 13th
do you get it?
One lazy sunday afternoon, I created this scrum collage as my desktop image
Recognizing Bottleneck's
Mar 24th
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.
Making sense of Best Practices
Dec 28th
A Best Practice is a collection of tools/techniques/approaches/methods when applied in prescribed order delivers desired results effectively and efficiently. “Best” in the term “Best Practice”, to me, implies that there is no further room for improvement, ever! There seems to be an implied sense of finality, why use anything less than the best? There also seems to be an implied sense of universality, wherein application of Best Practices under all circumstances will yield desired results most effectively and efficiently.
These Best Practices have come from well minded people who have shared their successes at solving problems in a given domain. People have either intuitively found certain practices to be superior and best suited to solve some problems or they have iterated over and tried multiple solution paths, to solve a problem over and over again and optimized their approach until Best Practices for their context has emerged. This is not to say that there exists a Best Practice for all problems. In HBR’s Nov 2007 Article: Leadership Framework for Decision Making, the authors assert that Simple Contexts are the domain of Best Practices. As per the article, the characteristics of a Simple context;
Simple contexts are characterized by stability and clear cause-and-effect relationships that are easily discernible by everyone. Often, the
right answer is self-evident and undisputed. In this realm of “known knowns,” decisions are unquestioned because all parties share an
understanding. Areas that are little subject to change, such as problems with order processing and fulfillment, usually belong here.
Best practices are suited only with in a simple context. Take for example the case of stolen/lost credit cards. The banking and credit card industry has faced this problem over and over again. Solution to this problem for both the credit card holder and the credit card company has been codified into best practices. This has been possible through simplification of the context through technical improvements in supporting infrastructure and collaboration between various credit agencies to simplify their domain. And not the other way around. Best Practices have not enabled simplification of the context, actually because of simplifications in the context Best Practices have emerged/formulated. I believe that instead of seeking Best Practice solutions for one’s operational context, one should instead focus on simplifying the context towards achieving effective and efficient means (practices).
The solutions all are simple…after you have arrived at them. But they’re simple only when you know already what they are.
Zen and the Art of Motorcycle Maintenance – Robert M. Pirsig
My take of why Best Practices are believed to be so great is because Best Practices carry a sense of assurance to provide, consistently, most effective and efficient results. Desirability for these benefits trigger transfer of Best Practices from one organization to another. This transfer happens via cross-pollinating agents, most likely to be consultants.
Richard Dawkins, 1976 in his book “The Selfish Gene” coined the term “meme” as an analogy to the concept of gene. A meme is any unit of cultural information, such as a practice or idea, that is transmitted verbally or by repeated action from one mind to another. Examples include thoughts, ideas, theories, practices, habits.
Within today’s corporate culture, the notion of Best Practice is a meme.
Richard Dawkins:
“If a meme can get itself successfully copied, it will”.
The Best Practices meme has a strong pull from receivers (demand), after all who doesn’t want the best. And I would argue that there is much stronger push from the suppliers (consultants) to sell Best Practice solutions in order to satisfy receiver’s need.
Richard Dawkins:
“Effective memes will be those that cause high fidelity, long lasting memory,” and not necessarily the ones that are “important or useful.”
Best Practices meme have high fidelity between both receivers and suppliers when they are simpler. Meme’s do not replicate exactly as the original when they get complex. For it to be memorable it hinges on simplified core elements that stick in the minds of people, easy to be mimicked for further replication. Either that or in the melee of buying & selling services, quick fixes to long standing problems and trivialization of complex contexts into simpler ones, unwittingly or purposely people have creatively oversold Best Practice solutions. In this process activities/practices that have no demonstrable track record for betterment have been tagged to be “the best” and effective practices are stripped of their contextual elements making them sell-able to wider domain of problem statements.
So, are there any Best Practices? – I think not. I am firmly in the camp with many others who have suggested to get rid of the term Best Practice. Few alternatives that I’m aware of are – “Good Practice”, “Current Thinking”, “Contextual Practice”. For now, as an alternative, I will personally settle for “Good Practice” since it does not carry the sense of finality and allows room for improvement. Conceptually I do believe that with in simple contexts certain Good Practices can provide effective and efficient results. However, I strongly urge that Good Practices should not be blindly accepted for its apparent goodness. All practices need to be tried out atleast once with in your own context to determine whether a given practice is good for you or not. A good practice in essence does not carry with it the assurance that what worked for me will also work for you. I am comfortable accepting practices and judging their “goodness” against my objectives and not benchmarking these against others who have apparently the best implementation of a best practice.
