Servant Leadership–Empowering the Agile Team


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.

Advertisements

Implementing Agile: Start with a Mindset


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.

The Agile Church


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…

Mixing Agile Approaches


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.

Characteristics of Hybrid Life Cycles


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.

 

Characteristics of Agile Life Cycles


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.

 

 

Characteristics of Incremental Life Cycles


This is a series of four posts I am doing based on the material in chapter 3 of the Agile Practice Guide.   The first part of this chapter compares and contrasts the four project life cycles:  predictive, iterative, incremental, and agile.   The following posts go more in depth in terms of the details of each life cycle.   I have covered predictive and iterative life cycles in my previous posts; in this post I go through the material on p. 22-23 of the Agile Practice Guide.

As opposed to the iterative life cycle , with its focus on quality and getting to a single correct solution, the incremental life cycle has a focus on speed of delivery.   Many initiatives cannot wait for everything to be completed; the customers are willing to receive a subset of the overall solution and have it supplemented in future releases of the product.   The frequent delivery of smaller deliverables is called an incremental life cycle.

Incremental life cycles optimize work for delivering value to sponsors or customers more often than a single, final product.   The initial deliverables are planned before beginning the work, and that first delivery is worked on as soon as possible.

The team may deviate from the original vision of the product based on customer feedback received after the initial deliverable, perhaps a single feature of the proposed finished piece of work.

The key is to deliver a minimum viable product (MVP) to a subset of customers.   The customers can use the product and provide customer feedback, which helps the team to learn what they need to provide for subsequent delivery of the final finished feature of the product.

So as opposed to a predictive life cycle, which delivers business value only at the END of a project, an incremental life cycle delivers business value more often.

It is important to understand the iterative AND incremental approaches, because the next life cycle to be covered in this series of four posts, the next one on agile, combines elements of BOTH.