Tag Archives: agile

Handling Bugs and Maintenance in Agile

One question that comes up often when teams are exploring the transition to Agile is how they are going to handle bugs or maintenance issues.  This blog will outline three scenarios that have worked for teams.

1. Building time into the Sprint

Image Source: http://www.asrintl.com/?page_id=310

Image Source: http://www.asrintl.com/?page_id=310

Perhaps the most common way that teams deal with unpredictable bugs and maintenance issues is to reserve some time for them within the Sprint.  For example, the team can handle 40 story points per sprint, but they only commit to 35 points, so they will have some time available for the unplanned bugs that need immediate action.  In some sprints, the bugs may account for more than the allotted 5 points and in other sprints, they may be less but on the whole, the team learns their rhythm and builds in enough reserves to handle whatever may come up.

Managing Conflicts in Agile

helping-hand

Image Source: http://www.reachingout.me/general-stuff/

Moving to Agile or Scrum introduces a lot of change and that can lead to conflicts in an organization.  There are a number of key factors to consider when managing those conflicts so that they are resolved quickly and collaboratively.

1. Level Set on the Goals

Here is a common scenario that we see in Agile.  The development team is frustrated because the Product Owner doesn’t have all of the answers and the Product Owner is frustrated that the developers ask for everything before they will work on anything.  Does this sound familiar?  In this scenario, we need to get back to basics and remember our main goal.  We want to deliver working software that adds business value as quickly as possible.  Both the development teams and the Product Owner share this goal and we need to remember that.  No product owner is knowingly going to withhold information about the marketplace or the product and no development team ever plans to write crummy code.  We all want the same thing, we just have different roles in how to achieve that.  So if you find yourself at a stalemate, think back to the original goal and realign on that.  It can really help to get everyone back on the same page.

Scrum Meetings

There are a handful of meetings that the Scrum Methodology includes as part of the cadence and this blog addresses each one and why they are important.

teamwork

Image Source: http://silenced-no-longer.blogspot.com/2012/11/a-revelation-putting-together-puzzle.html

Sprint Planning

The first meeting is called Sprint Planning and this is a two-part meeting.  The first part is  where the Product Owner has the opportunity to clarify and answer questions regarding the highest priority items in the backlog.  The Scrum team and Product Owner then set the Sprint Goal by deciding which stories will be included in this Sprint.  This is sometimes referred to as the “What” part of the meeting when we determine what we are going to build.  The second part of the meeting is for the Scrum team to discuss the individual tasks that will be required to execute the stories and any technical considerations or dependencies.  This is referred to as the “How” part of the meeting when the Scrum team decides how they are going to accomplish the what.  The team also usually picks the tasks that each individual is going to work on and estimates the amount of time that each task will take to complete.

Agile: The Power of the Fist (of Five)

There is a concept in Agile called Fist of Five.  The notion is simple – when you come to a decision point and you need to make sure everyone is on board,  you ‘vote’.  Agile is all about transparency and Fist of Five is one method to reinforce it.

Image Source: http://nicosteyn.wordpress.com/2011/01/12/5-rules/

Image Source: http://nicosteyn.wordpress.com/2011/01/12/5-rules/

We do it like the game “Rock, Paper, Scissors” where everyone shows their vote at the same time.  One – Two – Three – Shoot.  In theory, this is supposed to keep people from being influenced by their neighbor, but honestly, we think it is just more fun.

The voting works as follows:  A team member will propose a direction forward and the team will demonstrate their acceptance by holding up their hand with the number of fingers that corresponds with their level of support.

5 fingers = I am all in.  I completely agree.
4 fingers = I buy into the option and I will support it.
3 fingers = I may have some reservations, but I can support the decision and move forward.
2 fingers = I have reservations and I cannot support this decision without further discussion and clarification.
1 finger = I cannot support this direction.  I disagree.

Agile Textbook

As you may know, I am very proud to be co-authoring a textbook on the Agile Methodologies. This unique book is targeted at undergraduate computer science, software engineering and business students who do not necessarily have work experience to help them understand the nuances, challenges and benefits of an Agile implementation.  Our goal is to present the information in an easy to digest fashion to provide students with the terminology and concepts that they will need when they enter the workforce.

Studygroup relaxing in beanbags while doing school work.

Image Source: http://www.stevenharveyceca.com/individuals-future-college-students

Our question is:  What should we include in the book?  Is there something that you wish someone had taught you with regards to Agile?  Is there something that you wish new hires and interns understood about Agile?

 

Our book will cover the following topics:

  1. The history and value of agile development
  2. Understanding the different types of agile development
  3. Describing the different roles
  4. Cultural considerations with agile
  5. The new way to collect and document requirements
  6. Grooming and planning
  7. Tracking and reporting
  8. Testing, quality & integration
  9. Market management

We will reference many of the Agile experts as well as present stories and examples to make the information more relatable.

Please let us know your thoughts on what needs to be included.  We would love to get your input!

 

The Voice of the Customer

Part of Product Management and Agile Product Ownership is to incorporate the Voice of the Customer into whatever you are building.   Whether the customer is a farmer, a small business owner or a busy executive, it is the Product Manager’s job to get in their head and figure out how to solve their problems.  How do you know that you are getting the best information? 

voice_of_user2

Image Source: http://blog.mozilla.org/metrics/2009/07/13/does-mozilla-champion-the-voice-of-firefox-users/

Here are several methods of collecting data and each serves a particular purpose.

1. Interview

Meeting one-on-one with customers or prospects can enable you to collect great feedback.  The trick to the interviewing process is to ask open ended questions.  What is your number 1 business problem? What is the most time-consuming task in your day? What do you enjoying doing the most?  The data that you can gather from these conversations can be golden.  Make sure, though, that you remember that a single data point is just that.  Look for common threads from several conversations and solve the greater need.

The Agile Family

As you can tell, I am a bit of a nut about Agile.  There are so many things about it that I appreciate and now I have something new to add to the list.  We were told about a TED talk by Brue Feiler regarding an Agile Family and I had to watch it.  Following Bruce’s direction, we started our own Agile movement on Sunday night and since then three amazing things have happened.

First, let me share our dynamics.  We have two daughters, 11 and 12.  They are only one grade apart in school and they do everything together – including fight.  We are a loving, caring, sarcastic and funny family who definitely has moments of chaos and meltdowns.  During the school year, my least favorite time of day is just before bedtime.  Since my husband is a stay-at-home Dad, I feel like it is my responsibility to get my little angels tucked in every night.  Let me tell you – shear torture.  They would stall and play and not do what I asked and whine and stall.  You get the picture.  It got so bad we even nicknamed the little one “Delay Fish” from Dory’s character in Finding Nemo.

So as I watched Bruce’s TED talk, I thought – the nighttime ritual is what I want to change.  We started our first family meeting on Sunday with each girl making a list of what they need Agile_Checklistto accomplish before going to bed.  It includes showers, teeth brushing, finding and charging your cell phone and more.  I added some of the items that annoy me – like hang up your towel.  We then turned their notes into a checklist and taped it to the mirror in their bathroom.

We then said ‘what is something that doesn’t work in our family right now?’  The girls said (in their own words) that we weren’t good at respecting each other’s personal space.  Then we defined what that meant and created a Working Agreement. (1) Leave someone’s room when asked. (2) Have their permission to use something of theirs and (3) enter someone’s room only when you have permission.  Pretty reasonable.  We then asked what the punishment would be for someone who violated this agreement.  The girls agreed on the loss of TV on Saturday.

Measuring an Agile Product Owner

I went to a meeting last week and we were discussing how to measure a Product Owner.  The concept is completely understandable, but there was something about the meeting that didn’t sit well with me so I am devoting this blog to trying articulate my concerns and things that I think need to be considered.

The premise is sound  – how do you know if the Product Owner is leading you down the right path?  What if you build the wrong thing?  And how can you assess their mis-direction before precious time and resources are spent?

That is a 100% valid question and one that we should certainly spend time and thought to resolve.  The idea that there are ratio-driven metrics to measure the PO’s performance, though, seems counter-productive.

fignerpointing

Image Source: http://thoughtsonleadership.biz/three-fingers-pointing-back/

First, I think Product Owners have a very difficult job and I think very few people are naturally great Product Owners, if you go by the broad definition.  Product Owners are supposed to understand the market place, stay on top of the competition, interview current and prospective clients, and break down all of that data into meaningful features that will be delivered in order to drive the most business value.  They are also supposed to be experts at writing user stories, adding acceptance criteria, understanding at least some level of the technical details associated with the application, and they need to be decisive, informed and immediately available for the Scrum Team.  That is a tall order.  In fact, I recommend splitting the Product Owner’s responsibilities between the Product Owner and a Product Manager, as I referenced in a previous blog.

Sacredness of the Sprint

Here is another excerpt from our upcoming Agile textbook.  This is a topic that I am particularly passionate about!

No Changes to the Sprint

One of the most importance cultural changes related to Agile adoption is adhering to the sacredness of the sprint.  What does this mean?  It means that once a sprint goal is committed to, there should be no changes to that goal.  sprint_sacred.jpgThe group that has the hardest time adhering to this is upper management.  There is always some crises or customer request or great idea that an executive wants the team to investigate immediately and there is a tendency for executives to pull the team off of their sprint commitment to work on the latest critical task.  The companies that allow this type of distraction have the most difficult time adopting Agile.  The companies that stand firm and honor their sprint commitments tend to be more successful in their adoptions over all.  Truly, it is a sign of executive commitment to the process and the methodology if they honor this one aspect.

Mike Cohn, in his book Succeeding with Agile, is very firm on this issue. “Nothing is allowed to change within the sprint. The team commits to a set of work on the first day and then expects its priorities to remain unchanged for the length of the sprint. “ (2010, pg 279)

Agile Examples – The Scrum Team

This is an excerpt from the textbook that I am writing with a co-author on Agile.  Here are examples of a strong and weak Scrum Teams.  Would love to hear your thoughts and comments.

Strong Scrum Teams

The green team has a team member who is wicked smart, so much so that the rest of the team has trouble keeping up with him when he gets going on an idea.  He is almost always right in his direction but he processes information in his brain so quickly that when he talks, it is a bit like gibberish to the rest of the team because he doesn’t clearly state how he got from problem to solution.  On some teams, this type of savant could be extremely frustrating because when he talks, the team rarely understands what he is saying.  But the green team is a highly effective team and they recognize and value the intelligence and ideas of their super-smart colleague.  So they brainstormed the right way to allow him to communicate his ideas and thought patterns.  They painted all of the walls in the area with whiteboard paint which allows you to write on the walls, from floor to ceiling, and then erase it when you are done.  They encouraged their team member to write down the train of thought that his brain was making in solving a particular problem.   This allows the rest of the team to slowly digest what their colleague is conveying and they have a written record to access when they are trying to recall a specific detail.  The green team rallied together and found a solution that would allow all of their team members to actively contribute and drive towards the best possible solution.

Not so Strong Scrum Teams

The blue team is not optimized.  They have a member who is equally talented but far more disruptive.  This individual is negative and not a team player. Every idea that isn’t his own is stupid and anyone who doesn’t like his ideas is stupid.  He is very intelligent and knows the system very well so his behavior is tolerated even though he is so negative.  The sense is that the team could not do without him because of his expertise.  His presence has created a work environment that is tense and unproductive.  His team members are reluctant to confront him because he is so aggressive in his negative demeanor.  The issue of his attitude has been raised with both the Scrum Master and the IT Manager but neither are willing to address the problem because they fear losing his expertise on the system.  So this team operates in a constant state of fear. They do not know how this individual will react in any situation so they all retreat and wait for his reaction before they express any opinions of their own.  The team is failing to meet any of its deliverables because no one can commit to certain tasks when the bully on the team is driving all of the discussions and undermining the whole Scrum practice.  This is an ineffective team who would be far better off if the dominant individual was removed from the team.  They might suffer a bit from the lost expertise but they would gain far more by being allowed to brainstorm and work together.

Want to read more?  We have examples for Product Owners and Scrum Masters too.