Effectively Using Product Roadmaps for Agile

What is an Agile Product Roadmap?

A product roadmap is essentially an action plan for how a product will evolve to completion. Product roadmaps can be incredibly useful to outline your product functionality and showcase a timeline for when new features will be implemented. Multiple agile teams can utilize a shared product roadmap. When employed in agile development, a roadmap equips your product with the essential framework for a team’s daily tasks and should be reactive to developments in the competing landscape.

Many agile professionals have turned to product roadmaps as a plan of action to resolve managements need for documentation but is your roadmap a valuable project tool or just a required artifact created and then cast aside? If you create it and never look at it again, then you’re probably struggling with lots of issues like missed deadlines, frustrated stakeholders, bad/slow decisions and mediocre solutions.

How does a Product Roadmap Improve Projects?

When done well, the Agile product roadmap is the foundation and facilitator of solution delivery. The process to create and periodically update the roadmap generates meaningful conversations that create confident teams who are able to meet their commitments. A good roadmap process helps teams manage expectations, facilitate decision making, and most importantly, estimate and deliver valuable solutions.

A useful and predictable roadmap requires a consistent focus on three things:

  • Transparency
  • Data-Driven Forecasting and Decision Making
  • Reflection

Agile teams who focus on transparency and engage stakeholders in meaningful discussions need to build a sturdy framework for the Agile product roadmap. The framework should include:

  • Business Capabilities
  • Technical Dependencies
  • Other Project Impacts
  • Market Events
  • Risks/schedule constraints

When teams establish this solid framework across a timeline and commit to frequent recasting, the product roadmap becomes an essential communication and trust-building tool. Leaders and stakeholders understand the product/project plan, and the team becomes confident in their ability to deliver!

To learn more about how to create predictable roadmaps and facilitate transparent conversations, join me live at IIL’s Agile and Scrum 2018 Online Conference on June 7 and on-demand from June 8th through September 10th.

PMI is a registered mark of the Project Management Institute, Inc.


Shift from PM to SM

Can Great Project Managers Become Great Scrum Masters?

Most people assume that success as a project manager will translate directly to success as a Scrum Master. But it doesn’t. Becoming a great Scrum Master requires a big shift in mindset and skillset. That shift requires project managers to leave many of their previous go-to tactics, strategies and behaviors behind.

Essentially, PMs need to “untrain” their brain and change the way they respond to daily challenges. It’s not easy. I started my career as a project manager and made the transition to Scrum Master. The concepts of agile were easy to understand and they made sense, but applying them in my work with cross-functional, self-organizing teams was difficult.

The tools and techniques I used as a PM were not easily transferable to the Scrum Master role. I had to untrain my brain and learn new behaviors. I had to change the way I supported my teams and redefine how I delivered value to my organization.

I needed to embrace the fact that I did not “own” the project. Instead, ownership and accountability shifted to the team. My new role was to facilitate and support the team as a servant leader, no longer as a manager. This took immense pressure off my shoulders, which had been unconsciously weighing me down as a project manager.

After several years of learning, failing, working, training, being coached and coaching others, I realize it was all part of the journey. It was a journey that helped me evolve both personally and professionally.

Please join me live at IIL’s Agile and Scrum 2018 Online Conference on June 7 and on demand from June 8 through September 10, to explore how PMs and Scrum Masters respond differently to daily challenges. I will run through a series of common scenarios and discuss the skills and behaviors you will need to successfully transition into a Scrum Master Role.

I Carved Out This Time For You

Has anyone ever thanked you for taking time out of your day to speak with them? I recently connected with a person who seemed almost apologetic for taking up my time, as if she wasn’t worthy of my attention. I reassured her this was not the case; I had happily carved out this time specifically for her.

The woman was taken aback—surprised that I was prepared to focus on our conversation. Her gratitude in this interaction stopped me in my tracks and has stuck with me for several weeks.

In retrospect, it seems almost embarrassing. None of us should be so busy that people have to thank us for “giving” them our time. Instead of distractions and multitasking, the people we interact with should receive our full attention. It’s the key to unlocking strong relationships.

Whether you intentionally carve out time or step into ad hoc conversations, here are a few suggestions to help you improve interactions with others:

  • Focus in: Make a conscience effort to shut down the distractions and focus in on the present moment. Being mindfully present shows you are fully connected, physically, mentally and emotionally which is important for building lasting relationships.
  • Listen: Listening to learn will give people the attention they deserve. As a result, others will feel heard and understood which will go a long way towards building trust.
  • Be intentional: Plan time in your day to explore how your attitudes, thoughts and actions can strengthen important professional and personal relationships.

I will be the first one to admit that I don’t always practice what I preach, but I do try to show-up in all situations and approach each day with good intentions. Whether we’re at work, at home, at the grocery store or out with friends, carve out time and be present in the moment.

Partnership: Moving from ME to WE

In most cases, managers and even executives don’t get to choose their partners. They have “partnerships” not because they want to, but because they are obligated by contracts or by the structure of their organization.

Here are things I hear from clients who struggle with partnerships:

  •  “I am dependent on this group (or partner) to do X, Y, and Z before I can complete this work.”
  • “This business partner is known to be difficult or challenging.”
  • “I need to work with all these different groups to get the product out the door.”

Do these seem familiar to you? If so, you might be feeling the pressure of partnership just like an organization I worked with about a year ago. They had good intentions and hired me to coach their product teams through an agile transformation.

They created collaborative working space and team members were excited. We got everyone out of their cubicles and started putting practices in place to get them delivering in frequent intervals.

However, these teams had huge dependencies on other teams throughout the organization. The teams wanted to work together, but organizational and leadership constraints made the partnerships tougher than necessary.

For example, two dependent teams worked in different buildings five blocks apart. To make the partnership successful, one team needed to move, but their leaders refused to budge. Instead, product owners had to attend 6-7 different prioritization sessions due to these “partners” optimizing their agile transformations for themselves rather than the whole of the product or organization.

On the flip side, leaders who share common goals for the good of the organization can usually find ways to build strong partnerships or turn adversaries into partners.

I am currently coaching in an organization that has discovered the value of strong collaborative partnerships. For years, they had been pointing fingers at each other—it’s the business’ fault, no its technology’s fault—instead of working together to resolve their problems.

How did they start to make the shift? All it took was two people to realize the value of “we” was way more powerful than the value of “me.”

They realized the organization would be better off if they worked together and not against each other. Once they began to build mutual respect and learned to appreciate what the other brought to the table, then they started working together to find solutions to problems. They consulted each other on decisions. They valued each other’s input, opinions and experience.

I know this sounds simple, but as adults we tend to struggle with partnership at work. Maybe it’s because the culture of the organization calls us to “take sides” or promotes competition. Perhaps it’s a matter of personal ambition or a lack of trust.

Are you guilty of not being a good partner or do you throw up roadblocks just because you can? Take a few moments and reflect. Ask yourself, “What kind of partner am I and what kind of partner do I want to be?”

The Beauty of Blank Space

I was in Portland, Oregon a couple of weeks ago attending Agile Camp 2017 Northwest. I had a day before the conference to explore and decided to go to Portland’s Japanese Gardens. They are quite beautiful and invite peace and quiet as you enter the gates.

As I hiked through the gardens, I stumbled upon the sand and stone garden. I looked at the perfect concentric circles and I wanted to grab a rake and wander through the garden, making my own circles….getting lost in my thoughts.

I opened the brochure and found the description of the sand and stone garden: “An important Japanese aesthetic principle underlying this dry landscape garden is yohaku-no-bi, meaning ‘the beauty of blank space.’ This style of garden was not meant for meditation [zazen], but for contemplation.”

Maybe my presence in this specific garden was just coincidence, but I like to think it was divine intervention. I am currently coaching a group of leaders both individually and as a leadership team. Blank space (and giving ourselves the permission to create it) has been one of the main topics during my sessions with each of these amazing leaders.

The demands of the day-to-day keep us busy, but I find the “busy” is typically tactical. At the end of the day we may feel accomplished with several items checked off our list, but did we actually take any time to focus on strategy or self-reflection?

These leaders are so caught up in the day-to-day fire-fighting mode of supporting teams, answering to their leaders, managing projects, etc., that they don’t take any time to contemplate, strategize or even self-reflect. These leaders are all self-aware that they need to take this time, yet they rarely do.

So I have posed this coaching question: “What is stopping you from taking time for blank space?” The answer every time, “Me.”

Interestingly enough, this one question and a little nudge from their coach has given these leaders the permission they needed. They have all taken time to embrace yohaku-no-bi. The result has been leaders who are more settled, organized, confident and focused on strategy. So, I will ask you the same question. What is stopping you from taking time for blank space?

The Agile Practice Guide – A Personal Journey

Agile Practice Guide
Betsy Kauffman is one of the seven authors of the Agile Practice Guide (above).

When the Agile Practice Guide writing team convened to begin our endeavor, we spent quite a bit of time discussing our target customer. We landed on our primary customer being project practitioners who support agile teams, who may be in the midst of an organizational agile transformation, or who are just curious and want a better understanding. Being a part of this team and writing this guide are near and dear to my heart because several years ago, I was our target customer. Here is my story…

I jumped directly from college into a project management role and worked my way through several plan-driven, waterfall projects as a certified Project Management Professional (PMP). I was really good at leading teams and delivering according to “the plan,” but it didn’t really feel right. I was always a bit untraditional—I just wanted to focus on pulling the teams together to do the “real” work instead of spending time on documentation, audits and stage gates. (Some of you may be shaking your heads and thinking about confessions of a bad project manager while others may be excited and can relate.)

Fortunately, someone noticed my agile inclinations and asked if I wanted to go to Scrum Master training and then lead a couple of scrum teams. Sure…why not? I was excited about the opportunity to learn something new. (FYI-I did not have a clue what I was signing up for!)

That first training was eye opening. It finally articulated and formalized several of my beliefs, but also challenged my definition of success. The concepts were easy to understand and they made sense, but applying them in my work with cross-functional, self-organizing teams was difficult. I really struggled.

The tools and techniques I used as a PM were not so transferable to the Scrum Master role. I had to “untrain” my brain and learn new behaviors. I had to change the way I supported my teams and redefine how I delivered value to my organization. The biggest challenge of all—Scrum Master training invited me to get comfortable with failure—to allow my teams to fail so they could learn and improve. This was extremely difficult for me because on “my watch,” as a PM, there was no room for failure, personally or within my teams. Sound familiar?

I needed to embrace the fact that I did not “own” the project. Instead, ownership and accountability shifted to the team. My new role was to facilitate and support the team as a servant leader, no longer as a manager. This took immense pressure off my shoulders, which had been unconsciously weighing me down as a project manager.

After several years of learning, failing, working, training, being coached and coaching others, I realize it was all part of the journey. I needed to go through it to evolve both personally and professionally.

The Agile Practice Guide offers the combined knowledge and wisdom of seven agile practitioners. Our motley crew of writers representing both Agile Alliance and PMI, laughed, cried, argued and at times wanted to kill each other in passionate support of you, our target customer.

As the guide launches this week, I’m left with deep respect for my fellow authors. The amount of collaboration between these two groups has been amazing. Several of us will be at upcoming regional, national and international conferences. Please approach us—we enjoy sharing our experience and welcome your feedback.

Is Fear Stifling Your Agile Change Initiatives?

After a particularly mind-bending week of attending the Business Agility conference, I wandered into a coffee shop while visiting Louisville, KY and stumbled upon this little gem:

If you fear change, leave it in the box.

Change is always on my mind.  I spend hours thinking about better ways to coach organizations and individuals on embracing change, making change easier, experimenting with small changes or going all in.

When people resist change, fear is usually the cement that keeps their feet stuck in place.  Fear makes people afraid to take risks, to learn new skills, to lose their jobs.

The key to undertaking any large change effort, whether it is a transformation, reorganization, or a shift in a new direction, is finding leaders (at all levels) who have the courage to support the change—typically leaders who are willing to stick their neck out, even if there’s a chance it will get cut off!

I have been coaching in several organizations and the one consistent theme I have seen regarding successful change initiatives is that they have servant leaders who drive change in a way that inspires others to leave their fears in the “box.”  These organizational “heroes” are ready to be active change agents by pushing boundaries, questioning, and helping the organization take the action needed to transform.

How can you be a heroic change agent?

  • Start by setting aside your fears about reputation, politics and yes, even job security, to do the right thing for the customer and the organization.
  • Create and overly communicate a clear, consistent message that helps everyone understand the purpose of the change.
  • Remain steady and consistent in your commitment to change through the ups and downs of the journey.
  • Recruit and bring along others willing to become change agents. Extra bonus for getting skeptics to leave their fear in the box!

Great leaders are capable of transforming their organization and its culture. Leave your fears in the “box” and be a heroic change agent who inspires people to join forces and push the organization forward!

By the way, I’m not sure what the cow in the box represents, but I will noodle on it. Maybe it will be my next topic…


Does Your Coaching Build Roadblocks Instead of Relationships?

A big part of my role as an Agile coach is guiding clients through roadblocks.  The roadblocks come in all shapes and sizes—organizational, team related and personal.  I’ve encouraged reluctant executives, pacified anxious stakeholders, and coached old-school “waterfallers” into becoming agile advocates. But the one roadblock that continues to baffle me, comes from the most unexpected place—other agile coaches!

Almost every large organization has them—individuals that preach agile values both internally and externally but at the end of the day, let politics and paychecks get in the way of good practice.

The agile coach, more than any other role, should understand the critical importance of cooperation and collaboration. They should be mindful and espouse the agile manifesto and principles, which value customer collaboration, trust and transparency.

My plea to all agile coaches sounds something like this:

  • Partner with me.  Even if I’m a consultant, rather than an employee.  Even if I’m a consultant from a competing firm. Even if my boss or client is your boss’s or client’s political nemesis.  Even if I’m on the “wrong side” of the org chart.  Even if I’m not on the org chart.  Partner with me so we can build and design an alliance that is in the best interest of the customer as a whole.
  • Model collaboration.  The best way to help your team understand the benefits of agile collaboration is to model it yourself.  Show your clients how to navigate politics, processes and hierarchies to most effectively serve the needs of the end users by modeling collaborative behavior.  Coaches should develop shared key messages that keep all stakeholders focused on delivering value and promoting collaboration.
  • Be a resource.  Agile success is measured by how well we satisfy the customer through early and continuous delivery of value.  Agile coaches, who get wrapped up in internal politics, refuse to leave their silos, or are only focused on growing their business, limit not only themselves, but also the organization’s ability to deliver value.  Agile coaches should reach out, offer support and share best practices to aid other coaches and optimize the clients’ transformation.

As agile coaches, we can’t be roadblocks to each other.  We need to be a united front on the road to agile transformation.  That unity helps our stakeholders feel confident about the changes we are asking them to make.  We need to set aside personal gain and politics for the sake of organizational success—united we stand, divided we fall.


AATC 2016: Three Takeaways from Uncle Bob – Technical Agility

“Uncle Bob” Martin, co-founder of cleancoders.com spoke at the Agile Alliance Technical Conference in Raleigh, NC on April 8. Informed by 40+ years of technical experience, his perspective on the past, present and future of our profession was obviously enlightening. Here’s what I left the conference thinking about:

Do developers need to be less “bean bag and foosball” and more “slide rule and graph paper”? Uncle Bob made a strong case for technical discipline and professional standards similar to the fields of science and engineering. He characterizes the “waterfall period” as a hazardous mix of risky methodology, a staggering increase in computing equipment, and droves of young, undisciplined developers. This combination of factors explains why the waterfall period significantly lacked the number of advancements of technology that the early period did and led to many massive failures and the complex “legacy” systems that many current practitioners complain about today.

Are developers sitting on the sidelines? Agile, according to Uncle Bob, is currently being led by project managers who are using agile principles to drive process improvements with various frameworks including Scrum. While these process improvements are a necessary step in agile transformation, they do not address technical agility. When technologists stand on the sidelines, no one advocates for technical quality and solutions suffer. Developers need to get in the game! (The leadership game not foosball!) This need for technical leadership is driving the Software Craftsmanship and DevOps movements, but we don’t want the pendulum to swing too far in the other direction either…

How can we reunite Technology and Process? When focus swings back and forth between technology and process, organizations and customers lose. Bob’s presentation reinvigorated my belief that Technology and Process must march forward hand-in-hand if we are to advance Agile principles and erase the technical debt created by generations of waterfall. This belief inspired Agile Pi to transform organizations using a balanced approach that strengthens process AND technology.

Adaptability: How do you Respond to Change?

Valuing Adaptability OVER Following a Plan

This month, we move to the finale of our 4-part agile value miniseries. How can transformational middle managers help their team Respond to Change OVER following a plan?

Planning has a place in every organization, but plans shouldn’t prevent progress, and as the saying goes, “the only thing that is constant is change.” For organizations to succeed, managers need to enable adaptability through:

  • Self Reflection. How do you handle change to either scope of work or timelines? Is your initial gut reaction NO or do you start to figure out the “cost” of the change to the project? If so, you might not be serving yourself, your team or your organization well. Middle managers should model the behavior they want to see. Help your team by showing them your flexibility and how it builds partnerships and benefits the overall organization.
  • Focusing on Value. Many organizations try to prevent changes by making it very difficult, if not impossible, to implement changes. This resistance drives many business partners to include everything in their initial requirements to avoid the pain of adding changes later. While this seems like a good idea at the time, allowing change is imperative for companies to ensure they stay focused on what is going to bring the highest value in order to compete in a fast paced, evolving marketplace. By staying focused on business value, teams might actually deliver the product or project sooner with higher value features than originally planned.
  • Rewarding Responsiveness. Make sure performance evaluations/bonuses are not tied to inflexible behavior. Reward thinking and reward change that increases value. Don’t reward those who stay “on schedule” at the expense of strategic opportunities. Again, we aren’t saying that we don’t have a plan or follow a plan with agile transformations.  We need to be able to be able to adapt and easily change the plan to respond and react to meet our business needs.This concludes our journey through the Agile Manifesto. Middle managers play a critical role in agile transformations by applying agile values. Just remember–while there is value in the items on the right, we value the items on the left more.