The objective of this training manual is to provide an instant method of starting your project. I am the type of person that likes to read many books on the same subject to get as much information as possible so I can gain a rounded understanding on a subject. With that in mind, this is just one approach to starting up an Agile team. In the cost-conscious economy, I wanted to provide a format for small companies or teams to do a Do-It-Yourself Implementation while 1) starting a project 2) and training 3) and some basic information for effectively engaging management (especially if this is a “grass-roots” implementation). One final goal was was to 4) fill in a gap for teams who take traditional training and could use a daily step-by-step reminder.

This training also involves the entire team in a collaborative process in the initial sprint (Sprint Zero) for writing stories, writing tests as requirements, and development. When the whole team is more aware of each role, it opens dialogues increasing opportunities for higher performance.

Change management is a “squishy human resource thing” and it is hard to quantify results. Change is hard. Ingrained practices of working are like trying to till up a hard-packed dirt road…it takes a lot of work for the new practices to become second nature. Change management is the equivalent of tilling the fertile soil of the mind and questioning existing practices to prepare for the new way of doing things. For this reason, this DIY guide was designed to ask questions and open dialogue with the team. It is important to understand concerns, perceived risks, questions, and concepts that are liked, confusing, or disliked and share them with the rest of the team. Even if team members have participated in an Agile team before, like every individual, every team is at a unique place in their Agile journey. These questions can be used on a new team, a team that is mixed with Agile experience, or can be used for revisiting a process that may be a struggle for the team. It is important for the Scrum Master and Product Owner to note some of these concerns so they can prepare to address these throughout the duration of the project. The questions in this manual are designed to help the team start communicating with each other about their viewpoints on everything without judgment. This is the foundation of a high-performing self-organizing team.

For those who have already taken a class, you can still use this manual as a step-by-step implementation of each part of the project while you are starting up. The progression of the book covers the same material in the basic training classes, but lays out a day-by-day, step-by-step plan for executing your first Sprint, then stepping back and working on some Strategic planning, and then starting your second Sprint.

Pin It

Format of this e-Book

How this training manual is different: it provides just enough theory and background for you to do a Do-It-Yourself Agile start-up on your real project. You can use this book as a stand-alone book for implementing Scrum on your first project. Or you can attend traditional training and use this as a guide for the step-by-step implementation on your project.

  • Estimated Time Box: Suggested length of time needed to complete this chapter
  • Action plan: actions to be taken for this chapter.
  • The Concept: a concise introduction to the chapter
  • Additional Information: there are various subheadings in this section to describe the content of the paragraph. Some of them address the Scrum Master directly. Some give reasons for the approach. Some give background information. The content depends on the chapter.
  • What do you think? A series of questions designed to open a discussion with the team and gather information on your team’s unique place in their Agile journey. Just as every person is unique, every team is unique.  Even if you have done Agile before, you can use the discussion parts of this manual for starting up each new team to determine the “personality” of your new team.

If you are implementing Scrum for the first time and on your own, this training book assumes you have: one team of ideal size. It is possible to use Agile on large projects where there are multiple teams that integrate their features into a cohesive final product. Best practice is to start up with a single team of 6-8 total people (absolute maximum of 10 people), have all team members located in the same room (business team, developers, analyst/tester).

There are some modifications you can make if you don’t have these ideal conditions, but try for this ideal if you can. It’s easiest to do this in a small IT shop where you have the opportunity to create the process from the start. If you are implementing this in a company with an incumbent project management process, you will most likely uncover organizational dysfunction as impediments that are a challenge throughout the project. I have provided some minimal information on typical organizational impediments and preparation management can take to mitigate these impediments. There are vast resources in the form of books, articles, and blogs that round out thinking regarding these challenges at the organizational level. These references are provided in the Appendix.

Pin It

DIY Scrum Book Project – Table of Contents

This is an assemblage of training based on my experiences and templates I have developed throughout my agile career. I have attempted to assemble this training in a way that you could employ as you implement Scrum on your own.

The first post is the Table of Contents as I have currently defined it. (Subject to changes and amendments.) I will be linking the relevant posts once they are written to this page.

I. Introduction

  • Format
  • Forward
  • Training Agenda

II. Preliminary Activities

  • Introduction
  • Scrum Translator
  • How Management Can Support an Agile Transformation
  • Staffing the Team
  • Job Descriptions
  • Creating a Behavioral Interview to Hire Key Lead Roles
  • Scrum Master Preparation
  • Shopping List
  • Becoming a Change Agent

III. Agile Basics

  • Agile Basics Boot Camp
  • How it All Started – the Agile Manifesto
  • What Have You Heard About Agile?
  • Why Use Agile?
  • What is the Agile Methodology?
  • Why is Agile Better?
  • Agile Paradigm Shifts
  • Don’t Just Accept Change – Embrace It!
  • Communication – the Heart of Agile
  • Things That Can Happen on a Good Agile Project

IV. Team Foundations

  • Team Foundations
  • The Team
  • Define the High Performance Team
  • Create Your Team Ground Rules
  • Who is this Scrum Master Person?
  • The Critical Role of the Product Owner
  • Create the Vision

V. Sprint Zero

  • Sprint Zero
  • Create the Product Backlog
  • Write User Stories
  • Story Splitting Workshop
  • Estimating Stories
  • Test Driven Development
  • Continuous Integration
  • Ideal Hours
  • Definition of Done

VI. Strategic Planning (Vision)

  • Strategic Planning (Vision)
  • Create the Roadmap, Release Plan
  • Product Backlog Grooming and Management
  • Resource Planning
  • Project Planning
  • Adding Margin to the Plan (formerly known as Scope Creep)

VII. Tactical Planning (Sprint Planning)

  • Tactical Planning
  • Sprint Planning
  • The Sprint Cycle
  • Daily Scrum
  • Sprint Review and Demo
  • The Retrospective

VIII. Documenting Your Project

  • Documentation
  • Information Radiators
  • Website Layout

IX. Supplementary Information

  • Specialists vs. Generalists
  • Additional Notes for the Product Owner
  • Additional Notes for the Scrum Master
  • Additional Notes for the Development Lead
  • Testers
  • Business Analysts
  • Functional Analysts
  • Developers
  • Team Changes
  • Common Agile Problems
  • Agile Library at a Glance
  • Tools
  • The Distributed Team / Virtual Environment
  • Restoring Team Morale
  • Team Mood Board
  • The Demonstration
  • Agile Release Planning
  • Transitional Scrum (Waterfall to Agile)
  • Scrum Master as Change Agent



Pin It

The Scrum Translator

This is a quick reference guide of Agile terms and synonyms that are currently in common use. The Agile terminology is different for a reason – there area nuances of differences between the terminology to encourage different thinking around Agile. However, this translator is a quick reference for individuals who are outside the team and haven’t had the training to keep up with the team’s new language.

Agile Term Synonym Your Company Definition
Artifacts Documents   Any documentation. Can be in the form of websites, photos taken of a whiteboard, formal documents, tests written as requirements, etc.
Burndown Progress Report   Project Status used for the overall project and each short time box of activity
Ceremonies Meetings   The activities that comprise the general Scrum framework: Daily Scrum, Sprint Planning, Demonstration, and Retrospective
Continuous Integration Continuously built software   Integration of each feature after it’s developed and tested producing clean, functioning code
Daily Scrum Daily Meeting   Daily, 15-minute stand-up meeting of team reporting progress to each other
Demonstration Feature Demonstration   Developers demonstrate working code developed during the last time box of activity
Product Backlog Scope Document   A prioritized list of business requirements, technical requirements, bugs written in a story format from the user point of view
Product Owner Product Manager   Product Manager with budgetary and schedule responsibility focused on delivering the highest value features
Retrospective Lessons Learned (Post-Mortem)   A review of the Sprint and what worked, what didn’t and actions for improving. Team focused (facilitated by the Scrum Master)
Scrum Project methodology   Agile project framework. Scrum is lightweight and prefers not to be considered a “methodology” as that implies heavy-duty adherence to a process. There is flexibility in the process.
Scrum Master Project Leader   Project Leader (keeper of the process through teaching, mentoring and coaching). Responsibility is toward development of a high performing team not schedule and budget. Schedule and budget belong to the Product Owner and the Scrum Master can support the PO through accurate reporting.
Sprint Time box of effort   Short time box of development effort, self-defined by the team (with recommended 2-week Sprints taken into consideration)
Sprint Planning Planning meeting for timebox   Business prepares stories and teams discusses and confirms understanding of requirements
Story Points Estimate of difficulty   Estimate of relative difficulty in relation to other stories in the backlog that factors in complexity, amount of work, and risk.
Test Driven Development Write tests as requirements   Tests written as requirements and developed against until tests pass
User Story Requirements   Detailed Requirements
Velocity Productivity   Productivity measurement using Story Points


Pin It

Fine Tuning Knobs

Once your team has made it through the chaotic stages of bulldozing into an Agile framework, the team settles into a pattern of behaviors. Your retrospectives can seem to become stale and rote and often this is when people start letting things like the Retrospective go to the wayside. This is the time to begin leaning into the team and recognizing that now you are in fine tuning mode.

In the post I will discuss struggles I have seen across my teams from four different companies and the fine-tuning knobs that have been successful. For one of my teams who had been doing Scrum for more than a year, fine-tuning led to a 320% increase in productivity when you looked at a year over year comparison. While there were several fine-tuning factors that contributed to that impressive productivity increase, this post will address four of them. They were: breaking stories into small enough increments, becoming a cross-functional team, limiting work in progress, creating flow.

Agile Team Fine Tuning

Breaking stories down into small enough increments. One struggle I have seen consistently across my teams is breaking stories down into small enough pieces to finish in a single Sprint. The other interesting aspect is that there is a lot of pressure to finish an entire story in a given Sprint, sometimes to the point that it seems to defy common sense.

Specialization. The core of the issue really revolves around the specialization of roles. In the Ideal Scrum team, you have individuals who are completely cross-functional and able to do everything from business analysis, design, develop, and test and everything in between. The less hand-offs there are, the more efficient the process can be. I have always worked in transitional companies (companies transitioning from traditional project management to Agile frameworks). These large companies have developed highly specialized roles with significant depth and minimal breadth. The highly specialized roles create a relay race as team members hand off finished components of work to another team member until the component of work can be considered completed. I have had several team members observe that we have what could be considered a mini-waterfall model within the Scrum framework.

Becoming cross-functional. So, if you want to work on the cross-functional dial, there is a high likelihood you will run into a number of roadblocks here, as well. Creating a truly cross-functional team is a challenge at best, and just not possible in most. Developing a broad skillset doesn’t happen overnight. One of the constraints is that junior and medium level developers often just don’t have the breadth of skills yet. For the few senior members who do have a breadth of skills, they may struggle by thinking that other team members don’t have the ability or desire to become cross-functional.  Sometimes the organization itself is just not ready to let the team become cross-functional.

If you are going to work the story breakdown lever, it should be worked in conjunction with the cross-functional team. Until you resolve the issues created by very specialized roles, turning the story breakdown lever is going to be a frustrating exercise.

In the face of all of these “but” conversations, what can be done? My recommendation is to still continue to work on breaking stories down small enough and cross-functional dials, but at a slower pace. In general, I recommend that rather than fight the team disposition, go with the flow. In these cases, I found experimenting with Kanban elements (limiting work in progress, creating flow) are very useful within the Scrum framework. I treat Agile as a bag of tools and figure out which one works best for the team. My next post will share some of the specific ways I helped my team implement these principles.

Pin It

Become an Agile Whisperer

If you are involved in the Agile movement as a Scrum Master or Agile Coach, you are involved in introducing change into an organization. Change is always disruptive. But there are ways to minimize the impact. Becoming mindful of how you introduce change is a very useful skill to develop.

When I look back at my 13 years of introducing change to larger organizations, I have gone through my own metamorphosis of how I encourage change. All three may have their place, but the more effective are the last two.

  • The Bulldozer
  • Fine Tuning
  • Leaning In

The Bulldozer

Introducing a framework such as Scrum, is an example of the bulldozer approach.  When you jump into Scrum with a team of people who are new to the framework, it’s very disruptive and chaotic. You are basically shoveling a massive change onto the team. It’s not necessarily bad to use the bulldozer tactic to introduce change, but it should be the exception rather than the rule. If you embrace the idea that this is massive change, you can help manage expectations of the team and people external to the team. IMG_0137

Personally, I love change. I get very bored of routine and introducing change just to do something different keeps things interesting for me. The majority of people don’t love change. Especially change introduced by someone else that has little relevance to your world or even a detrimental effect. I learned through the experience that bulldozing change onto others usually doesn’t work, unless there is a selective deliberate application, such as jumping into an Agile framework.

Fine Tuning

Once you are into a rhythm with your Agile framework the massive changes slow down and the team slides into a pattern of incremental changes. I have noticed that my teams have transitioned into a rhythm at about the three-month mark after starting Scrum. You don’t see the impact right away, but if you are maintaining your metrics properly, you can gauge whether the tuning has an impact over time. Even when retrospectives seem rote and stale, don’t give up on these valuable opportunities to keep tuning the team. If your retrospectives do become stale, change it up with games that teach a lesson, or use different retro formats to keep it fresh or even entertaining.

For a year I worked with a team that used the fine tuning approach.  The team would review processes every two weeks and talk about things that could improve their performance. From month to month, it didn’t look like much change, but year over year, this team experienced 320% increase in productivity. Through selective tuning such as adding key personnel, becoming more cross-functional, reducing bottlenecks, stabilizing the team, solid backlog grooming, and a number of other small efforts this team was able to fine tune themselves into a highly productive team.

Lean In

This has been a hard learned lesson for me. I think the lesson of “leaning in” is something I first learned in Lyssa Adkins and Michael Spayd’s Coaching Stance workshop, but it has taken me some time to fully let the lesson sink in and apply it. Learning to be a coach through using coaching techniques applied in the specific Agile context was a powerful learning experience. I volunteered for one of the first demonstrations in the class introducing us to the idea of what traditional coaching was about. It was amazing to be listened to deeply and uncover ideas that I held within myself.

I used the term Agile Whisperer in the title of this post because of how I perceive whisperers (The Horse Whisperer, Dog Whisperer) engage with their subjects. They are acutely in tune with their subject whether it’s a horse, a dog, or a baby. They pay attention to it’s natural instincts and use those to achieve a desired state: accepting a saddle for a horse or eliminating negative behaviors in a dog.

In the Agile environment, the subject is our team. By “whispering,” it means adopting the characteristics of these other whisperers and getting deeply in tune with what is happening already on the team and leaning into aspects that are currently exist to achieve desired change. In essence, leaning in is learning to be quiet, bide your time, observe the team, listen carefully and look for the things they are already doing that contain elements of the change you want to introduce. If you must speak, ask questions. Pay attention to where there is lots of energy and conversation on the team.

When you join the team, go ahead and make the list of things you want to see changed. Depending on the environment, sometimes you can start discussing with team members or even the team at large (see Fine Tuning). In the Leaning In scenario, though, back up. Don’t talk. Be quiet for a while. Sometimes it’s hard to look like you’re doing nothing when, in fact, you are carefully observing and listening to the team. This is when you take ego out of your intention. If you do it well, the team won’t even realize your influence in the change. They’ll think they did it themselves. And that kind of change tends to stick much better.

I had an example that drove this lesson home to me. I had an environment that made introducing change a bit of a challenge. I had been noticing something in the way our stories were developed. A light bulb went on when I got into a discussion with a team member and realized there was an opportunity for a fairly substantial change to the team which would also have downline impacts such as dividing the larger team into smaller subteams.

Circumstances made it difficult for me to introduce this change immediately. Instead, I started paying close attention to where the really good, cross-functional conversations were happening on the team. In that week, I noticed those conversations had the elements of cross-functionality that that would be a core part of the change that I had been wanting to recommend. The key then, was pointing out what the team was naturally doing, asking some questions to bring attention to the good elements of this behavior, and posing the thought about organizing around this natural communication behaviors and making it more intentional. As I approached the change from this angle, team members jumped on the idea and ran with it. Introducing this significant change has been the least challenged thought I’ve ever presented because it was really based around what the team was already doing and simply embracing it and making it intentional from the start instead of a byproduct of final activities.

To sum up, if you are encountering resistance with introducing change, try leaning in and becoming an Agile whisperer by using noticing good behaviors that naturally emerge, calling attention to it, and making that intentional.

Pin It

Keeping the humanity

I’m planning to start a blog project writing about my experiences using Agile in companies transitioning from waterfall methods to Agile. The primary goal is to document my experiences. As I was thinking about this project, I was reflecting on how I use Agile outside of the boundaries of IT. It has been great to see efforts like Scrum inventor Jeff Sutherland’s Scrum, Inc. spreading Scrum beyond IT. Personal Kanban is another effort at going beyond IT. I have been enjoying these posts about using Kanban in the family to manage chores. Nag-less chores! How cool is that!

I’ve been wanting to contribute to the movement of spreading Agile beyond the borders of IT. I was messing around with the Agile Manifesto, wanting to translate it or take the IT jargon out of it. For non-IT teams, it only required a tweak of the phrase “working software” to “work product.”

We are uncovering better ways of developing software working by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software Work Product over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more

Very interestingly, though, when I looked at translating this for Individuals, it became obvious that individuals already work this way.

Solo entrepreneurs already focus on the human interactions over processes and tools, results over documentation, conversations over contracts, being flexible over following a plan. As the company grows, the things on the right come into play and need to be learned to manage a larger group of people. But, at what point in a company’s growth is the humanity lost and the focus on the items on the right so strong that we need a manifesto like the above to call us to our senses?

I don’t have an answer. But, this is something a start-up or small company might consider as it’s developing its culture.

Pin It

2013 Blog Project

I have decided to do a project for 2013. It will be a “three-book” project called “Scrum for…” Initially I was planning to publish one chapter per week, but I think that is a bit aggressive for me at the moment. However, by publicly declaring my intention, it will help me follow through.

As project manager, I am really a Scrum Master layering in Coaching practices in the Agile field. For the uninitiated, you might be scratching your head and wondering what a Rugby huddle has to do with IT and how does a klutzy person become agile? Agile is a type of project management framework that has been developed to improve the management of Information Technology projects. Scrum is one flavor of this Agile framework. Apparently the inventors of this framework of time and project management felt the teamwork displayed in Rugby was an appropriate metaphor for working together as a team on IT projects. It stuck. So, I am a Scrum Master. I have recently started studying Kanban. In 2012, I started adapting some of the core principles I have learned from my day job into a special set of courses for individuals. I enjoy using Agile frameworks at work and think the principles can apply to time and project management in non-IT teams as well as individuals.

I have primarily worked companies that have the traditional Control culture. There are unique challenges with adopting the team-empowering, self-organizing habits espoused by Agile in the traditional environment. In my second project, I started writing down lessons I wanted to remember for future engagements. Then I started turning it into a training book.

I kept writing while trying to find “the hook” that I wanted to use for the book. I transformed my approach several times. At first, I thought I would write it to help “democratize Scrum” by creating an inexpensive, step-by-step version of implementing Scrum. Peter Saddington already did that. Then I started pursuing the angle of having a DIY Scrum with step-by-step instructions and templates that would allow anyone to implement Scrum without a coach or teacher. Then I started thinking it would make a better supplement to training, by having the daily step-by-step start-up instructions for standing up a new Scrum team. I wrote half the book, even submitted it to a publisher, and then shelved it. The field is already very, very crowded with very good books.

However, I started digging up this idea again because I still constantly refer to my notes to help team members, management, product owners, project management offices, and whoever needs help understanding Agile in their current context. I am also glad I shelved the book, because it has allowed me another year of experience on three very different Scrum teams. More lessons learned! Still in the same Control culture. I realized that if it was still useful to me, I might as well publish the knowledge as a weekly series on my blog. The side benefit would be that it would help establish my reputation in the Agile community and provide insight in my knowledge as a Scrum Master (I am actually a Certified Scrum Practitioner) for future companies that might be interested in hiring me.

Then I started thinking: but this information is so helpful across any kind of project, not just IT! That is when it occurred to me to make it a “Three-Book Blog Project.” I decided to expand it to: a de-Geeked version – a version that has IT jargon stripped out and written for for “regular people” in normal teams like Marketing, Product Development, even construction. Since I had already started developing how to apply the principles at the individual level, I want to write a third version that translates the lessons learned from the IT Scrum to individuals, and again, strip out the jargon and make it accessible to every person. Since I have direct experience in helping IT teams use Scrum, the basis for the books is the Scrum for IT version. The other two books will be a translation of my experience into the non-IT and Individual version. These three books will be published one chapter per week starting in January of 2013 and most likely go into 2014:

  • Scrum for IT Teams in a Traditional Companies
  • Scrum de-Geeked for Regular Teams (not those IT Geeks)
  • Scrum de-Geeked for the Individual

The blog version will be freely available on my blog, with a table of contents that links nicely to each chapter. Since this is the writing-intensive portion of the project, the graphics and photographs will be very limited.

Pin It

Serious SNOS

I know I posted to “check back next week to talk about managing SNOS.” (SNOS = Shiny New Object Syndrome.) Well. I also mentioned I’m suffering from SNOS. I got so distracted with all the SNO’s, that I forgot to post! … This is serious…

So, anyway! I’m hyper-focused on rebuilding my basic routine. I had struggled with a bout of chronic migraines for the last six months. I am now on the recovering side of this episode. Even though I am on the upswing, I am still dealing with the far-reaching impact this period had on my regular routines. Thank you for your patience!

Now, the subject at hand:

Shiny New Object Syndrome and the Solution

Just to recap: You are officially suffering from SNOS when you have 15 or more ideas that are started and not finished. You begin to feel overwhelmed. You lose track of all these SNOS’s that you are working on. And sometimes you shut down.

The solution, in a nutshell, involves focusing your attention to a limited number of items and not starting anything else until you have completed that small set of items.

In the project management (and personal time management) vernacular, it is called Limiting Work in Progress. This is a concept tied to Kanban and Personal Kanban. In Personal Kanban, you decide on a limit of items you can start (say 3 or 4) and you DO NOT start any other items until those are finished. With a lot of tasks or items we start, sometimes we cannot finish them because we have a “roadblock”… something that is preventing us from moving forward to completion. The roadblock can be anything, from lack of inspiration or needing an answer to a specific question, to name just a few. You can put something on hold or in waiting and start another task. However, once you have reached your limit (say 4 items), you do not start any other tasks until you have removed the roadblocks on those other tasks and you can finish at least one.

Hyper Focus

Another term I have heard used was by  Kelly Rae Roberts. In referring to her methods of personal productivity, she called the technique Hyper Focus. I thought this term very descriptive. A short aside: very interestingly, this term is used in connection with those suffer from ADD and ADHD. The term is used in connection with the ability to focus intensely and with great attention. The negative side of this ability is when the focus happens: for example, if you get lost in researching an e-class, but you need to get ready for your art show, this is an example of inappropriate hyper focus.

However, I like the descriptiveness of Hyper Focus as it really provides a quick understanding of what we’re trying to achieve with this technique. The Urban Dictionary provided this definition to Hyper Focus:

“A theoretical state of being or ability in which one is able to concentrate and focus on a particular subject so intensely, ultimately becoming oblivious to everything else around.”

So, one of the keys to practicing Hyper Focus is not allowing other distractions (checking, Facebook, Twitter, taking phone calls, watching television, etc.) interfere with your concentration on the task at hand. This intense concentration and focus really increases your productivity tremendously. Also, by not starting any new tasks that are over your Work In Progress limit, you can provide some serious productivity gains with your time.

In the hyper-connected, multi-tasking, multi-focused world, it takes discipline to Hyper Focus on the appropriate task.

What do you think? Do you have a task that you could test out this concept of Hyper Focus?


Pin It