When Pigs Become Chickens

I received and interesting question, somebody asked me about some reasons why a pig might become a chicken I can think in a few:

1. The pig is a low performer and she is as productive as a chicken
2. The pig's motivation is so low that she acts like a chicken
3. The staff was reduced and we have less pigs or some were reassigned to other projects but still play chicken's role in our
4. Part time engineers that switch among projects and don't really contribute to any
5. Upper managers who like to play pig's role but run away when they have to get their hands dirty with complicated tasks

Mechanics and the Myth of the Satisfied Client

It’s always a true in software development that we try to satisfy clients believing that they’re always right and they always know what they want. Further, we tend to think on them like almighty goddess with unlimited decision powers. But let’s think it twice, why should we be more committed to customer satisfaction than other service industries?

Let’s take this example from real life, my real life at least. I took my car to the car shop because the front wheels were making some funny noise whenever I slammed on the brakes. The mechanic when below the car, took a look and found nothing. I insisted in that the car was making noises when I drove it, the mechanic said let’s take it for a test ride. I drove the car, slammed on the breaks and again nothing: no noises, no breaks failure no nothing. The mechanics just smiled to me and charge me a no cheap fee for his time.

As a customer, what was my problem? Did my car really have a problem? It was a random not easily reproducible bug? Honestly, I don’t know, but I’m sure that I’m not crazy and the noise was there. So the point is, does the client have enough knowledge to diagnose problems? More to the point, what approach the mechanic used to try to pin down the problem with my car? No big up front requirements, the mechanic uses and iterative approach for diagnosing, fixing is incremental and many times mechanics have to inspect and adapt their work as they move.

Lastly, mechanics usually don’t tell us how much they’ll charge us for their services; they complete the work and then ask for payment. Most of the time your car is fixed and you paid without questions. What a wonderful life mechanics have, don’t you think? Something that we can copy?

My article has been Published by the Agile Alliance

An article that I wrote last month, Key Metrics for Measuring Sprint Status, has been published by the Agile Alliance, see this link http://www.agilealliance.org/articles_by_category?id=10

The full article can be also found in this blog: http://juanbandaonscrum.blogspot.com/2009/08/key-metrics-for-measuring-sprint-status.html

Scrum Bolivia User Group on Twitter

The Scrum Alliance officially announced the creation of the Scrum Bolivia User Group on Twitter.

The Scum Bolivia Yahoo! User Group has been Created

Finally the Scrum Bolivia has an official User Group where Scrum Practitioners can meet to share experiences and learn from each other, this is an open group so no moderator approval is required. The link to this group is http://tech.groups.yahoo.com/group/scrumbolivia/



The Scrum Alliance also made public the creation of this group, and include it in its listing of official groups, see this link http://www.scrumalliance.org/user_groups/74

Plan for the Sprint vs. Sprint Planning

A typical question that comes from teams is how much planning should be made for before starting a Sprint? Further, what should we plan for? These are fair questions without direct answers. Let’s start trying to solve this puzzle one piece at the time.

What is planning?

According to Wikipedia, planning is “…the psychological process of thinking about the activities required to create a desired goal on some scale”. So, if planning involves thinking next questions should be, is this an individual or collaborative activity? The answer for this seems to be quiet intuitive, it’s an individual activity that is performed in a group but not necessarily a team activity.

What is Sprint Planning?

Is the stage in which the team, and when I say the team I mean everybody that actively will contribute during the Sprint (no chickens sorry), gets together in a single room for an X number of hours and try to define what to do. Focus on what and not how. One tip: don’t let the Product Owner run without answering all your questions, lock the door if necessary.

Plan for the Sprint

This is not the Sprint planning stage; this has to do with more tangible things like: capacity planning, logistics and infrastructure. For instance, consider you will be taking vacation and what type of environments or licenses are you going to need in the Sprint. Some other questions might to consider:

• Should I have to use Agile/Scrum for plan for the Sprint? Not necessarily, since this is a support part necessary for the sprint but not under the scope of the team.
• Who should take care of this? Somebody in your Management and/or IT staff.
• Is this really important for the Sprint? Absolutely, you can’t have a Sprint without knowing what resources you’d be committing.

Question on Why we're Always Late

• Why we always have Quality Engineers and Info Devs trying to catch up with development? Is this because development is moving too fast and QE/ID too slow? Or is this because development moves to slow holding back QE and ID work? We shouldn’t be asking this questions in the first place if we consider everybody as part of a single team (no dev, QE, and ID for separate) and we have a consolidated Definition of Done. DoD is what can tell us if a user story is really completed or half baked. DoD should be common and all team should aim to complete user stories under this definition.
• One step back, why we plan for more than we can achieve? Part of this is because we don’t plan thinking as a team, development plan first and then QE and ID add their estimates. Development estimates might fit whiting the timeboxed iteration but QE and ID would most likely fell of the mark. The other part of this is because we don’t know for certain team velocity.
• Why we don’t know team velocity? We measure progress in hours but we plan in user stories, our backlog contains user stories that when moved to iterations are tracked down using burn hours. What Scrum recommends is using burn down charts for user stories not for hours. Burning hours is not a good indicator of progress, on the contrary, it often mislead us when we try to evaluate iteration progress.
• Velocity could be better indicator if we can estimate the number of user stories that the team is able to produce in an iteration. However, story points or other metric should be considered to have a correlation metric for user stories’ size and complexity.
• Are carried over user stories that bad? Without question carrying over user stories break the Scrum principle of having a Potentially Shippable Product at the end of each Sprint. Moreover, from a production stand point, carried over user stories creates a technical debt that will drain team’s capacity in the future.