4squareviews

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 »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

In the last three posts I described the three elements of the culture of agile as described in the fourth chapter of the Agile Practice Guide.   These are

• self-organization
• 100% dedication (i.e., team members’ time not split between other projects)
• co-location (having access to a common workspace)

When I was the Director of the Executive Council at PMI Chicagoland, we talked about the creation of an agile culture and what threatened it within the organization.   One of the executives said, “well, you can create an agile culture on a team, but when you try to re-create that culture in the organization at large, watch out for the corporate antibodies that start to attack!”

What he was saying that the culture of the organization at large may be traditional, and creating a sub-culture within an agile team is all well and good, but the larger culture of the organizational may see this as a threat–in the analogy to the body’s immune system, the agile culture may be seen as a “foreign” or outside entity that the body needs to protect against.

In asking this executive what the main element of organizational culture is that perceives agile as a threat, he replied “organizational silos.”  I remembered that when this discussion came up on p. 47 of the Guide on “Overcoming Organizational Silos.”

How do you create an agile culture?   According to the Guide, “by building a foundational trust and a safe work environment to ensure that all team members have an equal voice and can be heard and considered.”   One of the names of this kind of organizational structure is a “heterarchy” where everybody is at the same level of power.   This is opposed to a “hierarchy” where certain members have more power than others, and this is often what you generally have in an organization that is divided into different silos or specialties.   On a traditional project that has a balanced matrix structure for example, you have the team members on a project who report on the one hand with regards to their project work to a project manager.   Their main work in the organization, however, comes from a particular department where they have a functional manager overseeing their everyday work for the company.   This often creates a tension within the team member of dual loyalties both to the project and to the larger operations of the company.

In agile, this is avoided by having the various functional managers who give team members to the agile project allow their members to join the project and dedicate all of their time to it for the duration of the project.   The loyalty now is not to a project manager, as in a traditional project, but to each other, the members of the cross-functional team.

Once the project is done, the organization at large can see how leveraging its people can optimize the project or product being built.   However, there is another advantage to the organization that is trying to adopt agile culture and that is to learn from the synergy of the team on that project and use it to try to dissolve the impediments that the organization puts out for cross-functional agile teams.

That is the way in which agile culture can affect the culture of the organization as large–not in the sense of destroying that overall culture, because that attitude is what causes the “corporate antibodies” to reject agile culture.   Rather, it should be seen in the light that agile culture “transcends and includes” the culture of the organization at large.  Yes, there are hierarchies that are unavoidable in many companies, but having the “heterarchies” of agile teams loose in the company may cause the silos to have greater communication with each other, and more empathy for what each of them needs.

In this way, agile culture can truly be transformative of the corporate culture as a whole, rather than being seen as a threat.

This was the last post on Chapter 4 on Creating an Agile Environment.  The next post will start with chapter 5: Delivering in an Agile Environment.  The first post will be on what a project charter, an essential document in traditional project management, looks like in an agile environment.

Filed under: Uncategorized | Leave a comment »

In the fourth chapter of the Agile Practice Guide which focuses on implementing an agile environment, after discussion on p. 40-42 of the various roles on an agile team, there is a discussion of the various values promoted by an agile culture.   In this context, you can take “culture” to mean the various qualities of the interactions between members of that group.   So what qualities does agile recommend in order to have a successful team?

These qualities are:

• self-organizing (working out problems as a group rather than expecting a leader to assign people work)
• dedicated team members (striving to have team members working exclusively on a single project rather than than dividing their time among a lot of projects)
• colocating (having a common workspace where meetings can take place to monitor progress on the project and to discuss solutions to any impediments that may come up)

In the last post, I discussed the quality of dedicated focus as it applies to an agile team, meaning that is best when team members’ time is 100% dedicated to the project.  In this post, I will discuss how there should be a space that is 100% dedicated to the project.  This means that there is some common meeting place where all members meet to exchange information and work on solutions to problems.   To do this, the members have to work in the same general location, and this value is called co-location.

The ideal situation is to have a social area where members of the team can meet to have stand-ups, retrospectives, or any other type of meeting required.   It should have private areas where small groups of the team can split off and work out any problems that may arise in executing the tasks of the project.

However, this ideal is not always achievable.   Geographically distributed members need to manage their communications with the “home team” so that the team can learn to trust each other and work together as effectively as if they were physically present.  How can this be achieved?

Well, the Agile Alliance recommends two things:

• Set-up video conferencing links between the various locations where the team is dispersed.   Start the link at the beginning of the day, and keep it open during the day so that the various members can communicate spontaneously with each other.
• Set up remote pairing by using virtual conferencing tools to share screens, including voice and video links.   This may prove as effective as face-to-face pairing.

There are two common attributes to these links.   They a) include a video component because you can tell a lot more than communication through an e-mail or even through a telephone call; and b) always open so that they can be used spontaneously whenever problems arise.

These three elements I mentioned at the top of the post–self-organizing, dedication, and colocation–are essential for the creation of an agile culture.   However, if the organization itself is more of a traditional mindset, there will be resistance that comes from the organization.   As an executive put it once from the Executive Council of the PMI Chicagoland chapter, “the corporate antibodies will attack any foreign body that tries to spread any contrary message.”   The antibodies in this case take the form of organizational silos.   These impede the formation of cross-functional agile teams.   How to overcome this corporate resistance will be the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In the fourth chapter of the Agile Practice Guide which focuses on implementing an agile environment, after discussion on p. 40-42 of the various roles on an agile team, there is a discussion of the various values promoted by an agile culture.   In this context, you can take “culture” to mean the various qualities of the interactions between members of that group.   So what qualities does agile recommend in order to have a successful team?

These qualities are:

• self-organizing (working out problems as a group rather than expecting a leader to assign people work)
• dedicated team members (striving to have team members working exclusively on a single project rather than than dividing their time among a lot of projects)
• colocating (having a common workspace where meetings can take place to monitor progress on the project and to discuss solutions to any impediments that may come up)

In the last post, I discussed the quality of self-organizing as it applies to an agile team.  In this post, I will discuss the quality of being dedicated to a project.   Here I mean that the team members’ time is dedicated 100% to the project.   This goes against the trend of multitasking, where a person switches from project to project in the course of a day.

Why is multitasking discouraged in agile teams?   For the simple reason that it lowers productivity.   Many people do not realize by how much it reduces their productivity.  Here are some facts I found on the website Productivity Theory

• Even short periods of mental blocks caused by alternating tasks costs between 20 to 40 percent of one’s productivity, according to a study at the University of Michigan’s Brian Cognition and Action Laboratory.
• If you’re immersed in a task, such as writing a report, and an email notification distracts you, know that it can take you up to 25 minutes to become deeply absorbed again in the task, advises Dr. Julia Irwin, a senior lecturer of psychology at Macquarie University.
• Other studies report evidence against multitasking as a desired skill. The University of London found that those who multitask during cognitive activities had an IQ drop similar to if they’d pulled an all-nighter or smoked marijuana, averaging ten points. Men who multitasked saw drop of 15 points, communicating with the average mental faculties of an eight-year-old.

(See the website at https://productivitytheory.com/multitasking-lower-iq/ for more information.)

This is why the agile ideal culture is where everyone the team is 100% allocated to one project.

Based on this information, we know now that the team needs to be focused in time to be at maximum efficiency on the project, but they also need to be focused in space.   That is the subject of the next post, on the third value mentioned at the top of this blog post, namely colocation.

Filed under: Uncategorized | Leave a comment »