5 Best Practices of Successful Executive Sponsors


Exec Sponsor









It is well know that executive sponsors can help a project to be successful, but not all projects with an executive sponsor succeed.

Why don’t they?

It is because there isn’t necessarily a training manual for how to be an executive sponsor or what pitfalls one must avoid.

So, how do you become a successful executive sponsor?

Build Trust & Communication

While the project manager is responsible for ensuring that the necessary work is being done so that a project will be successful, an executive sponsor’s role is to ensure the project is successful. While those may sound like the same thing, they are vastly different.

The project manager must focus on the day-to-day execution, while the executive sponsor should focus on the bigger picture, ensuring that the project stays aligned to the strategic goal and is being supported by other stakeholders and removing roadblocks.

In order to do this, the executive sponsor and project manager must have a candid relationship built on trust. Too often projects fail because people tend to hope for the best-case scenario and rely too much on best-case status updates. The communication between project manager and executive sponsor should be about openly discussing risks that the executive sponsor can help the team navigate.

Make Realistic Commitments

It goes without saying that commitment is a key component of being an executive sponsor, yet countless projects that have executive sponsors fail nevertheless. This isn’t to say that the failure is necessarily due to the executive sponsor, but as obvious as the importance of commitment is, there are many cases where the executive sponsor had an unrealistic expectation of their commitment. According to PMI’s annual Pulse of the Profession survey, one-third of projects fail because executive sponsors are unengaged.

Sometimes this has less to do with the individual and more to do with the organization. As more and more studies come out showing how executive sponsors increase the success of projects, companies want more executive sponsorship of projects. This has led to many executives being overextended across too many projects.

Before taking on a new project, sit down and determine the required time commitment and whether you have the bandwidth to meet that commitment. Your organization may be pressuring you to step up and take another project, but it won’t do them or you any good if the project fails.

Avoid Getting Overextended

We already discussed that the success of having an executive sponsor has led to many organizations overextending their executives. An in-depth study by the Project Management Institute found that executives sponsor three projects on average at any one time and they report spending an average of 13 hours per week per project, on top of their normal work.

Obviously, this isn’t sustainable and isn’t a recipe for success. The same study found several negative impacts from executive sponsors being overextended.

Project Mgt Statistics








The solution here is simple; you have to learn how to say no. That is, of course, easier said than done when you’re being pressured to take on a new project, but again, it won’t do them or you any good if the project fails.

Develop Project Management Knowledge

According to a PMI study, 74% of projects are successful at companies where sponsors have expert or advanced project management knowledge. Unfortunately, only 62% of companies provide executive sponsor education and development. Not every executive has necessarily been a project manager or gone through project management training.

The results speak for themselves; having advanced project management knowledge makes it far more likely that you will be successful. If your organization doesn’t provide executive sponsor development, take it upon yourself to become a project management expert. It will help your team, company and self. The Boston Consulting Group has found that successful executive sponsors focus on improving their skills in change leadership, influencing stakeholders and issue resolution.


I hope this has inspired you to develop your executive sponsor skills. While it may be difficult to find the time, the payoff will be well worth it for you, your team and your company!

What are some other important keys to being a successful executive sponsor?

Posted in executive sponsor best practices, Uncategorized | 1 Comment

Sketch Your Way to Faster Consensus and Better Products

This meeting is a waste of my time. When was the last time you had that thought? Was it because the conversation wasn’t focused, or people couldn’t agree, or maybe they were in violent agreement, but couldn’t see it?

We recently spoke with Jeremy Kriegel, an independent UX consultant, at Agile Day Atlanta, about a sketching technique you can use to get your meetings back on track, get to consensus faster, and deliver better products.

VersionOne: Why is sketching so important to agile teams?

Jeremy: It’s not so much about sketching per se. It’s about moving agile teams forward and getting to decisions faster. Sketching is one great way to do that, because people think in multiple ways. When you’re just talking, it’s just words and concepts, but when you add pictures, the communication becomes a lot clearer.

VersionOne: How do you respond when people say “I can’t draw”?

One of the barriers to doing sketch facilitation is that most people think they can’t draw. They’re thinking about sketching in terms of creating art. There’s a difference between sketching as art, and sketching as communication. When you’re sketching as communication, you only need some rudimentary drawing skills and a few basic techniques in order to communicate an idea and collaborate with people.

VersionOne: Are there any particular sketches or symbols that would be helpful for people to learn? Or do people just need to get over worrying about whether or not their sketches look good?

Jeremy: It’s a little bit of both. In my workshops, I start out by showing a beautiful wireframe that I found online that has crosshatching and perfectly straight lines that looks like someone took a lot of time and effort to create. Most people would agree it’s a beautiful sketch, but it takes a lot of time, and you just don’t have that kind of time in a meeting. Then I show people my version of that same wireframe, which is a really messy, squiggly, drawing, but it has all the right elements. That’s the first time people start to go, “Oh, I could do that.”

Then I start to break it down in terms of showing them a screen, like a regular web page, and say, “Okay now here’s a sketch version of that screen. Look at the elements and just draw a bar for the navigation bar and box with an x in it is an image place holder, etc. When they see it step by step, I think it starts to make sketching more comfortable.











Once I’ve demonstrated a number of techniques on how to represent text, people can start with very basic sketches with a couple of squiggly lines representing a line of text or a paragraph. Then they can move on to more advanced sketches that include details on different content, like a product description or directional text like “sign up for a newsletter” or “buy our product now,” to give people a better idea of what the content is intended to be.

The bottom line is if you can draw a straight line, a circle, a squiggly line, and the alphabet, that’s really all you need in order to do sketching for communication.

The next step is to break down this barrier between what they think they can do, and being able to do it. I start with a fairly simple webpage and give people a minute to sketch that page. Then I show them more complicated page and give them a minute to sketch that page. Then I show them a mobile app, and give them a minute to sketch that. That way they get some practice sketching different types of pages and content, and they have to do it really fast.

The point of sketching quickly is not to prove how fast you can go, but if you’re trying to facilitate a group discussion, the ideas are usually coming fairly rapidly and you have to be able to keep up with the conversation. This also helps you move away from this notion of being perfect. You just don’t have time to be perfect when you’re trying to capture a lot of input quickly.

Now that they’ve copied a few pages of sketches, then I ask them to take a common page type that they’re all familiar with, typically an e-commerce check out page, and sketch that from memory. That way I can ease them into the process from seeing what’s involved and seeing some examples, to sketching a page in front of them, and then creating their own sketches. That starts to get people over this fear of sketching.

In the last exercise, I ask people to pair up. One person plays a product owner and the other person plays the graphic facilitator. The first half of the exercise the product owner says, “We’re going to complete this checkout process. Here’s what I need on my shipping page.” The sketch facilitator visually captures the input in words to make sure they have their shared understanding of what they’re going to design. He captures the words that product owner is saying and writes the words down so the product owner can see and agree to them. Once they’ve done that they’ll move on to sketching with the sketch facilitator driving with input in real time from the other person. Then they’ll switch roles and go through the exercise again.

VersionOne: Have you seen examples when a team is having a difficult time communicating and then they start sketching and everything becomes better?

Jeremy: In my almost 20 years of being in this industry, sketching is one of the most powerful tools to help move teams forward quickly.

Years ago when I was at a big agency we always kicked off projects with these big workshops with stakeholders. We always took notes on the whiteboard, so that all the stakeholders and the team members could see, and agree, on what was being discussed. If people see the input in real time you can avoid issues later. If someone disagrees with something that you’ve written, they’ll say it right away.

Sketching saves a lot of back and forth time. You can discuss conceptually what you’re looking for, and then collaboratively visualize the project.

I’ve really seen the difference when I’ve worked with other teams where either no one was taking notes or someone sent notes in a follow-up email that no one actually looked at it.

VersionOne: Do you have any advice to help people get over their fear of sketching in front of a team?

Jeremy: Many people are nervous about getting up in front of their team, and doing something new. To help them get over this fear, I suggest that they try progressive desensitization. It’s a technique that people might be familiar with if they, or someone they know, is afraid to fly. The airlines have these programs that you can go through to help you get you over that fear.

The first step for someone who is afraid of flying might be to just drive by an airport. They know they’re not going to go in and they might feel a little anxious about it, so they just drive by an airport until that feels comfortable. Then they’ll go into the ticketing area. They know they’re not going any further, and they can just go in until that’s comfortable. They might come in and leave the first couple of times and might not go in any farther. When they’re comfortable in the ticketing area, they might go through security, and go to a gate. They’ll do that over and over again until they’re comfortable. Then they eventually feel comfortable to fly.

I suggest a similar approach with sketching. The first step could be taking notes privately, just so you get a sense that you can keep up with capturing the conversation. Then when you feel like you are getting good enough at that, then get up and take notes on a whiteboard that everyone can see, but maybe you don’t try and facilitate the meeting. Once you feel comfortable with capturing the conversation it will naturally progress to facilitation. People will look to you as the leader, and you’ll be able to take on more of a facilitator role. One of my caveats is you have to be aware of the power of the pen, because it’s very easy to control what gets captured if you’re the one writing it down.

Another way to get there is to fake it. There’s research around the impact that power poses have on your state of mind. Putting yourself in a confident pose will make you feel more confident. I demonstrate this by having people sit with their legs together, their knees together; their arms crossed, and put their head and chin in their chest. I ask them to get really small and whisper to themselves, “I’m a rock star.” People giggle a little bit, because it’s funny, you don’t feel like a rock star when you’re small like that. Then I have them stand up, and put their arms in the air, or stand in a Superman pose, with their hands on their hips, lift their chest up, hold their high, and say, “I’m incompetent.” Of course everyone laughs, because again it doesn’t work. Your mind wants to mimic the position that you put your body into.

Even if you’re a little bit nervous, just walk confidently to the front of the room with your body language saying you’re going to take charge and you’re going to be responsible for the team getting something done today. Then it’ll happen.

Click here to learn more.

Posted in Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, collaboration | 2 Comments

3 Keys to Mastering Responsibility

Far too many good, motivated, hard-working people get stuck in jobs they don’t want, projects gone bad, work problems and careers they don’t enjoy. It happens to individual contributors and it happens to leaders.

We recently spoke with Christopher Avery, the CEO of Partnerwerks, Inc., at Agile Day Atlanta, who shared the three keys to mastering responsibility and achieving much greater happiness, freedom and choice for yourself and for your team.







VersionOne: Why is mastering responsibility so important?

Christopher: I think the main reason we should be talking about mastering responsibility is because we know that leadership is innate in all of us. It has to do with the mental process we call The Responsibility Process® by which we can take 100% ownership for our lives, situations and challenges.

The reason that we should be talking about mastering responsibility is to simply help people who may have an inkling that their lives could be better and they could do something about it.

The other reason we should be talking about mastering responsibility is that people who practice this process, start enjoying greater fulfillment, lower stress, and higher engagement. They start applying this to self-leadership in their own lives, as well as use the tools to create better teams, better organizations, better cultures, and respond much more successfully to change.

The third reason is that the research on The Responsibility Process is only three decades old and not widely known.

VersionOne: Is the outcome of The Responsibility Process that people discover their passion and end up with a renewed focus on what they’re currently doing?

Christopher: Part of the process of taking responsibility has to do with understanding your own inspirations, desires, dreams, and your own definition of who you are when you’re most fulfilled. The other is true also. You may simply find profound acceptance in the life that you have.

One is an acceptance that what you’re trying to do or be isn’t who you are. The other is an acceptance that it is exactly who you are

The Responsibility Process is a framework for how we process thoughts about stuff going wrong in our lives. If we get good at the framework, then we can use it as a GPS to steer us towards greater fulfillment. If we’re not good at this framework, then we end up getting stuck.

VersionOne: What problems are typically driving people to contact you to find out about the responsibility process?

Christopher: The majority of the people who contact us are in a leadership positions who are feeling somewhat trapped and they don’t know how to get un-trapped.

The have the responsibility process in them. My process is to simply recondition them on how to think when they’re experiencing a problem, so they will get stuck in those mental states less often and for shorter times. They’re able to think more clearly about what they want and what the next steps should be.

Click here for learn more about The Responsibility Process.


Posted in Agile Leadership, agile program management, Agile Teams, Uncategorized | 1 Comment

What Kind of Agile Are You?









As many as 94% of organizations are practicing some form of agile according to 9th annual State of Agile survey™, yet I have first-hand experience seeing countless organizations that aren’t doing agile right, aren’t getting the maximum benefits and are just taking a superficial approach.

So how can you tell if your organization is doing agile right?

The Top 1% of the Top 1%

There is a vast difference between the way Olympic sprinter and world record holder Usain Bolt approaches his goals and how an everyday person trying to lose weight by running approaches their goals. Usain Bolt is the elite of the elite, in the top 1% of the top 1%. His approach to training is irrelevant and unrealistic for an everyday person trying to lose weight.

Your organization isn’t like an everyday person trying to lose weight. Whether you’re a startup or a Fortune 50 company, you’re striving to be or maintain being in the top 1% of the top 1%. You can’t afford to approach anything like an everyday person. You must have the same fierce focus as Usain Bolt.

So, let’s go back to the question. What kind of agile are you, or better stated, what kind of agile is your organization? Is your organization truly agile or just superficially so?

I’ve put together some comparisons of the approaches of Usain Bolt, everyday people and agile organizations.











Usain Bolt and his team of coaches, managers and agents have a single vision—­for Usain Bolt to be one of the greatest athletes of all time. To do this he must win medals and break world records. If he is breaking world records, then everything else falls into place. Usain Bolt isn’t focused on beating the competition; he is focused on continually improving in order to break his own world records.

“If I want to be among the greats of [Muhammad] Ali and Pele and all these guys, I have to continue dominating until I retire” – Bolt










Most everyday people trying to lose weight don’t have a true vision. Yes, they wish they could lose some weight, but most everyday people don’t have the fierce focus on meeting their running goals. Nor, necessarily, should they. Most of us everyday Joes have other things to focus on like family, work and paying the bills. While our health is utterly important, it gets deprioritized because our commitment is superficial and we skip runs and sneak snacks.









Is your organization truly agile or just superficially so?

Saying you’re agile isn’t enough to be truly agile. Having teams that do stand ups isn’t enough to be truly agile. Having a Kanban board isn’t enough to be truly agile. True agile is about organizational agility and organizational agility starts with a vision: a vision from the top that is burned into the hearts and minds of the entire organization.










Your agile transformation must be aligned to your strategic goals. Both must support a single vision that pumps through the veins of your organization. If you don’t have that, then you’re just a guy running through the motions so that you feel a little less guilty the next time you have a bag of chips.









The Litmus Test

If you’re ready to face the truth and find out whether your organization is truly agile or just superficially so, try exploring the following six questions.

  1. What is your organization’s vision?
  2. What are your organization’s strategic goals?
  3. What are your organization’s agile vision and goals?
  4. On a scale of 1 to 10, how aligned are the organization’s vision and strategic goals with your agile vision and goals?
  5. On a scale of 1 to 10, how well does the organization understand this vision and these goals? This includes executives, program managers, project managers, dev managers and dev team members.
  6. On a scale of 1 to 10, how strong is the executive support of the agile vision and goals?


While 94% of organizations are practicing some form of agile, according to 9th annual State of Agile survey, I have witnessed first-hand countless organizations that aren’t doing agile right, aren’t getting the maximum benefits and are just taking a superficial approach. Don’t get caught in the trap of thinking you’re agile just because you’re doing stand ups or have a Kanban board. I hope this has inspired you to take a few minutes to really reflect on whether your organization is truly agile or just superficially so.

 What are some other ways to tell whether your organization is truly agile or just superficially so?

 State of Agile is a trademark of VersionOne Inc.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Project Management, Uncategorized | Leave a comment

Measuring What Counts: Introducing the Better, Faster, Cheaper, Happier Measurement Framework

At Ivar Jacobson International (IJI) we have been involved in many agile adoptions ranging in size from single teams to entire IT development organizations. The single biggest problem we see is organizations not understanding why they are changing the way they work – they don’t visualize the goal, set any targets, measure the improvements, nor demonstrate the benefits generated.

This isn’t a problem where an empowered team is looking to improve their own way-of-working. However, it is often a showstopper when attempting a broader adoption, such as an organizational transformation or where the team is not yet empowered.

The key here is to establish a set of actionable measures to drive the change and inspire the teams. These should explicitly support the principles and values being promoted and challenge the teams to improve.

In this article we will look at one way to establish a measurement dashboard to support your agile transformation.

What Should You Measure?

To gather empirical evidence of the effect of the transformation you need to have both:

  1. Measures of the improvement – measures that quantify how well the transformation is going, the amount of cultural change and benefits being generated. For the teams to be truly empowered these measures should be kept as process and practice independent as possible.
  2. Measures of the mechanisms that produced the improvement – measures that quantify what is being used where, demonstrate the uplift in capability across the agile teams, and show whether the transformation is on track to achieve self-sufficiency

These measures will complement and, in many cases, reuse the measures that are being used by the teams to drive and control their work.

In this article we will focus on how to measure the improvements. The sad thing is that there is no standard set of improvement measures that can be promoted or prescribed as suitable for all agile transformations. Each agile transformation is different; with different goals to achieve and problems to address. What is needed is a set of measures focused on the improvements that need to be made. This set of measures will need to be inspected and adapted to ensure that it continues to be relevant as the transformation progresses and the initial improvements are built on to generate more and more business benefit.

Measuring the Improvement: Building an Improvement Dashboard

Our preferred approach to establishing an improvement dashboard is to use our Better, Faster, Cheaper, Happier framework. This is summarized in Figure 1 below.

Figure 1 – The Better, Faster, Cheaper, Happier Measurement Framework

Figure 1 – The Better, Faster, Cheaper, Happier Measurement Framework










This is a simple framework that helps organizations produce a balanced set of improvement measures that are aspirational rather than operational. It is important to achieve a balance between the measures, so that you don’t increase delivery speed whilst sacrificing employee or customer satisfaction, or improve quality whilst lowering productivity.

This proven framework helps organizations to identify and implement practical measures that:

  • Focus on the real business drivers, goals and benefits
  • Measure the things that really matter – the effects not the causes
  • Show whether things are really improving – eliminating seasonal fluctuations by looking at performance over a year, not a week or month
  • Consider how people feel – gathering both qualitative and quantitative data
  • Are simple and easy to understand – not complex derived measures and indexes
  • Don’t depend on using particular processes and practices – allowing the old and new worlds to be compared
  • Have relevance to the business – clearly showing where the business would like to see improvements
  • Have targets and obvious trends – the on-going trends are more important than point measures

The result will be a set of measures and targets that everyone can understand and support.

Some Illustrative Measures

There are lots of measures that could be relevant to your transformation. For illustrative purposes Figure 2 shows a compilation of some of the measures that we have seen to be popular within organizations embarking on large-scale agile transformations. For example, when starting out nearly everyone targets on-time delivery before focusing on cycle times – as a wise man once told me less late is still late.

Figure 2 - Change Initiative Improvement Dashboard

Figure 2 – Change Initiative Improvement Dashboard











A couple of things to note about this dashboard are:

  1. This is an illustrative dashboard and has never been used in this form by any specific organization. All the customers have used some of these measures, but they have also all had their own specific measures to address their specific problems.
  2. This probably lists too many measures for use at any one time. Most adopters start with eight or so measures, which is more than adequate to cover the four quadrants. At IJI we have built up a library of more than 30 candidate measures that support common organizational goals. The important thing is to understand the goals and the underlying concerns rather than to just go shopping for measures.

The measures shown in Figure 2 are:


  • On-Time Delivery – Percentage of releases that are released on-time
  • Escaped Defects – Mass of defects that escaped from 1) development teams to acceptance test and 2) from acceptance test to live in the last year
  • Meets Business Needs – Survey of whether the customers think the software delivered met their business needs
  • Level of Priority 1 Incidents – Number of priority 1 incidents reported in the live environments in the last year


  • Time to Production – Number of weeks it takes for a project to get a release into production once the project is started banded by overall project cost
  • Decision Making – The time it takes to commit to progressing a project or producing a release from decision to evaluate the request
  • Timeliness of Delivery – Survey of whether the customers think that the software was delivered in a timely fashion suitable for their business


  • Improved Value for Money – Survey of whether the customers think that the software represents good value for the money spent
  • Overheads – The cost of non-productive work done by the development teams (such as fixing escaped defects, support, administration etc.)
  • Stabilisation and After Care – The cost of stabilising and supporting releases in the warranty period after they initially go live


  • Business Satisfaction (organisational level only) – Survey of whether IT’s business partners are happy with the service provided by IT
  • Team Satisfaction – Survey of whether the teams developing the software are satisfied with the way that they work
  • Customer Satisfaction – Survey of whether the business representatives and users directly involved in the teams’ work are satisfied with the way the teams work

It is important that all the teams, projects and programs within the scope of the transformation, regardless of their level of agility or buy-in, can use the dashboard. For example, KPN in Netherlands was one of the first organizations to use the framework. They applied it to more than 14 programs and 400 projects within their IT Innovation organization. In the spirit of autonomy and empowerment the programs were allowed to opt out of the transformation if they were confident they could meet the targets. Unsurprisingly the teams that decided to stay with a waterfall way of working showed little or no improvement across the board falling well short of the average performance in all cases. For more on the KPN measurement story see http://www.ivarjacobson.com/resources/resources/case_studies/

Getting Started

The dashboard is created through a series of short workshops where the objective is to understand the most important areas to improve, and to identify practical, intuitive measures to evidence the improvements. The people involved should include leaders, executives, customer representatives, senior managers plus other key stakeholders with a specific interest in the improvement goals and results.

The workshop helps participants to understand the business drivers, goals and needs, and set some meaningful improvement targets. It starts by simply brainstorming what the words better, faster, cheaper and happier mean to the participants focusing the conversation onto the goals of the transformation, and proceeds through various rounds of discussion, consolidation and voting to identify key areas for improvement. This helps to quickly establish what measureable benefits are expected from the transformation and makes sure that they are aligned to the business goals.

The end result is an overall dashboard containing a set of intuitive measures that support the organizational goals and present the overall targets for the next stage of the transformation. This enables everyone to see the targets, the current status, and the improvements taking effect. Typically the measures are captured on a monthly basis providing an instant feedback mechanism on the effectiveness of the approach and whether or not the desired improvements are materializing.

Wrap Up

A truly agile organization is a learning organization that is continually refining and improving all its practices. It is an organization that is focused on continuous improvement and delighting its customers.

To reach this promised land you need a laser-like focus on results, whilst not forgetting why you are implementing an agile approach. Too many agile transformations stall when they are unable to demonstrate that the new way of working is any better than the old way. The mistake they make is to think agility is an end in itself rather than an enabler for better business performance. Quantify the results you are looking for and make sure you measure the effect of the transformation.

It’s astounding how many agile transformations fail to track the benefits they are generating, and in many cases seem to leave the organization no better off than they were before. The people involved, particularly the sponsors and other executives, can also be very impatient. Creating an agile organization is not something that happens overnight. Agility is no silver bullet and not every agile team, or project, will be successful. Patience is needed to see the transformation through and reap the full benefits of agility. Measurement is needed to make the benefits visible.

In our experience the biggest benefits are achieved in the second year as agility becomes business as usual and the effects of agile working ripple through the value chain. Sadly if you don’t demonstrate how you are going to measure the improvements and make them relevant to the business you often don’t get a second year.

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Metrics, agile program management, Agile Project Management, Agile Teams, continuous improvement, Scaling Agile, Uncategorized | 2 Comments

Do You “Really” Know Your Team? How to “Turbocharge” Interactions

Have you ever stated, “I didn’t know you could do that?” If so, you were not only stating the obvious, but also exposing a flaw in team formation. What would the result have been if you had known this characteristic about your teammate earlier?

Agile recognizes that people are unique individuals, instead of replaceable resources, and the highest value is achieved through interactions. People have unique physiognomies, however there are also internal characteristics such as motivational gifts, natural talents, learned skills, developmental environment, and personal passion, which can provide a much richer team experience.

Discovering these individual talents and sharing them at the team level can turbocharge interactions and lead to higher productivity. Here is an activity I have used with many people which is designed to expose these characteristics and facilitate better conversations.

Create a Personal Purpose Profile (PPP)

PPPStarting at the Individual level, each person creates a Personal Purpose Profile (PPP) or triple P. The triple P helps people understand their uniqueness in light of the five areas of focus. Each area reveals a different aspect of individuality and presents opportunities to connect with people.

Write PPP at the top of a paper and get ready to create a deliverable which will be a panoramic look at your life. It can be text-oriented or graphical, black and white or more colorful.

Motivational Gifts
PresentThe first area is to determine your motivational gifts. This will help develop understanding and relevant perspectives as a foundation for interaction.

In researching how people communicate and collaborate over 25 years, there are 7 responses or motivations that are regularly displayed during events, scenarios, or interactions. In addition, these reactions show up in people from an early age more like a gift rather than learned behavior.

Each person will typically have one main motivational gift, but can demonstrate some or all of the 7 gifts outlined below. This helps answer “Why don’t others see things the way I see them?” Here is a working definition – an individual’s first reaction when presented with an event, scenario, or interaction.

The 7 gifts and brief definitions are as follows:

  • The Perceiver sees life as all or nothing, right or wrong, and there is no gray area.
  • The Servant seeks to help with any situation.
  • The Teacher desires to share learned information.
  • The Encourager wants to give courage to people.
  • The Giver looks to invest time, talent, and money.
  • The Ruler understands the big picture and needs to control it.
  • The Compassionate is sympathetic to people’s issues.

Do any of these sound familiar? Take a few minutes to examine these gifts and make a few notes, drawings, or doodles on the paper, which identifies your top motivational gifts.

Natural TalentsTalent

The next portion of the triple P is natural talents. These are talents that have been a part of you for as long as you can remember. For example, some people are talented in a form of the arts like drawing, dancing, singing. Others might have outstanding academic aptitude in math or science, etc.   Others may have outstanding athletic ability in a sport. Statements like “you are a natural” or “this comes easy for me” will help to illuminate these as you think about them.

Take a few minutes to continue your triple P by documenting any of your natural talents.

SkillsLearned Skills

Next, is the area of learned skills. During life, there are many opportunities to gain knowledge and occasionally these will develop into valuable learned skills. Examples of these are computer skills, language skills, team skills, and even agile skills. Skills can be learned formally or informally and validated by degrees, certifications, or accreditations. Learned skills might listed on a resume or CV.

List your learned skills on your triple P.

Developmental EnvironmentGlobe

Each person was born and raised in a particular part of the world with it’s own culture, language, food, clothing, and overall lifestyle. These make up a developmental environment. Although it might not be where you are living today, the background will potentially influence your interactions with others.

Look back into your past and write down some of the things that describe your developmental environment.

HeartPersonal Passion

In our busy world, there are many activities that consume time. Most of these are “need to” type scenarios, however somewhere in the 3D arrangement of life is a personal passion waiting patiently to be done.

This could be called a hobby or form of relaxation. However it will usually be related to the question: What would you do if could do anything in the world? Examples could be spending time with pets, athletics, social endeavors, kids, community, etc., etc., etc.

Now that you are dreaming of doing it, draw a picture or write a story about your personal passion on your triple P.

Share Your Uniqueness

Celebrate how unique you are and start sharing your triple P. Don’t wait for someone to say, “I didn’t know you could do that?”  Start with your co-workers and begin to recognize the benefits of knowing your team better. With each passing day, there are interactions that could be improved if the participants knew more background information. It’s amazing how the smallest piece of information can spark a large conversation leading to enhanced communication and collaboration.


Agile recognizes that people are unique individuals, instead of replaceable resources, and the highest value is achieved through interactions. Creating and sharing a Personal Purpose Profile (PPP) containing motivational gifts, natural talents, learned skills, developmental environment, and personal passion should be a part of your agile transformation activities.

It’s time to have a team meeting and turbocharge your interactions.

Find out how VersionOne can support your turbocharged teams. 

versionone-coaches-kelly-keyAbout the Author
Kelly Key
SAFe Agilist, PSM1, MOL, PSD

Kelly has more than 25 years of experience in the software industry and 19 years working with agile practices. As an agile program manager, ScrumMaster, agile coach, and VersionOne administrator, Kelly has helped create successful products in the desktop, dot com, and mobile space for the airline, hotel, rental car, rail and cruise industries. As a thought leader, he is always looking to refine processes with continuous improvement while stimulating innovation.


Posted in Agile Adoption, Agile Coaching, Agile Development, Agile Leadership, Agile Management, Agile Methodologies, Agile Teams, Agile Training | 1 Comment

ScrumMaster: Servant Leader or Secretary?

SecretaryIn Certified ScrumMaster (CSM) courses, many Scrum myths are busted. One such myth is that the ScrumMaster is somehow an administrative assistant to a development team, to a product owner or to an organization.

The Scrum Guide notes that the ScrumMaster is the servant leader to a development team, to the product owner and to the organization: http://scrumguides.org/

The guide describes this service as coaching, guiding, enabling understanding, enabling outcomes and so on. It does not talk about the ScrumMaster typing or writing.

Get Your Hands Off the Team’s Work

When ScrumMasters describe writing down “notes” for the team or scribing the team’s tasks at sprint planning this is what I advise ScrumMasterss everywhere: “Get your hands off of the team’s work!”

Will the team ever learn accountability and collective ownership if there’s an admin who will simply scribe everything for them? What will the team do if their ScrumMaster / Secretary is off for the day? Typically nothing is noted in these situations because the team has not assumed any level of accountability or ownership for tracking their own work.

I have the pleasure of working with high performing Scrum teams. Rarely is there a case where the team members expected someone to write down what they were saying or doing. The development team members make notes, type and do all that is necessary. They see it as just “work they have to do,” as opposed to falling into dogma from traditional system development lifecycle roles. The ScrumMasters serving in those situations, truly understand that they are focusing on the outcome, listening for impediments and pulling interactions back on track. When ScrumMasters feel like they have to “scribe,” their focus is split and they rarely pick up on the items that a great ScrumMaster notice.

Get Your Hands Off the Product Owner’s Work

A great ScrumMaster also needs to serve the product owner. I recently performed an assessment in which the ScrumMaster “kept” the product backlog. The product owner had not only never touched the product backlog, they did not even have access to it. Yikes! Once again ScrumMasters who are falling into this dysfunction, I advise:“Get your hands off of your product owners work!”

The product backlog is for the product owner. It is the way they manage the work that is needed for the product. While anyone can add items, this should not be interpreted as “just send your items to the ScrumMaster and they will take care of adding them to the product backlog.” Many dysfunctions are created out of this type of activity. Not only is the product owner not taking responsibility for the list of items to work on for the product, they are also more than likely are not actively refining and getting items to a state of ready by sprint planning time either.

Service to the Organization

Many associate the ScrumMaster with only a development team and a product owner. This tells me that these ScrumMasters are missing a third of the job. The ScrumMaster has responsibilities in the organization to teach, coach and guide the right outcomes.

In Certified Scrum Product Owner (CSPO) classes, I hear product owners describe interactions with steering committees or leaders that get heated, go down rat holes and never have a definitive outcome. “Where was your ScrumMaster when this was going on?” I ask. They go on to explain that no note taking was necessary so the ScrumMaster was probably not needed for the meeting.

The ScrumMaster is a neutral. They are a facilitator. Who better to come along when the product owner expects emotional discussions? As a skilled, neutral facilitator, a great ScrumMaster can keep the discussion fact-based and focus on the outcomes. If good ideas are generated during the discussion, he or she can suggest that these ideas be captured in the product backlog, so that ideas that can be discussed at a later time and don’t detract from the focus of the conversation at hand.


The ScrumMaster is not an administrative assistant or a secretary. They are the master of the Scrum framework. A process enabler. An advocate for the development team, the product owner and the organization. Great ScrumMasters who focus on servant leadership and outcomes will enable delivering of business value with each sprint.

Check out VersionOne’s upcoming CSM and CSPO training classes.

Posted in Agile Coaching, Agile Leadership, Agile Management, Agile Project Management, Agile Training, Scrum Development, Scrum Methodology, Uncategorized | 3 Comments

How the Words You Use Affect Your Team

Words have a huge impact on team members affecting their work and ultimately your project, yet we often don’t put much thought into the words we use every day.

Check out some of the positive and negative connotations of traditional and agile project management words.

Waterfall Words vs. Agile Words

I recently went to my colleague Matt Badgley’s presentation Words Mean Things. It made me think about the words that we use in agile and how different they are than the words we used in Waterfall project management. So I compiled a list of words we use every day in project management and compared the waterfall words versus the agile words.

Scope Creep vs. Responding to Change

Scope Creep









Creep – verb

  1. Move slowly and carefully, especially in order to avoid being heard or noticed.
  2. (Of an unwanted and negative characteristic or fact) occur or develop gradually and almost imperceptibly.

Responding to Change









Respond – verb

  1. Say something in reply.

Scope creep in waterfall has such a negative feel. The word creep brings images of vines slowly engulfing your project. It makes the business analyst and customer the bad guys trying to sneak extra requirements into the project.

Where in agile, the Agile Manifesto says we should respond to change. Responding is proactively reacting to feedback from our customers. We’re responding to help the business and customer.

Post Mortem vs. Retrospective

Post Mortem











  1. an examination of a dead body to determine the cause of death.












  1. a survey or review of a past course of events or period of time.

Traditionally you don’t do a post mortem until the end of the project; six months, nine months, or maybe a year. Typically this focuses on what went wrong and the root causes, no one changes their behavior because it’s too late.

Whereas retrospectives are held on a regular basis. We’re reflecting on how things are going in small chunks so we’re able to address issues early before they become a bad habit.

Meetings vs. Ceremonies












  1. an assembly of people, especially the members of a society or committee, for discussion or entertainment.
  2. a coming together of two or more people, by chance or arrangement.












  1. a formal religious or public occasion, typically one celebrating a particular event or anniversary.
  2. the ritual observances and procedures performed at grand and formal occasions.

Most people, especially developers, don’t want to go to a meeting. It feels like a waste of time.

Whereas the word ceremony brings to mind a celebration. People coming together to celebrate something. With Scrum we’re on a regular cadence, working as a team to review the product backlog, commitments and demos.

Requirements vs. User Stories












  1. a thing that is needed or wanted.
  2. a thing that is compulsory; a necessary condition.

User Stories











  1. an account of imaginary or real people and events told for entertainment.
  2. an account of past events in someone’s life or in the evolution of something.

Requirements gives the sense that the discussion is over and you are required to do what has been set. It’s something that’s forced and you don’t have a choice, you have to do it.

Whereas with user stories, since the word user is in that phrase, it is pointing out that you are focusing on the user’s perspective. Then the story is about how that user is interacting with your product, what their pain points are with the product, and what you can do to make it better.


Agile words tend to have a much more positive connotation than waterfall words. This can greatly impact the mood of the team and be another factor to help your projects be more successful. More importantly, I think it shows how words we use every day without thinking can have a significant impact.

What other project management words are more positive in agile?

versionone-coaches-susan-evansAbout the Author
Susan Evans

Susan has more than eight years of agile project management experience in software development. Prior to joining the company, she was an internal coach who optimized the usage of the VersionOne platform to help many non-collocated teams thrive in their agile processes. Susan focuses on enhancing team relationships, communication skills, conflict resolution, and processes to help create happy teams that deliver high quality.

Posted in Agile Adoption, Agile Benefits, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Uncategorized | 2 Comments

Is Extreme Programming No Longer Relevant?

Agile Methodology UsedExtreme programming is no longer relevant. According to the latest annual State of Agile™ survey, less than 1% of the nearly 4,000 respondents stated that they were practicing Extreme Programming, while 94% said they were practicing agile.

Could it be that the need for engineering practices have passed?

I’m not suggesting that I think that teams don’t need engineering practices, I’m saying that after seeing these stats that I was concerned that people may have stopped thinking that they need engineering practices.

Has the need for engineering practices passed?

Extreme Programming is the first of the big movements that got the attention of the development community. Scrum probably came earlier but it was Extreme Programming that really started igniting people’s imaginations. Yet, lately we don’t hear about it. It made me nervous that agile has had so much momentum, yet the foundational engineering practices seem to have been passed by, so I dug a little deeper.

What I started to uncover is that while Scrum is still the most common project management oriented piece of agile, you’ll notice a lot of organizations are using a hybrid, they’re doing Scrum for their project management and their teams are using Extreme Programming practices without necessarily realizing those practices come from Extreme Programming. I think that’s okay, but it makes me wonder if we might start losing some of those engineering practices because we’re just not talking about them enough.

Extreme Programming Today

First, let’s talk about what is Extreme Programming. Extreme Programming is a set of practices, mostly technical practices, that we want to apply to our software development cycles. Now this can fit nicely with Scrum, so that’s good. Most of these practices are around test-driven development, which is vital. Practices such as refactoring, continuous refactoring, continuous integration, automated acceptance tests and pair programming. There are others, but these are the ones that I see as the heart of Extreme Programming. If we want to continue to emphasis these practices without calling them Extreme Programming, we might start to lose the holistic nature of what XP is all about. So I do worry about that.

I take heart that Extreme Programming practices are being used somewhat unconsciously. Often when I meet a new team practicing Scrum and ask about technical practices, they look at me like I’m crazy and say, “Well, duh, of course we are doing that.” That’s fantastic, but with the dramatic growth of Agile in the enterprise we need to be careful that we don’t start to lose these practices.

This makes me think of something Kent Beck said at the very first Extreme Programming Universe Conference, “You know, five years from now I hope we don’t even use the name, XP. It’s just how people make software.” It seems he has gotten at least half of his wish, people don’t tend to use the name, XP, but I’m not sure we’ve gotten to the point where it’s just how we write software.

Enterprise agile is, by necessity, going to focus more on project, program and portfolio management, leaving the implementation to the teams themselves. If no one is talking about technical practices, may they one day be overlooked and forgotten?

From my perspective, what we really need to do most is build on agile’s momentum by digging deeper into the technical practices. We need to make the second half of Kent Beck’s wish come true and make technical practices just how we write software.

A consultant by the name of Payson Hall once made a comment that sticks with me, “If you can’t reach this distance, you’re not tall enough to ride this ride.” If you’re not doing the Extreme Programming practices: pair programming, refactoring and so on, then you’re not ready to get on the agile ride. It doesn’t matter how many iterations you plan, how many fantastic meetings you have, how many Scrum gatherings you attend, if you’re not doing the engineering practices, you’re not going to be as successful as you could be.

As often is the case, this is not just a technical problem, it’s a people problem. If the organization feels like they are agile just because they are doing sprints or have a kanban board, they’re not where they need to be. They’re not going to succeed. They might get some traction. It’s certainly going to be better than just waterfall but they’re still not there. The whole point behind Agile practices is we need to reduce and flatten the cost of change curve and we can only do that with the technical practices in place.

What’s Next for Technical Practices?

There’s another movement that has been growing over the past few years called Software Craftsmanship. If you look closely, if you scratch the surface of the Software Craftsmanship movement, what you’ll see is the same people who have been incredibly active in the Extreme Programming community. This is no accident.

The Software Craftsmanship movement is a reaction to the emphasis on project management and a way to bring Extreme Programming practices and the idea that creating software is more than just typing a bunch of lines of code into. It’s important that we look at Software Craftsmanship as a natural extension of Extreme Programming.

We need to keep focus on the foundational principles that are core to XP, not just the technical practices but the values: communication, feedback, courage and, simplicity. Those values being an important part of our day-to-day lives in the software development community. Craftsmanship is a nice wrapper; it gives us a metaphor to think about it where Extreme Programming gives us the actual activities and the values that can help us make that successful.


What’s next for Extreme Programming? What can you do about this?

First, go read the book again. Every couple of years I go back and read the book and I learn more. It reminds me why this was so exciting in the first place. Second, make sure you’re doing these things. Make sure you’re embracing these values and practicing the technical practices on a day-to-day basis.

Does that mean that we’ll bring the words, Extreme Programming, back to the front? I don’t know. I don’t know if I care. What I do care about is that we find a way to get these great ideas back into the software development world.

versionone-coaches-steve-ropaSteve Ropa

CSM, CSPO, Innovation Games Facilitator, SA
Agile Coach and Product Consultant, VersionOne

Steve has more than 25 years of experience in software development and 15 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.

Posted in Agile Project Management, Extreme Programming, Uncategorized | 2 Comments

7 Tips We Learned About SAFe from Dean Leffingwell

SAFe is a marathon, not a sprint, and it can sometimes be fairly challenging, so who better to provide some tips than Dean Leffingwell, the creator of the Scaled Agile Framework® (SAFe®).

Here are seven tips I learned from the recent AgileLIVE Webinar on “Scaling Agile Faster, Easier, Smarter with SAFe and VersionOne.”

In addition, there were more questions than we had time to answer during the live event. I’ve attached the Q&A here.

7 Tips We Learned about SAFe from Dean Leffingwell

1) We need a new approach, one that harnesses the power of lean and agile and applies to the needs of those building complex applications and systems.

The Agile Manifesto was developed for small teams, but it also applies really well to organizations that have scaled horizontally rather than vertically. There is an entire body of work on lean now, with dozens of books written by Don Reinertsen, Michael Kennedy, Alan Ward and others that are great books, but they’re mostly ethereal principles, not practice-based. When I think about SAFe, I think about codifying the things we’ve learned and turning those principles into practices.

2) This cannot be a bottoms-up movement that falls on the deaf ears of leaders and managers.

Management owns the system and is responsible for changing it. Lean and SAFe are leadership approaches. That’s an important statement about where the responsibility lies.

3) One of our bedrocks is the house of Lean. The house of Lean transcends the team. It’s a value system that’s very broad and has value at the top. It has pillars and it has leadership.

The SAFe Value System is drawn as a house for a reason. Value is most easily stated as achieving the sustainably shortest lead time with best quality and value to people and society. How do you make that work? One of the pillars is ”respect for people and culture.” We must understand that a change to an enterprise is a change to culture and a change to people.

4) Product development flow is a key part of what we described, as well as how to avoid the stop, start, stop, start, milestone, stop, post-milestone, start activity to deliver value continually.

Innovation: we have a brand new body of work from the lean startup community furthering relentless improvement, or the Kaizen mindset. Kaizen is a change word; it’s a word designed to get people’s attention and make them ask, “You say you are continuously improving, but are you relentless in that improvement? Tell me one problem you’re working on right now and tell me what tools you’re using to solve the problem.”

5) At the enterprise-level we’re literally scaling agile across the enterprise. We need leadership. It’s not optional.

The foundation of agile development is agile teams. We’re scaling agile, so we can’t treat the leaders as impediments or just pretend as though we taught the software development teams to speak Chinese and we didn’t bother to teach the leaders. That’s not going to scale.

6) If you’re talking about enterprise-level problems, you must apply systems thinking.

Optimizing a part does not optimize the whole. Only when you optimize the whole do you get the optimum result. Build incrementally with fast, integrated learning cycles. That’s the PDCA loop of Walter Shewhart and W. Edwards Deming; that’s what an iteration is.

7) We want the measures to be meaningful.

SAFe is focused on milestones that are based on objective evaluation of working systems. Measurements that help visualize, limit WIP, reduce batch size and manage queue lengths are the basic tenets of flow. A long queue of work means you’re slow and a long queue of committed work means that you’re predictably slow. Shorten the queue and you’re going to get faster. You don’t have to just cut code faster to get results faster; you just need to manage the queue.


I hope you found these tips as beneficial. As I said in the beginning, SAFe is a marathon, not a sprint. If you find yourself in a bind, don’t stress; someone has probably encountered a similar challenge and can provide a few helpful tips.

Interested in learning more? Watch to the recording of the AgileLIVE Webinar on “Scaling Agile Faster, Easier, Smarter with SAFe and VersionOne.”

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in Agile Development, Agile Project Management, scaled agile, scaled agile framewok, Scaling Agile | 1 Comment