4squareviews

This is a review of section 6.1 Organizational Change Management in the Agile Practice Guide.   The particular topic being covered on pp. 73-74 is how organizations can either accelerate or impede the evolution of agile practices.   I used the phrase “corporate antibodies” because I heard it during a meeting of the PMI Chicagoland’s Executive Council during my tenure as the Director.  The discussion was how to create and foster an agile culture on projects.   One of the executives present said that creating an agile culture wasn’t the problem.   He said that the real problem was AFTER the project was completed.   He said that the enthusiasm and ideas from the members of the project team would start flowing into the organization, but would be stopped by what he called the “corporate antibodies”, meaning the traditional views of project management that were held by upper management.    This is just an example of how an organization can impede the evolution of agile practices.

Let’s go over the positive and negative ways an organization’s leadership can impact the spread of agile culture.

ACCELERATING AGILE CULTURE

Here’s the positive ways an organization’s leadership can influence the spread of agile culture:

• Visible and active executive sponsorship of agile projects (their presence at kickoff meetings is an essential part of this)
• Using communication and coaching to facilitate the change in corporate culture
• Progressively pacing the adoption of agile practices on a project-by-project basis
• Incremental introduction of agile practices to the team through agile coaches
• Leading by example by having management use agile techniques and practices whenever possible

IMPEDING AGILE CULTURE

On the other hand, management can impede the spread of agile culture in the following ways:

• Creation and maintenance of departmental silos–this creates dependencies (hand-offs between departments) that in turn prevent accelerated delivery
• Procurement strategies based on short-term pricing strategies rather than long-term competencies
• Leaders are rewarded for temporary efficiencies rather than the end-to-end flow of project delivery
• Employees are not given incentives to diversify, but rather to remain specialized contributors to a project
• Decentralized portfolios pull employees into working simultaneously on many projects at once rather than having them focused on one project at a time.

Given these two choices, management has to decide which would rather have:  agile bodies adding value to an organization, or corporate antibodies that try to prevent it…

Filed under: Uncategorized | Leave a comment »

This morning I achieved a milestone by reaching the mark of having used the language-learning app called Duolingo for 1,000 days in a row.   I have tried to create a long-running streak before, but I was always so busy I would forget to use it on a given day and, well, there went my streak!   THIS time I was determined to make it a rock-solid habit, so I made sure that I used the app and got 50 experience points (which the app considers to be the INSANE level of a daily goal) before I even got out of bed.   This is what has made the achievement possible.

One of the reasons why I like Duolingo is because it is already changing and always improving.    They keep adding more languages, and sometime last year, they added an additional challenge by adding 5 levels of difficulty to each language.   I had finished the all the skills in the “skill tree” for several languages (Spanish, French, German, Japanese and Chinese), and now I am simultaneously going back and working on each language to get each to level 5 and learning some new languages from the beginner level (Portuguese, Italian, Russian, Hindi, Korean).

Another set of features they have added are new modes of learning, so you can read stories, or listen to a series of podcasts in the language you are studying.   They have rolled these new features out for Spanish, and they are seeing if they are popular enough to create the other languages.

The basic feature of Duolingo, however, are the “skill trees” that focus on one skill at a time (such as a category of vocabulary or a grammar point), starting from the simplest (present tense) and going to the most complex (the conditional and subjunctive tenses).  They have added skills to the most popular languages (such as Spanish and French) and will probably continue doing this with the other languages as well.

In short, it never gets boring because if you complete a skill, a level, or an entire language, there will new content to learn the next week.   It’s why it has been such a pleasure to go on this journey of 1,000 days.

Why am I so into this language-learning app?   I’ve been a lifelong fan of learning foreign languages and about cultures of other countries since I was the age of 6.   My uncle came to visit and he had been living in Honduras for several years as an engineer.   He was divorced, but remarried a woman from Honduras and he was bringing her to meet my parents (he was my mom’s younger brother).    I was amazed at his ability to speak one moment in a way that I could understand, but then he would suddenly turn to his wife and speak some sort of gibberish that I couldn’t.    I started asking questions and he explained to me that he was speaking a different language.   I had heard of other languages, but never saw a person who could switch effortlessly between them.  I vowed that some day, I would like to be to do that too.

And so I did.   I studied Spanish in high school, French and German in college, and Japanese and Chinese in graduate school.   My problem is keeping them from fading in my mind from lack of practice by trying to practice them all at once.   It seemed an impossible task to organize given my busy life until Duolingo came along and it enabled me to do this every day, and to enjoy myself in the process!

So if you sign on to the Duolingo app, add me as a friend.   My real name is Jerome Rowley, but my username on Duolingo is Luojieli, because that is my name in Chinese!

Filed under: Uncategorized | Leave a comment »

I am going through the material in Chapter 6 of the Agile Practice Guide, which focuses on organizational support of an agile project.

Here are the changes particularly associated with agile projects, and why they have to be considered in any change management approach.

• Accelerated delivery–Agile is an approach that focuses on delivering project outputs early and often to the customer (the “incremental” part of agile) and giving feedback from the customer back to the team on a regular basis (the “iterative” part of agile).   On the organizational side, it is important to discover and deliver the features of the product to the customer.   But as the pace of delivery increases, it is important on the customer’s side to be able to accept the delivery and validate that it aligns with the project objectives, or point out where it doesn’t align in as clear a manner as possible.
• Learning curve–when an organization is just beginning to use agile approaches, there is a high degree of change when learning to accept the culture of agile.  Agile will require more frequent hand-offs between teams, departments, and even vendors.   Change management techniques can help address the hurdles of transitioning to agile approaches.

So it is not just a learning curve to learn the culture of agile, but an acceleration of already existing communications.

The problem in many organizations is that agile is seen as something that replaces traditional project management.   A better way to see this is that it transcends and includes a lot of the traditional structures in the organization, and can end up transforming them.   An example is with the “lessons learned” process, which in traditional project management was typically done at the end of a project (at least according to the 5th Edition of the PMBOK Guide).   When agile came along, this lessons learned process was still done, but not at the end of the project, but rather at the end of each iteration.   Any lessons learned were applied directly to the project at hand, and not at some hypothetical project in the future that may or may not take place.   This accelerated improvement not only made the project better, but those “best practices” that developed during the project could be used by the organization as a whole or even by other project teams.

This is an example of how agile did not replace a structure from traditional project management, but instead it transcended and included it (by having it incorporated into each iteration).   It proved so useful that in the 6th Edition of the PMBOK Guide, it is no longer a part of the “Close Project or Phase” process in the Closing process group, but is a separate process that it done during the Executing process group, as process 4.4 Manage Project Knowledge.

So with this more positive way to thinking about agile approaches, what are some of the characteristics of organizations that make supporting agile principles easier?   And conversely, what are some of the characteristics that may be roadblocks to achieving agile principles?   This will be the subject of the next post.

Filed under: Uncategorized | Leave a comment »

The subject of the 6th chapter of the Agile Practice Guide is the ways in which the organization at large can support an agile project.   The previous chapter covered the subject of implementing an agile project by creating an agile environment within the team.    The theme of this chapter comes from the statement on p. 71, the first page of the 6th chapter:  “Project agility is more effective and sustained as the organization adjusts to support it.”

The first topic in this chapter is change management in an agile environment.    In my opinion, the biggest difference between change management in an agile environment and a traditional project management environment is a psychological one:   the goal is that change should be seen as a positive good rather than as a necessary evil.

A graphic way to understand this comes from a book I am reading now called The Zen Leader by Ginny Whitelaw.   She talks about transforming your consciousness so that you can go from passively coping with problems or changes to actively using those same issues to transform your team and your organization.

A clue to how to do this transformation comes from her explanation of what you have probably seen demonstrated by a karate instructor:   focusing your energy on breaking a board.   She explains that the trick is that the person who wants to break the board does not focus on the board.   If you are trying to break the board, you focus your physical and mental energy on a point behind the board.   You are trying to reach that point, and the board is just something you go through in order to get there.   She says that seeing a problem and focusing on it is a way of coping with the situation.

If there is a problem that the project team encounters, the ways of passively coping with the situation are as follows, from the worst to the, well, least bad:

• Denial (what problem?)
• Anger/Rage (hey, what gives–this messes up our comfortable status quo!)
• Resistance (do we HAVE to do this? Is there any way we can mitigate the change (i.e., sabotage it)?
• Rationalization (we don’t want to do this, but we’re being forced to by outside forces outside of our control)
• Tolerance (it’s a necessary evil, but it has to be done if we want to go forward)

If you focus your team not on the problem itself, but on what the solution could possibly mean for the project, then you are flipping your mind from merely coping with the problem to transforming it.

Here are the stages of transforming as opposed to coping with a problem (from the good to the best):

• Acceptance (well, we don’t have a choice about the problem, but we do have a choice about how we react to it)
• Joy (if we were to make the change, it would make our customers happier, and benefit our organization)
• Enthusiasm (let’s all roll up our sleeves and think of how to get there!)

Saying this is one thing, doing it is, of course, another.    One mental exercise she has to help you shift your mind into positively accepting the above three stages is the following.

• Relax–raise your shoulders up to your ears, the way people do when they are tense.   Drop that tension, and exhale.   Sense that your awareness is going out of your head, and into the center of your body.    Start breathing from the belly or lower abdomen–it will continue your relaxation.
• Enter–Picture a circle, like the eye of a hurricane, that you can enter.   Although all around you are the swirling patterns of reaction to the problem (the “coping” described above), you now see that inside the circle you see the situation as a puzzle or a game.   This will allow you to enter a flow state where you start to engage your creativity.
• Add value–From the creativity within that you have engaged in the previous step, project this energy outwards to the other members of your team and lead them into your circle.   The energy will lead your team to help you add value by reaching towards a solution.

This book has been tremendously helpful to me in dealing with problems or changes on a project, and I thought it was important to start the section of Chapter 6 dealing with change management to show how important a psychological shift is when going from traditional project management to agile.

In the next post, I will discuss the particular changes associated with agile approaches.

Filed under: Uncategorized | 1 Comment »

This is a continuation of the discussion of section 5.4 Measurements in Agile Projects of the Agile Practice Guide.

Measurement of the progress in doing a project is different between traditional and agile projects.   Traditional projects used Earned Value Management, which takes the unit of measurement to be the number of dollars (or whatever currency the organization is using) budgeted for the completion of a work package.

There are basic building blocks to the measurements in Earned Value Management.

• Planned value (PV)–this is the authorized budget assigned to the work that is scheduled to be done.   (The key word there is “scheduled”.)
• Earned value (EV)–this is the measure of work actually performed.   (The key words there are “actually performed”–it is a a measure of how much scope was accomplished.)  This is expressed in terms of the budget authorized for that work.
• Actual cost (AC)–this is the measure of the actual cost for work actually performed.  (The key word is obviously “cost”.)

To get the Cost Performance Index, you take AC/EV, and to get the Schedule Performance Index, you take EV/PV.

In agile, the unit of measurement is a story point, which is an estimation of how “big” the user story (i.e., a feature of the product being created) is.   It is a relative estimation, so the size of the smallest feature may be designated arbitrarily as 1, and the other features given a number of story points in comparison.

When I was initially studying about agile, I thought that Earned Value Management wouldn’t be used, but an analogy can be used in an agile environment.   For example, an analogy of the Schedule Performance Index can be used.  SPI in a traditional project environment would equal

SPI = EV/PV = (value of work actually performed)/ (value of work planned)

Since PV and EV are both in units of dollars, you get a simple ratio as a result.   An SPI of 0.80 tells you that your team only got 80% of the work done.   Analogously in an agile environment, if you take SPI now to mean

SPI = (number of story points actually completed)/(number of story points planned)

then you can compute the SPI for a given iteration.   If you planned on completing 20 points in an iteration, and the team actually only completed 15, then the SPI is 15/20 or 0.75.

However, one of the main differences between EVM in a traditional vs. agile environment is the following.   In traditional EVM, earned value or EV refers to the work completed by the team.   However, EV in an agile environment refers to work that is not only completed by the team, but shown to the customer and validated that it conforms to their understanding of the requirements.   Because if it does not conform, then the item or feature has to be reworked.   It is not just work that is complete, but work that is also correct, that counts in agile EVM.

Now there are two ways of setting up iterations in agile.   One is take an arbitrary amount of time (usually referred to as a timebox) and then you take a measure of your progress every two weeks or however long the iteration is.   The team following this approach is referred to as an iteration-based agile team.

There is another way of marking progress, and that is having the iteration not be specific length, but the length of time is takes to do the next feature in the product feature backlog.   The team following this approach is referred to as a flow-based agile team.

The measurements used with flow-based agile teams are listed below in relationship to a Kanban board.  The “ready” column on a Kanban board is the list of features from the product feature backlog that are ready to be worked on, usually the left-most column.  When the item is ready to be worked on, it is removed from the “ready” column and put in the development column to its right.

• response time (the time that an item waits in the “ready” column until the work starts)
• cycle time (the time that it takes to process an item once the work starts)
• lead time (the total amount of time it takes to deliver an item, from the time it is added to the board in the “ready” column to the moment it is completed)

As you can see from the above definitions, the lead time is equal to the response time plus the cycle time.   The cycle time measures the work in progress.

According to the Agile Practice Guide, the cycle time can be used by a flow-based agile team in order to see bottlenecks or delays, whether they are inside the team or external (based on interactions with the customer or sponsor, or perhaps caused by delay of delivery of resources from a vendor).  The next post will talk about a cumulative flow diagram, a way of representing the measurements listed above, which can give clues as to the source of those delays.

Filed under: Uncategorized | 2 Comments »

This is a continuation of a discussion based on Chapter 5 (Implementing Agile) from the Agile Practice Guide, a publication jointly produced by the Project Management Institute and the Agile Alliance.

In the previous posts, I compared measurement of a project’s progress in a traditional vs. an agile environment.    A traditional measurement system such as Earned Value Management measures work completed; an agile measurement system measures work completed and delivered to a customer.    So it includes what in a traditional project management scheme consists of the following processes

• Process 8.3–Control Quality (internally verifying that the work conforms to the quality standards for the project)
• Process 5.5–Validate Scope (externally validating with the customer that the work conforms to the requirements for the project)

In other words, you measure whether the work is complete in a traditional measurement system; you measure whether the work is correct in an agile measurement system.

Two of the common systems for measuring progress on a project in an agile environment are a burndown chart and a burnup chart.   The raw data for both types of charts is the same, the number of story points.   The number of story points is an estimate of the effort required to complete a particular user story (feature) from the feature backlog.   The difference between the two types of chart is simple:

• a burndown chart starts with the total amount of story points expected to be completed in the course of a project, and as each user story is completed, the chart shows the remaining story points
• a burnup chart starts at zero, and as each user story is completed, the chart shows the completed story points

At the end of the project, a burndown chart will show zero remaining story points, and the burnup chart will show the number of story points completed for the whole project.  For examples of these graphs, see Figure 5.1 on p. 62 and Figure 5.2 on p. 63 of the Agile Practice Guide.

In a traditional project environment, the baseline may change if there are any changes to the scope during the course of the project.   Similarly, in an agile environment, if the scope changes during the iteration, the burnup or burndown charts will also change to accommodate those changes.

In agile, the velocity is a sum of the story points sizes for the features actually completed in the current iteration.    It is useful because, if the project continues at the current velocity of work production, you can take the number of remaining story points and divide by the velocity (number of story points done by each iteration) to get how many iterations it will take to complete the project.

It may take four to eight iterations to achieve a stable velocity.   After that, if the velocity changes, it will have a direct effect on the length of time it may take to complete the project, so it is important to measure velocity and compare it to the velocity of previous iterations so you can see whether there is any changes (up or down).

Now, the description above applies to iteration-based agile measurement.   If you use flow-based agile measurement, which does not use the regular cadence of an iteration, it is based instead on the completion of a particular user story or feature.   The next post will go into further detail into the flow-based agile measurements of cycle time and lead time.

Filed under: Uncategorized | Leave a comment »

This post will conclude my comparison of measurement of progress on projects in a traditional environment (using earned value analysis–contained in the first post) with measurement on projects in an agile environment (covered in the second post and this one).

Summing up the last two posts, as opposed to a predictive measurement system like earned value analysis that focuses on the completeness of the work, an agile measurement system will have the following characteristics:

• It will focus on customer value added.
• It will focus on quality (the correctness of the work), so that a feature is considered finished not when the team has done the work, but after the team has tested it and the customer approves.

Here are some additional features of agile measurement of progress on a project.

• The chunks of work being measured are made smaller, so that people are more likely to deliver on it.
• Product development involves a learning curve as well as delivery of value to a customer.   By keeping the work increments small, this allows for more feedback from a customer, which loops back to the team and causes them to improve on the next work increment.
• Rather than trying for a heroic pace to get done as quickly as possible, a steady pace is preferred that allows enough time to get the work done correctly.

The “steady pace” referred to in the last point above is important for the purpose of estimation.   A sponsor who wants to know when a project will be completed will be best served by a steady pace of work, because this will allow a simple calculation of

The number of remaining story points/remaining number of story points done per iteration.   With 500 story points remaining and 50 done on average per iteration, you can tell the sponsor with confidence that you will be able to get the project done in 10 iterations.   If each iteration is two weeks, let’s say, then you can see it will be done in 20 weeks.

This post reviewed the characteristics of agile measurement and estimation.   The next posts will go into the details of this type of measurement based on the material on pages 62-70 of the Agile Practice Guide.

Filed under: Uncategorized | Leave a comment »