Agile, Books

General Agile Reading List

Leave a comment

Colleagues and clients are often asking what agile books they should read or have in their corporate library.  Here’s a list of books I’ve read over the years that I thought would be good to start with.

The following book I believe is foundational for anyone interested in agile:

  • eXtreme Programming eXplained by Kent Beck

Here are some books for those seeking to be ScrumMasters:

  • Agile Project Management with Scrum by Ken Schwaber
  • Agile Estimating and Planning by Mike Cohn

Here are some good books for Managers as well as ScrumMasters:

  • Managing Agile Projects by Sanjiv Augustine
  • Implementing Lean Software Development by Mary and Tom Poppendieck

For people wanting to read more about agile requirements:

  • User Stories Applied by Mike Cohn
  • Agile Software Requirements by Dean Leffingwell (not as much about requirements though, more about Scaled Agile)

For people wanting to read more about testing:

  • Test-Driven Development by Example by Kent Beck
  • Agile Testing by Lisa Crispin and Janet Gregory

For people wanting to read more about retrospectives:

  • Project Retrospectives by Norm Kerth
  • Agile Retrospectives by Esther Derby and Diana Larsen
  • The Retrospective Handbook by Patrick Kua

For people wanting to read more about coaching teams:

  • Coaching Agile Teams by Lyssa Adkins

For Organizational Change Management:

  • Leading Change by John Kotter

Happy reading!!!  And remember, don’t just “Do Agile,” “Be Agile!”

If you have other books that you feel should be added please reply below.

Agile, Estimating

When Should I Re-Point My User Story?

Leave a comment

The intent of Planning Poker and pointing is to prevent analysis paralysis[i] and provide teams with a general, abstract, relative size for backlog items[ii] (i.e., user stories).  This consensus-based activity empowers teams to collectively discuss their estimates and any assumptions that may exist that effect those estimates.  Additionally, Planning Poker helps facilitate sprint planning, team capacity, and enables product owners to make decisions on which backlog items to be built.

As an agile coach I’m often asked “when should we re-point a backlog item that we’ve already pointed?”

My general guidance – don’t repoint any backlog item because it typically adds no additional value.

Are there exceptions to this?  Of course there are, that’s why this is guidance and not a rule.  If there is a significant change to a user story that causes it to become a different user story then I would consider repointing it.

When would this happen?  What constitutes “significantly”?

  • The user story stays the same but the acceptance criteria dramatically changes (it’s important to note that I’m not discussing just a refinement to the acceptance criteria). This change to the acceptance criteria in effect makes backlog items intent completely different.
  • The customer realizes they had the backlog item incorrect, “I wanted user story ‘X’, but that user story was incorrect, I need to re-write the user story”.

Teams often want to re-point because they want to get “credit” for the additional work.  But Planning Poker and pointing was not to establish credit.  So resist the temptation to re-point and ask yourself “is re-pointing a backlog item worth it or should we be spending the time delivering working functioning code?”

Remember, don’t just “Do Agile,” “Be Agile!”

[i] Grenning, James, “Planning Poker or How to avoid analysis paralysis while release planning”, 2002.

[ii] http://www.mountaingoatsoftware.com/topics/planning-poker

Agile, Ceremonies, Templates

Iteration Review

Leave a comment

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Iteration Review.

Pre-Requisites

Product Owner, Team and ScrumMaster shouldn’t spend more than 1 hour prepping for an Iteration Review.  Ideally is should take about 30 minutes for them to agree on what they are presenting and demonstrating.

Duration

½ hour to 2 hours

Purpose

The Purpose of the Iteration Review is for the Product Owner, Team, and ScrumMaster to present the Iteration’s product increment to their stakeholders.  Often this is driven by the Product Owner and he/she drives communication with his/her constituents.  The Team supports the Product Owner by providing a demonstration or presentation of the work that was done.  Typically the Product Owner provides the color commentary as the Team presents the product increment.

It’s very important for the Product Owner, Team and ScrumMaster to have ample time for interaction with their Stakeholders and encourage them to provide feedback.

The ScrumMaster typically helps collect the data for the “Quadrant Page”.

The Quadrant Page consists of four areas:

  1. Iteration Goal,
  2. Named User Stories for the Committed for the Iteration,
  3. Targeted User Stories for the Upcoming Iteration,
  4. Iteration Metrics.

The Iteration Metrics that are typically of interest are:

  • # of Stories Committed,
  • # of Points Committed,
  • # of Stories Delivered,
  • # of Stories Not Delivered,
  • Iteration Velocity,
  • Average Velocity,
  • # of Test Cases Run,
  • # of Defects,
  • # of Defects Fixed,
  • # of Defects Rejected.

Attendees

Participants1

  • Product Owner
  • Team
  • ScrumMaster
  • Stakeholders

Observers2

  • Anyone

Concludes

When the team has finished presenting the product increment and the stakeholders have had their questions answered and/or feedback captured.

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Estimating, Planning

Product Backlog Grooming

1 Comment

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Product Backlog Grooming.

Pre-Requisites

The Product Owner has a prioritized Product Backlog that aligns with their Release Plan and Roadmap.  To help expedite the meeting, the Product Owner should send out a list of stories that he/she wants the team to estimate. The team can then do any necessary research.

Duration

1 hour, 2 to 4 times during an Iteration

Purpose

The purpose of Product Backlog Grooming is for the Product Owner to present new stories to the Team, discuss the stories intent, capture the acceptance criteria and story point the story.  It is a time-boxed meeting where the goal is to estimate as many stories as possible in the allotted time.

If this meeting is conducted regularly, Iteration Planning – Part 1 will be much faster and smoother for everyone.

Attendees

Participants1

  • Product Owner
  • Team
  • ScrumMaster

Observers2

  • Anyone

Concludes

This concludes when the meetings allotted time has expired or all the stories that were prioritized for that session have been estimated (planning poker).

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Templates

Iteration Retrospective

Leave a comment

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Iteration Retrospective.

Pre-Requisites

None (for the “basic” Retrospective)

Duration

1 to 1 ½ hours

Purpose

The purpose of Iteration Retrospective is for the Team, Product Owner and ScrumMaster to reflect on the Iteration and inspect and adapt.  There are a variety of ways to run a Iteration Retrospective, but the “basic” Retrospective poses three questions to the participants:

  1. “What worked well?”
  2. “What did not work well?”
  3. “What should we change, add, or remove?”

Unless otherwise agreed to by the participants, the findings and discussions of an Iteration Retrospective are considered private to the team.  The reason is this is considered a “safe” meeting for the team.  They should feel free to discuss whatever they like without repercussion or concerns.

Often the Iteration Retrospective is under-valued by those new to Agile, but this is a very important activity.  This is the only meeting dedicated to improving the team.

Attendees

Participants1

  • Team
  • ScrumMaster
  • Product Owner (optional, but we feel it’s very beneficial to teaming if they attend)

Observers2

  • None

Concludes

The Iteration Retrospective concludes when the team feels they’ve completed answering the 3 questions and when improvement actions are documented and assigned for the upcoming iteration.

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Stand-Ups, Templates

Daily Stand-Up / Scrum Meeting

Leave a comment

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Daily Stand-Up / Scrum Meeting.

Pre-Requisites

Participants have updated their tasks to reflect new estimates for their work.

Duration

15 Minutes (maximum) + time for the “16th Minute”

Purpose

The purpose of this meeting is for the team to re-synchronize and re-evaluate their progress with each other on a daily basis.  Note: it’s not a status meeting for the ScrumMaster; it is a daily planning meeting for the team, as they are planning their work for the day.

The stand-up is for the team to make sure they still feel they are on-track, synchronize their work with their teammates, re-evaluate work remaining, and identify / raise impediments.

Each participant answers 3 questions:

  1. “What did I get done yesterday?”
  2. “What do I plan on accomplishing today?”
  3. “Do I have any impediments?”

Often because of time zone challenges I suggest changing the questions to:

  1. “What did I get done since the last stand-up?”
  2. “What do I plan on getting done before the next stand-up?”
  3. “Do I have any impediments that I wish to escalate that I require assistance with?”

Attendees

Participants1

  • Team
  • ScrumMaster
  • Product Owner (optional, but we feel it’s very helpful if they regularly attend)

Observers2

  • Anyone

Concludes

When each participant in attendance has provided their update to the team and the team has reviewed the burn-down chart.

The “16th Minute”

After the Stand-Up concludes, we encourage the participants to stay around and work things out as needed.  It’s also an opportunity for Observers to then ask questions of the team.  Team members that are impacted are identified prior to the beginning of the 16th minute.  Others are free to leave.

For scheduling purposes plan on another 15 minutes, but it is typically less than that.

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Planning, Templates

Iteration Planning – Part 2

1 Comment

Although this material may be found in a  variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of Iteration (Sprint) Planning Part 2 for Agile Teams.

Pre-Requisites

Iteration Planning – Part 1 has completed.

Duration

1 to 2 hours

Purpose

On Day 1 of the Iteration the Team takes the stories they’ve discussed with the Product Owner and decide what tasks they need to create to deliver that story and the estimates (in hours) associated with each one of those tasks.

The Product Owner is not required during Part 2 of Iteration Planning.  Often the Product Owner is “on call” if the Team has questions.  Usually as Teams mature, Part 2 of Iteration Planning is not facilitated by the ScrumMaster.  The ScrumMaster charges the team with what they need to accomplish and asks the team when we can get back together with the Product Owner to review.  That may often take 1 to 2 hours depending upon the number of stories pulled into the Iteration.

Note: if the entire team is not present during Iteration Planning – Part 2, it will take longer for the team to commit to their body of work.

Attendees

Participants1

  • Team
  • ScrumMaster (depends on team maturity, in the beginning the ScrumMaster is typically more involved)
  • Product Owner (on demand, as required)

Observers2

  • Not applicable, although anyone could observe, but as teams mature this activity is often done distributed and “heads-down” by the team members.

Concludes

The Team, Product Owner and ScrumMaster will re-convene and review the tasks identified to support the stories.  As a group they will conduct a “sanity check” to confirm that we have the right tasks.  Additionally, they will check to see if they have too much work or not enough work for the iteration.  If so, the Product Owner and the team will adjust accordingly.

After the team plans out the tasks, in ideal hours, the ScrumMaster will assist the team in comparing against their available capacity.

Part 2 of Iteration Planning concludes when the team commits to the work for the Iteration.

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Planning, Templates

Iteration Planning – Part 1

2 Comments

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of Iteration (Sprint) Planning Part 1 for Agile Teams.

Pre-Requisites

The Iteration Goal or Theme has been identified by the Product Owner.   The Product Owner has a prioritized list (based on business value, risk and dependencies) of user stories (stories) that he/she wants the team to deliver by the end of the Iteration.

Note: the less prepared the Product Owner is the longer Iteration Planning – Part 1 will take (see Product Backlog Grooming to determine how to make Iteration Planning more effective).

Duration

1 to 2 hours

Purpose

On Day 1 of the Iteration the Product Owner and Team discuss the prioritized stories.  The Product Owner will present the story to the team, and together they will create and agree on the stories acceptance criteria.

Once the team feels they understand the story, they will then conduct Planning Poker.  Planning Poker is an activity the Team conducts to determine the relative size of a story compared to other stories in their product backlog.  There are a variety of ways to size stories, but the simplest and often most effective way is to size a story based on Extra Small (XS), Small (S), Medium (M), Large (L) and Extra-Large (XL).

The Scrum Master will assist the team by showing them their planned velocity vs. historical velocity, to make sure it is work the team can accept.  This will be further validated at the end of Iteration Planning – Part 2 when the team commits to their work.

Attendees

Participants1

  • Product Owner
  • Team
  • ScrumMaster

Observers2

  • Anyone

Concludes

This meeting concludes when the team feels they have enough work for the Iteration and are ready to task out each story in detail so they can determine the steps required to deliver the story for their Product Owner.  The team then moves on to Iteration Planning – Part 2.

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, SAFe

Planning For Your First Potentially Shippable Increment – Part 2

1 Comment

Written by William F. Nazzaro and Anu M. Smalley

In Planning For Your First Potentially Shippable Increment – Part 1 we recommended that organizations should properly plan for their first PSI.  For simplicity, we will refer to this planning as preparatory activities for your first PSI.

What is the goal or purpose of these preparatory activities?

The goal is to be ready and able to delivery business value in the form of potentially shippable features at the end the release train.

How long should one spend on these preparatory activities?

As a benchmark, we found it useful to have this timebox be the same length as the upcoming Agile Release Train (ART).  If you are planning a 12-week ART, we recommend 12 weeks for the preparatory work.  It may seem like a lot of time, but there is a good deal of work to get ready for your first Potentially Shippable Increment (PSI). [1]  Keep in mind, this is recommendation, not a rule, and the preparatory needs will vary based on your organization’s agile maturity.

Below is a collection of six preparatory activities we refer to as “Form Program & Leadership”.  We recommend that these activities occur 10 to 12 weeks prior to the launch of your first Agile Release Train.

1.      Validate Value Stream

A successful agile transformation or a scaling implementation needs to happen bi-directionally – top down and bottom up.  Validation of the value stream brings together everyone in the value stream to ensure that all teams, leaders, and support services are dedicated and willing to meet the commitment to deliver on the value streams objectives, which is providing business value.  This helps the process of identifying and disseminating the vision of the value stream.

This is ideally done with executives from IT and the business.  This is to ensure that the value stream or the “kidney” is valid and complete.  With an incomplete value stream the rest of the effort to stand up a release train is at severe risk. With the value stream identified and validated we are now ready to form and train the leadership of the Agile Release Train.

2.      Form and Train ART Leadership Team

When considering membership for this team we will look at both the business and IT that make up the value stream.  In larger organizations we will consider senior leaders that are business stakeholders, value stream champion, IT leadership, and those managers making decisions on what personnel will be part of the Agile Release Train team.

The ART Leadership need to understand what the SAFe™ framework is, how its implementation will impact their teams and the commitment to delivering business value.

While it’s recommended that we provide the ART Leadership Team with the 2-Day Leading SAFe class.  We prefer to provide a shorter 1-day version that includes the following topics like Agile Manifesto & Principles, SAFe Big Picture Overview, SAFe Roles & Responsibilities, What to Expect During Your First PSI, and What Changes with Agile and What Doesn’t.

This enables them to know what they are committing to, how a release train works, and what they must do to help assure SAFe is implemented correctly.

This class is only held for the ART Leadership which will often have very different questions from the ART team members.

3.      Identify Program’s Key Players & Teams

Bringing together a 100+ people within a defined value stream together for 2 days to plan for the next 12 weeks is a huge endeavor and requires some level of responsible planning.  We need to ensure the correct people have been identified and are prepared to talk to the business value of the features being discussed as well as managing risks across the train.

Identifying key Agile Release Train (ART) players early on in the process is a critical step to the success of a SAFe QuickStart.  Some of the key players needed early on are:

  • Product Management
  • Architect
  • Release Train Engineer (RTE)
  • Release Management Team
  • Business Owners
  • System Team
  • Dev Ops
  • Scrum Masters

4.      Program Team Kick-Off

From the outset it should be clear what the purpose of the Program Team is, their roles and what’s expected of them and how agile may influence their behaviors.  During this time of “forming” we’ve found it advantageous to have the Program Team also establish a Working Agreement.  This working agreement should outline how they plan on working together to handle prioritizations, coordination, escalations, and impediments.

5.      Review Readiness Checklist

We should have the Release Train Engineer and his/her key people identified above actively work through the PSI Readiness Checklist.  While SAFe’s Readiness Checklist[2]  is a good place to start you may want to adapt this checklist for your organization. Some things to consider are:

  • Are all the teams on the train in place
  • Is training available for these teams on agile concepts as well as any tools and processes that are part of the organization
  • Has a coach been identified and engaged to assist with the teams as well as the groups on the program level
  • Is the tool to be used by the train for their PSI ready and set up
  • Are all support services available and committed to the release train
  • Are the engineering practices to be used understood and in place

This is not an exhaustive or exact list; rather, these are ideas to guide your activities and provide you with an awareness of the amount of preparation required to work to ensure a successful QuickStart.

6.      Establish Program Team Backlog

A common Program Team Backlog contains the stories the Program Team needs to keep the train on the tracks.  It’s important to note that the Program Team Backlog is different from the Program Backlog.  The Program Backlog contains the prioritized features.  The Program Team Backlog contains the stories that:

  • Remove impediments for the agile release train,
  • Establish, maintain and track program-level metrics,
  • Manage critical value stream relationships that are external to business or organization,
  • Represent the communication to and for the agile release train,
  • Drive a continuous improvement culture.

The Program Team Backlog takes time to build and these stories can impact the scrum teams’ abilities once we start the ART.  Having these items identified and potentially being worked on prior to the PSI Quick Start will ensure the train is effectively moving forward on the tracks.

Conclusion

In Part 3 of this article we’ll discuss the “Build Vision and Backlog” preparatory activities we recommend to address 6 to 10 weeks prior to launch.  In Part 4 of this article we’ll discuss the “Conduct QuickStart” preparatory activities we recommend to address 1 to 2 prior to launching your first Agile Release Train.

[1] Note: Not all individuals will be working full-time on the preparatory activities

[2] Agile Software Requirements, by Dean Leffingwell, p 485.

Agile, SAFe

Planning For Your First Potentially Shippable Increment – Part 1

2 Comments

Written by William F. Nazzaro and Anu M. Smalley

In 2013 the Scaled Agile Framework (SAFe) appears to be the de facto standard for those organizations seeking to go beyond team agile and truly bring distributed, scaled agile adoption to their enterprise.  While SAFe has made quite the splash and many companies are seeking to adopt it, we would like to share some of our experiences both pro and con with assisting our clients in implementing SAFe.

One area of SAFe that is incredibly powerful is the concept of a Potentially Shippable Increment (PSI) and the metaphor of an Agile Release Train (ART).

What is a PSI?

PSI provides the Program or Enterprise with a timebox in which iterations are then conducted.  The PSI offers the following: “a routine and continuous planning cycle, an aggregation of iterations value into larger piles of newsworthy value and a quantum unit of thinking, roadmapping, implementing and measuring.” [1]

What is an ART?

“The Framework’s primary scaling mechanism, the Agile Release Train (ART), is to the program what iteration is to the team. It follows the same pattern—plan, commit, execute, demo, and reflect—but at the Program Level (see Figure 1) where it produces system-level working software every two weeks, and full, potentially shippable increments of software every 4-5 iterations.” [2]

Agile_Release_Train
Figure 1 – Agile Release Train

Although the PSI and Agile Release Train are very helpful for teams to focus the delivery of business value to their stakeholders the one concern we have with the current version of SAFe [3] is little to no mention on planning for your first PSI.  While this may be an oversight or intentional (and we acknowledge that SAFe is meant to be a framework and not a prescriptive process), we feel this lack of detail may actually catch those new to SAFe off-guard as they embark on their first Agile Release Train.

Why do I need to plan for my first PSI?

Many organizations new to SAFe are likely to conduct an Agile Release Train Quickstart.  This 5-day immersion program will bring together anywhere from 50 to 100 people into a single location with the sole purpose of identifying PSI 1’s features and objectives.  If the Quickstart is the first time that a company is thinking about teams, governance, value streams and features, it could be quite costly and disappointing for those in attendance.

We therefore recommend planning for your first PSI and allow a Program and Enterprise the time to ask and answer these hard questions prior to bringing all of these people together.

Now that we’ve framed the problem, in our upcoming blog posts, we will discuss and share what should be done prior to launching your first PSI.