I was on vacation last week and was working on a blog post when my 5 year old barged into my office asking me to play dominos with him.  I figured I needed about 10 minutes to finish up the post so I asked him to go look at his clock and tell me what time it was.  He rushed out, came back and said, “daddy, it’s 9.25” so I said, “I will play dominos with you in 10 minutes.”

Expectation set.

At 9.35 he comes back in, grabs my arm and says “ok, its 9.35, lets go play dominos!”

“Hang on dude, I need a few more minutes…”

“NOOOOOO he says! I want to play dominos!”

Trust broken.

The great thing about kids is how they live in the now.  I set the expectation that I would play with him in 10 minutes and I broke that commitment.

So what happened?

Bad estimate finishing my post I suppose.  Maybe I gave an estimate based on what I thought was a realistic time frame for a 5 year old to wait regardless of the effort left on the task.  As a result that time-crunch probably led to lack of focus and it all went downhill from there.

Bottom line is I set an expectation, I broke the commitment and the consequence was the dreaded “5-year old melt-down.”

There’s a lesson here, well, a few actually.

1) Trust: When a team sets an expectation with their Sprint commitment they’ve largely said “trust us, we’ll get this stuff done in 2 weeks”  If teams get into a habit of setting expectations and not delivering, that trust will be broken and that has consequences that are much more serious than “oh well, we’ll do better next time“.  The product owner, stakeholders/customer or whoever, won’t believe the team when they estimate stories or when they make Sprint commitments.

Without trust you’ll end up piling more process on top of already existing dysfunctional process to account for the lack of trust.  Sometimes we like to call these “gates” and mask our distrust as “accountability or responsibility”

2) Team Responsibility: When a team sets an expectation, they are responsible for living up to that expectation.  If the team misses the commitment they should be pissed off they missed it.  Of course, when they nail it, it feels good.  It feels good to finish something and present the work to others in the organization.

Without team responsibility you’re just breaking work into 2 week chucks and not behaving any differently.

3)  Personal Satisfaction: Personal satisfaction is a great motivator.  Harvard Business Review posted an article on what really motivates people and progress was the number one factor.   Setting an expectation in the Sprint Planning session and showing the result at the Sprint Demo shows progress which is a great way for team members to feel a sense of personal satisfaction.  This is more important than managing by fear (the STICK approach) or managing with carrots (the REWARD approach).

These 3 factors are closely related.

Lack of personal satisfaction can lead to lack of team responsibility.  Lack of team responsibility can lead to commitments being missed which will lead to a lack of trust between the team and the organization/customer/stakeholder.

The difference between my story of breaking my commitment with my 5 year old and a team breaking their commitment is that I can re-gain that trust easily by saying I’m sorry and by taking him out for some ice-cream.

Chances are a team only has so many ‘get out of jail free’ cards and a pattern of missing commitments isn’t only going to kill your Agile initiative, it’s going to do damage to your business.

Related posts:

1. Learn the Secrets of Collaboration…From Your Kids One of the simulations I like to facilitate during...

Related posts brought to you by Yet Another Related Posts Plugin.

One of the simulations I like to facilitate during training sessions is a simple penny flipping exercise learned from Mishkin Berteig to show how the team approach can lead to substantial improvement and productivity gains.

The idea is simple, have the attendees work in a serial process where they have to pass the penny from person to person.  The goal is to get the pennies facing heads up in ‘the product environment’ (which is a piece of paper) at the end of the chain.  The second part has the same goal, but the teams can accomplish it however they want. I usually repeat the second part a couple of times to prove the meaning behind the exercise.  I’ll add a post with the mechanics on this game later.

Anyway, last night my 2 kids and I were playing dominos which always results in a living room disaster since we have a few hundred of the them.  20 minutes for me to set them up, 10 seconds for them to knock them down.   When it was time to clean up I simply stated the goal.  ”Ok guys, time to put all the dominos away in the clear bin“.  Just like a high-performing Scrum team, we started singing the Wonder Pets Teamwork song (what’s gunna work?  TEAMWORK!) and each “team member” started cleaning up.

My 4 year old son started picking up the dominos nearest to him, same for me and my 3 year old daughter.  The bucket was pretty much centralized between the 3 of us.  After we had cleaned up the dominos closet to us, my son immediately took the bin, moved it to the next ‘batch of mess’ and we proceeded to start with whatever dominos were nearest to us.  My daughter had walked towards the pile my son started with so she quickly self-adjusted and started on another pile.

I was stunned.  The collaboration was completely instinctive and there was very little, if any, discussion.  We all knew what the goal was and we all chipped in.  Once there were only a handful of dominos left, all 3 of us focused on that so no one was idle until there were less than 3 dominos left.

Sounds silly, I know, but the Agile principles were were much apparent to me during this clean-up session:

• all team members understood the goal
• team members self-organized
• team members adjusted based on work remaining
• team members started with highest priority items (as in, we all started with the pile in front of us)
• we had fun while working! (For those who don’t have kids, trying to convince a 3 and 4 year old to clean-up is not really that easy most of the time!)

I often get complaints in training sessions about the simplicity of the exercise and that moving pennies is different than real-world work.  I agree, it is but applying the one-team, shared goal value is more important.  Once folks buy into the team system, the rest of the work falls into line much easier.

Related posts:

1. Simple Exercise to Demonstrate Value of Collaboration This is a quick and simple exercise I ended...

Related posts brought to you by Yet Another Related Posts Plugin.

Ah, good old re-work.  The thorn in the side of Scrum teams, the impossible mountain to climb for development teams.  Re-work is un-avoidable.  When people see working software, they get new ideas and might want some changes.   Here are some thoughts for handling re-work based on a few scenarios that popped up at work this week.

If We Knew Earlier, We Coulda Did Something About it

Situation: During our iteration demos the team I’m working with found that they had improvements and suggestions now that they could ’step back’ and see their work.  Other folks who we invite to the demo would have some small ideas or our Product Owner would have some suggestions that were nit-picky, but nonetheless would be better for the user.

Problem: Waiting too long to get feedback.

Solution: I’m happy the team came to this conclusion themselves in the retrospective.  One of the team members posed the question that why don’t we show our product owner immediately when we complete the story and not wait for the demo?  Side note: I’ve mentioned this to them a few times, but it was great to see them take a problem and apply the learnings on their own.

Splitting the Iteration into Work and Re-work Phases

Scenario: There is too much re-work at the end of the iteration so we are going to take our 1 week iterations and shorten them to 3 days so we have 2 days to do re-work.

Problem: too much WIP and lack of communication between team and product owner. (In this scenario the product owner isn’t available full-time to the team and the proxy he assigned can’t always make a decision). There are a few other things happening here as well.  The work this team does is non-software and they rely frequently on interacting with people in other departments.  They’ll start something, get blocked and move on to something else therefore creating a great deal of waste.

Solution: The team has been struggling with this for a few iterations, I’m not working with them but did have a chat with their Scrum Master since he felt it was a failure on his part.  Not so at all.   I told him maybe trying to hammer Scrum into their work-style wasn’t the best thing to do.  Perhaps a Kanban system would be more effective for them.   We talked about what that meant and they’re not ready for that so instead they’ll try communicating with the product owner more often and help the PO understand he needs to be available for the team to fulfill their commitments.

Agile/Waterfall Hybrids is What we Did!

This one came up in a training session I was doing.  One of the attendees said mixing waterfall and Agile can work because in his experience there was no way to handle re-work in Agile.  The solution to this is similar to the first scenario I discussed at the start of this post.

The root of this problem is not getting feedback early enough or the lack of daily communication between the Product Owner and the Team that is required when using an Agile process.  A deeper problem was the apparent separation between programmers and testers on the team he was talking about.  I wasn’t able to deep-dive into the scenario since it was in the middle of class but I offered some suggestions about why it might be happening.

All of these examples, in my opinion, are some of the main reasons why companies fail with Agile.  They interpret “Agile” to mean flexible and let’s just change the rules to make it work for us.  While Scrum is a simple, adaptable framework, the fundamentals shouldn’t be changed to accommodate a broken process.   This type of dysfunction can lead to mis-trust between the Team and the business and also cause a rift between programmers and testers as they will start to ‘fall back’ into a waterfall mentality.

It’s important that the Scrum Master or Coach help the teams struggling with this to understand what the real underlying issue is and to work through it.

Related posts:

1. A Week in the Life of an Agile Coach – Tuesday 9:15am - I arrive at the office, check my...

Related posts brought to you by Yet Another Related Posts Plugin.

Recently I had a brief messenger chat with a former co-worker that they determined they were actually using Scrum-ban instead of Kanban.  The timing of this chat coincided when I seemed to be coming across a multitude of discussions about what is/is not in Scrum, what is/is not Kanban and so on.

My initial response was “is what you are doing working?“.  Her response was, “yes“.

My response, of course, then was “so why does it matter?”

I do understand the desire to have these processes defined but I’ve never much been a fan of labeling.  Being “Agile” isn’t about using Scrum, Kanban, Lean or any other tool/process, it’s about being dedicated to empirical processes that work within the context.  I also understand the dangers of  ”Agile” being tarnished by misused practices but by and large solving problems and rejecting the status quo are what really matters at the end of the day.

As an example, a few months ago a team member who was recently kicked off the team BY the team decided it was worth his time to prove a point by finding a page in Ken Schwaber’s book that mentions it’s not a rule for the team to stand-up at the daily scrum.   My reply was pretty simple in the sense that I never said it was a rule.  I explained to the team why it’s a good idea to stand-up and the team decided they wanted to sit, so they now sit. (results of our daily ’sitdown’ here).

Is sitting at the stand-up a Scrum smell?  Probably. I don’t care though.  The team gets more value out of sitting.

Before I knew what “Agile” was, common sense would dictate that if something isn’t working, find a better way of doing it by trying something new. I believe that’s much more valuable than worrying about what label you put on it.

Related posts:

1. Is it Dysfunctional to Sit at Your Stand-up? It’s called the daily standup for a reason.  It...

Related posts brought to you by Yet Another Related Posts Plugin.

One of my favourite scenes from Tombstone is when Ike Clanton says to Wyatt Earp, “Listen, Mr. Kansas Law Dog. Law don’t go around here. Savvy?”  After Wyatt replies that he’s retired, Ike reiterates “Yeah, that’s good, Mr. Law Dog, ’cause law don’t go around here.”

A common theme that has been emerging from the classes I’ve been delivering and conversations I’ve been having are along the lines of “wow, we need to change our culture” or “agile won’t work here because … <insert excuse>“  There seems to be a clear delineation between these 2 camps.

I blogged previously about the importance culture has with an Agile transformation and I make sure that I convey that to anyone I talk to that is new to Agile.

The first statement I usually use to combat this fear, uncertainty and doubt is the fact that there always must be a reason to transform to Agile.  Companies aren’t switching for the sake of being cool and hip, well if they are they have bigger problems, but instead they are switching because fundamentally, the way they are working is broken.

Transforming to Agile requires a deep organizational commitment and a fundamental shift in how companies operate and how departments and people interact with each other.

So underneath the skepticism and FUD, what’s the REAL problem?  What are people afraid of?  Here’s a brief summary of the top 3 excuses for why Agile don’t go ’round here:

1) We can’t have a SINGLE product owner, we need multi-level signoff and too many people are “the go to guy”

2) Agile won’t work here, everybody works on multiple projects at the same time.

3) Management tells us we HAVE TO launch with all these features on this date.

Hmm.  So what do we do?  Where’s the Agile checklist that allows us to fix these problems?  I’ve seen Scrum teams absolutely banging their heads against a wall trying to figure out why their fixed-date, fixed-scope projects either don’t make it or have terrible quality.  In this cas,e the ‘rapid de-scoping phase‘ happens in order to make the date but in that instance the damage is already done.  The teams inability to say no has rendered their yes useless, mis-trust ensues and the cycle repeats itself.

I’ve had this post brewing for a few weeks and decided to post it after our pilot team’s recent success and after reading Gil Broza’s great post entitled “so you think you’re Agile?”

While our topics do differ, the underlying tone is the same.  Organizations needs to understand what being Agile is.  They need to look to the manifesto, not to the Nokia Scrum test or a checklist.  They need to un-learn what has been instilled through so many years of the command and control approach.

AYE helped me change my approach from saying “here’s what you’re doing wrong and here’s the right things to do” to “what are you concerned about?  what are your challenges?  how can the knowledge and tools I have solve your problems”

Lately that approach is working much better and I find people who want help are more likely to accept help.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Serge Beaumont posted a great article on the The Definition of READY at Xebia Blog.  While the concept of being ‘ready’ for iteration planning is already in Scrum, I have found that it’s not something that gets a great deal of attention.  Product Owners are left to “get stories ready” without having a clear definition about what that means to the team.

I think the power of self-organizing teams have trained people to leave out the “how” until the team decides that in the planning session but as Serge points out “how” is a by-product of iteration planning and I would tend to agree.  Teams need to have some understanding or thoughts of implementation before they can commit to a batch of stories and a Definition of Ready is a great way to get there.

The problem I see with the Definition of Ready is that it can be quite complex depending on the type of story.  You may have stories that require UI changes, look and feel or legal changes that would make your Definition of Ready bigger than say stories that are geared towards updating an API or adding simple functionality.

Should you define the definition of ready for each story?  Should you have a base definition of ready and add/remove items as necessary?

Personally, I would move to having a Product Owner work in iteration sizes that are half the length of the team’s iteration to prepare stories with the definition of ready.

Monday, Week 1:

1. Iteration 1.T (the teams iteration) starts

In the Teams iteration planning session the team commits to their work, does their detailed estimates and task breakout.

During this week the PO or Product Team is grooming the existing backlog, re-prioritizing stories based on output from the last demonstration and working with the customer, again, to groom the backlog.

Monday, Week 2:

1. Iteration 1.PO starts: this is the PO or Product Team’s iteration to “get to ready” for the next set of prioritized user stories.  The PO meets with the team to define what ready for these stories mean.

Friday, Week 2:

1. Demo session: PO “demos” the readiness checklist discussed in the 1.PO planning session
2. Retrospective:  1.PO iteration retrospective that will allow the PO or Product Team to improve how they “get to ready”

Monday, Week 3:

1. Iteration 2.T (the team’s next iteration) starts: The team defines and commits to the stories that were given the “ok on readiness” from the previous Friday.

The benefits of this approach is that all the “readiness” activities can (and should!) be timeboxed so there is an expectation that the team will need to participate in another short session.

It also helps get the PO and Product Team into a rhythm while also leveraging the power of retrospectives so they can improve on how they gather stories and get them ready.

I threw this post together rather quickly but it’s something I’ve had noodling in my brain for a while, would be very interested to hear others thoughts and experiences about how you get to ready.

Related posts:

1. A Week in the Life of a Agile Coach – Monday Morning I thought it would be interesting to share a...

Related posts brought to you by Yet Another Related Posts Plugin.

I’m glad to see the Scrum Alliance is taking steps towards a better testing process to designate certification, especially with the recently released CSM exam objectives.

There are some widely varying opinions on the validity of Scrum certification but I think, much like any education, it’s not the sole means of determining qualification for a position.

The naysayers will argue that a 2-day (which is now 3-day by the way…) CSM class only serves to dilute the quality of Scrum Masters in the industry and is somehow de-valuing and undermining the Agile world.  Their argument is that “Agile” is being mis-represented by giving folks a designation that is being misconstrued by companies that are hiring these folks.  These companies get a false impression of Agile because they ‘hired a CSM’ without experience and ultimately Scrum or Agile fail which leads them to believe that the Agile myths are valid.

When I first drafted this post, the tone was more about companies getting what they deserve if they hire someone with no experience, regardless of what job they are filling.  After re-reading it a couple of times, I decided to ‘be more agile’ and put my energy into suggestions that could help improve the value of the certification.

What Companies can try:

1. Get educated on what Agile is and understand what they are in for.  They need to understand one ‘certified’ person isn’t going to come in and wave the magic wand.  It’s a team effort to make a new agile adoption work or fix a failed one.
2. Understand what CSM means.  Sure it’s just a 2-day course, but it means the person has received a quality education and understands the Scrum process even though they might not have practical experience.  As with any education, it’s only as good as how it’s used after being obtained.
3. Shouldn’t only interview CSM’s, don’t put the sole value on a piece of paper.  IE: put “preference given to someone with CSM designation” instead of “CSM required”
4. Bring in a panel of cross-functional folks to interview the person, make sure they will fit in the environment.
5. Have them participate in a real-world scenario.  A true scrum master would thrive on an opportunity like this to prove themselves.  Any reluctance and you know they aren’t the person you want.

The Noob CSM

1. Be Honest.  Yes I realize you can’t get experience without having some experience, but don’t pretend you are something you are not.  Setting an expectation upfront that your are capable only for the company to find you are not is far worse for you AND them than it would be to maybe look for a more junior role with a smaller team/company.
2. Focus on helping the company understand you have the knowledge and tools to make Scrum/Agile succeed but that it’s a team effort
3. Take the time to understand Agile adoption successes and failures and you will notice there is a common theme to them.
4. Learn, learn and learn.  Join Agile communities, participate in Agile forums, start or join a local Agile user group.  Being a ScrumMaster is not a 9 – 5 job, it’s a learning job that requires dedication.

So am I in favour of certification?  Well, as usual, it depends.  In certain circumstances, I am.  I believe having an education from a qualified trainer/institution gives you a solid foundation to start with.  The reverse is also true, I know some folks plenty smarter than me that have no certifications so I don’t take too much stock in it.  You can read  books/blogs and get the same knowledge but be wary of “scrum-but” or “agile-but”. Those are much worse and do far more damage to the industry than someone without practical knowledge and experience does.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I attended a great session on Agile vs Traditional last night with the Toronto Agile group and while there weren’t many traditional folks there, the session helped validate much of what I believe is the most important aspects of ‘becoming agile’.
The panel included Mishkin Bertieg, Scott Ambler, Colin Doyle, Orhan Kalayci and Winifred Menezes and you can see details and bios of these folks here.  Although the even was supposed to be a shootout between traditional vs agile methods, the discussions were skewed towards agile approaches.  Each panelist had the opportunity to comment or answer a question about traditional vs agile approaches in these categories:

1. Agile Evaluation: What do you expect to see when you first visit an agile organization?
2. Project size: Which approach works best based on the size of the project?
3. Estimating and Planning: Which approach is more accurate?
4. Requirements Management: Which approach is more effective?
5. IT Governance: which approach addresses this better?
6. Distributed Development: Which approach makes this easier?

Obviously the panelists’ opinions were skewed towards Agile having the ability to approach these more efficiently, but the key message overall was that even with using an Agile approach, culture, learning and constant improvement are the corner-stones to succeed with Agile.  To be successful in the areas being discussed, focus on building trust, relationships and make a commitment to improve.  They all really drove this point home in each topic.

Regardless of discipline, framework or methodology being used, it was pretty clear that corporate culture was the key.  There must be a mutual respect across the organization and within  teams and there must be a commitment to learning and constant improvement for Agile to really work.

I’ve always had the opinion that using Scrum, XP, Lean, Kanban or whatever you want to use is irrelevant if the culture doesn’t buy into the concept of what it really means to be Agile.  I’ve read many articles where people debate the use of Scrum vs Lean and nitpick about stuff that doesn’t matter such as “well, you can’t be Lean and use Scrum, they are 2 different approaches with different attributes.”

Who cares?

Yes, that’s right, who cares?

Being Agile is all about finding a better way to work and move forward as one team or organization, not worrying about whether or not you’ve followed the Scrum checklist (not that there is one, but we all know people love lists that tell them what to do).  This isn’t some hokey notion or religious argument, it’s common sense.  Give people the opportunity and trust them to do the right thing, and more often than not, they will.  Succeed as a team, fail as a team…but LEARN from the failure and move on.

This has been quoted many times by Agilistas, my apologies for not knowing the source to credit them, but the saying goes “It’s not my problem, the hole is in their side of the boat” This is the type of thinking that must change in order to be successful with Agile.

Now the challenge becomes, how do you help people adopt Agile culture?  Let me know what you think or drop me a line with how you’ve approached changing culture when adopting Agile.

Oh, and look for a follow-up on extremely short sprints for small teams, we learned quite a bit but I’ve been a bit swamped lately to follow-up.

Related posts:

1. Agile Just Don’t Go ’round Here One of my favourite scenes from Tombstone is when...
2. The Agile Coach Manifesto The Agile Manifesto is the heart of soul of...
3. 4 Steps to an Agile Transformation I often find that people new to Agile have...

Related posts brought to you by Yet Another Related Posts Plugin.

Today we are experimenting with 1 day sprints as an attempt to clear a large backlog of product work and client related work. During our last retrospective we noticed that there was at least one interruption each day during the sprint and while they were small, it’s still proving the point that when your development team is supporting existing clients, an interruption is only a phone call or support email away.To put a bit of history around why we’re trying this, we have a small team where I work.  We used to be split between product development and support/implementation groups and now we are one team working towards the same goals.   Even though we have been operating as one team for a few weeks now the support/implementation folks are still handling all of the support/implementation related work while the product developers focus on bugs/features/improvements.

There are a few problems with this but the main ones are:

1. product team isn’t exposed to REAL client feedback/issues
2. Implementation team gets bogged down with client requests
3. less team-wide knowledge sharing (read: specialists)

We had been operating in 2 week sprints and when you are supporting existing clients you can’t really tell them it’ll take 2 – 4 weeks for any request they submit.  As a result we re-prioritze often (which is good) but it’s definitly not in the spirit of sticking to Scrum (which is bad).

So here we are at day 1 and the plan is:

1. 15 minute planning session
2. 1 ‘daily’ standup (5 minutes at ‘mid-sprint’)
3. 15 minute retrospective and sprint review

This is going to be tough on everyone and there was some resistance to trying this method from the team but after a discussion they were willing to give it a shot which is great.  At first the phrase “it’s impossible to do anything in 1 day” was thrown around quite a bit but I think they will realize very quickly there isn’t much of  difference between 1 day sprints and 2 week sprints, you simply scale everything down to fit.

I expect some interesting results and would love to hear from others who have tried this method.  Leave me a comment!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

It’s been quite a while since I last blogged, my apologies to my faithful 10-person readership.  Today was a particular hellish day after being off for only a few days.  I came back to complete dis-array within the team and process and actually was quite surprised based on how well things were going and how well the team understood the process.

There was no agreed to work, team members (product owner included) all had different interpretations of the status of the previous sprint, when or if the current sprint started and what work was or was not agreed to.  In their defense customer support was unusually high so there were some fires that seemed to have frazzled them.  Either way, after almost a year re-implementing our previously failed Scrum process, the team should know better.

The Agile wall still had last Sprint’s items on it and when I asked them about it they said they didn’t really know what to do even though they had a backlog meeting already.  The PO said he “thought” the new sprint was started, 1 team member said it did start and another said it didn’t start.  Clearly something’s not right, it reminded me a bit of the agile exercise we did during my Scrum Master training course.  In a group of 20 or so people, 2 people pair up and 1 person plays manager and the other the subordinate .  The manager has to tell the subordinate to go straight, turn right, turn left etc and make sure that no one bumps into each other.  Today was like all team members were subordinates and no one was doing anything but slamming into a wall over and over again; hence the pulling out of my hair.

First of all I expressed my dis-pleasure with the team which immediately brought out the excuses to which I tore a page out of Darth Vader’s book and modified his “Asteroids don’t concern me admiral” with “I don’t want to hear excuses, you guys know better than this”

Then I tore through the sprint backlog and we refined it to estimate what needed estimating and then drew the line on what the team could get done.     Now that things are under control, I started to wonder why it could have possibly got this bad.  Had they not listened to anything I said over the last year?  Was the support disruption really the problem or was it something else?  I’m sure it’ll come out in the retrospective but I wanted to pose this question to fellow Scrummasters…have you seen this on your teams when you’ve taken vacation for a few days?  What did you do?

I’ll be posting a follow-up after our retrospective…I have a good idea of what will come out, or rather, what I’ll have to pull out from the team.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.