Posts Tagged ‘scrum;’

 

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

IMG_4457

This week I was walking past a conference room where a Scrum Master was preparing for the team’s retrospective.  I had to stop and take a picture because I really loved what I saw.  Here are a few of the things that really impressed me:

  1. The team’s improvement plan from the last retrospective is represented. This helps to solidify the value from the last retrospective’s suggested improvements.  By circling back around and discussing the team’s experience with the past action plan it helps the team to measure to see if the changes actually impacted their ability to become higher performing.  This also helps the team intentionally create ways to ensure that they act upon the plan they create because they re-evaluate how they implemented them and if the changes need to be adopted as part of the working agreement or if they were not valuable enough to continue.
  2. It is creative and fun.  You don’t need to be an artist to draw pictures for a retrospective.  In fact, I’ve found that scrum masters who can’t draw well but do it anyway have the most success!  Being willing to really put yourself out there when you know there’s an obvious lack of talent shows the team that you are willing to bring your full self in order to help them grow.  It helps to foster trust and relationship because you aren’t hiding your weaknesses from them.  The lack of drawing skill usually becomes a fun joke for the whole team as they try to identify what your pictures represent.  (In this retro the big joke was, “What in the world is the monkey doing?”  Answer= He’s pulling the elephant’s tail and frustrating him!)
  3. It uses the coaching skill of metaphor. This picture represents the teams experiences through the last sprint.  It helps the team to look at the sprint from multiple perspectives.  The perspective of positive things like things that specifically are helping us to do well and be better and things we want to celebrate.  It also helps the team get real about what’s frustrating them and what is really holding back their growth and progress in areas.  These perspectives take the team deeper than just what went well and what didn’t.

Presenting at agile 2015

Sunday, as I got on a flight and headed to Washington, DC for Agile Alliance’s Agile 2015 conference, I was looking forward to spending a week with other like-minded people who believe in living the agile values and principles and who are investing in themselves and in others to grow in their craft. I anticipate this conference all year because I love the full saturation of agile. I love the networking and new ideas. I love the opportunity to see what others in the industry are up to and to learn from them. And I love meeting new people who teach me great things!

Allison Pollard and I were given the opportunity to present a coaching topic called “Change Your Questions ~ Change Your World” this year. It was exciting to see Allison again and partner with her on this great topic and it was an honor to invest in the agile community at large.

Mornings were filled with “Lean Coffee” which is a facilitation game for having discussions about a range of topics with a group of people who self organize for the purpose of learning and communicating. So many coaches, scrum masters, product owners, managers, software engineers, and quality engineers had such great input and valuable perspectives to share. I had a ton of take-away items from the “Lean Coffee” sessions including ideas about new books to read, ways to manage workflow, how to inspire others, how to develop curiosity, and about interviewing techniques.

One particularly interesting thing I am bringing back from the conference is the use of improv with agile teams. I learned multiple improv activities that help agile teams learn valuable lessons and it completely blew my mind! I’m also bringing back a card game called, “The Product Owner Game” that helps product owners learn to balance cost and business value in order to select the most valuable features and user stories to work on each sprint. I attended a session on user story mapping that provided a great exercise I’m going to be able to walk through with product owners and scrum masters to help them learn this technique and bring it back to their teams for quarterly planning improvement.

There were multiple sessions about coaching in the midst of culture transformation and organizational change. One particularly interesting session provided me with a new tool called an empathy map that I can’t wait to use! Sessions about conflict and toxic environments provided exercises to help people discover their own triggers in order to learn how to deal with them in a healthy manner. I learned how to create an influence map that helps you look at an organization in a way that provides insight to areas where coaching can have the largest impact. I learned a new coaching model and attended a session on executive coaching that was fascinating. I learned from master coaches how to sharpen my professional coaching skills specifically for use in an agile environment and I learned more about how to take a coaching approach to mentoring.

In all this was one of the most successful learning weeks I’ve had all year. The return on investment for this conference was incredible just in the things I’m bringing back to the organization to help others grow. There are many ways companies can invest in its people to help them grow in understanding of agile. In my opinion, Agile Alliance’s Agile 201X conferences gives one of the highest rates of return of any conference I attend.

IMG_3320

This is Mark.  He challenges me.  He confronts me.  He inspires me.  I think he is amazing.  Mark doesn’t do things because someone like me who claims to know a bit about agile says so.  He looks at the world from every perspective. I love this about him because he forces me to think deeper than I’ve ever had to in many areas.  He stretches me as a coach and forces me to keep growing.

Definition of Done was an area where Mark really inspired me to dig deep.  This was his concern …

“I hear and see people teaching Definition of Done like it is a checklist of all the things a team has to do in order for a user story to be done.  I think this undermines ownership of quality code by the team because the checklist becomes a crutch and an excuse to be mediocre.  It causes people to say things like, ‘Well it meets the definition of done,’ when they know that the code still isn’t as good as it could be.  It develops the attitude of, ‘Oh well, it wasn’t on the list so I don’t have to do it.'”

And you know what?  I have witnessed the same behaviors so I had to agree with him – he was right.  Of course, while I agree that this poor behavior is often displayed, it was never the intention the creators of scrum had in mind.  It is definitely not the attitude that agile teams should employ.

After multiple conversations about the intent behind DoD and how it can be used for good and not evil, it was with a bit of hesitation Mark said, “I’ll trust you.”  This beautiful confrontation sent me on a mission to prove that there was a way to help teams create a Definition of Done that promoted a healthy value system and attitude about quality while still serving the purpose of having a clear working agreement about what it means to be done.

I joined with a few teams and we did collaborative sessions where we explored the attitude and value system we want to employ when developing software.  We discussed the practices that we use that supports those values and mindsets. Finally, after we had fleshed all that out we talked about the minimum items we required of ourselves on every piece of code we presented to the Product Owner and asked them to accept the work into their product.  We determined that we would consistently apply the mindset around quality we set forth in our DoD and employ the practices everywhere they were applicable when creating software.

Mark somehow got hold of an unfinished draft of the DoD for one of the teams today and sent me one of the best compliments an agile coach can receive.  He said, “That’s one of the best DoD’s I’ve seen… you could change my mind about them if that’s the idea we push.”

I am a better coach because he didn’t just give in to industry best practices.  The teams developing our code are better because they had to dig deep and determine the value system they wanted to work from.  And the product will be better because the quality standards are being considered in grooming, planning, and development.  Teams are growing and code is getting better and it’s all because one person stood up and was willing to take a stand for his beliefs.  Great job, Mark!

Just in case you’re interested…here’s a bit of the DoD two teams who share one code base came up with:

In our quest to deliver quality software…

We will strive to understand our customers and partner with them to build the right solution that they perceive as valuable to meet their needs.  Some of the practices we will use to ensure value are:

  • Creating frequent feedback loops with stakeholders and customers
  • Delivering incremental value and iterating on feedback received to increase value delivery over time
  • Building in ways to measure trailing indicators of actual value delivery

 

We will create software that is performant and measurable.  Some of the practices we will use to ensure performance are:

  • Performance Testing
  • Performance Monitoring by gathering metrics before and after introducing new code into production
  • Creating and Adhering to SLAs
  • Building in the ability to measure performance over time

 

We will create software that is stable.  Some of the practices we will use to ensure stability are:

  • Refactoring
  • Monitoring
  • Using Heuristics to build relevant tests
  • Health checks for less watched systems
  • Never making changes to code or configurations in production

 

We will create software that is maintainable.  Some of the practices we will use to ensure maintainability are:

  • Completing code reviews that include feedback
  • Reducing the introduction of technical debt
  • Making refactoring and architecture a priority and helping the business to understand the value it adds to the product

 

We will create software that is free from critical defects.  Some of the practices we will use to reduce the introduction of escape defects are:

  • Creating automated tests for major or critical features and core functionality
  • Creating test plans that are repeatable by anyone
  • Developer testing in the development/feature branch

 

We will create software that is self incriminating.  Some of the practices we will use to ensure our software is self-incriminating are:

  • Automated testing when appropriate
  • Features have automated tests written prior to acceptance
  • Monitoring
  • Logging

 

We will create software that is extensible, scalable, and flexible.  Some of the practices we will use to ensure extensibility, scalability, and flexibility are:

  • Creating software that is readable through depending on clearly written code rather than comments
  • Creating software that is repeatable
  • Creating software that is reusable
  • Automating whenever possible
  • Developing consistency in our coding and architectural practices and standards
  • Developing consistency in our deployment, testing, standards
  • By reducing the dependence on tribal knowledge when it makes sense to do so.
  • Automating deployments to production

 

We commit to employ these practices as the way we create quality software and employ this value system in every piece of code we develop.  At a minimum, we will ensure that the following practices are adhered to prior to considering work Done and presenting it to the Product Owner and asking them to accept it into their product.

  • [List of specific minimum requirements that span all types of user stories]

 

Further, after the Product Owner accepts our work into their product we will ensure that the following practices are adhered to before we will consider a user story Done Done.

  • [List of specific minimum requirements that are needed to move/validate code in prod]

Over the past several weeks I have encountered multiple people from completely different companies that are implementing scrum.  Some have been trying this for a few weeks.  Some have been doing it for a couple of years.  Others are somewhere in between.  Some received formal training.  Some read books.  Others supplemented with You Tube videos.

Everyone I spoke to had a different reason for meeting with me, an agile coach.  Some were people I was interviewing for clients to hire onto their full time staff.  Some were clients and potential clients.  Others were people in the agile community that asked for mentoring.

They all had something in common – doing it alone.  In each case, they got information about scrum and tried to implement change.  In each case they are struggling.  Half of the struggles they are facing are around simply understanding how to implement the scrum framework properly.  This stems from brain overload and trying to cram too much understanding into their minds from a two day class or a book and attempting to remember it with no context to their real world.  Then, trying to implement the things they learned in their own environment while not forgetting anything.  Yeah, right.

The other half of the struggle they are facing is a much larger issue.  This issue can’t be solved as easily in books, videos, and a two-day class.  This is an issue of a shift in mindset.  In each case, these people were trying to change a set of behaviors but they didn’t really grasp the mindset change that needed to happen in order for the behaviors to make sense.  The behaviors alone won’t bring agility to an organization, or to a team, or to an individual.  Agility is a way of thinking, a way of believing, a way of life.

This is why we say that learning scrum is easy but implementing it is so hard.  I can teach you the basic scrum framework in a couple of hours.  I extend it to a two-day course so I can teach you about the agile values and principles and try to let you experience how to practice the scrum framework.  But, organizations that want to be really successful invest in more than just a two-day training class.  The two-day training class just sets the groundwork. Organizations that want to be successful invest in coaching.

Having a coach on site to work with teams and with managers to help them on a day-to-day basis while they get started is an investment that far outweighs the price tag.  A coach helps teams to understand how to implement concepts the two-day class and books only talk about theoretically.  The coach helps the team sort through misunderstandings and watches for bad decisions that will lead them to bad behaviors.

A coach teaches teams how to think in new ways, challenges them to make decisions they would have never made before, to do things differently, to self organize, to build high performing teams, to live the scrum values, to properly live the agile values and principles, to identify when they or others are acting in anti-patterns and how to respond to break those anti-patterns.

A coach works with management and human resources to change the culture of the organization so that job descriptions reflect the new culture, the correct employees get hired, and the proper decisions are being made that lead the entire company towards and not further from agility.

A coach helps the company see where to spend less money in the right places and make the right investments that will save them money in the long run by creating a better return on investment and reducing technical debt. When something comes easy to you it is sometimes hard to understand when others struggle.

I’ve been coaching for about five years now and I love when people start getting this stuff.  But, I’m having a pretty rough week.  I realize now more than ever how hard this is.  It makes me so sad to see people struggling when they don’t have a way to get help.  I’m just one person.  Even if I could do this for free there’s not enough of me to go around.

Well, I can’t change the world – that I know.  But this week it all came to a head for me and I developed a personal mission statement to keep me focused because even though I can’t change the world I can change the people in the world.  I can do my part. This is what it’s all about for me – My Mission:  To leave you better than I found you with each encounter.