Posts tagged scrum

Was Our Velocity Seriously Zero?

November 20, 2009 · Filed under Point2 - Process and People · Tagged ,

Two Sprints ago something happened for the first time since I have been a Team Lead – my team’s velocity was a big fat zero. As a team we are fairly experienced in Agile and Scrum and quite self-organizing, yet somehow our Scrum board was portraying us as a rookie crew. The first question that may come to your mind is, “did you guy’s have to deal with a lot of production bugs or injected stories?” Sadly the answer would be, no. The team obviously wanted to get to the bottom of this anomalous Sprint so performing a root cause analysis seemed like the right thing to do.

After working through a root cause analysis exercise as a team (this is actually something we do on a weekly basis) we had a pretty good idea of what had contributed to us delivering a big fat goose egg. There were no real surprises revealed, but it did help to get some stuff written down and in front of our faces. On a positive note, the team did agree that even though we didn’t burn up any stories, a lot of work actually did get done. So what went wrong?

  • The was a lot of technical unknowns in the new project we were working on resulting in stories with fuzzy boundaries.
  • The team was unsure when they were done a story, and as a result they dragged on longer than they should have.
  • Our stories were obviously poorly broken down.
  • We were not representing the work that was actually getting done properly on our Scrum board.
  • The knowledge gained from earlier spikes may not have been leveraged to their full potential.
  • We had gotten a little too comfortable in our Sprint planning process. Our previous projects (in the recent past) were usually well defined and understood. Because of this we found ourselves spending less time planning because we could get away with a just in time mentality. This didn’t work for our current project.

Naturally we want our root cause analysis exercises to result in some sort of action plan. With an understanding of what led to our questionable Sprint, the team was able to put some corrective measures into place for the start of the next Sprint.

  • For each story/task on the Scrum board, represent hurdles and stalls visually. Even though we talk about them in daily stand-ups, seeing them on the board can help show severity if it goes on for a long period of time.
  • During our kick-off meeting break down each story into small, bite-sized tasks and use these on the Scrum board. They should be small enough that we have no cards on the board that have a complexity value over 1 – the smallest size possible on our scale.
  • Do not end the kick-off meeting until all task cards are completed, prioritized based on importance and dependencies, and a commitment has been agreed upon.
  • If we find ourselves doing something that is not represented on the Scrum board,
    1. ask yourself if you should even be doing it.
    2. if you should be doing it, write up a new card and put it on the board to ensure that everything we do is tracked.
  • Continue with one week Sprints.

So how did the team fare after putting their plan into action? They met their commitment. The kick-off meeting resulted in a Sprint plan that was straight-forward and well defined. It provided a clear-cut set of tasks that the team could easily base their commitment on.  During the Sprint they were more mindful of the work at hand and made decisions as to whether it belonged in the iteration or not.  As a whole we re-focused on areas that we had gotten too comfortable with and neglected.

It was very satisfying to see the team face this problem head-on. They calmly analyzed it, devised an action plan, and executed it. They could have easily panicked, but they didn’t. They proved that they were a mature team that could recognize a problem, and use their agility to correct it.

By Hemant J. Naidu

Leave a comment »

Value as an Agile Metric

November 5, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , ,

At Agile 2009 I attended Brandon Carlson’s talk entitled “Value or Velocity?“.  Velocity is often thought of as a measure of speed or productivity, but if a team can deliver x story points’ worth of the wrong product, and another team can deliver the same number of story points’ worth of an amazing product that everyone wants, but the two teams are said to have been equally productive based solely on their Velocity numbers.

In other words, getting more done is meaningless unless you know you’re getting the right things done.  To make sure you’re doing the right things, Brandon suggested assigning value points to epics.

The simplest method is Value Poker, kind of like Planning Poker.  The Product Owner assigns a value to each epic relative to other epics in the sprint backlog, with the smallest amount of value being a “1″, just like the story that requires the smallest amount of effort is a “1″ in Planning Poker.

Another, probably more accurate method is Attribute-Driven value assignment.  In this case, all product owners and stakeholders meet and assign values to epics together.  Each stakeholder will know the most about one or a small handful of attributes.  Some possible attributes include: market differentiation, strategic alignment, usability, system stability, sales commitment.  Draw up a chart with each attribute as a column, and each epic as a row.  The stakeholders for each attribute assign a value of 0-3 in each row for how valuable the epic is for that attribute.  Total up all the values for a row and then you have numbers you can sort on, and that can become your prioritized list,

To a stakeholder it is much more meaningful to hear “this month the team delivered 31 value points” as opposed to “this month the team delivered 31 story points”, because at the end of the day it’s delivered value that customers pay for, not complexity of stories.

By: Tefon Obchansky

Comments (3) »

How Scrum Saved My Wedding

September 18, 2009 · Filed under Point2 - Process and People · Tagged , , , , ,

So what does a couple do when they are getting married in less than two weeks, and there is a pile of things to get done for the wedding? Well, when the groom-to-be is me, the obvious answer is that they organize the work using Scrum. I had floated the idea to my fiance a little while ago, and she wanted nothing to do with it. In her mind she felt that a list on our whiteboard would be just fine.

When we found ourselves a mere two weeks from the big day, I once again asked, “are you ready to do Scrum yet?” She reluctantly agreed, tweeting her displeasure for the world to see and we got underway. We knew there was a pretty big list of things to do so we started off with a Blitz Planning session.

I grabbed a stack of sticky-notes and we started to blurt out tasks that needed to be completed if this wedding was going to fly. As the tasks were identified I jotted them down onto the sticky-notes. Once we felt that we had a fairly comprehensive list, we took a few minutes to give each story a complexity value. A value of 1 was fairly trivial such as “pick up the wedding rings from the goldsmith”, while a 5 was reserved for things such as, “write our wedding vows.” We stuck with the Fibonacci numbers to allow for uncertainty in the larger tasks.

Since we had approximately two weeks before the wedding it made sense for us to have two, one week Sprints. With a table covered in pink sticky-notes, we moved each of the stories into one of two piles representing each Sprint. Now we were able to do a more fine-grained planning of each Sprint.

We knew that the more complex stories had higher risk associated with them so we made sure to start those as early as we could. We did however remain mindful to not overload Sprint 1 with only the large stories. There were some stories that needed to be done on certain days, and some that had dependencies on other teams which required some clever shuffling.

It didn’t take very long before we had our Scrum board organized into two Sprints. We split the board into columns representing each day allowing us to put the story cards onto the day we intended to complete them. This gave us a really good visual representation of the work ahead. This layout is actually very similar to the Scrum board my team at Point2 uses. Having a visual representation of when stories are scheduled to start and expected to finish is a great tool for the team, as well as stakeholders to get a sense of how well the Sprint is going.

We’re about halfway into Sprint 1 and things are going as I was expecting. Stories are being burnt up on a daily basis, while some of the more complex ones are taking longer than we had initially estimated (sanding and re-staining the kitchen light fixture…..which needed to be done prior to our rehearsal dinner at our house). Some stories we had hoped to start on a certain day have not yet started, while some were completed early. We’ve also seen a couple of new stories injected into the Sprint requiring us to reshuffle the board.

Obviously the Scrum process at home can only be, “Scrum-like”, but as the Sprints progress I am seeing many of the same things that my Scrum team at Point2 experience from Sprint to Sprint. So maybe Scrum isn’t actually going to save my wedding since I don’t think it was ever in jeopardy, but I do think it was a great exercise to see how applying an Agile method in a completely non-technical area yielded many of the same results seen in the software development industry. If anything, applying Scrum to the wedding preparation was a useful tool in devising a plan, allowing us to visualize and execute that plan, and have a little fun along the way….geek-style.

By Hemant J. Naidu

Comments (2) »

The Corporate Culture of Post-it Notes

July 8, 2009 · Filed under Point2 - Process and People · Tagged , , , , , , , , , ,

Ahh, the ubiquitous Post-It® Note.  My workspace is covered with lovely multi-coloured notes, or it was until I discovered Digital Notes. The unassuming Post-it has become a legend but I wanted to  share it again, as told in The Knowledge-Creating Company by Nonaka, and Takeuchi.

Knowledge_Creating_Company

“Art [Fry] sang in the church  choir and noticed that the slips of paper he inserted to mark selected hymns would fall out.  He decided to create a marker that would stick to the page but would peel off without damaging it.  He made use of a peel-able adhesive that Spence Silver at the Central Research Lab had developed four years previously, and made himself some prototypes of the self-attaching sheets of paper.

Sensing a market beyond just hymnal markers, Fry got permission to use a pilot plant and started working nights to develop a process for coating Silver’s adhesive on paper. When he was told that the machine he designed could take six months to make and cost a small fortune, he single-handledly built a crude version in his own basement overnight and brought it to work the next morning.  The machine worked.  But the marketing people did some surveys with potential customers, who said they didn’t feel the need for paper with a weak adhesive.  Fry said, “Even though I felt that there would be demand for the product, I didn’t know how to explain it in words.  Even if I found the words to explain, no one would understand…” Instead, Fry distributed samples within 3M and asked people to try them out.  The rest was history.  Post-it Notes became a sensation thanks to Art Fry’s entrepreneurial dedication and dogged persistence.

(Nonaka I, Takeuchi H. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. 1995)

That entrepreneurial spirit has been part of 3M’s corporate culture almost since inception.  As stated in the William L. McKnight Management Principles:

“As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative. This requires considerable tolerance. Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way.

“Mistakes will be made. But if a person is essentially right, the mistakes he or she Post-itmakes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs.

“Management that is destructively critical when mistakes are made kills initiative. And it’s essential that we have many people with initiative if we are to continue to grow.”

Chris touched on this when he blogged about Failing Should be Easy and even Why don’t people like my ideas?!.  Art Fry was given the opportunity to fail.  When people didn’t like his idea, he proceeded to find a way to prove that his idea truly was great.

I’m proud that we here at Point2 allow people to fail; in fact, using Test Driven Development we ensure that everyone fails at first.

We give people time to explore and experiment, and everyone has some time for professional development.

Incidentally, Ken Schwaber’s early paper, “SCRUM Development Process” references heavily the work of Takeuchi and Nonaka and their description of a rugby organization style.

By: Kevin Bitinsky

Leave a comment »

If I Shorten the Race Can I Sprint Faster?

June 19, 2009 · Filed under Point2 - Process and People, Point2 - Technical · Tagged , ,

When Point2 adopted Scrum over a year ago we started with 30 day iterations. The process was new to us and it seemed like a reasonable starting point. As we ironed out our practices and got more experience we naturally started to make changes to improve how we did things.

After running through a few 30 day Sprints we soon realized that they were just too long. We were finding that at the end of the Sprint we were unable to remember what we did at its start. This became glaringly apparent during retrospectives. The decision was made to move to two week Sprints, and that is they way our six teams have been operating ever since.

My team had been throwing around the idea of shortening our Sprints even further over the last few months, but at our last Retrospective we decided to actually take the plunge. Even though we were being reasonably successful with two week iterations, we still felt that we could go faster. One week (5 day) iterations seemed like a good way to help take the team forward.  Here’s how we think the change will affect the team.

  • Even though two weeks was not long, it still left enough room for a large amount of stories to be part of the Sprint. This meant we had a broad focus.  One week iterations would allow us to easily visualize the Sprint. Our focus would be much sharper
  • One week Sprints would hopefully allow us to better accommodate change that comes in an Agile environment.
  • With weekly retrospectives would come more organized discussion to fine tune our process even further (that’s not to say we would not continue to make mid-Sprint changes if need be).

The team plans to make the transition at the start of the next Sprint. We understand there may be a bit of extra overhead in regards to planning and estimation meetings, but feel that these will get considerably shorter, having less impact on the actual Sprint.

Without actually having tried it yet the team just has a “gut” feeling that this will make us go faster. Just think about it for a second. If you are in a 400 metre race, you will have to run at a slower pace in order to finish. Cut that race down to a 100 metres and you should be able go to all out. I look forward to seeing how this will impact the team and will do follow-up posts reporting on our progress.

By Hemant J. Naidu

Leave a comment »

Why Did That Happen?

May 15, 2009 · Filed under Point2 - Process and People, Point2 - Technical · Tagged , ,

During our Sprints it is not uncommon for some problem event to occur.  Such events could be anything from a story taking considerably longer to complete than it was estimated to take, to a production bug being injected into a Sprint.  As a team we would usually acknowledge these events in our retrospective and make a few brief comments about how to eliminate similar occurrences in the future.  It seemed however as though we would promptly forget about the problem…until it happened again.

After seeing these problem events continue to occur, my team started throwing around the idea of doing root cause analysis. The hope was to get to the bottom of why these things were happening in the first place.

At first we were not quite sure how to conduct a formal root cause analysis, but after a little research we got ourselves pointed in the right direction. Our first analysis was a great exercise in drilling down into the heart of something the team saw as a problem. By focusing on one specific problem we were able to:

  • identify a plethora of individual areas that led to the problem in question.
  • isolate causes that could immediately be acted upon.
  • identify causes that we as a team could not solve alone.
  • bring causes into the foreground spurring discussion, and setting the team up to be mindful of them in the future.

As a team we have seen the benefit of analyzing our problem events and have integrated root cause analysis into our Sprint cycle. Just like we have a retrospective at the end of the Sprint we also have a root cause analysis session. One team member is responsible for presenting a problem event to the team and leading the analysis. To date we’ve done this three times and have used two different methods of analysis (Ishikawa Diagram, Cause Mapping). The way the analysis is run is completely at the session leader’s discretion.

We’ve already started to deal with areas that were immediately actionable, and have at least started to get the ball rolling in some areas that require a little more thought and organization. It is no doubt in my mind that as my team continues to identify and eliminate the root cause of our most crippling problems we will reach that hyper-productive state that so many Scrum teams strive for.

By Hemant J. Naidu

Leave a comment »

Mixing Up the Pairs and Collective Code Ownership

May 1, 2009 · Filed under Point2 - Technical · Tagged , ,

During my current team’s daily Scrums we’ll finish up by organizing our day.  It is usually pretty obvious what stories we need to be working on based on the state of the Scrum board, but who should be working on them is not always so clear.  During the lifetime of a story (which most often is multiple days) I will start to get uncomfortable if it has been worked on by the same pair.  As the Team Lead I’ll raise the question, “should we mix up the pairs?”

As a team we are striving to attain collective code ownership.  We are close, but not quite there.  In order to get there as fast as possible,  I feel that switching pairs often is one of the answers, but in the early stages this can be difficult and exhausting.

The previous team I led did reach a level of collective code ownership.  We committed to switching pairs at least twice a day, and facilitated this by introducing a mid-day stand-up to reorganize the team.  We would also use this time to discuss the progress of our current stories, before getting back at it. Our experience at the time revealed the following pros and cons.

Cons

  • lots of time spent “ramping up” a new pairing partner after joining a story in progress
  • developers could become frustrated having to give detailed explanations to new pairs multiple times per day
  • it was very draining for developers to have to switch contexts so often

Pros

  • better design resulted from multiple developers being involved in the story
  • developers were seeing all areas of the code
  • the team was suppressing the creation of “experts” for certain areas of the system. Everyone was an expert – our truck number was rising.
  • daily Scrums were becoming more useful since everyone understood the stories being discussed. No one had that glazed look on their face waiting for their “turn to report in”
  • our velocity started to increase

The process was not easy, but as we pushed forward we found that the time to get brought up-to-speed gradually got shorter.  During the daily Scrums our discussions were now leading the developers to form the pairs on their own in a more natural fashion.  And before we knew it they were switching pairs outside of our daily Scrums whenever they felt it made sense.  That’s when I realized we had collective code ownership.

Like I mentioned earlier my new team is still working towards collective code ownership so I am trying to implement some of the steps my previous team took.  The team is larger, and we are working with a bigger and more diverse code base, but I am confident that we will reach our goal.

I am interested to hear about others people’s experiences in this area.  What measures did your team make to maximize your truck number?  When do you think it makes sense to switch pairs?

By Hemant J. Naidu

Leave a comment »