Uncategorized

Retrospectives – Back to Basics

Alec Hardy Communication, Leadership, Uncategorized

Retrospective

For a new Scrum Master, the mechanics of getting started with retrospectives are deceptively easy. Somebody tells them to write three columns on the whiteboard (What Went Well, What Did Not, Ideas) and to facilitate the discussion. The Scrum Master makes sure that management is not invited to the meeting. He/she Identifies the team members who are not participating and try to get them talking. Simple. The retrospective becomes a blend of problems mixed with solutions and “action items” for the next sprint. If the team is lucky, it identifies the most valuable areas for improvement. Unfortunately for many teams, they go through the motions but do not get to the heart of their biggest problems/opportunities. It becomes a stale ritual and the team plateaus.

Surprisingly, many Scrum Masters fall short on the basics of how to conduct a retrospective. They think that all it takes is writing the three columns on the board. Properly done, it actually starts as soon as sprint planning is done.

In their book “Agile Retrospectives – Making Good Teams Great”, Esther Derby and Diana Larsen suggest the following structure for a retrospective:

  1. Set the stage – get the team in the right mindset for a retrospective
  2. Gather data – identify the key things that happened during the sprint
  3. Generate insights – about those things and why they happened
  4. Decide what to do – new practices to improve
  5. Close the retrospective – take a minute to step back and reflect on the sprint, the team’s accomplishments, and the retrospective itself

Lots of different techniques exist for each of the stages of a retrospective. The art is in the Scrum Master recognizing which one fits the team at that particular moment in time.

To set the stage for the retrospective, the Scrum Master may remind the team that the retrospective is a safe environment. They could also do a check in where they go around the room and ask each person “How are you doing today?” to engage the team. Another technique is to ask people “if the team were a car, what kind/make/model of car were we in this sprint?” and record each person’s answer on the board. This can provide an interesting reference point to revisit if someone says the team was a Pinto but during the remainder of the retrospective does not point out any problems that occurred during the sprint.

In gathering data about the sprint, the Scrum Master and team consider:

  • The sprint goal
  • The sprint backlog and the results (done, not finished, etc) for each story.
  • Impediments or challenges that occurred during the sprint. Laying them out on a calendar can help illustrate how they affected the sprint and generate conversation for how to handle them in the future (the Scrum Master may get in the habit of noting these as they happen).
  • Is the team going through a storming phase? Asking team members to track how they were feeling about the sprint during specific stages of the sprint can help surface opportunities for working agreements, practices the team should adopt, etc.
  • After trying to remember what happened over the last week or two (they know better than to do three or four week-long sprints) the team and Scrum Master may start to note some events as they happen to make data gathering easier in the retrospective.

To generate insights, the team can approach the discussion a number of different ways:

  • Was every story closed? If not, what state was each one in at the end of the sprint? Ask why. Then ask why again.
  • Did the team stretch yet still meet the sprint goal? Reflecting on what the team did well could reinforce those practices and also set the stage for a discussion about how to take it to the next level.
  • Is there a lot of discussion about whether the team should adopt certain practices? The insights could be focused on things the team to start doing, stop doing, and continue doing.

Teams are usually pretty good at coming up with ideas for how to do things differently. Trying to do all of them at once or forgetting about them in the throes of the next sprint are common pitfalls.  A good Scrum Master will gather these ideas as the team identifies them during the retrospective. A great Scrum Master will sense when the team has not really gotten to the heart of an issue or opportunity and prod them to drill down to the heart of the matter.

Once the team has identified ideas or new practices to try in the next sprint, posting them near the Scrum board is an easy way to quickly remind the team about them when the team is gathered around the board during the daily standup. The remaining ideas go into the Insight Backlog. This backlog can be evaluated along with new ideas that come out of each retrospective to decide which ones to try next.

Some formats for gathering data and generating insights include:

  • (Old reliable) What Went Well, What Did Not, Improvements. Team members write ideas on sticky notes and put them in the respective columns. Dot voting for which ideas to adopt.
  • Reviewing results for each story, conducting 5 whys for each one.
  • Start Doing, Stop Doing, More Of. Again, sticky notes placed by team members can help with participation.
  • Sailboat. What things are the wind in the team’s sails, propelling it? What are the anchors that are slowing it down? Another variation is Motorboat, where the team identifies the anchors that are slowing down the boat (team) and they can even place them a different ‘depths’ to indicate their severity.

Reflections

  • There are many ways to conduct a retrospective. The Scrum Master’s job is to find the right way to help the team improve at that particular moment in time.
  • Overcomplicating the format of the retrospective can get in the way of improvement.
  • Letting the format of the retrospective get stale can result in team members who have shut down from boredom before they even enter the room.
  • The Product Owner should be there. They are a member of the team after all.
  • In closing the retrospective, take time for Appreciations. Good people aren’t just working for a paycheck.

Product Ownership – How Can I Best Serve the Team Today?

Alec Hardy Uncategorized

POServeTeam

As a Product Owner, I start each day by asking myself, “How can I best serve the team today?” The PO and Scrum Master’s roles as servant leaders is not news. The challenge for the PO is translating this mindset into actions. It is all about mastering the cadence of product ownership.

Assuming that a backlog is in place and the team is working on the user stories, the Product Owner’s typical activities are something like:

  1. Attend daily standups. Every day.
  2. Help the Scrum Master resolve certain blocking issues for the current sprint.
  3. Meet with team members to answer questions about stories in the current sprint.
  4. Prepare for the next backlog grooming meeting. Revisit backlog prioritization, identify which stories will be groomed, add Acceptance Tests/Criteria or other information to the stories.  Consult with end users or business stakeholders where appropriate.
  5. Facilitate backlog grooming meetings with the team.
  6. Receive demos of or perform testing for stories as they are completed as part of the sprint. This is typically part of the team’s Definition of Done.
  7. Meet with clients/stakeholders/users to discuss and define future product plans.
  8. Participate in the team retrospective.
  9. Facilitate the sprint demo.
  10. Prepare for the next sprint planning meeting by revisiting backlog priorities and assessing progress against the Release Plan.
  11. Attend sprint planning.

This is a long list of responsibilities. Note the choice of words. They are not just tasks or meetings – they are key responsibilities that must be fulfilled in order for the team to function properly.

Organizational skills are key here.  As a product owner, I use a couple of different things to manage the volume and complexity of this role:

  1. A calendar for scheduling meetings and recurring events. Of course this includes daily meetings, weekly backlog grooming meetings and other ceremonies. I also schedule time to sit down by myself to prep for the next grooming meeting or to prep for the next sprint planning meeting. In doing so I am much more likely to actually do these rather than to forget about them or push them aside when a lot of other things pop up.
  2. A personal Kanban board (I use Trello) to keep up with requests that are made of me.  This could include questions from stakeholders/users/clients, information requests from developers, research items, or any other tasks that I need to take care of. I find that a Kanban board helps with prioritization. It also helps with tracking items that are in progress, such as when I need to request information from users to make a priority or feature decision for the developers. Some of these activities cannot be done in one setting so tracking them on the Kanban board helps prevent them from falling through the cracks. Limiting personal work in progress can help avoid task saturation and the mistakes that ensue.

Reflections

  • The Product Owner must understand and develop a cadence for fulfilling their responsibilities. Operating in a haphazard manner hurts them and the team.
  • Managing personal work in progress helps reduce mistakes and the number of things that fall through the cracks.
  • No personal organization system is perfect, so I also make it very clear to the Scrum Master and the team to call me out whenever I have fallen short on fulfilling my responsibilities. I am there to serve them, after all.

The ScrumMaster as Servant Leader

Alec Hardy Leadership, Scrum Master, Uncategorized ,

eadership in a modern organization is a paradox whereby leaders provide a vision of what the organization should strive to achieve but then serve those in the organization in order to realize that vision.  This is embodied in the management philosophy of servant leadership.

As defined by the Alliance for Servant Leadership, the principles of servant leadership are:

  • Transformation as a vehicle for personal and institutional growth.
  • Personal growth and its importance to the individual and the institution.
  • Enabling environments that encourage individuals to share ideas and express opinions.
  • Service as a fundamental reason that people want to lead.
  • Trusting relationships based on mutual respect, trust, civility, acceptance, and reciprocity.
  • Creating commitment rather than imposing controls in order to accomplish valued missions.
  • Community building where individuals work effective together, as teams.
  • Nurturing the spirit as a way to provide joy and fulfillment in meaningful work.

These principles fit squarely with an agile organization’s values of teamwork, collaboration, trust, continuous improvement, extraordinary service, and empowerment.

Exceptional leaders are confident enough to and capable of following a servant leader approach; those who are less skilled are autocratic. A Scrum Master can practice servant leadership by:

  • Seldom, if ever, telling anyone on the team what to do. Becoming a Scrum Master involves learning the various mechanisms and ceremonies associated with Scrum.  The most profound aspect of leading a Scrum team, however, is not in learning a methodology. Rather it is about asking very deep, probing questions and helping the team find its way to a solution rather than giving them the solution.  The benefits and impact of this are significant both in terms of the outcomes but also in the satisfaction and commitment that this builds in team members. It is one thing to say that team members are empowered; it is quite another to actually empower them.
  • Not assigning tasks to team members. For an organization transitioning to agile, other authority figures may misinterpret this as a lack of leadership by the Scrum Master.  If those authority figures attempt to direct the team, the Scrum Master should educate them regarding what it means for a team to be self-organizing.
  • Reminding the team about the product vision and sprint goals. Note that it is also key for the Product Owner for articulate product vision throughout an effort.
  • Removing roadblocks that stand in the team’s way.
  • One of the characteristics of an effective Scrum team is that most of its members have a general enough skill set to perform a variety of tasks and do whatever it takes to “move the ball down the field” as a unit. This requires that people who used to be very focused and very good at a specific type of work or technology develop and grow a broader skill set.  A manager serves their team by helping to steer them towards personal growth opportunities.  He/she enables this personal growth by encouraging team members to seek training for new skills and to take on assignments that are outside of their comfort zone.

Got an Impediment? Great!

Alec Hardy Impediments, Uncategorized

StopPart of a ScrumMaster’s job is to remove any impediments that are preventing the team from making progress towards the sprint goal. Often, the biggest challenge is not removing the impediment – it is actually getting people to identify the impediment in the first place.
 
Perception

Sometimes it’s a matter of perception.  Some people are reluctant to raise “blocking issues” because they are afraid that it is an indictment of the people that may be causing the issue.  Solution: call them “Impediments.”  Sometimes a simple euphemism changes the perception.

Visibility

Often someone on the team knows about an impediment and mentions it to their team mates and/or brings it up during daily Scrum but it gets lost in the shuffle. Maintaining a highly visible impediments list on a board in the team’s work area servers a dual purpose:

  1. Helps to keep the focus on removing known impediments
  2. Indirectly discourages individuals from becoming impediments

Encouragement

A typical management response to impediments is concern and root causes analysis (“How could this possibly happen? We need to make sure this never happens again!”). The Scrum Master’s response when a team member raises an impediment should be to say, “Great!  Thanks for sharing.  Now that we all know about it, we can address it.” A team that is comfortable discussing impediments is far ahead of one whose first instinct is to sweep them under the rug or to switch into CYA mode and run for cover.

Reflections:

  • Build a team culture that views impediments as a natural part of any challenging project.
  • Ensure that impediments are visible to everyone.
  • The retrospective is a great place to discuss impediments and how to avoid them in the future.

Becoming PMI-ACP Certified

Alec Hardy Agile Certifications, Uncategorized ,

PMIACPThe Project Management Institute’s Agile Certified Practitioner (PMI-ACP) credential is intended to certify that someone has agile experience as well as knowledge of agile approaches. As a Certified Scrum Master, Certified Scrum Product Owner, and Project Management Professional, the PMI-ACP was a logical next step for me. My goal in attaining the PMI-ACP was similar to the PMP and numerous technical certifications – use the certification process as a way to gain breadth and depth of knowledge. I was not looking just to pass the test.  When I started preparing for the test, I had been a Scrum Master for awhile but I recognized that I had a lot to learn beyond the mechanisms of Scrum. My exam prep process was broken into three stages:

First Stage: Foundation

My initial agile exposure was via Certified Scrum Master and Certified Product training and lots of practical experience as a Scrum Master for a large team. Having some “scars” from a transformation to agile makes subsequent readings much more poignant.

Second Stage: Broadening and Deepening

Other BooksThis is where someone can move beyond the mechanisms of an agile approach and begin to understand the art (“being agile” versus merely “doing agile”). The PMI’s Reference Materials reading list for exam preparation is like a “greatest hits” of agile writings.  At a minimum I recommend Mike Cohn’s User Stories Applied and Agile Estimating and Planning books, Lyssa Adkins’ Coaching Agile Teams, and Derby and Larsen’s Agile Retrospectives.  Jim Highsmith’s Agile Project Management: Creating Innovative Products also contains some unique insights. Beyond a certain point the other publications on the list contain redundant information and retaining the information becomes a challenge. The key to this stage is to approach the readings with the goal being to learn the techniques and nuances of agile. After all, the goal is to become a great agile practitioner and not just someone who memorized enough material to pass a test. Oh, and by the way, memorization alone will not allow you to pass this test.

Third Stage: Honing and Exam Prep

At this point you have agile experience and have been applying some of the techniques in the books mentioned above. Because it takes a little while to get through the books, your recollection of some of the material may be getting a little fuzzy, and this is where exam prep materials will help focus you for the test.

A few of the resources that helped me with this stage included:

PMI ACP Exam PrepMike Griffiths’ PMI-ACP Exam Prep book. This book does a great job of covering Scrum, Kanban, XP, and other lesser-known agile approaches. Value-driven delivery, working with agile teams, and adaptive planning are covered extensively. Continuous improvement is also covered, and as testimony to the breadth of this book, it goes beyond merely discussing retrospectives and covers topics such as Knowledge Sharing, Process Tailoring, Principles of Systems Thinking, and others. The book contains diagrams throughout to help illustrate the topics being covered. Exercices and quizzes and the end of each chapter help to reinforce topics.

The PMI ACP ExamThe PMI-ACP Exam – How to Pass on Your First Try by Andy Crowe was also useful.  This book was a little more difficult to digest than Griffith’s book as it does not provide many illustrations and exercises for the concepts that are covered. Also, it does not provide the same depth of coverage.  For example, Griffith’s books contains 50 pages of material covering value-driven delivery topics.  Crowe covers that in just a few pages. What does make Crowe’s book valuable is that it covers some of the subtleties of agile.  Remember when I mentioned that memorization alone won’t help you pass?  This book provides a perspective that will help with some of the questions on the test that require you to exercise judgment rather than regurgitate facts. Again, it is hard to retain all of the information in a book like this in the course of reading it, but the sample exams and the end of the book relate right back into readings from PMI’s Reference Materials. If you are trying to really learn and not just pass the test, this can be very effective.

DVDExam simulation software such as RMC Project Management’s PM FASTrack PMI-ACP Exam Simulation Software or AgileExams.com. The old days where the questions on an exam simulator would almost exactly match the real test are long gone, and this software is best used as a way of identifying other areas where additional learnings are needed.  Going through the test-taking process with a simulator can also be helpful to becoming comfortable answering questions on a screen with a timer counting down.

My philosophy has always been to use an exam as a framework for learning rather than just having a goal of passing a test. Everyone’s approach to preparing for an exam is different, and I hope this information helps.  Good luck!

Alec Hardy, PMP, PMI-ACP

A Swarming State of Mind

Alec Hardy Uncategorized

Planning
In a previous blog post, I discussed how sprint planning can help put the team in position to effectively swarm on tasks.  If building software is like playing golf, sprint planning is akin to assessing playing conditions, determining yardage, selecting a club, and setting up to hit the ball.  While the golfer has a few minutes to do all of these things, the act of actually swinging the club and hitting the ball allows little time for conscious thought or strategic decision-making. The player often acts based on habit and what feels right.

Execution

The same is true for task execution during a sprint. With the challenge and pressure of the sprint timebox, team members who are new to agile often revert to pre-agile habits. Signs include:

– Team members or (gasp) the ScrumMaster pre-assigning tasks to specific team members at the beginning of the sprint

– Team members only working on tasks that fit squarely within their skillset

– Each developer taking a user story to work on by themselves

Pre-assigning tasks:

No ScrumMaster worth their salt would assign tasks to team members as it is would be a violation of them principle of team self-organization.  Oh – not to mention totally disempowering the team as well.  Team members, on the other hand, may be tempted to pre-assign tasks. Having completed a sprint plan, they may proceed to divide up the sprint work and then head off in their separate directions to take care of their assignments.  This creates a couple of problems.

  • Having too many user stories in progress (think WIP) at the same time. This creates bandwidth issues for the customer, who is charged with participating in conversations about each story, writing acceptance tests for each story, and testing each story. Worst case, it can put the team in the position of having 80% of 100% of the stories done at the end of the sprint, which delivers zero value to the customer.
  • Promoting individual team member ownership of user stories rather than whole-team ownership.  This ownership can possibly impact others’ commitment to jump in to help out on the story, but more importantly it makes it harder for others to get up to speed to understand the story and the technical implementation if they were not involved in the conversations with the customers or any of the coding.

A pattern that minimizes work in process and maximizes team ownership is to not pre-assign tasks.  As team members finish a task, they look for the next available task to work on, even if it is for a story that someone else has started.

Working on tasks only within skillset:

We all know by now that Scrum prescribes three roles: Product Owner, Scrum Master, and Team Member. Putting aside discussions about whether the Product Owner or Scrum Master is a member of the team, the key point is that there is one Team Member role.  There are not separate roles for Web Developer, Data Base Developer, Data Architect, DBA, QA, etc. Properly constituted agile teams consist of specialized generalists with t-shaped skills. But skills are only part of the equation.  Desire for team success is paramount.  This means that a DBA is willing to help with QA testing in order to help meet the sprint commitment.

Developers who prefer to work on stories by themselves:

Sometimes Scrum Masters or functional managers have to make a hard assessment of whether team members prefer to work mostly by themselves. Not to be confused with introverts, some people gravitate toward coding because it allows them to delve deeply into the intellectual challenge of piecing together great code.  Before agile, so many buffers existed between developers and customers that loners could be valuable contributors to project teams as long as the team lead or systems analyst could be relay information to/from the customer and those developers.  These same types of developers struggle in the highly-collaborative world of agile teams.

Reflections:

  • Resist the temptation to pre-assign tasks at the start of a sprint. Strive to minimize WIP and maximize whole-team ownership of stories.
  • A culture that values team success rather than individual achievement is key.
  • Not all individuals are a good fit for agile teams.