; charset=UTF-8" /> Agile Scrum Consulting & Training Reflect early, Reflect Often, Almost Reflect Always; Don't be afraid to learn. Don't let your head work alone for long periods of time.

Doug Shimp – Agile Scrum Coach

I love the intersection of people, technology, culture and great products.

Learning To Be Comfortable With Success

There are at least 3 steps towards learning to be Comfortable with Success.

The first is making many mistakes and admitting to them.

Discover: I am not talking about being sloppy. The universe is relentlessly complex. Try many things and admit when it is not working out as you expected. “Reflect early & often“. Most people and organizations I encounter actually have a hang up with being able to look straight in the mirror and say that they made a mistake. The fall into a trap of predictive thinking for complex stuff. They think they can tame complexity easily. In both cases of people or organizations, not being able to admit and make mistakes shuts  down the whole approach to learning. By not admitting we made a mistake we drop the practice of the scientific method  and shut down simple open inquiry. Said another way we stop seeking feedback and shoot any messengers with bad news. Innovation and creativity are born from a sea of attempts and most of those attempts will not pan out (call them mistakes or whatever word works for you).comfortable with success

The second step is to never stop trying.

Persistent: ”It dosn’t matter how many time you get knocked down it only matter if you get back up.” Even when you cannot succeed at something a committed person or organization will keep trying. Trying in an almost mindless way. And sometimes still succeed (the hard part is we just don’t know where success will show and it is hard to know when to stop and try something else). The difficulty is learning how to back off and point your energy elsewhere. Again a habit of reflect early & often. For organizations this can be especially trying and can create a tension in tying to redirect energy elsewhere. Often people take it as a personal failing and feel like their position is being undermined by being asked to stop working in a direction that has not yielded any favorable results. The classics response is to get tough with them but, this fails to engage them fully on the next task because they never deal with the regret. An emotionally healthy thing to do is to help them let go and transition. The other end of the spectrum is organizations who behave so frenetically that they never really try because they are changing direction all the time. They trample their own ethics into the ground.

The third step is learning to be comfortable with success.

Win: Is perhaps the most fuzzy and elusive of the three steps. It is not about enjoying the after effects of success. It is more about being in the moment and amplifying that success and seizing it instinctively when it is at hand. For some, being in the lime light is the only thing they desire and they flourish at this step but, the above two steps constantly befuddle those types of people and organizations. Really the above two steps are sequential for those who are not innately comfortable with success. You almost need permission to give it your best and be dramatically successful. Being told you are good at something creates a state of affirmation that empowers those who are uncomfortable with success. The person or organization who is uncomfortable with success is chronically humble. Now the interesting thing is that “Reflect Early & Often” does not apply. It applies afterwards but, you have to learn to be comfortable in the moment and there is no time to learn as success is happening. Simply smiling and saying thank you is a right display of behavior but, you have to do more than that you need to feel comfortable in your skin at that moment in time so that your instincts respond correctly.  If you do not feel comfortable in your skin you will dampen your instincts on what is working and not react smart when opportunity passes by.

Learning to be comfortable with success.

Poem: A Reminder

Refect Early, Reflect Often.
Don’t be afraid to learn.
Kindergarten skills over technical skills.
Make it visible.
No head works alone.

Hope this can serve you as it has served me.

- Doug

Orlando Scrum Gathering and CSD

It’s March 5th, 2010 and a new Scrum Gathering is about to start. I find myself on the way to the Orlando Scrum Gathering to meet with my peers in the community. I am excited for this trip because of all the work being invested in a Certified Scrum Developer program.

The program is off to a great start and seems to be generating the right kind of focus. If the CSD Program can bring or highlight the skills that both developers need to write better code and management needs to lead complex development effectively then it is doing the right thing.scrum gathering orlando agile conference csd

Each certification program from the Scrum Alliance comes with it’s own challenges and risks. Sometimes it appears to be  just a stamp that says you know something. Right now it does behave that way but, it also continues to bring a focus on what is really helping companies develop better products by humanizing the process. The days of classic command as control paradigms are being replaced with smart adaptive strategies that enable the discovery of real solutions to challenging problems. I am optimistic that the Certified Scrum Developer program will be a success and see a major boost this year from the Scrum Gathering conference.

I am excited by the gathering because I get to interact with my peers. They always challenge me and teach me. The  Scrum Alliance has been a great place for growing a community deeply passionate about applied agile practice and growing many new thought leaders in agile.

Hope to see you there this year or next.

Is Microsoft Going Agile? Good Video

Great lead in question by Scott Gruthrie Silver Light team at Microsoft.

It is really not a choice so much as it is a discussion about how they can re-invigorate their very agile roots. Agile is not yours to keep, to remain agile you must practice the fundamentals. Microsoft has clearly been very agile in the past and acquired very agile organizations. My question becomes — How do they get it back or get it again?

The video is found here.

My comments follow

The word Agile:  We can take it in different ways for different microsoft has evolved many directionspeople but, from what I have experienced it is often a mess in understanding. There are very few good stable definitions out there from which to build a know center of understanding. Too often marketing has taken hold of the word and warped it’s meaning for personal gain. Or agile “experts” have not really nailed the term down to anything stable. Nothing is wrong with that, it’s just good business or people learning. However, the result is that it permeates a very messy set of understandings into the community at large.

clean code helpsClean code and clean tools allow for rapid feedback which enables a quick practice of agile understanding. A good IDE will enable rapid feedback so that the fundamentals are practiced continuously. When I use the word fundamentals it is like in basketball. You are never done dribbling the ball. Unit tests are a way to achieve rapid feedback but, like all of the agile practices not a panacea. Unit testing is a piece to a bigger evolving puzzle.

Common mistake when people view Microsoft is too see it as one company. My experience is they made up of many subgroups or companies within a larger framework. Some subgroups are very agile and some are not. The agility is not evenly distributed and understood within Microsoft. No surprise there, every big company I have consulted with has this problem. Some groups (teams and individuals) within Microsoft are great agilists, not all. They have some of the best in the world.

It was a good quick talk on adopting scrum and agile.

- Doug

Do People Pay More Attention When They Are Being Assessed?

Recently I had a discussion with a few peers about how to use assessments and exams.

The conversation went something like this.

“People who know they are being assessed will pay more attention in a training course or at their daily work. We need to use exams and assessments to getscrum punish learningthem to pay more attention because otherwise they will just flake off. People are inherently lazy and we need to make sure they work.”

The conversation above sounds like a hidden threat. The threat I see goes something like… If you miss something you are in trouble on the exam or “Pointy Haired Dude” is watching…. This is an old school paradigm that destroys critical thinking in my experience. For example, the issue of an Exam has dogged classic PMP training and has generally pulled down the quality of critical thinking across the spectrum of corporate environments. It dogs classic workshop training when the conversation moves from “whats the best way to think about this ….. to ….. will this be on the Exam? If not on the exam then, can we move on to stuff that will be on the exam?”

When people become more concerned about the exam or assessment they have often stopped thinking critically. For agile training, which is most of what I do these days, people can easily fall back to old learning styles of known answers to known questions. Most of today’s business problems are demandingly complex and do not have predictable outcomes. A test or exam is a simple predictive Q/A model and that includes the situational stuff as well. For situational stuff, I just memorize the abstract pattern for which the situational question is written for and then answer according to the pattern. To deal with complexity people need an empirical thought process for the finding stuff we don’t know we don’t know. Cramming more factoids into adult heads is counter productive. As adults we typically have more than enough information crammed in our heads. The question becomes “Can we make better use of what we already know or have experienced to deal with uncertainty?

In my experience, open reflective learning will occur and empirical behavior will result when, as a trainer/leader to I make the environment safe for learning. As a manager/director of people the same policy holds true, if you punish people for making mistakes they will stop making mistakes by trying not to do to much beyond what is painfully obvious that needs doing. In either case, learninig is shut down for knowlege workers. Sharing of knowledge, both tacit and explicit, comes to a halt and the organization’s ability to learn atrophies because those muscles are no longer being used. At this point the best we can achieve is a pursuit of efficiency and what you find is a focus on faster / cheaper / quicker. Anything that is different and innovative gets squeezed out by the fear of not doing something that is well understood and controllable.

Innovation is needed across most areas of today’s corporation. Learning should be part and parcel to every engaging job and challenge. For innovation to occur people need to focus on learning and that means expect mistakes. If they do not feel safe they will make feeble attempts to do some new things but, never really bravely reach out of their comfort zone. If you are hiring for factory / robot type positions then expect robots but, knowledge workers are key for innovative culture and fresh ideas.

People in my workshops pay attention because they care and I care. It is a social bond. As a leader/trainer you set a behavior pattern that will be modeled. Are you modeling “I am watching you!” ? People that work/report to me pay attention because we both care to do the best. Those that don’t care can and should be asked to leave or excuse themselves until they sort out their destructive tendencies. I call not caring destructive because it destroys empirical behavior .

Generally, it is useless to retain people that do not care. In most cases the overhead of managing them is in excess of not having them there. Which sadly means I am better off doing the job myself. As a leader or trainer your first job should be to foster an atomosphere where learning is safe and encourage your people to become learning machines. Better teams make better people who make better products.

  • At the forefront of learning is where innovation occurs.
  • Learning is about knowledge creation (see Nonaka’s paper).
  • Knowledge creation is an interactive process.Organizations that foster learning reach new heights.
  • People that are in learning mode are paying the best kind of attention.
  • A good scrum process enables the team learning process.

Maybe I am completely off my rocker :) but, I found the conversation interesting.
- Doug

Austin Agile Keynote


VersionOne was kind enough to invite me as a presenter to a small conference event in Austin on December 7th 2009. The Austine keynote went well and I was lucky enough to be ranked as the best presenter at the event. There were 90+ people in attendance and 78 people filled in an evaluation.

Catch me in Austin, TX delivering a Keynote for the Agile Journal December 7th,  http://www.accurev.com/seminar/austin20091208-4

Kanban Vs Scrum

Below is a Keynote presentation that I gave to an small conference in Austin On December 8th, 2009.

Certified ScrumMaster Course on Feb 8, 2010. Details Here

Scrum_vs_Kanban_v2Kanban for software development is a newer kid on the block, at least in the US. Besides being just another word like Scrum that is not commonly understood in the English language, how does it stack up? Both Kanban and Scrum align with the well with the value system described in the Agile Manifesto. And they make an interesting pair.

As much as we love Scrum, even we would have to admit that it’s not perfect.  Nothing is. In fact, a large part of the literature describes workarounds for various deficiencies that Scrum presents to us in certain circumstances.


One of the more commonly noted deficiencies in Scrum is that it plans its work a whole Sprint at a time.  This “batch” planning process is often not agile enough to cope with the actual rate of change of requirements.  In fact, PlaceHolder Stories, discussions of mid-Sprint Re-planning, and discussions of renegotiating the scope of a Sprint are common deficiencies that teams must cope with.

The new kid, called Kanban, which solves some of these deficiencies and presents others, is becoming popular for software development projects.

Altogether, Kanban, Scrum, XP and many other agile methods rely on a task boards and index card like systems to simultaneously decompose and manage the work. What’s new about task boards and index card systems? Index card systems have been around at least since 1925, when the first one was formalized by Dr. Crawford and used later to build NASA rockets. Increasing task orientation is a well understood method for improving team performance and has been well documented since the 1950s. Our goal will be to highlight both Kanban and Scrum and then touch on why we need to reinvent them ourselves so often.

Learning Objectives

  • An overview of Kanban
  • An overview of Scrum
  • Stacking them side by side
  • The Power of Index Card Systems and Task Orientation
  • Can one reduce or evolve from one to the other?
  • Why do we repeat ourselves so often?

Does self organizing team imply self assembly?

  1. Yes, organizations should let teams form by choosing their members.
  2. No, teams should be created and then self organize.
  3. Self organization does not work and therefore self assembly is irrelevant.

Discussion: The word self organizing is a little fuzzy for me.

fuzzy-teams-sharp-terms-self-organizeThe way I think about self organizing teams is that they are  pre-assembled. After assembly a pressure is applied to respond to a demand. The demand is articulated
in the form of a story/project (don’t want to dice those words right now!) And the pressure is from a business that provides support as long as … You produce something of value! “Eye on the Prize

The demand is applied such that we get feedback. That feedback has a sensitivity that can be adjusted or tuned like a dial. The dial for agile/scrum teams is easily seen in the form of a story (Chunk of Work) level  and can go up to the thickness of a project/product. If the demand goes unfulfilled then there is an implied threat of dissolution against the team or even loss of job individually.

Sometimes the support is so strong that we can ignore the demand and turn our noses up in the air. Big government / orgs often feel like that to me. It just do not matter because nothing bad will really happen so why sweat the small stuff. Even if that is not true and something bad will happen if it feels like nothing bad will happen then the behavior often develops a “don’t sweat the small stuff” approach.

Is self organizing the best way? I think that depends if it humanizes the workplace and makes better people with more compassion while igniting creativity to help the business thrive. Demands must be seen as real and consequences for failing to work well with others must be imposed.

Will Kanban replace Scrum?


  1. No way, they are opposites
  2. Kanban is for flow / Scrum batch
  3. Yes, Scrum is old school big planning steps
  4. Kanban minimal planning / Scrum is heavy planning
  5. No, Scrum can reduce to KanBan
As much as we love scrum, even we would have to admit that it’s not perfect.  Nothing
is.  In  fact, a  large part of this book describes workarounds  for various deficiencies that
scrum presents to us in certain circumstances.
One of the more commonly noted deficiencies in scrum is that it plans its work a whole
Sprint at a  time.   This “batch” planning process  is often not agile enough  to cope with
the actual rate of change of requirements.    In fact, Chapter 4.4 on PlaceHolder Stories,
the  discussion  of  the  mid-Sprint  Re-planning  in  Chapter  4.8,  and  the  discussion  of
renegotiating the scope of a Sprint in Chapter 4.3 are all about resolving this deficiency.
There  is  another  agile  process,  called  KanBan,  which  solves  this  problem  and  is
becoming popular  for  software development projects.  In  this chapter we will describe
the main strength of KanBan and how to integrate it into scrum.
Brief Description of KanBan
The  “KanBan  for  software” movement  is  led by David Anderson1
, and  is  really gaining
some  traction  in  the  agile  community.    The main  idea  of  KanBan  is  very  simple  and
based  on  the  Lean  “pull,”  “Just  in  Time”  (JIT),  and  “reduce  inventory”  principles:
eliminate planning inventory by making sure that you don’t commit to doing work until
you are actually ready to start the work.

kanban-flow-scrum-batchAs much as we love scrum, even we would have to admit that it’s not perfect. Nothing is.  In  fact, a  large part of our book describes workarounds  for various deficiencies that scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in scrum is that it plans its work a whole Sprint at a  time.   This “batch” planning process  is often not agile enough  to cope with the actual rate of change of requirements.    In fact, Chapter 4.4 on PlaceHolder Stories, the  discussion  of  the  mid-Sprint  Re-planning  in  Chapter  4.8,  and  the  discussion  of renegotiating the scope of a Sprint in Chapter 4.3 are all about resolving this deficiency.

There  is  another  agile  process,  called  KanBan,  which  solves  this  problem  and  is becoming popular  for  software development projects.  In our upcoming book we will describe the main strength of KanBan and how to integrate it into scrum.

Brief Description of KanBan

The  “KanBan  for  software” movement  is  really gaining some  traction  in  the  agile  community.    The main  idea  of  KanBan  is  very  simple  and based  on  the  Lean  “pull,”  “Just  in  Time”  (JIT),  and  “reduce  inventory”  principles:  eliminate planning inventory by making sure that you don’t commit to doing work until you are actually ready to start the work.

When are you ready for sprint planning?


  1. The PO says go.
  2. The Teams says they are ready.
  3. The SM has determined a time box for the sprint.
  4. The team and PO agree to a time box
  5. The PO understands and is prepared to talk about the stories

ready-sprint-scrum-planningComment: There are a number of things you should do before you can even begin planning.  The most important thing you can do is make sure that your Product Owner is prepared, and understands what the stories are about.  Remember that the Product Owner is a role here, so what we’re actually saying is that someone on the Team knows about each story; that is, each story has its own champion (Story Owner) who represents the Stakeholder’s needs/wants to the Team. This may require that the Product Owner (person) coordinates the efforts of all the Story Owners.