Agile Project Management for an Agile World

Why a deceptively simple solution to one of Waterfall’s deep flaws makes it no match for Agile software development

Earlier this year, I had the privilege of co-presenting on Agile Software development to a group of computer engineering students at the University of Cincinnati  with our Agile Padawan, Katie Dwyer. Walking through campus was a refreshing experience. Seeing all the young faces reminded me of my college days, and the level of optimism, energy, and hint of youthful rebellion that often pervades the student population of many college campuses. Yes, even in a time of great economic uncertainty, the spark is still there!

During our presentation, I talked about some of the weaknesses of the Waterfall model and contrasted those weaknesses with the strengths of Agile software development models. At one point, I talked about how Waterfall development includes a predictive model of requirements gathering—where all requirements are gathered up front, interaction with the customer is limited, and change control processes are formalized to limit changes throughout the project lifecycle. In contrast, Agile methods allow daily communication with the customer and frequent changes with minimal constraints.

This is where it got interesting. One of the students asked me why teams don’t extend the requirements phase, to make sure they capture “all the requirements.” A valid question and a seemingly logical one, especially from a college student with limited work experience. The short answer I gave was “change,” but I’ll explain that in more detail later.

What surprises me is that working professionals, whom I assume should know better, often propose such deceptively simple solutions. For example, conventional wisdom used to dictate that if a software development project is running behind, you put more people on it to get it back on track. However, in his classic 1975 book, The Mythical Man-Month, Fred Brooks made the observation that adding people to a late project actually makes it later. Yet, I still see this practice happen today and it serves as a reminder that I often need to better understand my audience and check my assumptions at the door.

I’ll expand on why it is often rare, if not impossible, to simply extend the requirements phase to capture all the requirements. Frankly, change is inevitable, and the four forces I see creating change for software systems the most include the following (in no particular order):

1. Business processes change. Making processes more efficient is probably the most common business process change I see. For example, when a process goes from four steps to three, it often requires a change to software.
2. Market forces. The emergence of new opportunities to meet a demand and/or become more competitive drive these changes. Many times, changes resulting from market forces necessitate a change sooner rather than later and the change must be made within the context of the current project.
3. Compliance. Whether internal or external, compliance brings about change in two forms. One form includes traceability and persistence of artifacts in the system. The other is compliance to process, which is driven by a compliance mandate. Often compliance changes add “waste” or non-value added (NVA) work to a process, but are nevertheless necessary.
4. Other unknowns. Here I lump together everything from, “the technology does not exist” to “I’ve changed my mind” and everything in between.

It is highly unlikely, if not impossible, to predict the above types of change over the course of a typical software development project. Which brings me back to the engineering student and his next (and last) question, “If this is true, then why not tell the customer no when they want to make a change?”

I can think of very few reasons why anyone would tell their customer “no”. Chief among them is when ethics are brought into question. Software development organizations, both internal and external, that embrace change instead of preventing change, delight their customers by giving them what they need, when they need it.  Furthermore, organizations who are able to delight their customers in this way, stand to reap the financial rewards that come with it.

Agree or disagree? I’d like to know your thoughts.

The Kanban Board and Gemba Walk, Two Powerful Mechanisms for Agile Communication and Change

It started with a shriek.  "You have a block!” Ghesu Ndefru, one of our solutions consultants at Seapine,exclaimed as she passed by the Agile Services' Kanban board.   When I asked about her reaction, she explained that it was the first time she had seen one of our cards, which are similar to user stories, in the “blocked” column.  As I reflected on the feedback, it reminded me of the combined power of the Kanban board and the Gemba walk, that latter of which I will discuss later in the post.  For this post I refer to Kanban board, but the board discussion could easily translate into another work visualization board type, such as a “Scrum Board” for those using Scrum or a more generic form, often called a "Task Board".

Since starting with Seapine late last year, one of the most challenging concepts for me to convey to the teams here has been the value of the Kanban board, especially a physical board.  We’ve had more than a few lively discussions around its importance and value within Agile organizations.  Knowing that seeing is believing, the Agile Services team was the first to employ this type of workflow visualization at Seapine.

Kanban boards are communication tools, and are one of a class of tools called information radiators.  In other words, they radiate information about endeavors that should be providing value to the organization.  Endeavors can be either project or operations based.

In my experience, the best Kanban boards share (at least) the following characteristics:

• Updated by the team members who are performing the work
• Facilitate a sense of community when the team is performing their stand-up
• Give stakeholders a full, unobstructed view of the work at hand
• Easily accessible and not restricted by layers of security
• Highly visible
• Highly transparent
• Enable teams and management to quickly identify bottle necks in  the workflow or (value stream)
• Encourage stakholders to go to the "Gemba"

This brings me back to Ghesu and her Gemba walk.  What is a Gemba walk anyway? IT Managers Inbox describes  Gemba walks as “getting managers and leadership out of their offices and into the workplace”. I think this offers a good start, but I believe the Gemba walk should be used by more than just management.  All stakeholders should be encouraged to get out and perform a Gemba walk to better understand what’s happening within their organization.  Gemba walks often involve asking pointed questions related to the focus of the walk, such as the ones asked by my associate Ghesu, much to my delight!

Recently I performed a Gemba walk through the Marketing department.  Imagine my surprise when I found not one, but two Kanban boards up.  During my Gemba walk, I asked our product marketing manager Matt Harp and our director of corporate communications Sarah Wigser, two questions: “Why are you using a Kanban board?” and “What value has it added since you started using it?” 

Here is a summary of their responses:

Sarah: "We're using a Kanban board to help with both project visibility and  task ownership. The benefit has been that it's much easier for everyone on the team to know what other team members are working on, see status of items, and see what we've accomplished. I think it keeps things flowing and cuts down on the 'who is working on what' confusion that we were running into."

Matt: We we're looking for "light-weight project management options, or at least a base-level of status tracking".  The value has been in the helping "to illuminate what folks are working on".

 

Nico Kruger, one of our solutions consultants in Australia, noted that using Kanban boards with our customers has yielded the following value:

• It is a very easy way of managing work and having it all be visible to everyone
• You get a sense of progress as you can see what was done and what is yet to be completed or started
• It makes scope change easier to manage as people can quickly see the impact.. almost without asking
• It is easy to setup so it is a quick win for any project I do
• It also gives customers a feeling that we know what we are doing and not just starting on stuff in no real order
• Identify road blocks quickly using the visual board… it is not just a excel sheet somewhere

By the way, have you realized yet that what I'm talking about in this post also includes managing business processes, not just software development? Kanban boards (or other work visualization boards) and Gemba walks work together to help improve results and value delivery within the entire Agile organization (not just the software part).   They make it possible for anyone within the organization to contribute to continuous improvement (or Kaizen). Not the least of which is the identification of blocks or impediments and the speed at which such issues are resolved.  Adding frequent stand-ups to the process will further improve the organization's ability to deliver, but stand-ups are the subject of another post!

Do you use Kanban or perform Gemba walks? I'd like to know what you think.

Oh, and one more thing (if I may take a play from the Steve Jobs' playbook). I'm excited to announce that next month at the Agile 2011 conference, Seapine will be demonstrating an exciting new capability for the Test Track product line, related to work visualization. If you're quick, you've probably already spotted it in the post. Please stop by our booth to learn more about this enhancement. At the very least, you'll walk away with some cool swag!

 

No One Gets Left Behind on Agile Projects, Not Even The Veteran Project Manager

Last month, on April 19, I gave a talk entitled Only the Agile Survive: Understanding the Business Case for Agile during the PMI Southwest Ohio Chapter Mega Event. This was a great opportunity for me to return to my project management roots and have a discussion with my fellow PMP’s about the relevance of Agile software development in today’s fast changing world. Special thanks to PMI SW OH for inviting me to speak!

In giving this talk, I realized that while we have come a long way since the 1990’s when lean principles were first introduced into software development (in the form of Agile practices), there is still much more work to do within the project management community. With the Scrum Alliance certifying thousands of Certified ScrumMasters (CSM) and Certified Scrum Product Owners (CSPO), and all the talk of the technical aspects and benefits of Agile software development, I believe the most alienated member of the Agile project team has been the veteran project manager. I define the veteran project manager as someone with 10 plus years experience and as having been traditionally trained as a PMP or Prince 2 project manager, with little or no exposure to Agile projects.

Why do I believe this? In an Agile world we emphasize the importance of the "generalist". Team members should be able to share the load and cover for each other so they can optimize the way they self organize (which is in stark contrast to a team of specialists which has been the norm on traditional projects).  An Agile team is also responsible for managing their own work and updating their tasks accordingly.

Furthermore, Scrum has further exacerbated the problem by having become, what seems like, the de-facto enterprise Agile process, leading some in the Agile community to joke that in the end, “process and tools won out over individuals and interactions”, which is a play on the Agile Manifesto values. But I digress, Scrum is not the problem, the problem is with the way the Agile movement has been interpreted and adopted by many organizations, further discussion of which belongs in another blog post. 

In Scrum, the Product Owner role handles budgets and much of the status reporting, while the Scrum Master facilitates the team’s success by removing obstacles. Veteran project managers will undoubtedly ask themselves, “If someone from the development team is the facilitator and the Product Owner watches the budget and reports status to senior management, then what is my role?”

A sampling of questions I received from the project managers both during and after my presentation included, "(In an Agile world) what happens with fixed priced/fixed scope contracts? and “(In an Agile world) how is an SOW handled?”. These are great questions that I would expect a veteran project manager to ask and are grounded in the reality that many project managers live in. My experience has been that many organizations don’t subscribe to the Scrum model that the Product Owner maintains the budget and does a large portion of the status reporting to management. Plus, there are parts of every project that Agile delivery methods such as Scrum and XP do not address, such as Initiating or Closing down a project. Turning a software engineer in to a Scrum Master or customer into a Product Owner and expecting them to succesfully deliver a project, when both have only served in traditional roles on traditional projects, can create further problems.

The point is, veteran project managers need to find out what their strengths are in an Agile world and use them to the advantage of the Agile team.  Veteran projects managers will know from their experience, the right questions to ask to ensure project success.  While it may be a steep curve for the veteran project manager to learn how to effectively lead and contribute to an Agile team (the heart of which is learning the underlying values and principles of the Agile Manifesto), the same can be said for any team member who is new to Agile development.  

Unfortunately, many veteran project managers will not be able to cross the chasm because the paradigm shift is too great.  Through my work with APLN Houston, Agile Cincinnati, and other organizations, I have met many who fail to grasp the basic concepts.  Not because they are not able to, but because they don't want to. However, for those who are able to cross the chasm, the rewards will be great for themselves, their teams, and their companies.

In my experience, the project managers who cross the chasm the easiest are the individuals who have had experience in multiple roles (such as software engineer, business analyst, etc) prior to becoming a project manager and either worked in multiple companies or organizations within the same company. I believe this is because veteran project managers who have a broad range of experience are less susceptible to traditional project management or corporate dogma. That said, I believe any learning curve can be overcome when approached with a beginner’s mind.

If you are a veteran project manager, ultimately it is up to you to decide how vast your chasm is and what steps you need to take to cross it. If you survived the widespread downsizing brought on by the 2008 recession, then you are probably a valuable asset to your organization.  Expand your knowledge of Agile values and principles by attending local user group meetings, many of which are free (except for your time commitment, of course). Or better yet, volunteer with your local Agile group and gain the skills through practical application. Trust me, your local Agile group will be happy to have you. If management requires the adoption of Agile practices, then request the training and coaching you deserve to ensure the success of you, your team, and your company.

So take heart, veteran project manager, you have not been left behind!

Triple A Ratings Aren't Just for Bonds, They're for the Agile Product Owner Too

In talking to a potential client the other day it occurred to me how misunderstood the role of the product owner (also known as the product manager or customer) often is.  The conversation centered around their admission that a previous attempt to adopt Agile methods had been a failure.  To my delight, they were not content to cling to the often misaligned and unsubstantiated view that "Agile doesn't work here!".

As we talked, several red flags were raised that they were not aware of themselves, namely "we had too much scope creep" and "requirements weren't detailed enough".  While I raised awareness to these red flags, the one that struck me the most was the comment that "our product owner wears about 9 different hats".  As we approach the 10 year anniversary of the signing of the Agile Manifesto,  why have we not learned that the role of the customer, often played by the product owner or product manager, is central to the success of Agile projects?  It reminds me that we still have a long way to go and a lot of educating to do.

While a good Agile product owner has many traits, I like to think the best and most successful are like a great bond, and have a AAA rating.   For product owners, the triple A rating means Available, Attentive, and Amiable.  I have defined each word below and encourage you to remind your team, especially the person in the product owner role, and those in your organization of their importance.

Available

The product owner is always available. Critical to the success of any Agile project, the product owner puts a priority on making themself available to the team.  Afterall, if they are not available to the team, how can the team make sure they are doing the right work. In my experience, the organization often demands that the product owner wear many hats as my potential client observed.  This problem is often an educational issue on the part of the manager that the product owner reports too and can be remedied by having a discussion with both parties.

Attentive

The product owner is always attentive.  Critical to the success of any Agile project, the product owner handles issues, questions, and the like, expeditiously.  They don't let things lag or go unattended for an unreasonable period of time.  If you can imagine a two week long iteration where a product owner lets an issue lag by a couple of days, let alone a few hours, then that lack of attention puts the team at risk of not delivering within the iteration.  Attentiveness also assumes empowerment.  An argument could be made that empowerment is a characteristic in it's own right, but without empowerment, a product owner is worthless.  They are not able to resolve issues for the team within an acceptable timeframe because they will waste a lot of time checking and double checking.  So, I lump empowerment with attentiveness for that reason.  This problem is often an education issue on the part of the product owner and can be remedied with the product owner.

Amiable

Lastly, the product owner is always amiable. Critical to the success of any Agile project, the product owner works with the development team to achieve the best outcome possible. Certainly a friendly disposition helps, but even more important is the willingness to listen to and accept the suggestions of other team members.  My experience with amiable product owners has been that they often have the best relationships with development teams by sharing a camaradarie that less amiable product owners fail to achieve.  Development teams are often willing to work harder and go the extra distance for the amiable product owner.  Furthermore, there is no easy solution to the problem of a less than amiable product owner. Even with education, often this comes down to a personality trait that product owners either have or they don't.  This is why I recommend that organizations pick their product owners wisely.

If the importance of the triple A product owner is not understood by the affected stakeholders and the triple A product owner does not exist on an Agile project, then yes, the Agile project and possibly the organization's Agile adoption will most likely fail.  In my experience, often the benefits of adopting Agile practices are over sold and the necessary tradeoffs are under sold by many information sources. Let me say this very clearly, yes, organizations will have to give up something (such as the 9 hat product owner) in order to achieve the benefits Agile methods have to offer. 

 

Progress Metrics for Agile Projects

Back in November 2010, I wrote an eBook about progress metrics for the Seapine Agile Expedition. This eBook discusses useful metrics for Agile projects and gives insight into some traditional metrics that have fallen out of favor with the adoption of Agile methods. For more information, read "Measuring Up: Progress Metrics".

There is also a supplementary blog post on The Seapine View that talks about how to move away from percent complete. This often misunderstood and misused metric is still alive and well in many organizations today, but yields little value in the way many people think it does. Read "How to Get Away from Percent Complete" to find out more.