Scrum Development Blog

Better teams make better products.

Posts Tagged ‘agile process’

Kanban Vs. Scrum

Agile Pathways | Posted by The 3Back Team
Feb 11 2010

Will Kanban replace Scrum?

Choose

  1. No way, they are opposites: Kanban is for flow / Scrum batchscrum flow kanban flow
  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 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.

Should we extend Scrum?

Scrum Questions | Posted by The 3Back Team
Jan 25 2010
  1. change scrum extendSure, thats what agile/scrum is all about.
  2. Sure, you might wonder if you are making things harder to detect.
  3. No way !!!

Comment: The idea here is that there can be only one source for Scrum. I guess that depends on where you get your definition from and what you need. Should there be only one way to think about scrum? Probably not, although,  a rookie mistake is to modify without have deep applied practice and experience under your belt. Should there be one clean centering definition? I hope so. The 1st common mistake we see people make is modifying scrum without understanding it. They often confuse themselves and their organization. Advice: Refrain from thinking about extending scrum or modifying it. It needs very little and all we seem to do is over complicate things.

Are Placeholder Stories Ok?

Planning | Posted by The 3Back Team
Jan 18 2010

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”.

You Don’t Do the Agile Process You Are the Agile Process

Agile Pathways | Posted by The 3Back Team
Mar 03 2009

You Don’t Do the Agile Process You Are the Agile Process

Saying it this way puts and emphasis on starting with self and looking inward before blaming outward.

For an agile process to be successful, and probably any process at all, it must allow some focus on people, passions and teams working together.

  • Without an aim we have no purpose and not much of a reason to be a team. When we have that product aim we can test our ability to work together by looking at the results of our product development effort.
  • Without a focus on people we often on mechanics of the process to the exclusion that people matter.
  • And without working towards our passions we fail to ignite the energy within ourselves and we fail to contagiously spread our enthusiasm to others around us.

When we properly include the above three in our line of vision and don’t fall prey to using a model of software development that is so complex there is no room in our heads for the above three, we can win BIG time. What we focus on matters and if the process is so complex there is little room to think about anything else, then we loose.

A recurring pattern, that we have observed in large scale adoption of Agile “The Pursuit of Enterprise Agile” . Is a successful pilot that really focuses on the people working together, can ignite a ground swell approach to adopting agile.

Typically, organizations get started by contracting with outside an outside expert who advises them how to start agile. The advice is typically some setup a pilot that will be small enough to influence yet important enough to keep attention focused. The idea behind a pilot is simple, “Let’s setup a little experiment with this thing called agile and see how it works out for you?” After a business case review or senior leadership buy-in, the pilot is set up with an appropriate amount of autonomy.

Usually, an internal person is to be part of the pilot and run it. That person is charged with setting up the pilot and documenting their observations so that the organization can learn. A team is formed, trained and started down the agile path. The team works shoulder to shoulder with an on-site agile consultant who demonstrates the habits and values of agile while in motion. Often the team quickly emulates the behavior and then falls into a rhythm of product development and delivery.

Then someone “process experts” typically take the observations of the people working together and abstract them. Now things really get whacked. The process expert believes they can take observations of the pilot and fold lessons learned into the enterprise methodology view. This is a too “hard problem” we have been trying to do this for years and are still in our infancy for understanding basic communication. However, based on what is written and documented in classic process literature you would be lead to believe we have evolved far more than we have.

After organization have absorbed the lasted round of process learning into their enterprise methodology. The very real skills and valuable team behaviors that were gained are lost. The next agile effort looks very much like the old process the organization ran before just with new words and language. The part that made the pilot effective is lost.

That is why “You Don’t Do the Agile Process You Are the Agile Process” works so well as a phrase. It constantly reminds me that agile starts with self.

People, Passions and Teams must be elevated above Principles, Philosophies and Practices. Without the first three the last three will not matter.