4squareviews

In the fourth chapter of the Agile Practice Guide, the discussion focuses on creating an agile environment.

On p. 37 and 38, the role of a project manager is contrasted with the servant leader role.   After I present what the Agile Practice Guide has to say, I want to relate some words of wisdom from one of the foremost agile coaches in the Chicagoland area, Anthony Mersino, from his Vitality Chicago blog.

Although some agile practitioners feel that project managers are not needed because the project teams are, after all, self-organizing, the guide says that pragmatic agile practitioners can add significant value in many situations.   The key is that they need to adjust their mindset to that of a servant leader.   Rather than explicitly coordinating the activities of the team, they foster great collaboration on the team, remove obstacles for the team to function more effectively, and aligning the needs of the stakeholders.

Here are five roles that a project manager does on a traditional project, and how the role of a servant leader contrasts this (taken from a graphic accompanying the following article on Vitality Chicago

https://vitalitychicago.com/blog/transition-from-project-manager-to-scrum-master/

• a driver, the servant leader is an enabler
• a decision maker, the servant leader is a facilitator
• a controller, the servant leader is a teacher
• communication hub, the servant leader is a supporter
• translator, the servant leader is a protector

If you are looking for resources in how to turn yourself from a project manager to a great scrum master, go to the above article by Anthony Mersino and see the list he has created.

In the next few posts, let’s look at how agile teams are organized.

Filed under: Uncategorized | Leave a comment »

I was going to do my daily post on agile project management today, but I’m taking the day off–in more ways than one.   It is a Wednesday, and it normally would be a work day, but the plant I work at is closed because of the extreme cold here in the Chicago area.   The temperature will go down to -25 F tonight, with the wind chill factor making it feel like -50 F.   I just spent half an hour in the crawl space in the basement, putting a heater near the pipes coming from the outside so that they don’t freeze and possibly burst during the night.

I was listening to the reports about how the weather will be the coldest it has been since 1985, and I decided to take a day off my normal blog schedule (where I am going through the Agile Practice Guide), and write about a movie I saw 15 years ago called The Day After Tomorrow.

It was a science-fiction movie about the effects of global warming, starring Dennis Quaid as the climatologist Jack Hall (Dennis Quaid).   After his warnings were largely ignored by U.N. officials when presenting his environmental concerns, his research proved to be true when an enormous “superstorm” developed, setting off catastrophic natural disasters throughout the world.   Among those disasters were, in addition to the rising of global air temperature levels

a) rising sea levels (caused by the melting of glacial ice in Greenland and Antarctica)

b) the slowing of the Gulf Stream (due to the melting of glacial ice in Greenland mentioned above), which normally keeps the countries East of the Atlantic Ocean several degrees warmer than the countries on the West side of that ocean

c) disruptions in air circulation patterns around the poles causing super-cooled air to be pulled from the stratosphere.

There are other unusual patterns that were mentioned, but the three mentioned above are the ones that stuck in my mind the most.   In the past few years since I’ve moved back to the Chicago area from California, I was worried about the rising sea levels to a certain extent, but was comforted in my mind with the fact that I no longer lived on either coast as I had done for many of the past 25 years.   I was concerned about the slowing of the Gulf Stream, but that was also a more distant concern.   As far as the last item above is concerned, I frankly thought that was tipping out of the realm of “science” and into the realm of “science fiction.”

However, I have heard in the past few years about the phenomenon of the polar vortex, which is a circular pattern of winds in the stratosphere that revolves around the North Pole and essentially “locks in” the arctic cold during the wintertime in the Northern Atmosphere.   North of this polar vortex it is super cold, but south of it, the winter temperatures are cold but not nearly to the same extent.

However, the average temperature in the wintertime in the arctic has gone up twice as much as it is in the temperate climates.   That means that the warm air from that climate zone flows north like a river in the atmosphere, and when it reaches the polar vortex, it crashes up and over it like waves over a wall during a hurricane.   The polar vortex actually gets breached and it splits into two or three lobes, some of which get pushed away from their normal position over the poles.

Today we are seeing the results of this:   a super-cooled body of air that normally would not travel below the arctic circle is going to be passing over the Midwest United States, and the temperatures have been plummeting for the past 24 hours.   It’s now -15 F (-38 with the windchill), and the temperature will continue to go down until it reaches -25 F just before dawn tomorrow.

Now, this is not as dramatic a change in temperature as depicted in the movie (where the drop happened in literally a few minutes), but when you’re actually living through it, it brings home that what was a science-fiction movie actually was based on a lot of science that has proved to be true.

I am sure there will be some politicians who take advantage of the intense cold to cast doubt on the phenomenon of climate change, like the one who held up a snowball a year or so on the Senate floor to demonstrate that there was no such thing as global warming.  I was half expecting him to go to McDonald’s, buy a Happy Meal, hold it up on the Senate floor and say that it proved that there was no such thing as global food insecurity!

But for those of us who are out here living in the consequences of actions taken (or not taken) by the government, this weather we are experiencing is another in a series of warnings nature is giving us, as told in the lyrics of the song Nature’s Way by the band Spirit way back in the 1960s:

It’s nature’s way of receiving you
It’s nature’s way of retrieving you
It’s nature’s way of telling you
Something’s wrong

I hope this will make more people heed the call!

Filed under: Uncategorized | Leave a comment »

In the fourth chapter of the Agile Practice Guide, the Agile Alliance discusses the role of the “servant leader” (such as scrum master) and contrasts it with the role of project manager found in traditional project management.

In the last post, based on the material on the top of p. 35, I reviewed what the Guide says about the role of facilitation, which faces inwards towards the project team, helping them create acceptable solutions.

The other part of servant leadership faces outwards from the team to the organization at large, and this is where the support role becomes crucial.   The visual image I get of this is of the sport famous in Canada called “curling.”  It is a a sport in which players slide stones on a sheet of ice towards a target area which is segmented into four concentric circles.   Once projected by the thrower, the path of the stone may be influenced by sweeper with a broom who accompanies it as it slides down the sheet of ice, using the brooms to alter the state of the ice in front of the stone.   In the analogy with an agile project team, the team members are the ones who throw the stone across the ice, but it is the servant leader who like the sweeper accompanies the stone on its flight, and tries to sweep impediments out of the way so that the stone can make it to the target.

Here are some of the specific actions a servant leader can take within the organization to smooth the project towards its goal:

• Streamline documentation processes–identifying “bottleneck” processes involving documentation, and then working with a department to evaluate the amount of documentation required so teams can spend more time delivering a valuable project instead of producing exhaustive documentation.
• Educating stakeholders–explain how prioritization of work, greater accountability and productivity of empowered teams, and improved quality from more frequent reviews are connected to benefits of business value and therefore of a better “bottom line” for the organization.
• Advocate for training and career development–consult with human resource development to encourage team members to grow beyond their current roles, benefiting both the team members and the organization as a whole.
• Support bridge-building activities with groups external to the project, creating positive feedback loops of appreciation and good will based on increased collaboration.

This post and the last one outline the roles of the servant leader.   How does the role of project manager differ from that of a servant leader?   It is important to be aware of this so that project managers can transition to taking on the role of a servant leader in an agile framework.   That will be the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In the fourth chapter of the Agile Practice Guide, the Agile Alliance talks about creating an agile environment.   The first focus is on the role of the “servant leader” which is a change from the role of the traditional project manager.

A project manager manages and coordinates the activities of the project team; a servant leader, on the other hand, facilitates cooperation among members of the team.   Rather than making decisions on behalf of the team, they encourage the team to come up with its own solutions.

What does a facilitator do?

• Encourage collaboration–holding interactive meetings, promoting informal dialog between team members, encouraging knowledge sharing
• Expose and communicate bottlenecks–if there are impediments having to do with resources, then the facilitator needs to get the organization to provide those needed resources.   If the bottlenecks have to do with navigating the documentation required by the organization, the facilitator assists with this or tries to streamline the process in the organization at large in order to reduce unnecessary documentation that does not add value.  If the bottlenecks are internal having to do with communication issues or personality conflicts, then the facilitator helps resolve these.

The next post covers the other responsibilities of a servant leader.

Filed under: Uncategorized | Leave a comment »

These are my notes for Chapter 4 of the Agile Practice Guide:  “Implementing Agile:  Creating an Agile Environment.”

In the last post, I talked about how to create a agile mindset with your team by considering several key questions.   In this post, I will talk about the concept of “servant leadership,” and how it can help empower the team to use an agile approach.

“Servant” leadership seems to be an oxymoron, but it is leading through service to the team, by focusing on what the team needs in order to do the work it has organized itself to do.

Servant leaders approach project work in this order.

1. Purpose–“define the “why” or purpose so they can coalescence around common goals for the project.
2. People–once the purpose is established (as in paragraph 1 above), encourage the team to have each member contribute to the project team in the way that suits them best.
3. Process–focus on results, in particular, delivering finished value often., rather than getting the process down perfectly.

In the next post, I will discuss the characteristics of servant leadership that allows project leaders to become more agile.

Filed under: Uncategorized | Leave a comment »

I’ve been going through the Agile Practice Guide and I’m excited about starting chapter 4 today.   Why?

Well, the first three chapters were, respectively, an

• Introduction–to the Agile Practice Guide itself
• Introduction (to Agile–showing the 4 values and 12 principles of agile
• Life Cycle Selection–comparing and contrasting agile with the other three life cycles of project management (predictive or traditional, iterative, and incremental; with agile combining characteristics of both the iterative and incremental life cycles)

With all of that preliminary material out of the way, the fourth chapter goes into Implementing Agile:  Creating an Agile Environment

The first step is to have your project team adopt an agile mindset.   There are five questions that the Agile Alliance recommends you discuss with the project team in order to help develop an implementation strategy.

• How can the project team act in an agile manner?  (review the 4 values of the Agile Manifesto)
• What can the team deliver quickly and obtain early feedback to benefit the next delivery cycle?   (This is the “incremental” part of the agile life cycle)
• How can the team act in a transparent manner?  (Is there a common space to be used by the team?  Is there a visual way such as a Kanban Board to picture the workflow, the members of the team working on various aspects of the work, and to identify barriers?)
• What work can be avoided in order to focus on high-priority items?   (This is what I call the “negative carving of the elephant” process, where you create a sculpture of an elephant by looking at the block of marble before you, picturing within the marble the image of an elephant as the final product, and then systematically carving away those bits of marble that are not an elephant.)
• How can a servant-leadership approach benefit the achievement of the team’s goals?   (This is most important for the project manager to reflect on:  a servant leader on an agile team is NOT the same role as a project manager on a traditional project team.)

This last point is so very important that the Agile Alliance Guide spends the next few pages on this.   I will devote on the next posts to the following topics contained on those pages 33-37.

• Servant leadership empowers the team
• Servant leader responsibilities
• Servant leaders facilitate
• Servant leaders remove organizational impediments
• Servant leaders pave the way for others’ contributions

This discussion of the role of servant leader in an agile environment with then be contrasted with the project manager role in a traditional project management environment.

Let us go to the next post, which discusses the concept of “servant leadership.”  It seems like a contradiction in terms to have a leader who is actually a servant.   Within this seeming contradiction, however, is the heart of what it means to lead an agile project.

Filed under: Uncategorized | Leave a comment »

I’m going through the Agile Practice Guide, and I’m about to start chapter 4 on setting up an agile environment.   Before I start on that chapter, however, I wanted to state an unusual motivation for learning about agile.

Besides being important for my professional development as a project manager, I am interested in seeing if there are agile methods that might help get our church on solid ground in terms of growth and outreach to the community.   I am the President of the Board of Trustees for my church in here in the Midwest, and about a year ago, we had a major flooding incident which created a lot of damage to the church.   We were insured, fortunately, but the process of repair and restoration took about 9 months to complete.

We JUST moved back in to our building in January, and now everybody is excited to be back and everybody wants to do a lot of different projects to get the church programs going again as they were before, and even increase our membership and outreach to the community.

So I’m reading on agile methodology to see if some techniques, such as using a Kanban board, might help us prioritize the various projects and so create a “project backlog” which we will then work on various committees, until the urgent projects are done.   Once we are “up and running” in the same way as before the flood on an operational level, then we can take up projects that try to grow our congregation and increase our links to the local community.

So using agile for our church is not really so radical an idea after all–we are a non-profit organization after all, and non-profits sometimes need project management even more than for-profit organizations simply because their resources are more limited.   I am interested in Kanban first of all, but we’ll see what other methods might be useful.

Agile is, after all, useful in a time of great change, and that is what is upon us with our move back to our building, so I hope it will be of use to us in the next few months or so!

Tomorrow I will start posting on the contents of Chapter 4 on creating an agile environment…

Filed under: Uncategorized | Leave a comment »

In the third chapter of the Agile Practice Guide, the four life cycle approaches for projects are compared and contrasted.

The first part of the chapter compared and contrasted the approaches, and the next part of the chapter went into more details for each approach.

Then the next section, which I just finished posting on, talks about hybrid life cycles which take elements of the different life cycle approaches and combines then.

This next topic in this section about hybrid life cycles goes into details about mixing or blending different agile approaches.

The example given on p. 31 is one of the most common blends in widespread use, involving each of the following three approaches:

1. Scrum–provides guidance on the use of a product backlog, a product owner, scrum master, and a cross-functional team–includes sprint planning, daily scrum, sprint review, and sprint retrospective sessions.
2. Kanban–a kanban board helps the team to further improve its effectiveness by visualizing the flow of work, making impediments easily visible, and allowing flow to be managed impediments easily visible.
3. XP–use of story cards, continuous integration, refactoring, automated testing, and test-driven development.

The blend of practices from these various produces a synergistic result of higher performance than each individual component in isolation.

The next post will discuss some of the project factors which will help you determine how to tailor the various options among hybrid approaches for your project.

Filed under: Uncategorized | Leave a comment »

This is a series of posts on the characteristics of various life cycles, based on the material in chapter 3 of the Agile Practice Guide.   The chapter compares and contrasts the four types of project life cycles:

• Predictive (traditional or waterfall)
• Iterative
• Incremental
• Agile

The first part of the chapter did a comparison between the four types.   The next part, which I’ve covered in the last four posts, goes into more detail of the characteristics of each type.   This posts goes into the section which talks about characteristics of hybrid life cycles, which is a combination of predictive, iterative, incremental, and/or agile life cycles.

There are several ways to create a hybrid life cycle.

1.Agile Development Followed by a Predictive Model

The early processes utilize an agile development life cycle, followed by a predictive roll-out phase.    This approach is used when there is uncertainty, complexity, and risk in the development portion of the project, which makes the agile approach beneficial for that portion of the project.   The roll-out phase, if it defined and repeatable, can be undertaken in a predictive team.

EXAMPLE:   Development of a new high-tech product through agile methodology followed by roll-out and training to thousands of users using predictive project management

2.  Combined Agile and Predictive Approaches

This is actually a common scenario.   Some approaches are taken from agile, such as:

• short iterations
• daily standups
• retrospectives

However, other aspects of the project may still follow predictive approaches such as:

• upfront estimation
• work assignment
• progress tracking

EXAMPLE:   When a team is incrementally transitioning to agile.

A gradual transition to agile involves adding more iterative techniques to improve learning and alignment among teams and stakeholders.   Later, more incremental techniques can be added to accelerate value and return on investment sponsors.

Usually an organization tries to transition to agile on less risky projects with a low-to-medium degree of uncertainty.   Once this transition is successful, larger, more complex projects can be tried using agile techniques.

3.  Predominantly Predictive Approach with Some Agile Components

In this case, a portion of the project with uncertainty, complexity, or opportunity for scope creep is being tackled in an agile way, with the remainder of the project being managed using predictive approaches.

EXAMPLE:  An engineering firm building a facility with a new component.   The agile component of the project deals with the new component in order to uncover issues early on while there is time to incrementally improve the process through experimentation and adaptation before it is incorporated into the rest of the facility which has been previously built before (and can therefore be dealt with using predictive approaches).

4. Largely Agile Approach with a Predictive Component

This approach might be used when a particular element is non-negotiable or not executable using an agile approach.

EXAMPLE:  Integrating an external component developed by a different vendor that cannot or will not partner in a collaborative or incremental way.  After the component is delivered, a single integration is required.

To conclude this discussion, note that project teams may design a hybrid life cycle based on project risks.   The higher the risk, the better that portion of the project is to be handled through agile methods.  The goal of project management is to produce business value in the best possible way given the current environment.

Is feedback needed from customers as the team produces value?   Then, try incremental life cycle approaches.

Is it necessary to manage risk as ideas are explored?   Then, try iterative approaches.

But, if the organization cannot deliver intermediate value (such as with construction projects) agile approaches may not be useful.   Only use agile if you need frequent customer-based delivery.  The feedback from the customer will be used to plan and replan the next chunk of work.

This post has talked about mixing life cycle approaches.   The next post will talk specifically about mixing agile approaches, and what some of the common blends are of agile frameworks used on projects.

Filed under: Uncategorized | Leave a comment »

This post is part of my notes for the Agile Practice Guide.   I have taken notes on the 4th Edition of the guide to the Project Management Body of Knowledge (or PMBOK Guide for short) in preparation for my CAPM certification in 2012; then for the 5th Edition which came out in 2012, and most recently for the 6th Edition which came out in September 2017.   I did it not just for myself, for the study group I helped run, first as an assistant to the Director of Certification when I was at the Orange County, CA chapter, and then as the Director of Certification at PMI Chicagoland when I moved to Chicago in 2013.

But with the publication of the 6th Edition of the PMBOK Guide, my notes would not be complete without my notes for the companion publication to the PMBOK Guide, namely, the Agile Practice Guide put out by the Agile Alliance in conjunction with PMI.

This third chapter of the Agile Practice Guide compares and contrasts agile with the three other life cycles for projects:   predictive (traditional or waterfall), iterative, and incremental.   I never clearly understood before the difference between iterative and incremental, or how knowing how those two life cycles work helps you understand agile, which combines features of both.   This chapter clears all of that up very helpfully, and I hope you find that it does the same.

After comparing and contrasting the four life cycles in the first part of the chapter in a more general way, the Guide goes into details about each of the four life cycles in the next part of the chapter.   I already did three posts on the other life cycles, so this post will cover agile.

Agile incorporates elements of iterative and incremental and iterative life cycles in that a) it goes through work in iterations (cycles), and b) it delivers incrementally to the customer, gaining feedback afterwards which may change the requirements.   It is used to adapt to high degrees of change and deliver project value more often.

Incremental delivery can happen in one of two possible ways so that the project aligns with customer needs.

Iteration-Based Agile

In each iteration, the timebox (length of time of each iteration) is the same size.  Each timebox results in working tested features.   So with each iteration you will have the same steps:

• Requirements
• Analysis
• Design
• Build
• Test

For each timebox, the team works on the most important feature, and collaborates as a team to finish it.  Then the team works on the next most important feature and finishes it (and so on).

Flow-Based Agile

In each iteration, you have the same steps as above, namely:

• Requirements
• Analysis
• Design
• Build
• Test

However, the timebox (again, the length of the iteration) is not the same each time, but is based on the number of features in the Work In Progress (WIP) limit.   The time it takes to complete a specific feature is not the same for each feature, and that is why the length of the timebox may differ.

The team defines its workflow with columns on a task board and manages the work in progress or WIP for each column.   Because the iteration is not a fixed length, it is important that the team and stakeholders determine the most appropriate schedule for planning, product reviews, and retrospectives.

As we head towards 2020, more and more projects are becoming hybrid projects, that is, projects that use a combination of predictive, iterative, incremental, and/or agile approaches in a hybrid approach.

The next post will cover characteristics of hybrid life cycles.

Filed under: Uncategorized | Leave a comment »