Apr 12 10

Agility and Reality

by dan

Exploring Scrum

When plans and reality collide there is a need for agility.

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Mar 4 10

Agile Earned Value Metrics – Book Chapter

by Doug Shimp

Scrum is a popular project management framework for agile projects. Scrum projects are typically managed quite informally, with the only metrics used being various velocity metrics and burndown charts. Because these metrics only measure the speed of delivery, not the project’s cost or the business value it generates, many project managers are resistant to Scrum.

scrum agile papers book

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Dec 8 09

Kanban Vs Scrum – Emperical Light Weights

by admin

Kanban for software development is a newer kid on the block, at least in the US. Besides being just another word like Scrum that is not commonly understood in the English language, how does it stack up? Both Kanban and Scrum align with the well with the value system described in the Agile Manifesto. And they make an interesting pair.

As much as we love Scrum, even we would have to admit that it’s not perfect.  Nothing is. In fact, a large part of the literature describes workarounds for various deficiencies that Scrum presents to us in certain circumstances.

download-scrum
Presentation

One of the more commonly noted deficiencies in Scrum is that it plans its work a whole Sprint at a time.  This “batch” planning process is often not agile enough to cope with the actual rate of change of requirements.  In fact, PlaceHolder Stories, discussions of mid-Sprint Re-planning, and discussions of renegotiating the scope of a Sprint are common deficiencies that teams must cope with.

The new kid, called Kanban, which solves some of these deficiencies and presents others, is becoming popular for software development projects.

Altogether, Kanban, Scrum, XP and many other agile methods rely on a task boards and index card like systems to simultaneously decompose and manage the work. What’s new about task boards and index card systems? Index card systems have been around at least since 1925, when the first one was formalized by Dr. Crawford and used later to build NASA rockets. Increasing task orientation is a well understood method for improving team performance and has been well documented since the 1950s. Our goal will be to highlight both Kanban and Scrum and then touch on why we need to reinvent them ourselves so often.

Learning Objectives

  • An overview of Kanban
  • An overview of Scrum
  • Stacking them side by side
  • The Power of Index Card Systems and Task Orientation
  • Can one reduce or evolve from one to the other?
  • Why do we repeat ourselves so often?
Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Oct 16 09

Will Kanban replace Scrum?

by admin

Choose

  1. No way, they are opposites: Kanban is for flow / Scrum batch
  2. Yes, Scrum is old school big planning steps
  3. Yes, Kanban minimal planning / Scrum is heavy planning
  4. No, Scrum can reduce to KanBan
As much as we love scrum, even we would have to admit that it’s not perfect.  Nothing
is.  In  fact, a  large part of this book describes workarounds  for various deficiencies that
scrum presents to us in certain circumstances.
One of the more commonly noted deficiencies in scrum is that it plans its work a whole
Sprint at a  time.   This “batch” planning process  is often not agile enough  to cope with
the actual rate of change of requirements.    In fact, Chapter 4.4 on PlaceHolder Stories,
the  discussion  of  the  mid-Sprint  Re-planning  in  Chapter  4.8,  and  the  discussion  of
renegotiating the scope of a Sprint in Chapter 4.3 are all about resolving this deficiency.
There  is  another  agile  process,  called  KanBan,  which  solves  this  problem  and  is
becoming popular  for  software development projects.  In  this chapter we will describe
the main strength of KanBan and how to integrate it into scrum.
Brief Description of KanBan
The  “KanBan  for  software” movement  is  led by David Anderson1
, and  is  really gaining
some  traction  in  the  agile  community.    The main  idea  of  KanBan  is  very  simple  and
based  on  the  Lean  “pull,”  “Just  in  Time”  (JIT),  and  “reduce  inventory”  principles:
eliminate planning inventory by making sure that you don’t commit to doing work until
you are actually ready to start the work.

As much as we love scrum, even we would have to admit that it’s not perfect

kanban-flow-scrum-batch

. Nothing is.  In  fact, a  large part of our book describes workarounds  for various deficiencies that scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in scrum is that it plans its work a whole Sprint at a  time.   This “batch” planning process  is often not agile enough  to cope with the actual rate of change of requirements.    In fact, Chapter 4.4 on PlaceHolder Stories, the  discussion  of  the  mid-Sprint  Re-planning  in  Chapter  4.8,  and  the  discussion  of renegotiating the scope of a Sprint in Chapter 4.3 are all about resolving this deficiency.

There  is  another  agile  process,  called  KanBan,  which  solves  this  problem  and  is becoming popular  for  software development projects.  In our upcoming book we will describe the main strength of KanBan and how to integrate it into scrum.

Brief Description of KanBan

The  “KanBan  for  software” movement  is  really gaining some  traction  in  the  agile  community.    The main  idea  of  KanBan  is  very  simple  and based  on  the  Lean  “pull,”  “Just  in  Time”  (JIT),  and  “reduce  inventory”  principles:  eliminate planning inventory by making sure that you don’t commit to doing work until you are actually ready to start the work.

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Oct 16 09

Is it ok to have Placeholder Stories?

by admin

Choose:

  1. place-holder-story-scrum-agile-slackA placeholder story is a sign of sloppy planning
  2. All work should be known ahead of time and planned during sprint planning
  3. Yes, this allows the Product Owner to dump things into the sprint as needed.
  4. Sometimes we have a history of unexpected bugs/issues of handle it now. This allows us to track how much of that is showing up and leave some slack for when it does.
  5. We often have work we know we will have to do but, don’t know what it is yet.

Comment: This is a way to track how much unknown work is showing up and manage the amount by triggering a conversation when needed. One of the most common issues for scrum teams is what to do about work that we expect to have to do during a Sprint, but don’t actually know the details about yet, such as bugs we have to fix in existing systems, or expected sales support efforts. Using Place holder stories is a a method to manage these “known unknowns”.

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Oct 15 09

When is a requirement truly required?

by admin

When does the word requirement truly mean what is says in English?

Choose

  1. The development team creates a spec.
  2. The Product Owner says it is.
  3. The business asks for it.
  4. There is a test which actually requires it to be there and fails when it is not.

Comment: We often find ourselves lost in the desirements trying to find the real requirements for our system. Those things which seem required often end up being only desired. The word requirement has suffered more from confusion and misuse than just about any other word in the IT lexicon of development. What is a “nice to have” requirement? I mean really! I have close to 20 years of experience in the industry including training and writing requirements. Even with all of that experience the word still makes me a little crazy. I like the word desirement because of it’s contrast with requirement. When there is a test that makes it required with a pass/fail then it is a requirement, until then it’s just a a desirement.

So, a more interesting question is …. When is a requirement truly required?

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Oct 14 09

When are you ready for sprint planning?

by admin

Choose:

  1. The PO says go.
  2. The Teams says they are ready.
  3. The SM has determined a time box for the sprint.
  4. The team and PO agree to a time box
  5. The PO understands and is prepared to talk about the stories

ready-sprint-scrum-planningComment: There are a number of things you should do before you can even begin planning.  The most important thing you can do is make sure that your Product Owner is prepared, and understands what the stories are about.  Remember that the Product Owner is a role here, so what we’re actually saying is that someone on the Team knows about each story; that is, each story has its own champion (Story Owner) who represents the Stakeholder’s needs/wants to the Team. This may require that the Product Owner (person) coordinates the efforts of all the Story Owners.

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Oct 13 09

How do you fill a sprint?

by admin
  1. You get past work experience. And calculate the amount of work the team can handle
  2. Get estimates from the team and double the number they give you to determine work load.
  3. Meet with each individual and see how much work they can take on. Build a sprint plan from that information. Then gather everyone, show the sprint plan and kickoff the team sprint.
  4. Use the PO/SM powers to challenge the team to take big bites. Get as much loaded in the sprint as possible. The PO/SM can form a powerful pincer to overcome resistance.
  5. This is sprint planning.  You commit one story at a time. Make sure the team is committing to sharp definitions of done.

fill-sprint-work-story-doneComment: After a Story is committed to, the Team (with the PO in the lead) has the option to reprioritize the Story list, and the Team takes the next one to consider. Once again, the Team comes to the “doneness” Agreement and commits to adding the Story to the list of already-committed-to Stories. This process is repeated until the Sprint is “full” and the Sprint Plan is complete.

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Oct 12 09

When is a story too large for a sprint?

by Doug Shimp
  1. It is never too large for the sprint. The team must learn how to meet business expectations.
  2. The team cannot agree on which stories to work  on during the sprint
  3. The product owner has prioritized the story into sprint planning without any written definition of done
  4. When the team cannot agree on how to commit to the story
  5. Teams are inherently anxious; SM/PO must challenge the team and not accept no for an answer.
  6. Make the sprint bigger so the story fits.

Comment: The Team may not be able to commit to a story, or might notbig-story-bite-epiceven be able to agree on “done.” This makes the story in question is an epic, by definition, and the Team must decide what to do. Typical choices include committing to an Analysis Story to figure out what to do about the epic, or extracting a smaller story from the epic to do instead (putting the remainder back on the backlog), or skipping the story altogether and moving to the next one. Bottom line: We need a sense of movement to understand what the team can and cannot do. Biting off chunks of work that are too large obscures movement and makes throughput / velocity that much harder to understand. Use the team’s ability to commit to understand the work that the  story represents.

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare
Oct 10 09

Can work be added during a sprint?

by Doug Shimp
  1. You should never add work during a sprint
  2. If the Product Owner wants it then put it in
  3. As we understand the work we adjust our view of the work to reflect what it takes to do the job
  4. This is really a question of granularity. If the adjusted work is in small bits then yes, as the bits get larger we risk loosing rhythm and consistency.
  5. Our sprint plan should have nailed it. Changes during the sprint is a sign of sloppy planning.

breaking-work-into-granulairty-and-grooming

Comment: Changes to work forms an interesting tension.  At a fine grained detailed level it changes all the time. Each person’s individual to-dos often change to reflect their understanding of what it takes to get the job done. As the level of granularity increases to task then it is a change to the team’s plan. If the number of changes is significant and adds up to more than one story’s worth of work then you better stop and adjust your plan, usually you want the product owner in on that discussion. And if there are several new  stories that were  suddenly found and are so important they must be done right now, then call a stop and reset your entire sprint with a sprint planning session. Generally, the commitment by the team to the sprint should not change. Note: definition of team makes this an interesting discussion. Bottom Line: The goal here is to help the team get better at  expressing work they can do and following through on a commitment.

Amazon Wish ListBitty BrowserBlogger PostLinkedInPlaxo PulseRedditWordPressTwitterStumbleUponSlashdotTechnorati FavoritesPingHuggGoogle ReaderGoogle BookmarksDeliciousBlinklistFacebookShare