Agile Innovation

Ideas, Suggestions, and Lessons Learned to help teams innovate.

by

The Agile Buffet Rule

Take all you want, but eat all you take. – Jay Packlick

I learned about the Agile Buffet Rule from the ever loquacious @jpacklick. This is not to be confused with the Warren Buffett Rule or even the Jimmy Buffett Rule. The concept, as it applies to Agile, is simple: Take as many stories as you want from the backlog, but make sure you have the available capacity to complete the work you take. I’ve noticed a trend at some companies where teams are not completing all of the work they have committed to, but calling the sprint successful. Often they are close to completing all their work; however I was taught to finish everything on my plate. Maybe it was the way I was taught Scrum in the old days, but I still feel if you don’t complete all the work you commit to, your sprint was not successful. It is very empowering for a team to be able to use velocity and capacity to plan their work, and have the costumer’s confidence that you will be able to finish what was committed.  For Agile to be successful, you need to to win the trust of the business. You do that by delivering what you promise.  It should be uncommon when you don’t finish all the work you signed up for. To be clear, I don’t have any problem with teams adding stretch goals to the sprint, so long as everyone understands they are stretch goals, and not part of the sprint commitment. You have a ten pound sack of potatoes and that’s all that will fit. Don’t try to put fifteen pounds in a ten pound sack. When I’ve observed teams committing to more work than they have in the past, the common question I ask is: what is different about this sprint versus the last one? In other words, what has changed since the last sprint that enables you to commit to a higher velocity?

So that begs the question: how do we ensure that we complete all the work we commit too? We can break the answer into two parts: Planning and Executing the Sprint.

Planning

The obvious answers are to make sure  you are not going over your velocity or capacity thresholds (velocity in points and capacity in ideal hours). Your velocity is an average of your points over time (sprints), which should be relatively stable. So do not take more story points than your velocity. Likewise, if you are doing your planning via WIP, Cycle Time, etc. the same rule applies: Don’t take more than your WIP allows, unless something has changed.

Your capacity takes into account the number of hours available for this sprint. So make sure you are accounting for any changes in team personnel, holidays, vacations, etc. One way to achieve this is to create a capacity sheet which takes into account a simple formula for each team member: number days in the sprint x number of ideal hours per days x % dedicated = available capacity. Here’s a quick explanation of the variables:

  • Number of days in the sprint: This is the total number of days, less any holidays, training, conferences, vacation days, etc.
  • Number of ideal hours per day: This is the amount of hands-to-keyboard-time you actually do on project work each day. It could be based on an 8 hour work day, less meetings, breaks, lunch, phone calls, responding to emails, etc. I’ve seen teams use as little as 2 and as high as 6. Never more than 8 unless they plan to work 12 hours days. To give you some relevant data, from a study we did at Nokia, the average team only spends a 1/3 of their day on actual project work.
  • % dedicated: It’s unfortunate, but many organizations continue to loan team members across teams. As a result, you may have team members dedicated less than 100% to the team. Thus, you must adjust their capacity accordingly. I don’t condone this, but it is reality.  For those that are interested in  why this is a bad idea, you can find it here in Kenny Rubin’s most excellent presentation on Economically Sensible Scrum.

The end result is the total number of hours, each team member has available to commit to the sprint. During Sprint planning, when tasks are created and assigned, the Scrum Master (or other team member) can reduce the number of hours available, per team member, each time a task is assigned.  You are free to sign up for tasks until your total reaches 0. Here’s and example of a capacity worksheet I typically use:

Capacity Planning Chart

Capacity Planning Worksheet

Sprint Execution (aka How to Finish what’s on your plate)

On what he thought of his team’s execution: “I’m in favor of it.” – The late Tampa Bay Buccaneer’s Football Coach John McKay

Using the information radiators in Scrum is paramount. Use of the burndown chart and other information radiators (Cumulative Flow Diagrams, Cycle Time, WIP, etc.) to make timely decisions is critical. If it becomes clear that you are not going to be able to complete everything on your sprint backlog, when should notify your customer/product owner? The answer is immediately. The more time the PO has, the better the options become. Don’t make the mistake of waiting, thinking things will improve, when the data is telling you otherwise. As pilots, we are taught to trust our instruments and not our gut. Why? Because wishing the situation was different won’t help. The data is telling you that failure is on the horizon, it is better to admit it and come clean. Doing anything else erodes trust. Be decisive and be proactive. What strategies can we employ to make sure we finish the sprint? Here are some suggestions (in no specific order):

  • Remove impediments – This strategy should be obvious, and hopefully, is being done on a daily basis.
  • Swarm – Can we gang up on unfinished work?
  • Add people/experts – perhaps we are struggling with a difficult story and the expertise exists outside of the team. With this strategy, you are essentially trying to increase your velocity.
  • Move the stories to different owners – It could be that the person working on the story, isn’t the best one suited for the work.
  • Work overtime – Not ideal, but can work as long as it doesn’t happen very often.
  • Move into a team/war room – Sometime getting together in a crisis can help bring ideas out faster.
  • Out of ideas? – Ask for help. This is not the time to be shy. Ask the team, ask your manager, ask your coach, the Internet, etc.

The key of course, to making use of these (or other) strategies, is early detection. None of these will work if you procrastinate.

 

by

Why Companies Choose Not to Innovate

You read that right, it’s a choice. Companies often make a conscious decision to not innovate. Why do companies choose to do this? Why is it so hard for their employees to innovate? Let me count the ways:

  1. Because it is easy, embarrassingly easy, to kill an idea –How often have you been in a meeting, when a coworker comes up with different approach to solve a problem or new idea? What is the reaction? “Oh wow! Great idea Jane! I’ve got some ideas on how we can implement that.” Or is it more like this: “That won’t work, and here’s why…” “We tried that before and it didn’t work, because… “ Why? Because it is part of our corporate culture. It is easy (and comfortable) to find reasons why an idea won’t work. It is easy to poke holes in a new idea or product, but hard to figure out how to make it better and even harder to figure out how to make money with it. The latter requires an extreme use of brainpower to take a germ of an idea and grow it. It requires research, strategic knowledge of your customer base, economics, sales and marketing.
  2. Confuse innovation with entrepreneurship – Innovation could be defined as a cool new idea or process. Entrepreneurship is the ability to take that idea to the next level, and make (or save) money with it. Simply having smart creative employees is not enough. In order to gain business value, a process (and supporting infrastructure) needs to exist which allows companies to nurture and capitalize on ideas. Far too many companies create cumbersome and unnecessary obstacles by forcing employees to fill out copious amounts of paperwork, go before review boards, etc.
  3. Not providing the time or environment to innovate – One of the main tenants of economics is that people make rational decisions. It is irrational to expect employees to work overtime to create innovation for a company; on top of their normal 40-50 hours a week. If an employee wanted to work overtime on an idea, the rational decision would be to simply work his/her 40-50 hours, then put in personal time on his/her idea. This part-time innovation approach is how many startups are initiated. So, by expecting employees to work overtime on innovation for the company, the company is actually incentivizing them to innovate (and hopefully profit) on their own.
  4. Risk Intolerance – If companies choose to allow innovation time, or try to implement something like the Google 20% rule; corporate leaders must understand the nature of risk involved. Many companies are simply unable or unwilling to accept the risk that most ideas will not create value. For those unwilling to accept risk, it becomes a pure opportunity cost, and therefore a wasteful expense.

Issues, 1,2 and 4 above are the result of a toxic, but not uncommon, corporate culture. It has been ingrained into our tech DNA to challenge and vet new ideas (which I view as a good thing). However, I have witnessed corporate cultures, which pride themselves on establishing nearly impossible impediments to innovation. Moving towards an entrepreneurial culture which accepts risk takes time, leadership, and an unwavering commitment to the following principles:

  • There is a commitment to experimentation, innovation, and being on the leading edge
  • This culture does not just quickly react to changes in the environment—it creates change
  • Effectiveness depends on providing new and unique products and rapid growth
  • Individual initiative, flexibility, and freedom foster growth and are encouraged and well rewarded

Culture changes must come from the top of the organizational food chain and it doesn’t happen overnight. It will most likely take years and require vigorous attention to change management principles (see Dr. John Kotter’s Our Iceberg is Melting).

So where does Scrum come into the mix? This is after-all an Agile blog. While a culture change is required to bring about strategic innovation and entrepreneurship, you can use Scrum and Agile methodologies to address issue #3 – Innovation time.

6x2x1 Rule – One way to enable innovation time is to introduce the concept of a Scrum hack-a-thon. For teams that have two-week iterations: every 6 iterations have a 1-week hack-a-thon. This is known as the 6x2x1 rule: After six 2-week iterations, have a 1-week hack-a-thon.

How it works – I first learned this from Kenny Rubin, who originally taught me Scrum. I took it a step further and add a few rules:

  • A separate product backlog is created to track innovation ideas. The stories are not prioritized. They may or may not be groomed, that is up to the team. For the hack-a-thon, the team members decide what to work on (within reason – see below). Should a story start to mature into a product, the product owner can move it into the product backlog.
  • Prior to the start of the hack-a-thon, the team presents what they want to work on to the team and product owner.  The team and the product owner are responsible for making sure the ideas make sense for the company and the team (or individual team member).
  • Employees can work on their own idea, or join other team members.
  • It doesn’t have to be a new product idea. For some, it could be a learning session (e.g. I don’t know JQuery, so I am going to spend the week learning it); which could be used to reduce technical debt or improve an existing product.
  • The team is free to work on what they want.  However, the project(s) they work on must be beneficial to the employee as well as the company. For example, it isn’t beneficial to a telecom company for an employee to create an iOS video game.
  • Other than emergencies, nothing else happens during a hack-a-thon that interrupts the team (e.g. no meetings, planning sessions, etc.).

The 6x2x1 Rule is one method, there are probably many others. Even if you use the above method, you are still below the Google 20% innovation benchmark, but it is a start.