What is your company Standard Time?

So I started thinking about recent conversation I had with someone regarding the discipline with adoption of Scrum within a large group, with 5-7 teams. As we touched on her observations and current condition as experienced by the teams, she pointed out the fact that these teams valued autonomy as such one expression of this was they had freely established their own sprint cadence and were unlikely to give this up. This was in the context of the suggestion that it would be valuable to establish a single sprint cadence across the group, be it mapped out across two or more weeks, as it will remove all the wasteful activities needed to synchronize across these teams.

The next day, was Friday morning and as part of my daily routine I watched the recording of from night before of The Daily Show, Jon Stewart show of September 25th 2014

Steven Johnson, author of How We Got to Now was being interviewed by Jon Stewart. He explained that his book was about the history of inventions and a look back as to how we got to now given an outcome we see today and often take it for granted. He points out, as in the case of clean water, that for most of us is a simple act of filling a glass at the faucet, is build on top of hundreds of inventions that proceeded in history. He then pointed out that we wouldn’t be able to TiVo shows like this had it not been the simple invention of standard time.

It works out that until 1918 every town in America had defined there own time standard, there was no concept of standard time across U.S.A. Would you believe if it wasn’t for the railway system we probably wouldn’t have seen the need for standard time. Even then, it wasn’t until 1883 every railroad had their own time standard, not to mention every town on the line defining its own to complicate the simple matter.

 

Continue reading…

Reblog: The Innovation Dead End by Jocelyn Goldfein

This article by angel investor and advisor Jocelyn Goldfein is one of the more honest looks at the challenges and opportunities for innovation in large companies that I’ve seen.

 

Meetings! Huh! What are they good for?

Absolutely … some things!

(with my apologies to Norman Whitfield, Barrett Strong, and Edwin Starr)

People regularly lament about meetings. I am guilty of it myself. I used to cynically and sarcastically say, after spending time in a long and fruitless meeting, “Meeting rhymes with beating!” Many would often shake their head in agreement. “There are too many meetings” is a common refrain at many companies. Interestingly, I often hear this after groups have adopted Scrum, “Why are there so many meetings in Scrum?” “Isn’t Scrum supposed to be lightweight? Agile?” Let’s quickly review what meetings Scrum defines and then we will see what happens in practice for many teams, especially when starting out with Scrum.

The 5 Scrum meetings

  • Sprint Planning
  • Daily Scrum
  • Backlog Refinement
  • Sprint Review
  • Sprint Retrospective

These are the four original meetings plus “Backlog Refinement”, which has recently become part of Scrum (see http://agileatlas.org/atlas/scrum).

A simple breakdown of each meeting

Sprint Planning

Purpose:  Development Team commits to work they plan to get to the Definition of Done by the end of the Sprint (the Team’s Sprint Goal).

Outcome: A solid Team commitment to a Sprint Goal represented by their Sprint Backlog (containing all the Product Backlog Items (PBIs) and, possibly, task breakdown).

Duration: 2 hours per week of sprint, often less, as teams mature and improve.

When: At the start of a Sprint (after the Sprint Review and the Sprint Retrospective).

Who: Development Team, Product Owner should be available to clarify PBIs, Scrum Master facilitates.

Daily Scrum

Purpose:  Daily meeting for the Development Team to inspect and adapt how to best achieve their Sprint Goal.

Outcome: Impediments get surfaced and improvements for the day’s work are agreed upon.

Duration: 15 minutes per day.

When: Every day of the Sprint.

Who: Development Team, others can attend but only listen, Scrum Master facilitates.

Backlog Refinement

Purpose:  Product Owner helps the Development Team to understand the work coming in the next Sprint or two. Sometimes this involves writing acceptance criteria, slicing items smaller, sizing, estimating, or anything that helps the team prepare for the next Sprint Planning.

Outcome: Upcoming PBIs are ready for the upcoming Sprint Planning Meeting.

Duration: Varies by team but is often 1-2 hours per week of the Sprint.

When: Varies, but preferably not immediately followed by Sprint Planning. Try to allow a day or two in between these meetings.

Who: Development Team and Product Owner, anyone else who can increase the Team’s understanding, Scrum Master facilitates.

Sprint Review

Purpose:  The Development Team demonstrates the PBIs they believe have achieved the Definition of Done to the Product Owner and other stakeholders.

Outcome: Feedback for the Development Team on what they built, often resulting in the generation of new PBIs. Also, a broadly understood view of current progress.

Duration: One hour per week of Sprint, but can vary depending on the number of teams demoing and how big the audience is.

When: At the end of the Sprint, before the Sprint Retrospective and the Sprint Planning Meeting.

Who: Development Team, Product Owner, generally, anyone else can attend, especially desired are stakeholders, Scrum Master facilitates.

Sprint Retrospective

Purpose:  The Development Team gets together to examine how they have worked together during the previous Sprint and what they will try in the next Sprint to improve.

Outcome: One specific experiment the Development Team will put at the top of their next Sprint Backlog.

Duration: One hour per week of Sprint.

When: At the end of the Sprint, after the Sprint Review and before the Sprint Planning Meeting.

Who: Development Team, Scrum Master facilitates.

There are a large number of variations on the above descriptions but I think of these as a good starting point. If I customize the process, I don’t lose sight of the purpose or the “why” of each meeting.

The Meetings of a Typical 2-Week Sprint

Special thanks to ICAgile and Ahmed Sidky for the inspiration for these two graphs.

Sprint-Cadence-Doing If you add up all the meeting time vs. time for building the product or service (or doing agile vs being agile), you get: Sprint-Cadence-BeingThat’s larger than a 6:1 ratio. Looks very lightweight to me. Where does the complaint about too many meetings come from then?

Common Scrum Meeting Anti-Patterns

There are many symptoms of dysfunctional Scrum meetings. Here are just a few.

Sprint Planning

Symptom: Planning takes too long

When Teams start out, this meeting seems to take forever, wearing the Team down so they agree to any amount of work. My first Sprint Planning meeting dragged on for 3 days!!!

Cause: Poorly refined Product Backlog

A Product Backlog that is not well-refined will not be well-understood by the Team. They will need time to gain enough understanding to make a solid commitment to the Sprint Goal. This refinement ends up taking up most, if not all, of the planning time. Time usually runs out and a rushed Sprint Goal is created. So much work gets packed into the Sprint, during the Sprint there is no time to refine the Backlog for the next Sprint, perpetuating the problem. Sprint Goals in this circumstance are rarely reached.

Cure: Weekly Product Backlog Refinement Meetings

Make a serious commitment to a timeboxed, Product Backlog Refinement meeting every week. Make sure the right people are in the room. Ensure that the goal of this meeting is to be ready for the next Sprint Planning.

Daily Scrum

Symptom: Lasts longer than 15 minutes
Cause: Poor meeting facilitation and/or weak team agreements

This meeting is truly for the Team to synchronize and coordinate their efforts for the day so that the Team can be as effective as possible. But, other items leak in like reporting status to a leader, deep-diving on problem solving, staff meeting agendas, etc.

Cure:

Instead of trying to describe what needs to happen, let Jeff Sutherland, the co-founder of Scrum, describe the Daily Scrum in a two-minute video:

Jeff Sutherland describes the Daily Scrum

Notice he mentions the type of agreements Teams can have, e.g. “We can talk about one issue for no more than 60 seconds…” When Teams hold each other accountable to their own agreements can lead to much more effective and dynamic Daily Scrums and eliminate much waste.

Sprint Review

Symptom: Team demos unfinished, non-shippable, product increments

The Team shows everything they have completed whether it meets the Definition of Done or not.

Cause: Not focusing on the Agile principle of “working software as the primary measure of progress”

Many traditional project management views about reporting progress are rooted in the idea that you can estimate the percentage of completion of work. Unfortunately, reporting that something is 50% finished lacks information needed to use for decision making. It makes it difficult to answer the “Are we ready to ship?” question. Also, people want to be recognized for the effort spent on the work to date so they hesitate leaving anything out.

Cure: Only demo “potentially release product increments”

By only demoing the PBIs that meet the Definition of Done, it is very clear to everyone in attendance what real progress has been made. A decision to ship is now much easier to make. This gives the organization real business agility. Teams improve from rarely completing anything in their Sprint Goal to completing nearly everything after making this change.

Sprint Retrospective

Symptom: Too many improvements to make

When presented with the real challenges facing the Team, they will regularly want to solve many problems right away. They often will commit to too many improvements.

Cause: Not strictly prioritizing improvements

One of the most difficult activities is deciding what is not going to get done. Being crystal clear on what is most important is difficult when faced with so many choices.

Cure: Choose one actionable improvement per Sprint

By only choosing one experiment to try in the next Sprint and making it specific and actionable, we increase the odds of actually making improvements. It gives Teams something to reflect on during the next Retrospective. Over time, repeatedly making small improvements will add up to many significant improvements for the Team willing to learn and experiment.

In general

Good meeting facilitation skills are critical for keeping meetings focused on their purpose. Training and supporting Scrum Masters to develop these skills has invaluable benefit to the Team and the organization as a whole.

So…

While there are many other dysfunctions, I’ve highlighted the ones I hear about most often. If there is enough interest, I’ll add more.

 

Value Team Heuristics and use of Story Points when forecasting

When it comes to estimation in Software development, the difficult question to answer is when can we go to market? and when can we release the product or service? These are difficult questions, both from the business perspective as well as the development perspective.

There has been a lot of conversation in the agile community around User Stories and use of Story Points to size the product backlog items. What is often lost when teams adopt this technique is the value of team heuristics, as in team experience and the importance of relative sizing.  These put together and followed with some discipline allow the team with the ability to forecast – as in over discrete periods of time, sprints,  express an ever accurate answer to the questions:

How much by this date?

or

All this by when?

If no one is asking these types of questions at the end of each sprint then you may be in danger of falling into the cargo cult scrum trap, as in following a ritual of sizing product backlog items for ritual sake.

So what does heuristics really mean?

In a nutshell heuristics refers to experience based techniques for problem solving, learning and discovery, one which is good enough approach to finding an answer, where the perfect answer is not knowable or would be too expensive to learn.

So, if you are familiar with how most sciences work, you have probably encountered the use of  heuristics before. For instance, rather than predicting exact ratios of chemicals for a reaction, chemists use heuristics as guidelines in predicting how various chemicals will react. Similarly in engineering for instance aircraft designers use heuristics by considering coefficients of lift and drag to point them in the right direction, with the design empirically refined based on experimental evidence.

In essence to answer either of the questions stated above there is a heuristic alternative to the careful reasoning that occurs in the long cycles of phased approach in gathering requirements, analysis, design, development and test. This heuristic alternative works well for estimation and this is in spite of sometimes serious errors. The key is to ensure the errors are bounded across short time intervals, with frequent pauses assess the outcomes and inform what to do next. Of course Scrum provides for a natural cycle of pauses at the end of each timebox, where the team can take stock of the outcomes as well as assess the steps the team actually took vs. assumed what they took, yes essentially these being the sprint review and end-of-sprint team retrospective.

First Order Estimation

So what is the first order of estimation, well it is something we all do so naturally and effortlessly when it comes to driving a car to riding a bike to walking in a busy mall, else surely we would be running into each other most of the times. I mean when is the last time you got out a measure tape when changing lanes on a freeway or overtaking to ensure you have the most accurate measurement in distance or speed.

In essence the first order estimation I refer to is a relative measure, in this case of work items (user stories) to one another.  To me it is similar to coefficients of lift and drag considered in aircraft or even car design. Its just that in this case these estimates can be now be thought of as being the teams coefficients, one that corresponds to the team that is going to do the work based on their perspective for product backlog items as opposed to anyone elses.

Team’s coefficients

There are teams that only look at their team coefficients, user story points, when planning a sprint. This may well be all that is needed for planning, but in truth this is only the case for a teams that have been together for a long time, have experience of working with each other and have established team heuristics, their rules of thumb.

Teams that are new or new to working as a scrum team often miss out the need to assess the team capacity at a more granular level of planning, one that breaks a product backlog item (user story) into actual tasks that need to be performed in order to get to done!, before making team commitments. So it is best for a team to be mindful and disciplined towards developing the team heuristics and continued reliance on wisdom of the crowd to decipher difficult problems that includes estimation.

To do this start with having a stable team one that takes a disciplined approach in their scrum ritual meetings during the sprint. This includes when refining backlog items and/or sizing using story points to when planning out by defining tasks along with task level time estimates as this is what will help shape the teams commitment to the plan that appears in the form of a sprint backlog.

Eureka!

Daniel Kahneman, in his book Thinking, Fast and Slow, points to how judgement happens, and while it is a complex function of the brain what he points to is what Psychologist have to offer based on their observations supported by what Neurologist tell us about functioning parts of the brain.  In essence we have evolved to with two modes of thinking, called System 1 and System 2 as coined by psychologist Keith Stanovich and Richard West.

Where System 1, evolutionary the oldest, the part that is responsible for fight or flight and ingrained to our survival instinct, operates continuously and generates assessments of various  aspects of the situation with little or no effort. This basic assessments plays a vital role in intuitive judgement, as this routinely substitutes the more difficult question being asked of by System 2, the essence of heuristics.

Where as System 2 thinking considers, only if it must, the difficult to answer questions the one that System 1 doesn’t readily offer an answers to, and it triggers many other computations including basic assessments acting as a mental shotgun according to Kahneman. He points out the word heuristics comes from the same root word as does the word eureka, and is technically defined as a simple procedure that helps find adequate, though imperfect answers, to difficult questions.

Continue reading…

What is Technical Debt?

Recently I’ve been hearing people use the term technical debt to describe all sorts of things that are related to system improvement. However, used properly, technical debt is not a catch-all phrase for system improvement work, but a subset of that work.

What is Technical Debt?

Ward Cunningham first described technical debt in an experience report in 1992:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

To better understand technical debt, let’s explore the analogy to financial debt.

Four out of five people buying a home in the United States in 2013 took out a mortgage to do so. For the most common type of mortgage (30 year fixed with 20% down) on the average home price in the U.S. (~$200k), the total cost of the loan is 175% of the cost of just buying it outright. That’s right, for a $200,000 house, you’d pay about $350,000 over the life of the loan, or $150,000 just in interest. Why would anyone do that? Of course the answer is simple –  it might take you years to accumulate the cash before you could own a home, so people make a decision to accumulate debt in order to get the home sooner, knowing full well that they’ll need to pay more in the long run for that early entry. They are trading an advantage (early entry) for a disadvantage (higher total cost).

Technical debt, then, is the conscious choice to get to market faster by skipping some steps required for long term code sustainability. Just like financial debt, we know that in the long term it is more expensive (we’ll need to pay interest on top of the principle), but we do it because the advantage of getting to market sooner outweighs that cost. And just like financial debt, we need to create a budget for paying it back down.

Are All Bugs Technical Debt?

Let’s use three of example defects to answer this question.

  1. Defect A is an error that was reported by a customer a few months after a release. It happens when a specific workflow is followed that the team didn’t anticipate, and causes the program to freeze. The team was using good automated testing, but we didn’t catch this one due to the unusual customer workflow.
  2. Defect B is an error that was discovered in a regression test, and was determined to not be a “release-blocking” bug – in other words, we knew about it but decided to release anyway. Now customers are complaining about the bug and the team decides to go ahead and fix it.
  3. Defect C is a display problem that happens on a new version of a browser that was released after our software was released. It didn’t occur in previous versions of the browser.

In this example, only Defect B is technical debt, Defects A and C are not because the business never made a conscious choice to ship with those defects. In any moderately full featured software product, the level of complexity involved results in some defects making it through to customers. Some of those may have been known prior to shipping and others weren’t. If we didn’t consciously choose to release with the bug, or were consciously skipping some defect prevention steps in order to get out the door sooner, these are just defects, not technical debt.

Is Refactoring Technical Debt Reduction?

As in the case of defects, it all depends on whether we were making conscious trade-offs on architectural and design approaches in order to release sooner. If we know that there is an area of the code that is a mine field, and no one wants to touch it (except for that one coder that’s an expert), but we chose not to refactor due to the amount of time & effort involved, then we have technical debt. If, on the other hand, new code has been added, the system is becoming more complex, and we just need to do some refactoring as part of the standard craft of software development, that type of refactoring is not reducing technical debt, it is simply the good practice of continuous system improvement. Think of it as entropy reduction, not technical debt reduction.

Test Automation?

Lack of robust test automation is probably one of the most common instances of technical debt. In the craft of software development, using automated tests is equivalent to a surgeon counting the sponges prior to a surgery to make sure we don’t leave anything in the body of the patient. If we’re not doing it, we are really being irresponsible. Now, I’m not stating that we need 100% code coverage for unit tests, or 100% functional coverage for automated regression tests – there is a point of diminishing returns. Again, it comes down to a case of intention – do we want much better coverage but just don’t have time to do it? If we don’t have time, that is just another way of saying it is not as high a priority as shipping the feature. In other words, we are consciously choosing to get to market faster by skipping automation that the team thinks would be helpful. In such a case, we are creating technical debt.

Summing Up

Technical Debt reduction is one important category of system improvement. To lump all system improvement under the banner of technical debt does us a disservice because it seems to imply that any problems or inefficiencies in the code were just a conscious choice by the team. That is not the case. Sometimes we make decisions to ship a less than optimal product in order to get earlier feedback or a market advantage. Even if we aren’t doing that, there will be ongoing improvement required. Separating out Technical Debt as a specific category helps us acknowledge the prioritization decisions we’re making regarding quality vs. speed, and watering that term down by lumping it together with everything else muddies the waters and can lead to disengagement by the team that didn’t “get it right the first time”, an impossible task in a complex domain.

It is critical that Technical Debt be paid down as soon as possible. It follows the rules of compound interest – the longer we wait to pay it off the more it accrues, and if it’s not paid off in time, eventually it leads to a bankrupt code base. It simply needs to be abandoned and started over from scratch, an extremely costly result. Clarifying when we are making a conscious choice to accumulate technical debt needs to have a payment plan associated with it to avoid these risks. Lumping ongoing system improvement into that category makes the payment plan much more difficult to plan for.

 

10,000 hours not the predictor, but the result

A new meta-analysis of 88 recent studies shows that the famous 10,000 hour rule (see the original study by Ericsson or the popularized version told by Gladwell) for mastery accounts for only a small percentage of variance in expert level performance. Other factors that seem to be at least as important: intrinsic talent, how early in life one is introduced to the area, and, perhaps the most important factor, how much the individual enjoys the activity.

http://www.psychologytoday.com/blog/the-homework-myth/201407/perfect-it-turns-out-is-what-practice-doesnt-make

So, to put this in context, the most likely path to mastery of some topic in life is to explore many different things at an early age, find one that is really enjoyable and that you have some talent at (in other words, you find it much easier than many of your peers do), and then focus on it. You’ll be naturally motivated to spend the 10,000 hour figure, making that figure a result of the real root cause – enjoyment.

Agile adoption failure? You’ve got a cultural mismatch.

Bob wanted to chat. “We can’t seem to make this work”, he said. “I just don’t think scrum works for a team like ours.”

I had provided scrum training and a bit of coaching for his team a few months back to get them going. Their story was pretty common – they had been using kind of an ad hoc, waterfall style process. They weren’t very strict about it, but the traditional phases were all there – Product Managers writing requirements documents, the team building out the requirements, a few months of testing, then release. They had heard about scrum and how other teams had really liked it and after the training, they were pumped up about how it could be a much better process for them.

Now things seemed to be falling apart. The team was cheating on the definition of done to get features into the demo by the end of the sprint. “We’ve got to meet our commitments!” they stated. The daily scrums seemed more about rote reporting to the engineering manager, who was also the scrum master. Product Managers were regularly adding “emergency requirements” in the middle of sprints. Retrospectives had quickly devolved into a disengaged, repetitive finger-pointing session focused on what went wrong in the last sprint.

I handed Bob a copy of the book “Tribal Leadership” and asked him to read it and see if it gave him any insight into solving his problems.

“Is Tribal Leadership an agile book?”, Bob asked.

“Not exactly, but I think it will help your team be more agile”, I replied.

While our first inclination may be to jump in and fix each of these problems, I’ve learned that the problem probably is not about the team or about the process. In short, Scrum and other agile approaches are patterns of a Tribal Stage 4 and 5 culture, and if you’re working in a Tribal Stage 2 or 3, you’re going to struggle to make it work. Hit the break for more about cultural stages and some ideas for how to move the needle.

Continue reading…

Using the Fist of Five technique to gauge confidence

In Scrum Training courses, we do a scrum simulation that is pretty fun. Early on in the simulation, teams need to do sprint planning. If you’re familiar with scrum, you’ll know that the primary purpose of the Sprint Planning Meeting is for the team to arrive at a commitment to delivering a Sprint Goal and/or a set of Product Backlog Items during the Sprint. In the simulation, I push the teams pretty hard as far as the amount of time they get to do sprint planning. They usually have not quite enough time to really think through the plan, but I push them to make a commitment anyway. Under this pressure, most teams will smile and make a commitment to a plan in which they’re not very confident. This pattern of commitment with low confidence is a persistent challenge with many of the teams that I work with.

To help highlight this pattern of commitment without confidence, I use a facilitation technique called “Fist of Five”. As soon as the team has their commitment and I’ve looked around the table asking if everyone agrees (typically with everyone nodding, and often with at least one person’s body language screaming “no way” while they nod their head), I’ll ask them to think for a moment about their own personal confidence that the team will meet its commitment. I ask them to think of how confident they are on a scale of one to five, with one meaning not confident at all, and five meaning completely confident that barring some highly unusual circumstance, the team will meet the goal.

Fists of FiveI tell them that once they’ve got their one to five number in mind, to simply put their fist in the air without revealing their vote, indicating that they’re ready. When all of the fists are in the air, I ask hem to reveal their votes together on the count of three. It’s always a revealing moment when some people who had passively nodded their heads to the team’s commitment hold up a two or three (or even a one). I then ask anyone with lower than a four to share their concerns about meeting the commitment. Often this results in a quick change to either the plan or the commitment itself to address the concerns of those that were not at a four or five. With the modified plan, we’ll re-vote until everyone is at a four or five.

I’ve found this facilitation technique to be useful in many situations where there might be tacit agreement to a plan without true confidence. I’ve used it in sprint planning meetings, release planning sessions, and even family discussions where we’re deciding what to do.

Splitting stories into small, vertical slices.

One of the biggest challenges for teams that are new to an agile approach is the change from what we call horizontal splitting to a “vertical slice” approach. Teams often aren’t used to thinking about problem decomposition this way, and I’ll hear comments like “well, our system is too complex”, or “we need to build really big features or our users won’t get what they need”. I always tell people that in the eight years I’ve been using this approach with hundreds of teams, I’ve only been stumped once to where we just couldn’t figure out how to slice something small enough to fit into a two week sprint. Well, we could have split it, but it didn’t add any value.

Below I’ll give a quick overview of why we prefer this approach and four simple strategies for splitting stories into small slices.

Continue reading…

The Secrets of Successful Agile Development

I’ve compiled all of my experience into what makes agile development successful into the following 14 slides. I hope they’re helpful!