Category Archives: Reference Information

Pitfall of Scrum: Excessive Preparation/Planning

Regular big up-front planning is not necessary with Scrum. Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans. Even the Product Backlog can be created after the first Sprint has started. All that is really necessary to get started is a Scrum Team, a product vision, and a decision on Sprint length. In this extreme case, the Scrum Team itself would decide what to build in its first Sprint and use the time of the Sprint to also prepare some initial Product Backlog Items. Then, the first Sprint Review would allow stakeholders to provide feedback and further develop the Product Backlog. The empirical nature of Scrum could even allow the Product Owner to emerge from the business stakeholders, rather than being assigned to the team right from the start.

Starting a Sprint without a Product Backlog is not easy, but it can be done. The team has to know at least a little about the business, and there should be some (possibly informal) project or product charter that they are aware of. The team uses this super basic information and decides on their own what to build in their first Sprint. Again, the focus should be on getting something that can be demoed (and potentially shippable). The team is likely to build some good stuff and some things that are completely wrong… but the point is to get the Inspect and Adapt cycle started as quickly as possible. Which means of course that they need to have stakeholders (customers, users) actually attend the demo at the end of the Sprint. The Product Owner may or may not even be involved in this first Sprint.

One important reason this is sometimes a good approach is the culture of “analysis paralysis” that exists in some organizations. In this situation, an organization is unable to do anything because they are so concerned about getting things right. Scrum is a framework for inspect and adapt and that can (and does) include the Product Backlog. Is it better for a team to sit idle while someone tries to do sufficient preparation? Or is it better to get started and inspect and adapt? This is actually a philosophical question (as well as a practical question). The mindset and philosophy of the Agile Manifesto and Scrum is that trying to produce valuable software is more important that documentation… that individuals and how they work together is more important than rigidly following a process or tool. I will agree that in many cases it is acceptable to do some up-front work, but it should be minimized, particularly when it is preventing people from starting to deliver value. The case of a team getting started without a product backlog is rare… but it can be a great way for a team to help an organization overcome analysis paralysis.

The Agile Manifesto is very clear: “The BEST architectures, requirements and designs emerge out of self-organizing teams.” [Emphasis added.]

Hugely memorable for me is the story that Ken Schwaber told in the CSM course that I took from him in 2003.  This is a paraphrase of that story:

I [Ken Schwaber] was talking to the CIO of a large IT organization.  The CIO told me that his projects last twelve to eighteen months and at the end, he doesn’t get what he needs.  I told him, “Scrum can give you what you don’t need in a month.”

I experienced this myself in a profound way just a couple years into my career as an Agile coach and trainer.  I was working with a department of a large technology organization.  They had over one hundred people who had been working on Agile pilot projects.  The department was responsible for a major product and executive management had approved a complete re-write.  The product managers and Product Owners had done a lot of work to prepare a product backlog (about 400 items!) that represented all the existing functionality of the product that needed to be re-written.  But, the big question, “what new technology platform do we use for the re-write?” had not yet been resolved.  The small team of architects were tasked with making this decision.  But they got stuck.  They got stuck for three months.  Finally, the director of the department, who had learned to trust my advice in other circumstances, asked me, “does Scrum have any techniques for making these kind of architectural decisions?”

I said, “yes, but you probably won’t like what Scrum recommends!”

She said, “actually, we’re pretty desperate.  I’ve got over a hundred people effectively sitting idle for the last three months.  What does Scrum recommend?”

“Just start.  Let the teams figure out the platform as they try to implement functionality.”

She thought for a few seconds.  Finally she said, “okay.  Come by this Monday and help me launch our first Sprint.”

The amazing thing was that the teams didn’t lynch me when on Monday she announced that “our Agile consultant says we don’t need to know our platform in order to get started.”

The first Sprint (two weeks long) was pretty chaotic.  But, with some coaching and active support of management, they actually delivered a working increment of their product.  And decided on the platform to use for the rest of the two-year project.

You must trust your team.

If your organization is spending more than a few days preparing for the start of a project, it is probably suffering from this pitfall.  This is the source of great waste and lost opportunity.  Use Scrum to rapidly converge on the correct solutions to your business problems instead of wasting person-years of time on analysis and planning.  We can help with training and coaching to give you the tools to start fast using Scrum and to fix your Scrum implementation.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Nexus Reifies

Nexus Scrum

I had the privilege of attending Scrum.org‘s 2-day seminar on Scaled Professional Scrum. The Nexusa connection or series of connections linking two or more things (direct translation from Latin a binding together), is the recommended scaling framework. The purpose of the Nexus is to manage dependencies between 3-9 Scrum Teams towards “reification”, to make an abstract idea real or concrete. This is ensured mostly through a single Product Owner, single Product Backlog, integrated (Nexus) Sprint Planning, Review and Retrospective and the addition of a Nexus Integration Team whose membership is made up mostly of Scrum team members internal to the Nexus, but often also includes other support personnel. The structure is very similar to LeSS, but perhaps even less prescriptive and is certainly much less prescriptive than SAFe. This is probably my favourite thing about the Nexus – the fact that it has just enough structure to be a model for scaling Scrum, but is light and flexible enough to accommodate all of the nuances that “just depend” on your situation. Like the other two above-mentioned scaling models, it places emphasis on the need for strong technical practices, continuous integration and the synchronization of events to facilitate integration. There is flexibility around synchronization, in that if the Nexus Sprint is 4 weeks in duration and teams within the Nexus want to do 2 or even 1 week Sprints, the model accommodates – as long as all of the teams’ work is combined into a fully integrated (reified) increment of potentially shippable product by the end of the Nexus Sprint.

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Summary of User Stories: The Three “C”s and INVEST

User Stories

Learning Objectives

Becoming familiar with the “User Story” approach to formulating Product Backlog Items and how it can be implemented to improve the communication of user value and the overall quality of the product by facilitating a user-centric approach to development.

Consider the following

User stories trace their origins to eXtreme Programming, another Agile method with many similarities to Scrum. Scrum teams often employ aspects of eXtreme Programming, including user stories as well as engineering practices such as refactoring, test-driven development (TDD) and pair programming to name a few. In future modules of this program, you will have the opportunity to become familiar enough with some of these practices in order to understand their importance in delivering quality products and how you can encourage your team to develop them. For now, we will concentrate on the capability of writing good user stories.

The Three ‘C’si

A User Story has three primary components, each of which begin with the letter ‘C':

Card

  • The Card, or written text of the User Story is best understood as an invitation to conversation. This is an important concept, as it fosters the understanding that in Scrum, you don’t have to have all of the Product Backlog Items written out perfectly “up front”, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories.
  • The Card is usually follows the format similar to the one below

As a <user role> of the product,

I can <action>

So that <benefit>.

  • In other words, the written text of the story, the invitation to a conversation, must address the “who”, “what” and “why” of the story.
  • Note that there are two schools of thought on who the <benefit> should be for. Interactive design specialists (like Alan Cooper) tell us that everything needs to be geared towards not only the user but a user Persona with a name, photo, bio, etc. Other experts who are more focused on the testability of the business solution (like Gojko Adzic) say that the benefit should directly address an explicit business goal. Imagine if you could do both at once! You can, and this will be discussed further in more advanced modules.

Conversation

  • The collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.
  • As much as possible, this is an in-person conversation.
  • The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.
  • This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g. Acceptance Tests).

Confirmation

  • The Product Owner must confirm that the story is complete before it can be considered “done”
  • The team and the Product Owner check the “doneness” of each story in light of the Team’s current definition of “done”
  • Specific acceptance criteria that is different from the current definition of “done” can be established for individual stories, but the current criteria must be well understood and agreed to by the Team.  All associated acceptance tests should be in a passing state.

INVESTii

The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:

I – Independent

  • The solution can be implemented by the team independently of other stories.  The team should be expected to break technical dependencies as often as possible – this may take some creative thinking and problem solving as well as the Agile technical practices such as refactoring.

N – Negotiable

  • The scope of work should have some flex and not be pinned down like a traditional requirements specification.  As well, the solution for the story is not prescribed by the story and is open to discussion and collaboration, with the final decision for technical implementation being reserved for the Development Team.

V – Valuable

  • The business value of the story, the “why”, should be clearly understood by all. Note that the “why” does not necessarily need to be from the perspective of the user. “Why” can address a business need of the customer without necessarily providing a direct, valuable result to the end user. All stories should be connected to clear business goals.  This does not mean that a single user story needs to be a marketable feature on its own.

E – Estimable

  • The team should understand the story well enough to be able estimate the complexity of the work and the effort required to deliver the story as a potentially shippable increment of functionality.  This does not mean that the team needs to understand all the details of implementation in order to estimate the user story.

S – Small

  • The item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint. In fact, this should be considered as the maximum size allowable for any Product Backlog Item as it gets close to the top of the Product Backlog.  This is part of the concept of Product Backlog refinement that is an ongoing aspect of the work of the Scrum Team.

T – Testable

  • Everyone should understand and agree on how the completion of the story will be verified. The definition of “done” is one way of establishing this. If everyone agrees that the story can be implemented in a way that satisfies the current definition of “done” in a single Sprint and this definition of “done” includes some kind of user acceptance test, then the story can be considered testable.

Note: The INVEST criteria can be applied to any Product Backlog Item, even those that aren’t written as User Stories.

Splitting Stories:

Sometimes a user story is too big to fit into a Sprint. Some ways of splitting a story include:

  • Split by process step
  • Split by I/O channel
  • Split by user options
  • Split by role/persona
  • Split by data range

WARNING: Do not split stories by system, component, architectural layer or development process as this will conflict with the teams definition of “done” and undermine the ability of the team to deliver potentially shippable software every Sprint.

Personas

Like User Stories, Personas are a tool for interactive design. The purpose of personas is to develop a precise description of our user and so that we can develop stories that describe what he wishes to accomplish. In other words, a persona is a much more developed and specific “who” for our stories. The more specific we make our personas, the more effective they are as design tools.iii

Each of our fictional but specific users should have the following information:

  • Name
  • Occupation
  • Relationship to product
  • Interest & personality
  • Photo

Only one persona should be the primary persona and we should always build for the primary persona. User story cards using personas replace the user role with the persona:

<persona>

can <action>

so that <benefit>.

 


i The Card, Conversation, Confirmation model was first proposed by Ron Jeffries in 2001.

ii INVEST in Good Stories, and SMART Tasks. Bill Wake. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

iii The Inmates are Running the Asylum. Alan Cooper. Sams Publishing. 1999. pp. 123-128.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Full-Day Product Owner Simulation

The Product Owner Simulation that I shared last summer has some minor updates based on a stronger emphasis on product vision.  In particular, two 5 minute exercises before and after the Product Box exercise help to frame the concept of product vision and make it stronger.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Retrospective Technique: What Did You Learn?

Retrospectives are a key part of continuous improvement in Agile teams.  The retrospective techniques that a team uses should be adjusted to the needs of the team.  In a Scrum team, for example, the ScrumMaster will often decide on the techniques to use based on the current issues facing the team and then facilitate the retrospective for the team.  There are some great resources which give you collections of tried-and-true retrospective techniques including Esther Derby’s book “Agile Retrospectives” and the amazing online tool “Retr-o-mat“.  As an active consultant and trainer, I am always looking for new techniques to share with my clients.  Sometimes, I even create a new one (or at least new to me).  The “What Did You Learn” technique is new: I’ve been using it and testing it for a few years now to refine it.

What Did You Learn?

By itself, this is a powerful question.  As part of my work with OpenAgile, I’ve been helping teams and organization to focus on learning as an even broader category than continuous improvement.  The Learning Circle and the processes in OpenAgile help with focusing on learning.  The question “what did you learn?” is very open ended, and can certainly work as an extremely simple type of retrospective in OpenAgile or in Scrum or other Agile methods.  Often people like to have a little more structure and guidance so the “What Did You Learn?” retrospective technique provides four categories of learning for people to think about, share, and discuss within a team.

Setup

Setup for this retrospective is very simple: a flip chart or whiteboard divided into four sections or columns works fine, along with a piece of paper for each person in the retrospective, divided up the same way, and sufficient markers and pens for everyone.  Here is a downloadable PDF version of the handout for the “What Did You Learn” retrospective.

The facilitator will also participate at various points if they are a member of the team (e.g. a ScrumMaster).  It is easiest to do this with a group in-person, but can also be done reasonably well with video or teleconferencing.

Process

The facilitator introduces the retrospective with a welcome and, if necessary, a recitation of the Retrospective Prime Directive.  Then, the process is described to the group.  Each of the categories of learning is also explained as follows:

  • Questions.  When you can formulate a question about something, it means that you have learned about a gap in your knowledge.  In other words, you have discovered something that you would like to learn.
  • Information / Data / Facts.  These are specific details that relate to some area of knowledge or skill.  This category of learning is the simplest and is often what people focus on when asked “what did you learn?”  Information tends to be dry and unemotional.
  • Insights / Concepts / “Aha!” Moments.  Often when we have a collection of facts or an experience, we see a pattern or make interesting connections between things.  This leads us to the great feeling of an insight.  Insights tend to be exciting or scary and have an emotional component.
  • Action Items.  These are decisions about what we would like to do in the future, but they could be extremely short-term or very long-term or anything in between.

There are three main stages in the retrospective as follows:

  1. Individual Reflection.  For 10 to 15 minutes, each individual works silently to write down the things that they have learned in the appropriate category on the handout.  Everyone should try to get at least a couple things into each of the four categories, but more is welcome.
  2. Sharing with the Group.  Systematically going around the group and getting people to read from what they have written.  This is another 10 to 15 minutes.  This stage should not get bogged down in discussion, but brief clarifying questions should be welcome.
  3. Identifying Important Learning.  The group now has open discussion to decide on a small number of things it considers the most important that it has learned.  This could be based on popularity, but impact, depth, or uniqueness might also be factors in considering importance.  These are the items that get written down on the flip-chart.  This is usually the longest part of the retrospective and can take up to 30 minutes.

Applicability

This is an excellent retrospective for a team that is going through a significant transition such as starting a new project, a major change in business direction for a product, or as a wrap up technique for sharing lessons learned with other parts of an organization.  It is not a good technique for a brand new team that hasn’t worked together before as there will be little common ground for deciding on the importance of peoples’ various shared learning.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

What’s in a Voice? Communicating Who You Are [Updated with edits]

In our professional lives and in doing business, we commonly follow the advice to “dress for success.” We make certain to wear that business suit, or a particular pair of snazzy heels, or a certain color of tie. For better or for worse, we can be judged in the first few seconds of contact with a potential employer or customer by our attire, our hairstyle, our facial expression, our nose ring…

A more subtle way we evaluate a person is through the sound of his or her voice. The voice is a very personal instrument, and it can communicate so much about who you are, your abilities and your intentions.

The voice can tell you whether someone is nervous or at ease. Whether they’re authentic or stringing you a line. Whether they care if they communicate with you or not. When I was a kid, I thought I could detect when someone was lying to me by a certain glitch in the voice, or a tell-tale tone. Often, our brain makes intuitive judgements about what’s being said to us, and is sensitive to vocal rhythm, clarity, tones, and the use of language.

One may think it’s not fair to judge someone by their voice. Let’s face it, a voice – like being short, or having a large nose – is usually unchangeable. But it’s how the voice is used that matters. We all have an inherently full, expressive voice, but things happen to us in life that can negatively influence and/ or harm that voice.

Think of the person who speaks so quietly it’s almost a whisper – you must lean closer to catch what she says. This person may have had some trauma in her life, like being constantly told as a child to ‘be quiet’, to de-voice her. I know people whose greatest fear is public speaking, who quake inwardly and outwardly, even if they have something important to share with others.

Personality is also expressed through the voice. Imagine the annoyingly loud talker sitting nearby in a restaurant. This is certainly someone who wants too much attention and tries to get it by being overbearing. Or the fast-talker, who doesn’t want any other opinions but his own to be expressed, and doesn’t give the listener an opportunity to think or to respond, lest they disagree with him.

Anyone can be trained to use their voice for positive communication. A voice is an instrument that can become effective and optimal with practice.

Here’s a few things to think about in how you use your voice:

  • Are you clearly enunciating your words so as not to be mis-heard?

  • Are you directing your voice to the person or people you want to communicate with?

  • Are you speaking in a rhythm that’s neither too fast nor too slow?

  • Are you allowing your true feelings or intentions to come through?

  • Are you being honest?

The voice is just one of the important tools we use to communicate. If your work requires relating to other people in any way, for example, making presentations, or promoting a product, consider how you use your voice and what it may communicate about you!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Best Agile Advice Articles – Ten Year Anniversary!

Agile Advice was started in 2005.  In ten years, we have published over 850 articles (an average of just about 2 per week!).  Here are some collections of the ten “best” articles.  I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.

Ten Most Popular Agile Advice Articles

  1. How Two Hours Can Waste Two Weeks (75,000+ visits)
  2. The Seven Core Practices of Agile Work (25,000+ visits)
  3. Eight Barriers to Effective Listening (17,000+ visits)
  4. Seven Essential Teamwork Skills (17,000+ visits)
  5. 24 Common Scrum Pitfalls Summarized (15,000+ visits)
  6. Mentoring and Coaching: What is the Difference? (14,000+ visits)
  7. Wideband Delphi Estimation Technique (14,000+ visits)
  8. The Pros and Cons of Short Iterations (13,000+ visits)
  9. Three Concepts of Value Stream Mapping (13,000+ visits)
  10. Agile Work and the PMBoK Definition of Project (11,000+ visits)

Ten Most Commented Upon Agile Advice Articles

  1. 24 Common Scrum Pitfalls Summarized (19 comments)
  2. Agile Becomes Easier with Useful Tools (12 comments)
  3. Important Words about Scrum and Tools (9 comments)
  4. The Skills Matrix and Performance Evaluation on Agile Teams (9 comments)
  5. The Definition of Done is Badly Named (8 comments)
  6. How Two Hours Can Waste Two Weeks (7 comments)
  7. Agile is Not Communism (7 comments)
  8. Agile Tools vs. Agile Books (6 comments)
  9. The Decline and Fall of Agile and How Scrum Makes it Hurt More (5 comments)
  10. The Planning Game: an Estimation Method for Agile Teams (5 comments)

I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin).  These contributors are all experts, all have great experiences, and all are fantastic people to know.  I’m grateful for their contributions since they have all made Agile Advice a better place to browse!

Five Most Frequent Contributors (of Articles, besides Mishkin)

  1. Paul Heidema (34 articles)
  2. Travis Birch (24 articles)
  3. Christian Gruber (19 articles)
  4. Mike Caspar (16 articles)
  5. Shabnam Tashakour (13 articles)

Plans for the Future – Five Top Ideas for Series

  1. Essays on each of the Values and Principles of the Agile Manifesto
  2. Summary articles of several Agile methods including Scrum, OpenAgile, Kanban, Crystal, XP, and others
  3. Real Agility Program case studies
  4. Reviews of other scaling / enterprise Agile frameworks such as Disciplined Agile Delivery, Large Scale Scrum, Enterprise Scrum
  5. New guest articles from thought and practice leaders.
Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Comparison of the ScrumMaster, Product Owner, Project Manager and Team Lead Roles

Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum.  Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:

ScrumMaster Product Owner Project Manager Team Lead
NEVER NEVER Assign Tasks YES
NO PARTICIPATES Create Schedule NO
NO YES Manage Budget NO
Remove Obstacles PARTICIPATES YES YES
NO Define Business Requirements PARTICIPATES NO
NO YES (Deliveries) Define Milestones NO
Facilitate Meetings NO YES YES
YES (process and people) YES (business) Risk Management PARTICIPATES
Organizational Change Agent NO NO NO
NO Accountable for Business Results RARELY (just costs) NO

Of course, there are many other ways we could compare these four roles.  What would you like me to add to this list?  Add a comment with a question or a suggestion and I will update the table appropriately!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility – Self-Organizing Team Creation Event for Large-Scale Agile Enterprises

In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams.  It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment.  The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective.  They were functional teams (e.g. a team of testers).  But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration.  So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team.  Everyone was involved – all the people who would be on the teams were in the room.  Those teams stayed together with the same membership long after that meeting.

This “team creation event” was a fantastic success for that particular department.  What made it a success?

  1. Everyone participating already had Agile training and experience.  They knew what they were getting into and why they were doing it.
  2. Everyone was encouraged to participate through the way the meeting was facilitated.  No one felt like their opinion was ignored.
  3. The meeting was long, but also time boxed.  It wasn’t an open-ended discussion that could go forever.
  4. It was in-person!!!  Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.
  5. It was honest: tough things were discussed including potential personality conflicts.  This open discussion required expert facilitation.
  6. Management was not involved in the decision-making during the meeting.
  7. The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?
  8. A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.
  9. Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)

In the Real Agility Program, the team creation event is used to launch a Delivery Group.  The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people.  Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day.  Longer is not recommended.  For larger Delivery Groups, we recommend that the team creation event be held off-site.

Facilitation of the team creation event is usually done by the process/people Real Agility Coach.  If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.

The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work.  If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again.  A few days should be the maximum delay.

One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready.  In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees).  As a result, the teams created in the team creation event were not really properly stable.  This caused a great deal of disruption and even significant morale problems for some teams.  It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event.  That includes any necessary means to encourage people who are thinking of leaving to reconsider.  It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.

So, to make it systematic, here are the steps required to run a team creation event:

PREPARATION

  1. Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.
  2. The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.
  3. The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.
  4. In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group.  Is it for a specific Program?  If so, what is the objective of the program from a business perspective?  It should not just be a one-time communication.  This should come from the business Real Agility Coach.
  5. The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations.  These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.

TEAM CREATION EVENT AGENDA

  1. The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.
  2. Management stakeholders make their presentations to ensure that participants have a clear vision.
  3. The business Real Agility Coach summarizes the vision presented by the management stakeholders.
  4. The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:
    • Cross-functional
    • Multi-skilled (see the Skills Matrix tool for ideas here).
    • Correct size (usually 7 +/- 2).
    • People who want to work with each other.
    • People who want to work on that particular team’s goal (if such is set).
    • Everyone must be on a team.
    • Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).
  5. Everyone starts self-organizing!  Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams.  These optimization opportunities should always be offered as suggestions rather than being directive.
  6. As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.
  7. Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).
  8. The people/process Real Agility Coach closes the meeting.  It is critical to record the final results of who is on which team.  It may be easiest to get the teams themselves to do this before leaving the meeting.

FOLLOW-UP

  1. The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.
  2. The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone.  Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.
  3. Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.
  4. A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.

Have you experienced an event like this? Did it work? What was different from what I described?

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Tips to Start Agile in a Hostile Environment

Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally.  In some cases, management may even be hostile to the concepts and practices of Agile methods.  If you are interested in Agile, you don’t have to give up hope (or look to switch jobs).  Instead, here are some tips to start using Agile methods even in hostile environments.

Regular Retrospectives

Some Agilists claim that the retrospective is actually the key to being Agile.  In some ways, this is also the easiest practice to introduce into an organization.  Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“.  These are retrospectives that can be done in 15 minutes or half an hour.  Try to do them with your team weekly.  If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting.  If you are “just” a team member, you might have to get some modest amount of permission.

So why would it be good to do a retrospective?  Because it’s a high return-on-investment activity.  For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning.   Here are a couple more articles about the importance of retrospectives:

What’s an Agile Retrospective and Why Would You Do It?

What is a Retrospective?

Practice-by-Practice

Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start.  Myself, my first formal Agile environment, I started with the Daily Scrum.  Another time less formal, I started with Test-Driven Development.  In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months.  This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders.  This is the practice-by-practice approach.  Start with a simple Agile practice that you can do without asking anyone for permission.  Make sure it is a practice that makes sense for your particular environment – it must produce some benefit!  If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start.  If you are more business-oriented, then maybe consider user stories or one of the Innovation Games.  If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.

It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another.  If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.

Stealth Project

Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy.  This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”.  This is an opportunity to do Agile.  Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.”  There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support.  In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it.  Don’t talk about it.

The “just do it” approach requires that you have some influence.  You don’t have to be an influencer, but you need connections and you need charisma and you need courage.  If you don’t have at least two of those three, you shouldn’t try this approach.  You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works.  Here are a few comments on Stealth Methodology Adoption.

Co-Conspirators

There’s nothing like working with a band of rebels!  If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work.  Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans.  Of course, you need to actually execute some of your plans.  Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.

But, like any rebellion, you really need to trust those you work with in these early stages.  Lacking that trust will slow everything you do possibly to the point of ineffectualness.  Trust means that you have, for some time, a formal vow of silence.  Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.

Read “Fearless Change”

I can’t recommend this one enough!  Read “Fearless Change” by Mary Lynn Manns and Linda Rising.  This is a “patterns” book.  It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use.  Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent.  Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.

Don’t Call it “Agile”

This isn’t really a “tip” in the sense of an action item.  Instead, this is a preventative measure… to prevent negative reactions to your proposals for change.  The words “Agile” or “Scrum”, while they have their supporters, also have detractors.  To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names.  Use another name.  Or let your ideas go nameless.  This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”.  By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.

A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”.  Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.

Get Some Training

Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program.  It’s a 40-week program that takes about 12 hours/week of your time for coursework.  The next cohort of participants starts in June 2015 and we are taking deposits for participants.  This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Add the Scrum Values (back) into the Scrum Guide – Voting

Hi Everyone.  A Scrum Alliance colleague of mine mentioned that in a conversation with Jeff Sutherland (one of the authors of Scrum), Jeff suggested that the community could request and vote on a change to the Scrum Guide (the official description of Scrum) in order the add the values back to the guide.  The values are normally listed as focus, commitment, courage, openness and respect.  Please go and vote (and / or discuss) this on the Scrum Guides User Voice page.  Voting is super easy – you just need to sign in with Facebook.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Scaled Agile Framework: I Learned about Weighted Shorted Job First (WSJF)

Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items.  The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.

Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done.  Scores therefore give a sequence to jobs.  The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”.  The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.

In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners.  The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Book List for Enterprise Agile Transformations

Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them.  This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent.  Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.

I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization.  It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile.  It is about urgency and need, and about a recognition that Agile is better than not-Agile.  If you aren’t in that situation, this is not the book list for you.

Culture

These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture.  Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.

The Corporate Culture Survival Guide – Edgar Schein

Beyond the Culture of Contest – Michael Karlburg

The Heart of Change – John Kotter

Management

This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments.  These books all touch on culture in various ways, and build on the ideas in the books about culture.  For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.

Good to Great – Jim Collins

The Leaders’ Guide to Radical Management – Steve Denning

The Mythical Man-Month – Frederick Brooks

Agile at Scale

These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.

Scaling Lean and Agile Development – Bas Vodde, Craig Larman

Scaling Agility – Dean Leffingwell

Lean Software Development – Mary and Tom Poppendieck

Supporting

These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.

Toyota Talent: Developing Your People the Toyota Way – Jeffrey Liker, David Meier

Agile Retrospectives – Esther Derby

Continuous Delivery – Jez Humble, David Farley

The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.

The OpenAgile Primer – Mishkin Berteig, et. al.

Priming Kanban – Jesper Boeg

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Evolution of a Scrum Diagram

Over the many years that I have been teaching Scrum (since 2005!), I have had a diagram of Scrum as part of my slides and/or handouts.  The diagram has gone through several major and minor changes throughout that time.  Here is the progression from oldest to newest:

First Attempt

This diagram was used in some of my earliest slides when I first started delivering Scrum training.  It is bad.  It is woefully incomplete.  But, here it is:

01 Scrum Process Diagram

Second Diagram

I knew the first one was bad so after not too long, I created this next diagram as a supplement that was meant to show the whole Scrum process all in one page. Similar to other Scrum “cheat sheet” style diagrams. I used this diagram until about 2008 when I got some very good feedback from a great trainer, Jim Heidema.

02 All of Scrum Diagram

Third Try

The changes I made were small, but to me, significant.  Changing from a “mathematical” language of “Sprint N”, “Sprint N+1″ to a more general language of “Current”, “Future” was a big deal.  I really struggled with that.  Probably because I was still relatively new to being non-technical.

03 All of Scrum Diagram

Diagram Four

This fourth diagram made some minor formatting changes, but most importantly added “Backlog Grooming”.  It’s funny how long I talked about grooming in my classes before realizing that it was missing from the diagram.  I used the previous diagram and this diagram for a couple years each before making a rather major change to create the next one.

04 All of Scrum Diagram

Fifth Go

A couple years ago I realized that I wasn’t really talking about the Scrum values in my classes.  I started to introduce them in some of my other handouts and discussions, but it still took a while for me to reflect those values in my diagram.  I had also received a lot of feedback that having two Product Backlogs in the diagram was confusing.  Finally, I realized that I was missing an opportunity to use colour more systematically.  So, a major reformatting, systematic colour coding and the addition of the Scrum values was my next change.

05 All of Scrum Diagram

Branded Diagram (ug.)

In a rush, I added some logos to the diagram. Just made it gross, but it’s badness, combined with feedback about said badness, actually inspired a major change for the next version.

05 All of Scrum Diagram - Branded

Newest Diagram

Literally just a week ago, I was showing my brand-new branded diagram to a bunch of people who really care about design and UX.  The very first comment when I handed out the diagram was: “wow, you can really tell this wasn’t done by a designer!”  Well, that got me thinking deeply about the diagram (again).  So, here is my newest, latest and greatest (still not done by a designer) version of my Scrum diagram!

06 The Scrum Process

The Future

I would absolutely love constructive feedback about this latest diagram. Of course, if you like it, please let me know that too! The thing I like about this is that it is a way of looking back at almost 9 years of my teaching history. Continuous improvement is so important, so I welcome your comments! If you have your own diagrams, please link to them in the comments – I would love to see those too! In fact, it would be really cool if a bunch of people could make little “Evolution of a Scrum Diagram” posts – let me know if you do!!!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Ranking: the Best and Worst Roles to Transition to ScrumMasters

So you’re trying to do Scrum well because you heard it gave you great results.  You know that the ScrumMaster role is critical.  How do you find the right people to fill that role?  Here is a list of several roles that people commonly leave to become ScrumMasters, and a few not-so-common roles as well, all ranked by how well those people typically do once they become ScrumMasters.  From Worst to Best:

  • Worst: PMI-trained Project Managers (PMPs).  Too focused on control and cost and schedule.  Not easily able to give teams the space to self-organize.  Not able to detach themselves from results and focus on the process, values and teamwork needed to make Scrum successful.
  • Bad, but not awful: Functional Managers.  The power dynamic can be a serious hindrance to allowing teams to self-organize.  But, good functional managers already are good at building teams, and empowering individuals to solve problems.
  • Bad, but not awful: Technical Leads.  Here, the biggest problem is the desire to solve all the team’s technical problems instead of letting them do it.  Now, instead of detachment from results (project managers), it’s detachment from solutions.
  • So-so: Quality Assurance people.  Good at rooting out root-cause for problems… just need to shift from technical mindset or business mindset to cultural and process mindset.  Another problem is that QA is not nearly as respected as it should be and QA people typically don’t have a lot of organizational influence.
  • So-so: Junior techies: Enthusiasm can make up for a lot of gaps and naiveté can help solve problems in creative ways, but there will be a huge uphill battle in terms of respect and influence in an organization.
  • Good: non-PMI-trained Project Managers: rely on teamwork and influence rather than tools, processes and control (of course there are exceptions).
  • Awesome: Executive Assistants.  Respected and respectful, use influence for everything, know everyone, know all the processes, know all the ways to “just get it done”. Of course, they don’t usually know much about technology, but that often turns out to be good: they don’t make assumptions, and are humble about helping the technical team!

The ScrumMaster creates high performance teams using the Scrum process and values.  The ScrumMaster is not accountable for business results, nor project success, nor technical solutions, nor even audit process compliance.  The ScrumMaster is responsible for removing obstacles to a team’s performance of their work.  The ScrumMaster is an organizational change agent.

Other things you might want to consider when looking for a ScrumMaster:

  • Does the person have experience managing volunteer groups?
  • Does the person have good people skills in general?
  • Does the person want to create high-performance teams?
  • Can the person learn anything – business, process, technical, people, etc.?

Bottom line: try and avoid having PMI-trained project managers become ScrumMasters.  Even with good training, even with time to adjust, I often find that Scrum teams with PMI-trained project managers are always struggling and almost never become true teams.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail