Out of Iteration Software Bugs

I did a presentation last week at an Agile event and during the Q and A session one of the questions was about “out of iteration bugs”. Specifically how are they handled? Good question, not all the bugs found in a software project will come from QA activities. It is inevitable that the users are going to find something with the software that needs to be fixed and or changed. What to do?

In most cases the issue is treated like any other backlog item to be prioritized and addressed in an iteration. Depending on the severity / priority rating of the issue, the product owner can weigh the cost of fixing the bug now or having the Agile team complete a different user story. It’s just a matter of cost/benefit tradeoff of where the Agile team’s resources are spent.

Out of Iteration Software Bugs

To Squawk or not to Squawk

The daily standup meeting is one of the core concepts of Scrum. In the meeting the team members talk about just three things:

• What I did yesterday
• What am I doing today
• What are my impediments

And that’s it…   However, the teams that I see can’t keep it that simple, there is always some banter ( a good sign of team happiness ) and extended discussion on what is going on that may derail the team or another team member.  If the discussion goes on for more than a few minutes we table the discussion for right after the standup.  While it’s important to keep the standup moving its more important not to squash communication.

Who should participate? Anyone who is involved or interested in the project.  Who should actually talk?  Only the folks directly involved in working on the backlog.  The other participants should keep their thoughts to themselves until they get a chance to talk to the Scrum Master away from the team. 

Now I’m going to break the rule, one last thing at the end of the standup I want to know if there are any announcements.  This is a time for individuals that are close to the project but not working on the Product backlog to give the team any information that is valuable for the team.  Usually I limit who can give announcements to a very few trusted individuals.

Daily Stand-ups.. keep them simple fast and open to the team.

To Squawk or not to Squawk

Agile and Team Motivation - Goals

I recently started a series based on an Esther Derby Amplify discussion about how to demotivate a team. Esther mentioned in her discussion that unclear and changing goals are a big demotivator for a software development team. Besides agreeing whole heartedly my first thought when reading her discussion is how a good Agile implementation combats these demotivators. Let’s see how Agile methodologies thwart some of these potential demotivators for software development teams.

But first, a high level review of some key Scrum concepts; The Prioritized Product Backlog, the Sprint Backlog, and the Sprint Planning Session.

The Product Owner prioritizes the Product Backlog to identify the highest priority / value product features to be delivered by the Agile software development team.  By viewing the Product Road Map and the Product Backlog the Agile software development team can get a fairly clear idea about the project’s long term goals. 

Scrum and Goal Stability / Clarity

• The Product Road map is created by the product owner to provide a long term view of the product vision.

• The Product Backlog provides a view of the desired functionality expressed as user stories. The Product Owner prioritizes the user stories to place the highest value user stories to the top of the Product Backlog.

• The Sprint Planning Session and the Sprint Backlog; The Scrum team conducts a Sprint Planning Session in which the Scrum team selects from the Product Backlog a set of user stories and then commits to complete the selected user stories in the next Sprint.

• It’s important to note that once the Sprint commitment is agreed upon by the Scrum team, the contents of the Sprint cannot be changed by someone outside the Scrum team.

• Every day the Scrum Master conducts a Standup meeting with the Agile software team to review progress against the Sprint commitment. Using burn down charts the team can see if they will complete the user stories and meet the commitment (goal) of the Agile team.

• Once the Sprint completes, the Agile team demonstrates the completed code to the product owner to validate that the Agile software development team delivered what was expected by the Product Owner.

In the Scrum / Agile environment, the team can see all aspects of the project, from the macro level Road Map to the micro level of the individual task. The Scrum team members set their own commitments on what they can deliver and are responsible to deliver on their commitment. It’s reassuring for the software development team to know they won’t be thrashed with constant change. It’s also very satisfying for an Agile software development team to deliver functionality on time, demonstrate it, and have the product owner validate that the developed user stories are what was expected.

Agile and Team Motivation - Goals

Agile and Team Motivation

Esther Derby makes some good points here about how to demotivate a team.  What struck me about her points is that they are exactly opposite to how a good Agile software development team works.

Esther wrote “What demotivates people? Bureaucracy, unclear goals, constantly shifting goals, micromanagement, punishment for delivering accurate by unwelcome status (to name a few).”

How does an Agile team differ from this?  I’ll start a whole series of articles to review these demotivators and how Agile teams avoid and address these issues.

Agile and Team Motivation