4squareviews

I am going over the Agile Practice Guide, a publication put out by the Agile Alliance in conjunction with the Project Management Institute.    I am currently reviewing chapter 5 on the implementation of agile projects, and am now on section 5.3, Troubleshooting Agile Project Challenges.

On pages 58 and 59 of the Agile Practice Guide, there are twenty-one challenges or “pain points” described together with the suggested solution(s) to the problem.   However, they are listed in a random, laundry-list fashion without much rhyme or reason to the order.  So what I have done is reviewed all the suggested solutions and grouped those challenges that require the same type of solution.   These five types of solution are:

1. Production of agile charter
2. Product backlog/user story definition
3. Kanban boards
4. Focus on team roles/responsibilities
5. Testing implementation

This second group of solutions, which centers on the creation of a product roadmap culminating in a project backlog with user stories, covers one third of all the challenges or “pain points” listed by the Agile Practice Guide.

Let’s pull back for a minute and discuss what is involved with a product roadmap.   In an agile project, you start with the product vision, which is how the customer envisions how the product will look and perform.   This vision is of the finished product.   That is like saying you are going on a journey and stating what it at the final destination.   You then have to figure out how you are going to get from here, the starting point, to that final destination.   That is the product roadmap, where you start creating requirements or features that the final product should have.   For each requirement, the team and the product owner should the expectations and value that the requirement represents for the customer.

The result should be a series of user stories which describe how the feature or requirement will fit into the overall final product.   The stories must strive to be as objective as possible, so the acceptance criteria for when the user story is “done” can be easily agreed upon by the customer and the team.

Once the user stories are clarified, and put into the product backlog (the equivalent of the “scope statement” in a traditional project), you can then move on to estimation of how long each story will take.   This takes the laundry list of user stories and ranks or prioritizes them according to their size (how long the completion of the user story will take) and their impact on the overall final product.   Once these factors are weighed, you can then figure out which user stories to work on first–hence the term product roadmap.

Okay, so that’s how the process is supposed to go.   If any of these steps listed above are not done carefully, problems can arise.   The list below shows the challenge or pain point an agile team can experience and its recommended remedy that has to do with the product backlog and the user stories it comprises.

1. Poor user experience–the user needs to be involved in the process of creating the user stories that make up the product backlog
2. Inaccurate estimation–reduce the story size by splitting up the user stories.  Use relative estimation involving the whole team in order to estimate the size of user stories.  Consider spiking (doing a focused study) to understand any story that is unclear.
3. Work delays/cost overruns due to insufficiently refined product backlog items–the product owner and the team should work on user stories together.  Create a definition of “ready” (as in “ready to start work on) for the user stories.  Consider splitting user stories up so that they are smaller.
4. Work is not complete–Work on the definition of done (i.e., acceptance criteria) for user stories and for the project as a whole.
5. Too much complexity–For each user story, encourage the team to focus on the question, “What is the simplest thing that would work?”   This uses the agile principle of simplicity, which can always be described as “the art of maximizing the amount of work NOT done.”
6. Too much rework–measure the work in progress (WIP) at the beginning of the project.  Consider team spikes (doing a focused study) to learn and focus on adding value rather than perfecting the design.    Create a robust definition of done for user stories and shorten iterations if necessary.
7. Inefficiently ordered product backlog items–Rank the user stories not just by their duration, but also by the value that they will contribute to the final product.

You can see that some common theme of these solutions is to make sure that the entire team including the product owner work on the creation of user stories, to reduce the complexity and/or size of the user stories if possible (especially at the beginning of the project), and to create acceptance criteria (i.e., the definition of “done”) for these stories.  If you can make sure to incorporate these practices in the creation of the product backlog and the management of the user stories that it comprises, many of the issues or challenges listed above can be avoided or at minimized.

The next set of solutions deals with the clarification not of the product (which is what the product backlog is for), but of the process, and Kanban boards are an excellent tool for dealing with challenges in this area.   These challenges addressed by Kanban boards will be the subject of the next post.

Filed under: Uncategorized | Leave a comment »

I am going over the Agile Practice Guide, a publication put out by the Agile Alliance in conjunction with the Project Management Institute.    I am currently reviewing chapter 5 on the implementation of agile projects, and am now on section 5.3, Troubleshooting Agile Project Challenges.

On pages 58 and 59 of the Agile Practice Guide, there are twenty-one challenges or “pain points” described together with the suggested solution(s) to the problem.   However, they are listed in a random, laundry-list fashion without much rhyme or reason to the order.  So what I have done is reviewed all the suggested solutions and grouped those challenges that require the same type of solution.   These five types of solution are:

1. Production of agile charter
2. Product backlog/user story definition
3. Kanban boards
4. Focus on team roles/responsibilities
5. Testing implementation

This is the first post, so I will cover the four challenges (out of the total 21) that require the production of an agile charter.

Here are the pain points and their suggested solutions.

1. Unclear purpose or mission for the team–create an agile charter which includes the vision (why is the product of the project being produced–what need does it fulfill), the mission (what benefits does your organization stand to gain by doing the project)
2. Unclear working agreements for the team–create an agile charter that includes the values of the team, the principles, and the working agreements (how will meetings be conducted, how will people communicate with each other, etc.)
3. Unclear team context–create an agile charter that explains the boundaries or constraints (e.g., is there are a hard deadline for the project), and the committed assets (both physical resources and human resources).
4. Unclear requirements–create an agile charter that crafts a product vision (as mentioned above, why the product of the project is being produced).   The team and the product owner (who looks out for the interest of the customers and stakeholders) should clarify the expectations for the product, and decompose this into tracking a list of smaller, concrete requirements.

As you can see, going through the agile chartering process solves a number of problems down the line.    The biggest mistake people have when doing a project is rushing to the planning (design) phase before spending sufficient time in the initializing phase which includes the production of a project charter.

In the next post, the next type of solution will be discussed:   paying attention to the product backlog and the definition of the user stories it contains.   This process solves the largest group of challenges or pain points of any of the five listed above:  eight to be exact.   These eight challenges will be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

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

The first seven practices were covered in earlier posts.   The eighth practice is using iterations and increments to help deliver the working product.

First of all, to understand the context for this practice, you should refer to Chapter 3 which refers to the four types of project life cycles:  predictive, iterative, incremental, and agile.

1. Predictive is simply the traditional project management life cycle.   The requirements are fixed at the beginning, the activities are ideally performed once for the entire project, and the delivery of the final product being done once at the very end.
2. Iterative is a project life cycle where the requirements are dynamic (i.e., can change during the course of the project), the activities are repeated to allow feedback on partially completed or unfinished work so that the work can be improved and modified until a correct solution is found.    Like the predictive model, the delivery of the final product is done at the very end.
3. Incremental is a project life cycle where the requirements are dynamic, and the work is broken down into smaller deliverables.   The activities that are done are repeated for each deliverable.   The big difference here is that the delivery of the project is done incrementally in deliverables that the customer may be able to use immediately.
4. Agile is a project life cycle which leverages both the aspects of iterative and incremental project life cycles.   On the one hand, an agile team iterates over the product to create finished deliverables.    Feedback is obtained early on from the customer, which gives the customer a voice in what the final product will look, feel and perform.

This is why the practice listed here is how to use both iterations and increments to help design a better product.

For iterations, it is best to refer to the first practice on the use of retrospective meetings which serve to punctuate the flow of work in order to create a cadence for delivery and a time for reflection as a group to give feedback on how the process is going.

For increments, it is best to have a process in place where

a) the testing is done by the group to assure that the deliverable achieves the user story that it was based on.   This is the equivalent of scope verification in a traditional project management framework

b) the customer receives the deliverable and is given a demonstration.  The customer gives feedback on whether, from the customer’s standpoint, the deliverable achieves the user story as promised.   This step in the process can be problematic if the customer does not know beforehand what the user story is, or has an understanding of it that differs from that of the agile team.    This is why the user story has to be written in an objective manner, so that subjective interpretations of what it means can be eliminated as much as possible.    This is the equivalent of scope validation in a traditional project management perspective.

c) The team then takes the feedback from the customer on how the product looks, feels and performs, and then in the next retrospective they will either continue on to the next deliverable, or if there is negative feedback, they will discuss how to adapt the product in order to have it conform to the customer’s expectations.

So the feedback created at the end of increments  are used as the raw data which drives the analysis done during the retrospectives.   This is why agile is considered a project life cycle in which iterations and increments work together hand in glove.

This concludes this series of posts on how to execute an agile project.

The next section, section 5.3, discusses troubleshooting agile project challenges.   In a manner typical for PMI, these 21 challenges or pain points are listed in a laundry-list fashion, with no clear thematic group (at least that I can see).   So I am going to analyze these 21 challenges and see which can be grouped together based on the nature of the troubleshooting possibility (the creation of an agile charter, the development of a product backlog, the role of the servant leader or product owner, etc.).   The first post will be those agile challenges that can be remedied by creating an agile project charter.

Filed under: Uncategorized | Leave a comment »

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

The first six practices were covered in earlier posts.   The seventh practice is actually a bundle of execution practices that are designed to help quality on the project.

1. Continuous integration–as each module is designed, the entire product created so far must be retested to make sure that it still works as intended.
2. Test at all levels
   • Unit testing should be done for the building blocks, and then
   • System-level testing  should be done to make sure that the building blocks are communicating data properly.
   • Smoke testing, also known as “Build Verification Testing”, is a type of software testing that is comprised of a set of tests that aim at ensuring that the most important functions work.  The result of this testing is used to decide if a build is stable enough to proceed with further testing.
   • After smoke testing, regression testing is done.   Regression testing is when you are testing around specific areas of an application where defects have been fixed to ensure that no other issues have been introduced.
   • Agile teams have a strong preference for automated tests that ensure uniformity of testing through the design-test-deliver cycle (see paragraph 3 below regarding ATDD).
3. Acceptance Test-Driven Development (ATDD)–the entire team gets together ad discusses the acceptance criteria for a work product.   Based on these agreed-upon criteria, the team creates automated tests that will allow the work product to be tested to see if it meets the acceptance criteria.
4. Test-Driven (TDD) and Behavior-Driven Development (BDD)–the advantage of writing the automated tests before creating the product is that it actually helps people doing the design and it helps mistake-proof the product.
5. Spikes (timeboxed research or experiments)–spikes are concentrated periods of focus not on creating the product itself, but on doing work which helps facilitate that creation.   They are used when the team needs to learn more about some critical technical or functional elements.   Examples of such research are:
   • estimation
   • acceptance criteria definition
   • understanding work flow

The last practice is the eighth and final one on the list at the top of the post, namely, implementing iterations and increments in order to help deliver work product.   That will be the subject of the next post.

Filed under: Uncategorized | Leave a comment »

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 five items in previous posts.   The sixth item is what I’m covering today.    There are two ways of managing the work flow on an agile project:

• Flow-based:  an iteration is considered complete when the team reaches some sort of milestone, like when it completes a major deliverable, ships something or even completes a release.   It is based on the completion of a definable chunk of work.
• Iteration-based:  an iteration is done on a regular basis, with a two-week iteration being the most popular.

The common agile practices related to planning for iteration-based agile (the second option above) are what is being covered today.

First of all, the team must establish the length of the iteration, with two weeks and four weeks being the most popular options.   Note that it is possible for a new team to meet once a week at the beginning when the team is getting used to working together, and then lengthening the iteration to two weeks once there is a rapport established between team members.

Second, the group needs to decide what story size the team has the capacity to handle within a given iteration.

Third, the product owner has to take into account when people are unavailable, as they will not be working at full capacity or perhaps even at all (for example, when they are in vacation).   When teams have a reduced capacity, the team needs to plan for work that meets that capacity.

Fourth, it is best for the product owner to make the stories smaller in the beginning so that the teams see progress in the form of a finished product, and therefore gain confidence to be able to take on more work during an iteration.

The big takeaway from agile planning vs. traditional project management planning, is that in agile, you do not plan just one in a single chunk, but a little at a time.   Once the work is delivered, the retrospectives described in an earlier post keep the team on track, so that they can plan a little more of the work for the next cycle.

So this deals with managing the scope, a measure of the completeness of the work.   The correctness of the work is also vital, and that takes you into the domain of quality.

The next post will cover the execution practices that help teams deliver value.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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!

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »