Posts Tagged ‘Agile’

 

2016-05-27_22-55-59.jpg

 

I love to walk around team spaces and identify cool things that people are doing so I can share them with the organization.  Last week while doing a Gemba Walk in one of my offices I found this!

On his metal scrum board he created “What’s at Risk” information radiator magnets in the design of a traffic light.  Red indicates that the story is at risk with a high likelihood that it will not be completed this sprint.  Yellow indicates that the story is somewhat at risk and there is a chance that it will not be completed this sprint.  Green indicates that story is not at risk and is expected to be completed this sprint.  He uses two magnet discs to cover up the extra colors and only displays the current risk state of the story.

This is a great, simple way to make risk transparent to the team so they can make appropriate decisions and adjustments as well as communicate properly to stakeholders.  Placing the information radiators on the scrum board makes it very easy for anyone walking by to know exactly what to expect this sprint.  It also gives indications that help may be needed to remove roadblocks or provide information in order to help the team move forward on that story.

Information radiators are a great way to promote transparency.  How are you using them to help your team grow and to allow others insight into how they are doing?

Advertisements

IMG_0077

Agile values and principles are the core foundation by which Agile organizations operate and make decisions. Everything we do is based in these.  With that being said, viewing every principle through a holistic perspective is absolutely necessary.  Every word in the principles we live by has value and impact.  So, when we reduce a principle to a three word summary, I believe we do ourselves a disservice.  This practice often results in focusing on part of the principle without the balance of the other side.  Through this oversight, we inadvertently create environments where there is unbalance that leaves people frustrated and confused.  They begin to believe that Agile is the problem.  But, the real problem is our failure completely embrace the Agile values and principles and settle for anti-patterns instead.

Today, I’d like to take a deeper look into Agile Principle #8 which states:  Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 

People often refer to this principle as the sustainable pace principle.  The most common description given of how we practice this principle is that the development team should not be expected to do more work than they can complete in a normal business day.  We don’t want people working 70 hours a week because they are forced to do more work than is possible during a normal work week.  Working at that pace is something a team may be able to do for a sprint or two but they cannot work at that pace indefinitely.  When people are tired and overworked they make more mistakes and it actually slows down their ability to produce work.  It also impacts motivation.  When people are overworked and have no work/life balance motivation dwindles.

But there’s another part to this principle that I don’t hear quoted as often.  It’s the part that talks about the constant pace at which the sponsors, developers, and users should be able to maintain.  This is about the consistency of our delivery, sometimes referred to as predictability.  Developers should be able to trust that sponsors and users will allow them to work at a sustainable pace.  In return, sponsors and users should be able to trust that developers will consistently provide a continuous stream of valuable software.  The team has a responsibility to be transparent with the sponsors and users regarding how much work they can complete in a certain timeframe.  They also have a responsibility to be transparent when the forecast must be changed along the way due to new information or unforeseen problems.  This gives the sponsors and users the ability to communicate and make decisions regarding the impact of the forecast change.

How does this impact the way the team conducts planning and communicates their forecast?  Teams should plan for as much as they can realistically complete and communicate that forecast.  Then, they should strive to complete 100% of their forecast every sprint.  If something happens to prevent the completion of the forecast they should communicate as soon as feasible to stakeholders so they know what to expect.

Should teams forecast 125% of what they believe they can realistically complete and be happy if 80% of the work gets finished?  No.  Why?  First, because it sets unrealistic stakeholder expectations to communicate more work than the team can realistically expect to finish.  Second, because it contributes to a lack of trust between the stakeholder and the team when the team keeps promising work they consistently don’t deliver.  Third, because the extra time planning and tasking stories that aren’t likely to be worked creates waste and adds unnecessary time to the planning process.

Then what do we do with “stretch” stories?  It is my belief that “stretch” stories are not a part of the forecast.  Plan and communicate what you believe you can complete.  If the backlog is groomed properly it will always have at 1-2 sprints worth of work in “ready” state.  So, if the team runs out of work they can always agree to pull in another story.  The solutioning and tasking for that story can take place when the decision to pull it in happens.

If the team consistently gets 100% for 3-5 sprints, stretch yourself and bring a few more points into your sprint forecast.  It may take you a couple of sprints to get to 100% again but it will stretch your ability to produce work and push you to incorporate practices like automation in order to move faster.

There should be an understanding that no team will always complete 100% of the work forecasted.  This is another part of the concept of trust and transparency.  Stakeholders and customers trust that developers will always strive to complete 100% of the forecasted work.  Developers trust that when something happens and they can’t deliver 100% and communicate openly to stakeholders and users there will be grace and understanding extended.

 

IMG_3317

Information radiators (IR) are used to help teams see information transparently so they can make fact based decisions about how they want to change.  But how do you know which information radiators to use with a team?  How do you know how many are needed and what to display?

The best way to use information radiators is in response to something you see or something the team is struggling with but needs a way to really understand what’s happening in order to grow.

In the story below a Scrum Master started using this version of a sprint (points) burn up so her team would have a visual representation of how they were actually working together during sprints as a basis for which to develop improvement experiments.

  • Symptom #1 they were consistently not finishing all of the work in the sprint
  • Symptom #2 they were starting a lot of work at one time in the beginning of the sprint but rushing to get work tested and accepted during the last two days of the sprint
  • Symptom #3 they were carrying over stories and said that it was okay because it gave the testers something to do while the developers were heads down during the first 8 days of the sprint – which indicated that they were actually doing mini-waterfalls.
  • Symptom #4 they were adding stories to the sprint after it started before the original work was complete weren’t finishing the new work brought into the sprint

During the first sprint review they analyzed the burn up and noticed that the green bars that represent points accepted did not show up until the last two days of the sprint.

  • They realized that starting a bunch of stories and working on them separately didn’t make them go any faster because it created a bottleneck in testing at the end of the sprint which left some stories unfinished.
  • They decided to pair up or swarm on work in order to open fewer stories at one time and get them tested and finished earlier in the sprint.

During the next sprint they paired on work and focused on finishing rather than starting work.  At the end of the sprint they analyzed the burn up again and noticed improvement, but not enough.

  • They realized that they were less successful completing larger stories because they took longer to develop which caused them to start testing too late in the sprint to finish.
  • They decided to break stories into smaller more manageable pieces of value so they could finished them quicker.

During the next few sprints they noticed that working with smaller stories helped them close stories faster.  By continuing to pair on stories and limit work in progress they found that they were able to more consistently deliver stories every few days during the sprint.

The team noticed that though they had begun to deliver at a more consistent rate they were still having problems finishing all of the work by the end of the sprint.  They analyzed the burn up in their next retrospective to see if they could gain any new insights.

  • They realized that they were actually finishing the number of points they originally forecast during sprint planning.
  • They recognized that during days 4-6 they finished 10 points of work but they also added 10 points.  They also recognized that every time they finished a story they seemed to add another which was contributing to why they had unfinished work at the end of the sprint.
  • They decided to work on breaking down their tasks better so multiple people could swarm on stories.
  • They also decided that instead of a developer bringing a new story into a sprint when there wasn’t development work on any of the stories the developer would cross over and help the testers with a story they hadn’t developed.
  • Lastly they decided that in the last 2 days of the sprint, if there were no stories they could assist on they would focus on some smaller technical debt clean up tasks rather than bringing in new stories they would not have time to finish.

Over the span of a quarter the team was able to effectively make improvements to their delivery and predictability by using this information radiator to help them visually inspect their work habits.  At the end of the quarter the team felt that acceptable improvements had been made and analyzing the burn up during retrospectives was no longer a value add so they abandoned that practice to focus on other improvement areas during retrospectives.

IMG_0069

While attending the Agile Coaching Institute’s Coaching Agile Teams class a while back the instructors read this poem to the class.  It served as a powerful reminder that as an agile coach, or a scrum master/team coach, we must see people and teams as naturally creative, resourceful, and whole if we want to empower them to grow and move forward.  As a coach I must be a servant to those I coach.  I’m not here to be better than them or to have all the answers.  I’m here to serve them in their quest for greatness.

It’s often a first reaction to want to jump in and fix things and fix people.  It’s so easy to have all the answers.  It’s empowering to play the super hero.  But the real power is in allowing people to identify their own solutions.  The real power is in self restraint and waiting for people to grow and change on their own.  The real power is in stepping back so other people’s greatness can shine forth.

This poem serves as a daily reminder that it is impossible to both be a fixer and a servant to others.

A Fixer*

A fixer has the illusion of being casual.

A server knows he or she is being used

in the service of something greater,

essentially unknown.

We fix something specific.

We serve always the something:

wholeness and the mystery of life.

Fixing and helping are the work of ego.

Serving is the work of the soul.

When you help, you see life as weak.

When you fix, you see life as broken.

When you serve, you see life as whole.

Fixing and helping may cure.

Serving Heals.

When I help, I feel satisfaction.

When I serve, I feel gratitude.

Fixing is a form of judgment.

Serving is a form of connection.

*Author Unknown

2015-12-03_13-22-04

(This post is by guest blogger, Kenny Barnes.)

For our latest retrospective, I created a jeopardy board using JeopardyLabs – Online Jeopardy Template.   I used a mix of Agile related categories (Scrum, Agile), items related to the team [Working Agreements, Sprint (more details below)] and something the team is really passionate about (Star Wars).  It took about an hour and a half to come up with the questions/answers and setup the board.

To play the game, the team drew numbers and broke up into two teams.  The teams then took turns picking a category and amount.  If the team picking didn’t know the answer, the other team had an opportunity to answer and take the points.  We ended with a final jeopardy question related to Star Wars that saw one team answer correctly for the win.

Now you might be asking yourself, well this is cool but how did you come up with an action plan or discuss any team issues?  Well the Sprint category took care of this.  The “answers” in this category had both teams, regardless of who selected it, come up with things that worked well, didn’t work well, wins to celebrate, etc.  Each team had two to three minutes to come up with the answer to these questions.  We then had each team give their answers and we discussed them.  The $400 selection was what do you want to try this next sprint.  We had a great discussion and came up with our action plan.

The team really enjoyed playing the game and the change of pace it offered.  They definitely want to do it again next quarter.

IMG_4429

A common belief is that the difference between coaching and managing is simply asking questions rather than giving orders.  I used to believe this.  Instead of making decisions for my teams and telling them what to do I would ask them questions and get them to derive their own solutions.  I thought that meant I was coaching.  But the more I got into coaching the more I really wanted to make sure I was doing it right and being effective.  So, over the past two years I have invested in myself and in my craft.  I have learned everything I can about professional coaching and gotten mentoring by master coaches.

What I learned through the experience is that coaching is ALOT more than just asking questions.  In fact, through this experience I learned that professional coaching skills (and a ton of techniques and coaching models) can mean the difference between being adequate or being excellent for a scrum master, agile coach, or agile manager.

Now, I’m on a mission and a journey to mentor scrum masters in learning coaching skills and show them how to apply them in real world scenarios with agile teams.  As an agile coach I have the unique opportunity to develop scrum masters in a way that I have never seen done before and I’m excited and humbled to get this opportunity to invest in the careers of a great group of people.

IMG_4197

This week I was particularly impressed with a method used by a Scrum Master to help his team understand which stories on the backlog were “ready” and which were not.  It’s amazing how such a simple technique can bring the transparency needed to help a team prepare for a successful sprint.  His technique is to use colored stickers as markers on the ordered product backlog hanging on the wall next to the team’s scrum board to indicate the state of the story.  If the story is not groomed it gets a red sticker.  When the team begins grooming the story and has made pretty good progress but isn’t all the way in line with the definition of ready yet, he changes the sticker to yellow.  Once the team has completed grooming the story and it meets the definition of ready, it gets a green sticker.  This green sticker is an indication to the team that the story is fully groomed and ready to be pulled into a sprint.

Prior to sprint planning, he works with his product owner to ensure that any stories she has ordered towards the top of the backlog that are potential candidates for the next sprint are in ready state.  If a story is not in ready state the team does not pull it into a sprint regardless of where it is on the product backlog.

This scrum master is inspiring those around him with simple yet profound ideas and ways of creating growth in the team and product owner.