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.

Christopher-Avery---Partnerwerks

 

 

 

 

 

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?

pic1

 

 

 

 

 

 

 

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.

Vision

vision

 

 

 

 

 

 

 

 

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

vision2

 

 

 

 

 

 

 

 

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.

vision3

 

 

 

 

 

 

 


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.

vision4

 

 

 

 

 

 

 

 

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.

vision5

 

 

 

 

 

 

 


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?

Conclusion

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:

Better:

  • 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

Faster:

  • 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

Cheaper:

  • 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

Happier:

  • 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 | Leave a comment

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.

TurbochargeHuddle

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 | Leave a 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.

Conclusion

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

 

 

 

 

 

 

 

 

post•mor•tem

noun

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

Retrospective

 

 

 

 

 

 

 

 

ret•ro•spect

noun

  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

Meeting

 

 

 

 

 

 

 

 

meet•ing

noun

  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.

Ceremony

 

 

 

 

 

 

 

 

cer•e•mo•ny

noun

  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

Requirement

 

 

 

 

 

 

 

 

re•quire•ment

noun

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

User Stories

 

 

 

 

 

 

 

 

sto•ry

noun

  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.

Conclusion

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
SAFe Agilist, CSP, CSM, PMP, PMI-ACP

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.

Conclusion

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.

Conclusion

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

10 Agile Books You Should Read This Summer

It’s all too easy to take it a little bit easier during the summer, so we created a list of agile books to keep you on your toes.

Whether you read them at the beach on vacation or the back porch while the kids are at camp, you can rest assured that your agile practice will be a little bit better this fall.

Sutherland bookScrum: The Art of Doing Twice the Work in Half the Time
By Jeff Sutherland

We live in a world that is broken. For those who believe that there must be a more efficient way for people to get things done, here from Scrum pioneer Jeff Sutherland is a brilliantly discursive, thought-provoking book about the management process that is changing the way we live.

In this book you’ll journey to Scrum’s front lines where Jeff’s system of deep accountability, team interaction, and constant iterative improvement is, among other feats, bringing the FBI into the 21st century, perfecting the design of an affordable 140 mile per hour/100 mile per gallon car, helping NPR report fast-moving action in the Middle East, changing the way pharmacists interact with patients, reducing poverty in the Third World, and even helping people plan their weddings and accomplish weekend chores.

Woven with insights from martial arts, judicial decision making, advanced aerial combat, robotics, and many other disciplines, Scrum is consistently riveting. But the most important reason to read this book is that it may just help you achieve what others consider unachievable – whether it be inventing a trailblazing technology, devising a new system of education, pioneering a way to feed the hungry, or, closer to home, a building a foundation for your family to thrive and prosper.

*Book description from Amazon

Cobb bookThe Project Manager’s Guide to Mastering Agile:
Principles and Practices for an Adaptive Approach

By Charles G. Cobb

The Project Management Profession is beginning to go through rapid and profound transformation due to the widespread adoption of agile methodologies. Those changes are likely to dramatically change the role of project managers in many environments as we have known them and raise the bar for the entire project management profession; however, we are in the early stages of that transformation and there is a lot of confusion about the impact it has on project managers:

  • There are many stereotypes and misconceptions that exist about both Agile and traditional plan-driven project management
  • Agile and traditional project management principles and practices are treated as separate and independent domains of knowledge with little or no integration between the two and sometimes seen as in conflict with each other
  • Agile and “Waterfall” are thought of as two binary, mutually-exclusive choices and companies sometimes try to force-fit their business and projects to one of those extremes when the right solution is to fit the approach to the project

It’s no wonder that many Project Managers might be confused by all of this! This book will help project managers unravel a lot of the confusion that exists; develop a totally new perspective to see Agile and traditional plan-driven project management principles and practices in a new light as complementary to each other rather than competitive; and learn to develop an adaptive approach to blend those principles and practices together in the right proportions to fit any situation.

*Book description from Amazon

Scaled Agile Framework (SAFe) Distilled:
A Practical Guide to Scaling Agile in the Enterprise
By Richard Knaster and Dean Leffingwell

Today, companies know they must adapt quickly or die. They are increasingly seeking to adapt by using agile principles and practices – but many are still changing too slowly, and can’t sustain change. Fortunately, a growing number of enterprises have found a far more effective solution: the Scaled Agile Framework (SAFe).

SAFe changes the game by integrating Agile, Lean and product development flow thinking with a new operating model that successfully coordinate works at all levels: team, program, and portfolio. SAFe helps managers learn to become lean-thinking leaders, working with teams to continuously improve their systems, and create environments where everyone flourishes.

In Scaled Agile Framework (SAFe) Distilled, two SAFe pioneers show software practitioners how to use achieve higher productivity, improve the quality of their software processes, and bridge the divide between executives, managers and practitioners – aligning everyone towards common goals and objectives. If you want to scale and sustain agile in the enterprise, SAFe can get you there. Scaled Agile Framework (SAFe) Distilled will help you launch it, quickly earn value from it, and grow its value with every new project.

*Book description from Amazon

AgileChangeMgtAgile Change Management:
A Practical Framework for Successful Change Planning and Implementation

By Melanie Franklin

The concept of agile working has been adopted by many organizations that recognize the need to respond quickly and easily to new opportunities in a world of complex and continuous change.

Agile Change Management offers best practice advice for planning and implementing change projects. Concrete tools help deliver projects successfully and realize benefits earlier on in the process.

By emphasizing and encouraging collaborative practices, the book illustrates how to build trust, influence and motivate others, and create a roadmap that outlines all the processes, activities and information needed to manage any type of change initiative. With advice for creating the right environment for change the book explains: who should be involved at each stage in the life style cycle, what tasks need to be completed at each stage, the concept of change in both large scale transformational programs and micro-level business projects, and the needs and benefits behind change strategies.

Along with a practical toolkit of materials available both online and in the book, Agile Change Management is essential reading for anyone who wants to develop the competencies of an effective change manager working in any project or program.

*Book description from Amazon

AgileMgt(1)Agile Management for Software Engineering:
Applying the Theory of Constraints for Business Results

By David J. Anderson

This book is certainly about software development management, but it is also a book about business. Managers can no longer afford to discuss these two topics independently. This book is meant to eliminate the seat-of-the-pants intuition and rough approximations that have been far too prevalent in software development management. The growing popularity of agile methods has shown that a healthy balance between strict process and individual flexibility can be achieved.

David Anderson takes it a step farther, and explains how the healthy balance of agility can help businesses become more profitable. The result is a book that will allow managers to foster teams that produce better software, less expensively, on time, and with fewer defects.

*Book description from Amazon

AgileMgtLeadershipAgile Management
By Ángel Medinilla

If you have tried to implement Agile in your organization, you have probably learned a lot about development practices, teamwork, processes and tools, but too little about how to manage such an organization. Yet managerial support is often the biggest impediment to successfully adopting Agile, and limiting your Agile efforts to those of the development teams while doing the same old-style management will dramatically limit the ability of your organization to reach the next Agile level.

Ángel Medinilla will provide you with a comprehensive understanding of what Agile means to an organization and the manager’s role in such an environment, i.e., how to manage, lead and motivate self-organizing teams and how to create an Agile corporate culture. Based on his background as a “veteran” Agile consultant for companies of all sizes, he delivers insights and experiences, points out possible pitfalls, presents practical approaches and possible scenarios, also including detailed suggestions for further reading.

If you are a manager, team leader, evangelist, change agent (or whatever nice title) and if you want to push Agile further in your organization, then this is your book.

*Book description from Amazon

AgileCoachingAgile Coaching Paperback
By Rachel Davies and Liz Sedley

Discover how to coach your team to become more Agile. Agile Coaching de-mystifies agile practices – it’s a practical guide to creating strong agile teams. Packed with useful tips from practicing agile coaches Rachel Davies and Liz Sedley, this book gives you coaching tools that you can apply whether you are a project manager, a technical lead, or working in a software team.

To lead change, you need to expand your toolkit, and this book gives you the tools you need to make the transition from agile practitioner to agile coach.

Agile Coaching is all about working with people to create great agile teams. You’ll learn how to build a team that produces great software and has fun doing it. In the process, you’ll grow a team that’s self-sufficient and skillful.

This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to coach your team through the agile lifecycle, from planning to writing software. Learn the secrets of running effective agile meetings and how to get your team following a consistent approach to creating software. You’ll find chapters dedicated to introducing Test-Driven Development, designing retrospectives, and making progress visible.

*Book description from Amazon

AgileEstimatingAgile Estimating and Planning Kindle Edition
By Mike Cohn

Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. In this book, Agile Alliance cofounder Mike Cohn discusses the philosophy of agile estimating and planning and shows you exactly how to get the job done, with real-world examples and case studies.

Concepts are clearly illustrated and readers are guided, step by step, toward how to answer the following questions: What will we build? How big will it be? When must it be done? How much can I really complete by then? You will first learn what makes a good plan-and then what makes it agile.

Using the techniques in Agile Estimating and Planning, you can stay agile from start to finish, saving time, conserving resources, and accomplishing more. Highlights include:

  • Why conventional prescriptive planning fails and why agile planning works
  • How to estimate feature size using story points and ideal days—and when to use each
  • How and when to re-estimate
  • How to prioritize features using both financial and nonfinancial approaches
  • How to split large features into smaller, more manageable ones
  • How to plan iterations and predict your team’s initial rate of progress
  • How to schedule projects that have unusually high uncertainty or schedule-related risk
  • How to estimate projects that will be worked on by multiple teams

*Book description from Amazon

AgileExperience_Agile Experience Design: A Digital Designer’s Guide to Agile, Lean, and Continuous (Voices That Matter)
By Lindsay Ratcliffe

Agile development methodologies may have started life in IT, but their widespread and continuing adoption means there are many practitioners outside of IT – including designers – who need to change their thinking and adapt their practices. This is the missing book about agile that shows how designers, product managers, and development teams can integrate experience design into lean and agile product development. It equips you with tools, techniques and a framework for designing great experiences using agile methods so you can deliver timely products that are technically feasible, profitable for the business, and desirable from an end-customer perspective.

This book will help you:

  • Successfully integrate your design process on an agile project and feel like part of the agile team
  • Do good design faster by doing just enough, just in time
  • Use design methods from disciplines such as design thinking, customer-centered design, product design, and service design
  • Create successful digital products by considering the needs of the end-customer, the business, and technology
  • Understand the next wave of thinking about continuous design and continuous delivery

*Book description from Amazon

AgileProjMgtAgile Project Management with Scrum (Developer Best Practices)
By Ken Schwaber

The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But Scrum’s simplicity itself—its lack of prescription—can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-creator and evangelist Ken Schwaber identifies the real-world lessons—the successes and failures—culled from his years of experience coaching companies in agile project management. Through them, you’ll understand how to use Scrum to solve complex problems and drive better results—delivering more valuable software faster.

Gain the foundation in Scrum theory—and practice—you need to:

  • Rein in even the most complex, unwieldy projects
  • Effectively manage unknown or changing product requirements
  • Simplify the chain of command with self-managing development teams
  • Receive clearer specifications—and feedback—from customers
  • Greatly reduce project planning time and required tools
  • Build—and release—products in 30-day cycles so clients get deliverables earlier
  • Avoid missteps by regularly inspecting, reporting on, and fine-tuning projects
  • Support multiple teams working on a large-scale project from many geographic locations
  • Maximize return on investment!

*Book description from Amazon

Whether you’re brand new to agile or been practicing for years, there’s something for everyone on this list of summer agile reading. I hope the list has inspired you to continue your agile advancement this summer.

What other books would you recommend?

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

Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and Its Four Planning Objectives

Satish2

 

 

 

 

 

 

 

In the first blog post of this series of six, I explained the need for Agile Planning Framework with its four planning levels.

In this second blog post, I explain four objectives at each planning level, and how to use the proposed Agile Planning Framework to implement and operationalize your customized agile planning playbook.

Agile Planning Framework: 4 planning levels x 4 planning objectives covering 16 practices.

Table 1 presents the recommended Agile Planning Framework, with four agile planning levels represented by its four columns, and four key objectives represented by its four rows.  The wording of each objective is the same for all four levels, offering a unified treatment of each objective at all four levels, and also making the objectives easy to understand and manage.  However, the implementation of each objective with specific practices depends on the level.  For each of the four objectives, there are four practices corresponding to four levels of planning.  Altogether there are 4 x 4 = 16 practices covering all four levels of planning and four objectives. These 16 practices are numbered as 1.1 through 1.4, 2.1 through 2.4, 3.1 through 3.4, and 4.4 through 4.4.

Table 1: Customizable Agile Planning Framework with 4 Levels,
4 Objectives and 16 Practices

Table1A_V2

Table1B_V2Objective 1 – Choose and include appropriate method for planning in your Agile Planning Playbook:  At each level of planning, Row 1 of Table 1 shows which specific planning method to choose from a set of choices, what specific things to pay attention to, and things to avoid as they cause waste.

Objective 2 – Obtain required inputs for planning and do necessary preparation ahead of the planning sessions:  Agile planners must obtain the inputs required for planning and do the necessary planning preparation ahead of each planning session (meeting or workshop).  Organizational old habits and inertia might mean multiple reminders and follow-up with at least some people, which some planners may find distasteful (pulling the teeth experience), and may be tempted to skip this diligence.  Without required inputs needed for planning and preparatory steps completed, the planning work to be done during a planning session will not be effective. Row 2 of Table 1 lists the input information needed for planning at each level.

Objective 3 – Develop your agile plan:  At each level of planning, several outputs must be produced to develop the Agile Plan at that level.  Row 3 of Table 1 lists many of these key outputs of the agile plan at each level of planning.  Note that the agile plan also needs to specify how workflow against the plan will be monitored.

Objective 4 – Re-plan as required, and improve the agile planning process and agile planning playbook on an on-going basis:  An agile plan is not an end-all in itself.  As an agile plan gets implemented at each level, lessons are learned through experience, and new inputs are received from the environment (market changes, competitive changes, and business condition changes), the plan itself will need revisions (agile re-planning).  The nature and method of re-planning change with the planning level.   The need for re-planning must be understood by the highest level of management – an area where agile champions and coaches may need to put some effort to overcome old mindsets.

Lessons learned from developing and executing agile plans at all levels, lessons discussed at reviews and retrospectives at all levels, and inputs received from the environment should become the basis for on-going improvements of the agile planning process and the agile planning playbook at your organization.

Relationship among Agile Planning Framework, Agile Planning Playbook, Agile Plans and their Implementations

Figure 3 shows this relationship along with an explanatory legend.  I encourage agile champions to use the Agile Planning Framework presented in this blog series (Blog 1 and 2) to guide the development of your customized Agile Planning Playbook.  Customization is done in the way you choose planning levels and planning objectives, and implement 16 practices of Table 1.  Agile Planning Playbook is part of the more comprehensive Agile Lifecycle Playbook.  Four planning level-specific playbooks are part of the Agile Planning Playbook.  Each level of planning provides the context for the next lower level of planning.  Implementation at each level provides feedback to the agile plan at that level, and based on the nature of the feedback the agile plan may be revised.

Moreover, implementation at each level provides a second order – what I call “derivative” – feedback to the Agile Planning Playbook; for example, if there is a systemic trend based on several days of daily feedback, it may alter the Agile Daily Planning and Daily Scrum Playbook.  As an example, if a team finds it difficult to hold to the scheduled start and end time of their daily Scrum meetings based on daily feedback from several days of work, then the team tries to find the root cause, fixes it, and revises its own Agile Daily Planning and Daily Scrum Playbook.

If a team finds that the same problems have recurred few sprints later even after “fixing” them as a result of an earlier sprint retrospective, the sprint planners and agile champions must explore deeper over the feedback data from a series of sprint retrospectives (hence it is called derivative feedback), address the root cause, and revise their Agile Sprint Planning Playbook.  Feedback from few samples in agile implementation is usually enough to drive a change in the agile plan at that level, but it requires sustained or systemic feedback over several samples (derivative feedback) to warrant a change in agile planning playbook at that level.  Sometimes, a feedback at one level of agile implementation may be so strong that it could alter the agile plan at a higher level.  An agile implementation or a plan or sometimes even a playbook may be altered due to inputs from the environment (market changes, competitive changes, technology issues, business changes).  This is not shown in Figure 3 to avoid clutter and to stay focused on the relationship among Framework, Playbooks, Plans and Implementation effort.

Fig3_APF_APP

Fig4_Legendfor_Fig3Figure 3: Relationship among Agile Planning Framework, Agile Planning Playbooks, Agile Plans and Implementation

Guidelines for customizing the Agile Planning Framework:  For a client-specific project of a relatively modest duration (say, six months), you may be able to skip Level 1 planning (Product Vision and Strategy) and start with Level 2: Release Planning, consisting of two release cycles of three months each.

Teams that are new to agile development may start with Level 3: Sprint planning and Level 4: Daily Planning and Daily Scrums.  As they gain experience of few sprints under their belt, they may then start doing Level 2: Release planning, and with further experience start with Level 1: Product Vision and Strategy planning.

For entrepreneurial start-ups with high degree of uncertainty about their real customers and their real problems, and about technical feasibility of their solution, staring with a two-year long vision and strategy exercise may not be very productive.  A start-up may spend the first several months on Level 3 (Sprints) and Level 4 (Daily) planning and execution to validate their assumptions, demonstrate prototypes to potential customers, and make small changes in the (implicit) strategy or even “pivot” (significantly change) the strategy based on feedback from short sprints.  Only when they have a good understanding about real customers and their real problems, and have some confidence in technical feasibility of their solution, they may advance to Level 2 (Release) and finally to Level 1 (Product Vision and Strategy) planning.

For a very large organization with many portfolios, programs and projects, you may have five levels of planning: Portfolio vision and strategy, Product vision and strategy, Release planning, Sprint planning, and Daily Planning and Daily Scrums.   Alternatively, you may choose to have multiple Agile Planning Books targeted for different lines of businesses or product lines.

For well-jelled, highly experienced and stable teams that have demonstrated a stable velocity pattern (velocity changes within a narrow range across successive sprints), Planning Level 4 can be substantially simplified.  Such teams should still conduct Daily Scrum meetings and may break stories into SMART tasks, but may track the effort for an entire story, and not at the task level.

You may add one or a small number of new objectives (beyond four objectives in Table 1) to your Agile Planning Framework, if required for your specific situation.  Ability to add new planning levels and new objectives makes the Agile Planning Framework extensible.  If you decide to add new levels or new objectives, I will be very interested in knowing the reasons (you may send me an email at Satish.Thatte@VersionOne.com).  If you delete or modify or relax any of these four objectives, your agile plan will be incomplete or inadequate or of poorer quality compared to a plan developed by rigorously and diligently following all four objectives.

From Agile Planning Framework to your customizable agile planning playbook:  Agile champions owning the agile planning playbook have many important responsibilities:

  • Take the Agile Planning Framework from this blog series and customize it to create your agile planning playbook, instead of developing the playbook from scratch. This will save you substantial effort and result into a better and higher-quality playbook.
  • Choose your own method for implementing each of 16 practices of Table 1. Furthermore, you should explore how to integrate your agile planning playbook with your Agile Lifecycle Management platform (see below) as that will make its actual use by agile champions, agile planners and agile team members much more likely and natural.
  • After getting the buy-in and commitment for agile planning from your senior executives, educate agile planners and stakeholders in your organization on the agile planning playbook to be used in your company, and also get their inputs in developing your agile planning playbook.
  • Make sure that your agile planning playbook is followed by agile planners at all four levels of agile planning, and even more importantly agile team members do their work driven by those plans.
  • Improve the agile planning process and the playbook on an on-going basis.

The resulting agile planning playbook can be a brief document or a set of wiki pages.  However, this solution will be disconnected from and will be poorly integrated with your ALM platform, and may not get used much as it is an “out-of-band” solution; and for that reason, it’s not my favorite.  I strongly recommend that you implement and operationalize your agile planning playbook as an “in-band” solution that is well-integrated with your ALM platform.

If you are using or planning to use VersionOne as your ALM platform, I encourage you to implement your agile planning playbook using VersionOne Communities, Templates, Reporting and Customization capabilities, pilot your playbook with few agile projects, and then roll it out at a larger scale.  If you have questions on how to implement and operationalize your customized agile planning playbook or to implement a more comprehensive agile lifecycle playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.

Though last but not the least, the agile planning playbook is necessary but not sufficient for agile success.  Excellence in agile project execution is also essential, in addition to be good at agile planning.  However excellence in execution will not be effective in delivering business results without proper agile planning.

The past blog of this blog series:

  • Blog 1: Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Levels

The next five blogs of this blog series:  In the following four blogs (Blog 3 to 6), I will explain the implementation and customization details for four practices needed to realize the four objectives at each planning level.

  • Blog 3: Succeed Strategically using Your Agile Product Vision and Strategy Planning Playbook
  • Blog 4: Succeed in each Release using Your Agile Release Planning Playbook
  • Blog 5: Succeed in each Sprint using Your Agile Sprint Planning Playbook
  • Blog 6: Succeed every Day using Your Agile Daily Planning and Daily Scrum Playbook

In Blog 6, I will also present a complete example of an Agile Planning Playbook based on the Agile Planning Framework.

If you have questions on how to implement and operationalize your customized Agile Planning Playbook or to implement a more comprehensive Agile Lifecycle Playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.

Your feedback: I would love to hear from the readers of this blog either here or by e-mail (Satish.Thatte@VersionOne.com) or on Twitter (@smthatte).


versionone-coaches-satish-thatteAbout the Author
Dr. Satish Thatte
SPC, CSM, CSPO, CSP

Dr. Satish Thatte is Agile/Lean Coach & Product Consultant at VersionOne.  He has over 30 years of industry experience, covering 15 years of software development and management at Texas Instruments, Bellcore and LG Electronics, 7 years as VP of Engineering at several companies practicing agile methods, and 6 years of agile coaching and consulting engagements for over 50 clients with impact at the executive level.  He obtained his MS and PhD degrees in Electrical and Computer Engineering from the University of Illinois at Urbana-Champaign.

His expertise is in application of agile-lean methods and getting business results, agile transformation, and scaling up agile methods. He has been a speaker at a number of organizations and events: NYC Scrum, NY SPIN, NJ SPIN, Philly SPIN and AgilePalooza. He is a member of the Scrum Alliance, Agile Alliance, and a Senior member of the IEEE, and has served as Director of Modeling and Simulation at the Conscious Capitalism Institute.  Learn more about Satish and his blogs at LinkedIn and blogs.

Posted in Agile Adoption, Agile Coaching, Agile Leadership, Agile Management, Agile Methodologies, Agile Portfolio Management, agile program management, Agile Project Management, Enterprise Agile, scaled agile | Leave a comment