Category Archives: Agile

It is a well-documented fact that I love Agile. I blog about it, write books about it, make my kids do their chores in an Agile way… But the realities of an Agile implementation are often full of struggles and angst.

In this blog, we will address the 5 Common Frustrations of Agile teams with some tips on how to avoid.

Great Idea Syndrome or Critical Client Request

These are the ideas that come up, usually from the executive team, that can disrupt a sprint in progress. What can you do?

Have the Product Owner be the ‘interceptor’ and immediately begin flushing out requirements without involving the developers.

Be very transparent with the Executives about the current work in progress and its priority. Sometimes that will diffuse the urgency of the new request.

If it keeps happening, create a Kanban team (or just identify a single developer) that doesn’t have commitments in the current sprint that can take the one-off requests without bothering the dedicated developers.

Commitments aren’t honored

The sprint comes to an end and tickets/tasks/stories just roll to the next sprint. This is often accompanied by loads of excuses but it is demoralizing for the team and devalues the entire Agile process. What can you do?

Work on the definition of done. Does “done” mean tested and ready to deploy? (It should). If so, you might not be leaving enough time for QA so you might have to back up the ‘code complete’ timeline.

Remove distractions and disruptions. If the team is getting hit with new work, then that needs to be removed (see above).

Make sure the team understands and agrees to what ‘commitment’ means. This might start with a working agreement. Often, they aren’t aware that making a commitment means you will get it done. If they think it is okay for a story or task to roll to the next sprint, then something is missing in the interpretation of Agile and its commitments.

Check your estimating. One of the biggest problems associated with missing sprint commitments is the underestimation of how long it will take to finish a story. This is very common with Scrum teams so it is just something you work to continuously improve. Some sprints will be better than others, but taking the time to learn from and refine estimation problems will definitely help in making future commitments.

One of the foundational tools for Agile is Working Agreements. This blog will explore three uses for this power concept.

First, what is a working agreement?

A working agreement is a document of the values and behaviors that apply to a team. It facilitates great discussion about what will work for all team members. For software development teams, it could address topics such as after-hours availability, meeting etiquette, team member attitudes on interruptions, philosophical positions on accountability and more. Working agreements are powerful because they are crafted by the team, for the team. This is not management dictating terms; it is the team coming together to decide what works best for them. No two working agreements should be the same, and as team members change or teams evolve, working agreements should be modified to stay current.

Now that we know what they are, how can they help build teamwork in even the most dysfunctional team?

Facilitate Difficult but Necessary Conversations

When developing a working agreement, the team is gathered in a relaxed setting where difficult conversations can arise without drama and theatrics. Let’s talk about whether starting meetings on time is important to us. If so, we can add it to the working agreement. If there is a team member who is chronically late, then this discussion isn’t about singling them out, but rather figuring out what works best for all team members. Agile is a powerful way to do business. It is not a magic pill and it will not solve all of your problems – but it will bring them to the surface where they can be positively and proactively addressed. A working agreement is one of the tools to drive that critical conversation.

Do you want to create winning teams? Or improve already effective teams? Agile can help – regardless of what department you are in. As background, Agile is a software development methodology that uses practical tools and concepts to empower people to be more productive. Here are three tools that you can start using immediately to enhance teamwork and trust in your organization.

Working Agreement

What is it?

A working agreement is a document of the values and behaviors that your team defines for how they will work together. It is powerful because it is crafted by the team, for the team (not by management). It facilitates great discussion about what will work for all team members. It could address topics such as after-hours availability, meeting etiquette, team member attitudes on interruptions, philosophical positions on accountability and more.

How to get started:

The easiest way to introduce a working agreement at the office is before a long meeting. The meeting could be a few hours or a few days, but long durations tend to bring out the worst in all of us. Ask for five minutes at the start of the meeting to document a working agreement. Ask everyone to define the appropriate behaviors for the meeting. You may have to prompt the group with provocative questions like “Are smartphones allowed? Who is taking meeting minutes? When are break times? If everyone is not back after a break, does the meeting commence, or do we wait?” With a little prompting, a healthy discussion should take place. Write down the results of the discussion and keep the working agreement displayed throughout the meeting. If anyone violates a tenet of the working agreement, any team member can gently point out the discrepancy and the meeting can continue. This simple introduction to working agreements will allow people to become familiar with the practice and then you can apply it more broadly to project teams.

This is the final installment in our blog series “what does it take to launch a product?” If you are interested in the previous posts, we covered Product Definition, Pricing, Sales Enablement and Making Hard Choices. This blog will highlight the communication plan that is required with a product launch. Like many elements of Product Management, it requires more thought and care than might initially be expected.

Here are some tips and tricks regarding communication:

Involve Marketing

If you have a Marketing department that is separate from Product Management, include them in a discussion about launch communication. We all have our skill sets and you want the best players in the right positions. Many product managers are excellent marketers and writers, but they may not have the depth of expertise and relationships that your Marketing team does. This is an opportunity for close collaboration.

Identify your audiences

You may have several “masters” to serve and they may need to be communicated to very differently. Internally, you have to think about your sales force, executive team, customer service representatives and other company employees. Externally, you have to consider existing customers, prospects, the media, Analyst firms and possibly investors or shareholders. Each audience may need a slightly different message so it is prudent to think through this ahead of time so you aren’t left scrambling right before launch. Also, some audiences can promote your message so you want to get to them early in the process.

Determine appropriate amount of communication

How much is too much or not enough? Communication can be tricky because you don’t want to over-message something that is small, thus diluting your Marketing credibility. Nor do you want to under-message something big and miss a potential opportunity.

We solved this, like many other companies by creating Launch Levels. An “A” launch is a big deal – Press Release, videos, micro-site, sales training, etc. In order to qualify as an “A” launch, it has to be a brand new product or a significant enhancement that will drive revenue. Depending on your innovation cycle, you may only have one or two “A” launches per year.

A “B” launch is less impactful; it might be only available to existing customers, or it might be an inexpensive add-on that won’t drive significant revenue, or it might be a version 1 product that you are testing on a smaller target market before making a big splash. “B” launches will have fewer marketing assets and activities than an “A” launch but still require thoughtful consideration of content, audience and timing.

“C” launches are more like product enhancements. You definitely want to get the word out but it isn’t worthy of an Analyst Briefing or new website.

The way we manage the different launch levels is to have a Launch checklist and whether a task is required, optional or ‘as needed’ varies by the launch level. For example, in our company, a social media campaign plan is required for an “A” launch, ‘as needed’ for a “B” launch and not applicable for a “C” launch.

Have a plan

Even if your organization isn’t mature enough or big enough to have a Marketing department or need the sophistication of launches levels, take the time to craft a communication plan. It is important to let the world – or at least your sales people and prospects – know about this great new offering. If you aren’t purposeful about it, or you slap something together at the last minute, it can devalue the product and no one benefits from that!

Launching a product is a highly orchestrated effort that requires thought, planning and follow-through to be successful, but when it is successful, it is a great feeling to see your “baby” hit the market and start generating sales. There is such a sense of pride and accomplishment that comes from it. I hope every reader gets to experience that feeling. Happy launching!

This is the third in a blog series on How to Launch a Product. The first concerned defining the product, the second was about pricing and this post is all about Sales Enablement.

One of my favorite events every year is Sales Kick Off (SKO). SKO provides a great forum for sales enablement but it should be happening throughout the year and certainly with every product or significant feature launch. Let’s explore the key elements for successful sales enablement.

Use cases– this cannot be overstated. Product Management needs to provide Sales with scenarios or use cases where the product will solve a real business problem. These use cases need to be simple to understand and easy to remember. The use cases used in Sales Enablement do NOT have to be exhaustive as that would be difficult and too much for sales to digest. They need to be simple and educational. With a proper grounding in ways the product could be used, the Sales force is armed to go out in the marketplace and find similar instances or even more complex scenarios. Product Management needs to provide Sales with simple examples so they stay engaged, pay attention and remember the products capabilities when they are in front of that sales opportunity.

This is the second in a series on “What does it take to launch a product?” This blog is about pricing which is a critical exercise in the process of launching a product. The observations shared here are focused solely on B-to-B sales (business to business, not business to consumer which has many different nuances.)

Golden Rule #1: Sales cannot set standard pricing

Every once in a while, I will hear from someone that their executive team wants sales to set the pricing because they are most aware of the marketplace and the competitive pressure. And while I agree that Sales should have a tremendous amount of input in the pricing process, they shouldn’t have the final say in setting *standard* pricing. It is a bit like having the fox watch the henhouse. Anyone with a quota has different incentives with regards to pricing than someone who is objectively trying to express the business value of a product. Once Standard pricing is set by Product Management (PM), then Sales will have an active role in deals-based pricing or ICB pricing. But Standard pricing must be owned by an organization without a quota.

Golden Rule #2: PM (or Finance) should define both Published Pricing and the floor

In the b-to-b world, like most other markets, pricing is negotiated. It is often the case that you want to publish your standard pricing which is the price that you would love to get, but you understand that there needs to be some wiggle room for the Sales force to negotiate. Our experience has been that when PM sets the standard and the floor, Sales has clear boundaries that they can move within. Some skeptics will say that Sales will always go straight to the floor and that may be true but it depends on a number of factors – namely their comp plan. If good salespeople will make more money by pricing closer to the standard/published pricing, then they will. Less experienced sales people or folks who are compensated on volume and not margin will likely go straight to floor pricing. But if PM defines it, the company should still be confident that adequate margins are maintained, even at floor pricing.

By most accounts, my first experience with an Agile roll-out (specifically Scrum) was quite successful. We went from 3 Scrum teams to 12, we increased employee job satisfaction measurably and we delivered faster and more accurately than ever before. We rolled out six products in less than 3 years and that is a remarkable feat. One that I am certain we could not have achieved without moving to – and embracing – Agile. So how did we do it? What made our efforts successful when many other companies have struggled or failed? Here are my perspectives on how we found success.

Image Source: http://obdc.com/consulting-for-business-success/

Executive Sponsorship

Agile is a movement that requires top-down leadership to say ‘this is going to happen, here is why it is good and we should all start rowing in that direction.’ Without that vision and dedication to making it happen, it would have been really hard to move out of Waterfall, which had been ingrained into the workflows, processes and the very culture of an organization. But top-down isn’t enough. You also have to have a group of developers that are eager to make the change. Like most things, you cannot force people to change their behaviors if they are completely unwilling participants. At our company, we were very lucky. We had incredibly talented developers across the organization who were anxious to try new ideas and see how we could innovate. That bottoms-up enthusiasm combined with the top-down dedication gave the movement to Agile a fighting chance.

We are an Agile family. Some of our processes work better than others, in typical Agile fashion, but we aspire to continously learn and improve. Our latest family problem is chores. We have three teenagers and determining what is fair and finding a common “definition of done” is quite challenging, filled with all kinds of wonderful teenage angst. Our activities tonight are attempting to bring clarity.

Step 1: Define chores with a Definition of Done

First, we sat down with index cards and listed out the chores, one per page. Truthfully, I did this mostly on my own but I read them all to the kids to make sure they agreed.

Being a Product Manager and an Agile enthusiast, I spend a lot of time and energy working on prioritization. It is both an art and a science to make sure that you and your team are working on the most important thing. The first in this blog series on prioritization answered the question “Should we do this at all?” and the second shared different tools to help with prioritization, specifically MoSCoW and the Risk-Value Relationship. In this blog, we will tackle the Kano model, which holds a special place in my Agile story. I first learned about it when I was doing research for our Agile textbook. It then found its way into Businessolver and was a part of the story regarding how we addressed our Product Roadmap. Very cool.

Kano Model Explained

First introduced in the 1980s by Professor Noriaki Kano, it is a great tool for Product Managers to use when assessing different kinds of value. The vertical axis represents satisfaction. The higher you are, the more satisfied you are – one might say ‘delighted’ to put it into Businessolver terms. The horizontal axis represents how well something is done.

Source: Businessolver

Looking at the grey line first, these are basic needs – the ‘must haves.’ Thinking in terms of a hotel experience, we expect there to be hot water. Hot water is table stakes for a hotel experience. If you don’t have hot water, meaning the establishment didn’t do it well, then you are highly dissatisfied. However, if the hotel did have hot water, meaning they performed that function very well, it does not delight you. It is expected, so when done well, it doesn’t even register in your mind.

The blue line represents performance needs. This could be the check-in process at the hotel. It has the opportunity to dissatisfy – if the lines were long, the desk clerk inefficient or your room wasn’t ready – those circumstances could be very disappointing. Conversely if they recognize you when you walk in and you are greeted with speed and efficiency, then you might be pleasantly surprised, heading towards delighted.