Demonstrations/Reviews in an Agile Environment


I’m going through the Agile Practice Guide on a systematic basis to review all of its contents.   Chapter 5 covers the implementation of a project in an agile environment.

Section 5.2 of this chapter covers the eight most common agile project practices, which are:

5.2.1 Retrospectives

5.2.2 Backlog preparation

5.2.3 Backlog refinement

5.2.4 Daily Standups

5.2.5 Demonstrations/Reviews

5.2.6 Planning for Iteration-Based Agile

5.2.7 Execution Practices that Help Teams Deliver Value

5.2.8 Iterations and Increments Help Deliver Working Product

I covered the first four items.s on the list in the last few posts.   The previous item I covered was Daily Standups.  The next item I will discuss in this post is demonstrations or reviews.

Once a team completes a feature, the team needs to demonstrate the working product.   In a traditional project management environment, this is called “verifying the scope” internally before the scope is validated by the customer.

The customer will then give feedback and the team will implement any changes suggested.

As a general rule, the team should demonstrate a working product at least once every two weeks.  A team that does not demonstrate a product with that frequency needs coaching to enable frequent delivery.

The next post will cover the next item, planning.

 

Advertisements

Stand-Ups in an Agile Environment


I’m going through the Agile Practice Guide on a systematic basis to review all of its contents.   Chapter 5 covers the implementation of a project in an agile environment.

Section 5.2 of this chapter covers the eight most common agile project practices, which are:

5.2.1 Retrospectives

5.2.2 Backlog preparation

5.2.3 Backlog refinement

5.2.4 Daily Standups

5.2.5 Demonstrations/Reviews

5.2.6 Planning for Iteration-Based Agile

5.2.7 Execution Practices that Help Teams Deliver Value

5.2.8 Iterations and Increments Help Deliver Working Product

I covered the first three items on the list in the last few posts.   The previous item was about the backlog refinement process.   Now I’ll start on the fourth item, which is daily standups.

The purpose of standup meetings is to:

  • make commitments to others on the team
  • uncover problems
  • ensure the work flows smoothly through the team.

The standup should take no longer than 15 minutes, according to the Guide.

The questions that everybody on the team should answer in a round-robin fashion are the following:

  • What did I complete since the last standup?
  • What am I planning to complete between now and the next standup?
  • What are my impediments (or risk or problems).

These questions make people accountable to each other for work they committed to doing in the previous day’s standup.   If the work was not completed, the focus in not on the blame, but the barrier which caused the work not to be completed.

It may be helpful to understand what a standup is by listing some things that it is not.

  • It is not a status meeting–that would only cover the first question listed above.  It is asking the second question above (“what am I planning to complete?”), which covers the purpose of “make commitments to others on the team.”   It is asking the third questions above (“what are my impediments?”), which covers the purpose of “uncover problems.”
  • It is not a problem-solving meeting.   The problems are uncovered during the standup, but individual problem-solving sessions can occur after the standup.

The standup, in short, is a way of fostering intense collaboration among members of the team, and that is one of the reasons why it is one of the eight most common agile practices introduced in Chapter 5 of the Agile Practice Guide.

The next post will cover the fifth item, demonstrations or reviews.

 

Backlog Refinement in an Agile Environment


I’m going through the Agile Practice Guide on a systematic basis to review all of its contents.   Chapter 5 covers the implementation of a project in an agile environment.

Section 5.2 of this chapter covers the eight most common agile project practices, which are:

5.2.1 Retrospectives

5.2.2 Backlog preparation

5.2.3 Backlog refinement

5.2.4 Daily Standups

5.2.5 Demonstrations/Reviews

5.2.6 Planning for Iteration-Based Agile

5.2.7 Execution Practices that Help Teams Deliver Value

5.2.8 Iterations and Increments Help Deliver Working Product

I covered the first two items on the list, retrospectives, in the last few posts.   The previous item was the preparation of the backlog, done by the product owner.   Now I’ll start on the third item, which is backlog refinement.    This is where the product owner takes the backlog he or she created and takes it to the team for … well, refinement.

What does “refinement” mean in this case?

  1. The team has to understand what the stories mean, so that if the description by the product owner was not sufficient, the team can ask the product owner questions to make sure the meaning is clear.   If the team finds that there are potential challenges or problems in the stories, then the product owner can request the team to spike the feature in order to further explore the risks involved before committing to it.
  2. The team has to understand how large the stories are in relationship to each other.  This is key to planning in an agile environment (this is an item to be discussed in a later post).

What should the format of the refinement meeting be?   There are several ways of going about it:

  • Just-in-time refinement (for flow-based agile).   The team takes the next card off the “to-do” column and discusses it.
  • Iteration-based refinement, done for one hour midway through an iteration.
  • Multiple refinement discussions for teams that are new to the product area.

In any case, the Guide recommends that the refinement meeting not be more than one hour per week.   If the team is spending more time than this, it could be that the team may be lacking the critical skills needed to evaluate and refine the work.

One interesting possibility that the Agile Practice Guide mentions is the combination of the backlog preparation and backlog refinement.   This is where the team participates in the preparation of the backlog, and not just its refinement.

Here again, the Guide suggests several ways of going about this combined process:

  • The product owner presents the overall story concept to the team, and have the team discuss it and refine it, splitting it into several stories if needed.
  • The team splits into three groups taking the roles of a developer, tester, and business analyst/product owner to collaborate in writing the story.   With input from all three groups, the story should end up being understood by all of the team.
  • The team works on producing stories on a daily basis that are small enough so that they can be completed in a single day.   This will ensure that the team can complete a steady flow of completed work.

Whether the product owner does the backlog on his or her own, and THEN presents it to the team for refinement, or works with the team to create and refine the backlog, the end point is the same.   The team should understand the stories well enough to estimate their size, prioritize them, and then get to work!

 

Using Retrospectives for Personal Time Management


After completing two posts on the use of retrospective meetings in an agile environment, I had to relate some thoughts I’ve been having about why the planning system I’ve been using has worked so well for me.

I started using the Full-Focus Planner system by Michael Hyatt back in 2018, and renewed my subscription to receive more planners in 2019.   I’ve been thinking about why I made that decision.   Of course I chose it because it works, but why does it work so well?

Well, that came to me while I was doing the previous posts:   most planners have pages for each day of the week, but the Full-Focus Planner has a few extra pages which it calls the Week in Review.   The things you would expect to see in an agile retrospective–what worked and what didn’t work–are here as well.    Plus a section on action items you can take in order to improve things.

I think this weekly review is part of the reason why it has been such a successful tool for me.   If you see that something is not done that needs to be done, you can schedule it again with a higher priority.   If it still doesn’t get done, then you know that there is some procrastination issue going on.   If that’s the case, you can do things like:

  • get help from someone else
  • break a large task into smaller ones
  • use the Pomodoro method of doing only 30-minutes of work at a time on the task, where you actively work for 25 minutes and then give yourself a reward of 5 minutes spent on some pleasant activity.

But it is also a reflection on what has been done and particularly what has been done well, so you can use it give yourself a confidence boost.   But, like in agile, it is the regularity of the review that is important.   And, the attitude is also important:  just like in an agile retrospective, it is not the time to look at yourself and heap blame upon yourself for not accomplishing this or that task.   The focus should be:  what’s done is done.  Now what?

One way to get your personal retrospectives like the ones in agile is to get yourself an actual kanban whiteboard to plan and track tasks, or to use one of the many kanban apps for personal use that are coming online.   Doing something visually in conjunction with your hands ignites a lot more mental pathways in your brain than just scanning a list visually.

Now let’s move on to the next activity that is considered key in agile projects:  that of creating and then prioritizing a backlog list, the equivalent of a work breakdown structure in traditional project management.  That will be the subject of the next post.

Retrospectives in an Agile Environment (2)


In the last post, I discussed how the retrospective in an agile environment has effected the “lessons learned” process in a traditional project management environment.

In this post, taken from section 5.2.1 of the Agile Practice Guide, I will discuss the characteristics of the retrospective in agile.

It’s interesting that of the 8 practices that the Agile Practice Guide discusses in section 5.2, they say the single most important practice is the retrospective.   Why?  Because it allows the project to adapt its process in the face of changing circumstances.   This is why I have heard it said that traditional project management copes with change, whereas agile project management uses change to transform the process.   And part of that transformation process is the retrospective.

Many teams uses 2 or 4-week iterations for the “sprint”, or timeboxed iteration, of the project.   The Guide says that the 2-week iteration is the most popular of these two setups.

The team CAN do a retrospective at other times if some sort of significant milestone has been reached, such as the completion of a release or ships a significant portion of the product.   It can also be done if there is some problem which causing the team to be stuck and completed work is not flowing through the team.   The retrospective is then used to gather data and process that data in order to decide what to try as an experiment to get the team un-stuck.

Here are some important points to remember about the retrospective.

  1. It is NOT about blame, instead of focusing on WHO, it is focusing on WHAT was done since the last retrospective and finding out what worked and what didn’t, and also where the impediments were.
  2. Eventually the analysis of the data about the completed work should lead to root causes, the designing of countermeasures, and developing action plans to remove any impediments discovered.
  3. There should be a limit of the number of action items to the team’s capacity to address improvement.
  4. With each action item, decide how to measure the outcome to know precisely when it is done.
  5. After listing the potential action items, the facilitator should lead the team to ranking them; the highest ranked items up to the limit set in step 3 are the ones that will be focused on.   IF these are all completed before the next iteration, then you can go to the next ones on the list.

The important thing to realize is that the standup meetings are for recognizing problems, and the retrospective meetings are there for solving them.

According to the Agile Practice Guide, it is possible for a team to have a standup meeting to recognize problems, and then to follow it up right after the standup by a retrospective meeting that will work on solving those problems.   But the important takeaway here is that they are separate meetings with their own flow and dynamics.

I would like to put in a brief word about personal retrospectives, that is, the importance in organizing systems like the Full-Focus Planner by Michael Hyatt of doing something like a personal retrospective on a regular basis in order to increase your own productivity and to decrease your frustration when you become “stuck.”  That will be the subject of my next post.

Retrospectives in an Agile Environment (1)


I am now going through Chapter 5 of the Agile Practice Guide on implementing an agile project.

The first of the practices that agile advocates is that of retrospectives.   Before I discuss this, let me talk about the analog of this type of practice in traditional project management.

It is the lessons learned process, part of the Close Project or Phase process according to the 5th Edition of the PMBOK Guide.  This lessons learned process is part of the final process of any project.   It is a review of what worked and what didn’t, and is designed to help future projects avoid similar mistakes, or to take advantage of best practices implemented by the project.

However, a few years ago I was at the PMI Chicagoland monthly dinner meeting when the subject of the talk was exactly this lessons learned process and how it had changed.

Companies were now doing the process throughout the project to make mid-course corrections.   This news was enthusiastically received, and I went to the person giving the talk and asked him what the impetus was for the change.   “Oh, that’s easy to answer,” he said.   “It comes from the retrospectives done in agile.”

And so, I was excited to see that in the 6th Edition, the lessons learned is its own separate process that is done throughout the project.   It is a concrete example of how agile is not only transforming how projects are done in that agile environment, but it is also having an effect on how traditional project management is done.

However, there are differences between the “lessons learned” process done in traditional projects and the “retrospectives” done in agile.   I will discuss these in the next post.

The Project Charter in an Agile Environment


I am now moving on in my review of the Agile Practice Guide to Chapter 5:  Implementing Agile: Delivering in an Agile Environment.

The previous chapter was about creating an agile environment.   This chapter will get into the nuts and bolts of how to implement a project in that agile environment.

The first pages of the chapter, pp. 49 and 50, deal with the project charter in an agile environment.

Before we move on to this discussion, let’s review what function the project charter serves in a traditional project environment.   In this way, it will make it easier to compare how a project charter is created in a traditional vs. agile environment.

Based on what PMI says in the 6th Edition of the PMBOK guide, the purpose of a project charter in a traditional project environment is to:

  • establish a partnership between the performing and requesting organization (the customer)
  • establish internal agreements within an organization to ensure proper delivery under the contract
  • grant formal authority to the project manager to implement the project

The project charter is drawn up by the sponsor (which could be a person or an entity such as the Project Management Office), OR the sponsor can delegate the creation of the project charter to the project manager.  (I won’t go into all of the elements of a traditional project charter; these can be found on p. 81 of the PMBOK guide.)

In an agile environment, the project charter is done by and for the project team.   The chartering process helps the team to answer the following questions:

  • Why are we doing this project?  This is the project vision.   Simply put, why does this project matter?
  • Who benefits and how?  This is the project purpose.
  • What does “done” mean for the project?  These are the project’s release criteria.
  • How is the team going to work together?  This maps out the intended flow or work.

Although the team goes through the chartering process together, a servant leader may facilitate the process.   Going through the process has the additional function of having the team start working together.

The emphasis in agile is not necessarily the creation of a formal document, as long as the teams come out of the process understanding how to work together.   This understanding can be referred to as a social contract.   Here are some core elements of that social contract:

  • Team values:  sustainable pace and core hours
  • Working agreements:  what does “ready” mean so the team can take in work; what does “done” mean so that the team can judge completeness consistently; respecting the timebox; respecting the work-in-process (WIP) limits
  • Ground rules:  such as one person talking in a meeting at any given time
  • Group norms:  such as how the team treats meeting times

Simply put, the project charter is a team charter which creates an agile environment in which team members can work to the best of their ability as a team.

The next section covers common agile practices, such as

5.2.1 Retrospectives

5.2.2 Backlog preparation

5.2.3 Backlog refinement

5.2.4 Daily Standups

5.2.5 Demonstrations/Reviews

5.2.6 Planning for Iteration-Based Agile

5.2.7 Execution Practices that Help Teams Deliver Value

5.2.8 Iterations and Increments Help Deliver Working Product

I will start the next post with the first practice on the list, that of retrospectives.