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.


3 Ways Managers Enable Customer Collaboration

Valuing Customer Collaboration OVER Contract Negotiation
Managers Enable Collaboration

This month, we move to part 3 of our 4-part agile value miniseries. How can transformational middle managers enable Customer Collaboration OVER contract negotiation?

Contract negotiation comes across the desk of middle managers in several ways – working with 3rd party vendors, engaging teams within the organization, or collaborating with end customers. As you find yourself in these situations, cut through the contract jargon by focusing on these three tasks:

  • Develop Shared Understanding. Do I understand the other party’s needs and capabilities, and do they understand mine? Do we both see the vision of the problem we are trying to solve? Without a common understanding and a candid picture of abilities to deliver, we set ourselves up for a contentious relationship as time goes on.
  • Establish Clear Milestones. It’s often tempting to try and define all deliverables (and the penalties for failing to meet them) while negotiating a contract. Instead of giving into temptation, consider a Deliver-Inspect-Adapt routine that allows both parties to surface the need to change quickly and collaboratively.
  • Define Success. Don’t focus on checking off contractual clauses, define success as the delivery of business value with quick validation. If we can talk to one another as though we are on the same team, we can deliver value rapidly in a win-win environment. On the flip side, if we find that we can’t work together, we can quickly and mutually agree to discontinue the relationship without the need for any prolonged contractual maneuvering.

The manifesto does not ask you to abdicate your responsibility to “protect the organization” when working through contracts. Instead, it encourages us to focus on the conversations and understanding that will lead to working relationships that drive business value.

3 Ways Managers Enable Working Software

Valuing Working Software OVER Comprehensive Documentation 
Managers Enable Working Software Over Documentation
This month, we move to part 2 of our 4-part agile value miniseries. How can transformational middle managers enable Working software OVER comprehensive documentation?

As a manager, your job is to pave a smooth and gentle path for your team. Excessive documentation is a huge barrier to success, especially when it provides ZERO value to the customer! Here are 3 ways you can demonstrate the power of working software OVER documentation:

  • Create partnerships. Work with groups who require documentation (audit, security, PMO) to understand their needs. Help them understand how your teams operate. Work together to streamline and produce valuable documentation.
  • Align metrics. Metrics like number of defects opened (for testers) or number of defects closed (for developers) are counter-productive to the overall goal. ALL team members should have the same goal: produce valuable working software. Metrics should align with this goal in a way that increases cooperation, efficiency and value to the customer.
  • Modify status reports. Work with stakeholders, project managers, etc. to remove status reports focused on % complete. Working software is either done or not done–there is no 50% or 75% in agile! Instead report on the amount of business value delivered in the form of working software.
The manifesto does not give you permission to eliminate all paperwork, but encourages you to question the value, level of detail, and format of every “required” document.