Agile in Practice

I've been a project manager/program manager and have taught project management and program management since 1992. I have the gray hair to prove it.

One of my secret tools was timeboxing. Oh, it wasn't such a secret, because I asked people to timebox their work. I timeboxed my work. I taught about timeboxing. I found that limiting the time that people worked on a task helped them focus. 

I am not talking about hacking 20% off a schedule for people to feel "pressure." I've never found that to be useful. But using timeboxes? Wow, so useful for me. 

Here's how I have used timeboxes:

1. When I have work I don't know how to start. Have you ever wondered about a specific task you need to do? You sit there and say, "I have no idea how to start this. Maybe I should check email." I use a 10-minute timebox to gather myself and write down how I could start this work. I limit this timebox to 10 minutes because I want a long-enough period of time to make progress and short enough period that I can see where I am at the end.
2. I find it helpful to reflect on my work every so often. I like to think about how I can work better. I happen to use a one-week timebox to reflect back on the previous week and plan my next week's work.
3. When I have deliverables at a certain time. I have clients, books, and teaching deliverables. Yes, I have more than one project underway at all times. That's because I'm a consultant. I create small timeboxes to make progress on all my work. I work on one thing for an hour, get that piece to done, and decide what to do next. While I am in that timebox, I concentrate on just that work.

You'll notice I haven't said anything about "agile" here. Agile uses timeboxes for many things, including my examples. 

When a team doesn't know how to start, they do a spike. The entire team learns together, for anywhere from an hour to a day. The team decides on their timebox and understands what the rest of the deliverables are by the end of the timebox.

Many teams use two-week iterations as their team cadence. They have a rhythm for demonstrations and retrospectives. They do exactly what I do: reflect and use their current data for planning the next chunk of work.

I prefer that teams work on only one project during an iteration. For many teams, this is impossible. In that case, I ask the Product Owner to make sure the features are small, so the team can see the flow of work (that they make progress all the time) and that they manage the interruptions. 

Timeboxes are not new to agile. They are an old project management "trick" or tip. 

If you find yourself under pressure, consider your deliverables. What can you focus on now--and not interrupt yourself for a short time--to then deliver? You have found the secret: deliverables in short timeboxes. 

Regardless of your project approach, consider timeboxes in some way. You don't have to be agile to use them. And, if you are agile, maybe explain how you use timeboxes. Maybe I can learn from you!​

Now that the agile movement has expanded to larger organizations in more industries, we’re seeing a lot of variation. Granted, we’re used to a variety frameworks, techniques, and methods in use, from XP to Scrum to Kanban to Continuous Delivery. However, lately we’re hearing more and more about the use of “Hybrid” approaches.

Maybe you’ve heard an executive say “we’re not agile yet, but we’re using a hybrid approach”. Or maybe you’ve heard some consultant proudly declare “unless you do lots of prototyping, you’re only hybrid agile”. And then at the meetup you hear another person say “Oh, we’re not hybrid, we use a blended approach”.

With all this chatter, it can get pretty confusing as to what people actually mean. Those of us working on the upcoming Agile Practice Guide have heard this chatter too, and we’re adding a dedicated section to the guide focused on this topic. Here are some of the initial patterns we’re seeing...

“Iterative” vs. “Incremental” vs. “Agile"

Project lifecycles live on a continuum, ranging from Plan-Driven on one end to Agile on the other end. To help us understand this continuum, let’s say two of the key aspects of agility are “Deliver Early and Often” and “Adapt to Change”. If we were to plot that on a two-dimensional graph, we would get something like this…

On the continuum from Plan-Driven approaches (lower-left) to Agile approaches (upper-right) there are different degrees of delivery (incremental) and degrees of change (iterative). Those techniques that achieve BOTH high degrees of delivery AND high degrees of adaptability are called “Agile”.

“Blended” versus “Hybrid”

But that’s just too simplistic. In the real world, we don’t just use one approach; we almost always combine different techniques together. To help us understand the different combinations, we’ve settled on some working definitions.

Blended Agile is the combination of two or more established agile methods, techniques, or frameworks.

That is,  adding some Kanban and wip limits to your Sprints would be a “Blended” approach.  Or maybe you want to “blend” an information radiator with your continuous delivery status. For many of agile practitioners, that’s easy to understand. We combine known adaptive-aggressive techniques to be better at what we do:

Blended = agile + agile = better agile.

But what about the rest of us who are mere mortals? What if we’re not able to use these various techniques just yet? What if there are either constraints or demands that require some non-agile elements to happen? Well, in those cases, you should consider the “Hybrid”:

Hybrid Agile is the combination of agile methods with other non-agile techniques

For example, a detailed requirements effort, followed by sprints of incremental delivery would be a “Hybrid Approach”. Likewise, frequent iterative prototyping of a design, followed by a single plan-driven implementation would be a “Hybrid Approach”. Here, the idea is to take a non-Agile approach and inject some Agile techniques to address a specific issue or opportunity:

Hybrid = non-Agile + Agile = something in between that makes sense

When should we use Hybrid approaches?

Just like anything else in the world, there is a right reason and a wrong reason to do something. To be clear, the wrong reason for mixing techniques together is to keep up with the Joneses. “Doing agile techniques” is not the goal. The goal is to deliver the right business outcome using the right techniques.

Here are two scenarios.

1. Hybrid as Fit-For-Purpose: For projects that have a lower risk profile, use Plan-Driven approaches to look for lower costs. For higher risk projects, use Iterative techniques to repeat activities until issues are revealed and resolved. For projects needing aggressive delivery, Incremental techniques will deliver something sooner, to ensure customer engagement. Finally, in order to to navigate complex environments, Agile techniques may have a higher initial overhead, but it might be worth it for the overall outcomes. Each has their own strength. Mixing these together in the right way can fit your context better than just narrowly using only one of them.
2. Hybrid as Transition-to-Agile: Many teams are not able to make the switch to Agile ways of working overnight. The larger the organization, the more move parts, the longer it will take to shift. If you’ve lived in a Plan-Driven world for several years, then agile methods will look and feel very different. As a result, your initial foray into the agile world will be a messy amalgamation of both.  That’s okay. You’re using specific techniques to move in a direction that you want to go to.

Every project has different needs. For those finding themselves in a mostly plan-driven environment, a hybrid approach can be a transition to more adaptability and delivery. For those already delivering and adapting aggressively, blending in some new techniques can raise your bar even higher.

Don’t simply declare “we’re Agile”; the reality is you’re almost always using some combination of different techniques already. Instead, a better strategy would be to stop and think which approaches would be the best for where we are, and what we want to achieve.

This post recounts a working group session held on September 25th at the PMI Global Congress conference in San Diego and its main findings. The workshop was an opportunity for conference attendees to learn more about the goals and objectives for the Agile Practice Guide and provide their suggestions for content and list what questions they would like the guide to answer. 

The session was well attended with over 60 people contributing their ideas for the guide and once all the information had been collated, it filled over 30 typed pages of ideas, suggestions and questions for the core team. We will review some highlights from the presentation and the top topics, ranked by popularity.

We started the session explaining the inputs and constraints that govern the creation of the Agile Practice Guide. The guide is an important new collaboration between the Agile Alliance and the PMI that brings content from both communities and existing publications. After collecting this content, it then needs filtering and constraining to meet the requirements of a PMI standards publication for naming conventions and alignment with other guides, etc. This process is illustrated below: 

The timing of the congress was perfect for providing inputs to the core team who are working on the guide. It came about 30% into the “Working Draft Development” activity and the results of the workshop have been passed to the core team who are busy writing chapters of the guide at the moment. After creating the first draft, the upcoming activities include Editing and Subject Matter Expert (SME) Review. These activities and the overall publication timeline are shown below:

At the workshop the participants were engaged in groups to generate ideas, discuss them within their group and then create peer-validated lists of their highest priorities. Working in timeboxed iterations three topics were explored. These were:

1)    What topics you would like to see covered in the new Agile Practice Guide?
2)    What PM roles stay the same and what changes when using agile methods?
3)    When using hybrid or agile approaches what problems have you seen and what are some solutions to these problems?

The Results
As mentioned earlier, the results of asking these questions were prolific and wide reaching. However, some topics bubbled to the top as we group the suggestions based on frequency of occurrence, these are listed below:

1)    Popular topics for inclusion in the guide:

• Clarity around roles, responsibilities
• A common terminology
• Understanding the range of agile tools, techniques and approaches and their application
• Guidance on how to develop hybrid approaches
• Information about how to help their organizations transform
• Tools and techniques for estimating costs and measuring performance 
• Organizational considerations associated with portfolio management, PMOs and enterprise scaling 

2a) PM roles that stay the same:

• Overall accountability for project
• Interface with executives related to project (i.e., change control negotiation, reporting)
• Some level of planning responsibility
• Some level of leadership, people and resource management responsibility
• Some level of fiscal authority/responsibility

2b) PM roles that change:

• Servant leader rather than controller
• No longer assigns tasks or designs workflows
• Some responsibilities associated with facilitating communication/negotiation
• PM processes adapt using new agile approaches

3) When using hybrid or agile approaches what problems have you seen and what are some solutions to these problems?
Problems seen:

• Insufficient flexibility
• “Command and control” remains
• Inconsistent application of agile methodology/combining incompatible approaches
• Ineffective change management

Potential solutions:

• Agile mindset versus practices
• Access to training/coaching
• Effective change management
• Quality assurance associated with use of/adherence to practices

Obviously in a post like this we can only share the tip of the iceberg of suggested topics for the guide, but hopefully it illustrates the type of guidance being sought by some of the community. The session was very valuable for us as the core development team and we would like to thank again everyone who participated.

Recently, a team of practitioners with a variety of backgrounds, experiences, beliefs, and cultures has come together to collaborate on an Agile Practice Guide sponsored by the Agile Alliance and Project Management Institute for publication in 2017. We are unique in that we represent what are considered very different organizations with dissimilar, even opposing, mindsets tasked with coming together in agreement. We have also learned that we all have the same outcome in mind - to provide both communities with something special. A useable guide that provides practitioners greater understanding of the applications of agility. An understanding as to the components in Agile that enables a shift in projects, programs and organizations to move further along the path of agility where beneficial... 

Agile Practice Guide Team Vision: Enabling better results by equipping practitioners to become more agile and integrate additional tools through the application of situational guidelines.

Why is this important?

It's important because we need to build a bridge between the communities of the two organizations and learn how to support each other. We need to become servant leaders and walk the talk. We, our communities and practitioners, often talk about PMI and the Agile Alliance as opposing organizations, like we are political parties with completely opposing views. Like we are engaged in a battle for what is right or wrong in totality. In actuality, neither is completely right or completely wrong in and of itself. We and our communities of practitioners make it so by our words and actions. Both communities have within their DNA the relentless drive to deliver value and quality, to communicate openly and take the high road to resolution. Yet, there is tension and a belief that "we are better than them" but who is "we" and who is "them"? And what does “better” mean in this context?

We often discuss Traditional Plan-driven and Agile methods as if there is nothing that joins them together. As if they are absolutes and there is nothing in-between that may provide a pathway to moving between them. This is incorrect and in actuality there are far more projects, programs and organizations in the middle using a blend of methods. These are a hybrid of Plan-driven and Agile methods, frameworks, tools and mindsets. Hybrid is a much broader representation of what is truly happening in most businesses rather than what is at either end of the spectrum.

The Agile Practice Guide is a collaborative effort to facilitate a more holistic and inclusive view and we would like to ask you, the members of both communities, to assist us in getting there. We will be blogging on many of the facets of this guide and we’re asking for your thoughtful feedback. Please join us in building a bridge to shared understanding. We believe this Agile Practice Guide will help many of us to accelerate our journey to excellence.