Some of the symptoms included not finishing the sprint work, disagreements about what done meant to the developers, testers and business people, struggling to finish regression, missed deadlines and releases.  It’s always tough to gather enough context in a short amount of time to offer some advice.  I could see the main challenge was getting the team to buy into a shared goal and removing the silos.   Having said that, these guys seemed quite collaborative, I think they were simply having problems adjusting to Agile given they’ve only been trying it for a couple of months.   I think they’re on the right track and seem committed to improving which is just great.  Anytime people want to give up their own time to learn is a good thing in my books.

As we talked about ideas about how to find balance I suggested one way to help manage these symptoms is to pull less work.  Of course every action has some impact and I mentioned that this can create idle time, especially in cases where “the development work” is low effort but the “testing work” is high.  You could have developers idle! Nooooo!  I could see an adverse reaction to that suggestion so I made a joke about making sure “resources” are 100% utilized!  The reality is, people need slack, especially to learn a new process and move forward.

I asked the product owner flatly that if they are missing releases now.  He said yes.  I asked if they have quality problems as a result of in-sufficient testing.  He said yes.  I then asked what’s the harm of slowing down?  Your missing releases with lower-than-desired quality now.  You’re only fooling yourself if you think slowing down is going to cause problems because you already have those problems now.

I could feel a bit of shock from a couple of people in the room after I said that.

The point is, when you are looking for a coach or consultant, they’re not there to be your friend.  They are there to help you figure out how to solve, manage or cope with your problems and you are not going to like some of the answers you get.  A good coach is going to tell you either the brutal or kind truth and the best you can do is establish personal safety by having an agreement and shared understanding about what is expected from the coach from your perspective and the same from the coaches perspective.  Once you can get that agreement in place what unfolds can happen in the name of progress.

The “stand-up” ends up being a ritual where the drones…er team members, answer the 3 questions because, well, that’s what Scrum says you’re supposed to do.  What did you finish yesterday, what will you finish today and what’s blocking you.   Pretty simple stuff.  I worked with one team that had terrible ‘standups’ until they started sitting down.  One team member (who was kicked off the team) made it a point to bring Ken Schwaber’s book to prove to me that you don’t have to stand at the standup.  I asked him if he could remember a time when I said they had to stand-up.  He grumbled and stormed away.

I’ve noticed a pattern of teams going through the ritual only to do a real standup after they finish the ritual.    The ‘standup’ itself is a status meeting with the 3 questions and I’ve noticed the teams that exhibit this pattern finish that pretty quickly.  Then they move on to the real standup, focus on the work on the task-board and co-ordinate their work for the day.  I’m sure some purists would call this some type of critical dysfunction, but what’s the harm?  From my observations, the ritual lasts 5 or 10 minutes and the ‘real’ standup about the same.  Oops, that puts us over the 15 minute time limit.  I guess all is lost then.

How about you?  Does your team function like these other teams I’ve observed?

One of the team members was busy and couldn’t make it (which was a piece of data on it’s own) but we went ahead anyway and did a safety check first.  I don’t remember the exact name of the techique from Diane Larson’s and Esther Derby’s Agile Retrospectives book, but it’s the one where you ask people to write down whether they are an explorer (fully engaged), shopper (want to pick out at least one idea), vacationer (yes! I don’t have to do REAL work!) or prisoner (get me the H outta here!).  I was pleased to see all “E”‘s.

I explained to them as a facilitator I wouldn’t be participating and that I’d just be helping.  I offered a couple of suggestions, a retrospective on why they stopped doing retrospectives or a timeline of the last few months similar to a release retrospective.  They opted to go with the retrospective on why they stopped doing retrospectives.  I asked them to write down some positives and negatives about past retrospectives that I hoped would spark some dialogue.  The output was simple and we were done really quickly without much discussion:

Good Things:

- had a chance to slow down and talk about how things were going
- got to see thoughts from other team members’ perspective

Bad Things:

- they had been combining their retrospective with another team (it’s a small company, so they’d have about 10 – 12 people from 2 teams that work fairly closely in one retrospective).  As a result, the other team was dominating the retrospective
- they were too busy to do them

Those were the two main items from each after we clumped them together using an affinity diagram and after a quick chat they decided on one thing to start doing.  Start doing a 30 minute retrospective every 2 weeks.  30 minutes was enough time to ‘be away from work’ and I suggested they put up a timeline to capture good and bad things as they come up.  They thought that was a good idea and they also agreed that one person would take ownership of the retrospective every two weeks so they would be sure they’d do it.  Time will tell I suppose!

The energy was really low during this retrospective as well.   It felt a bit forced as I had to poke them to get them to open up a bit and try and focus on each other instead of me.  We wrapped up quickly since I sensed they were pretty tired and since we got to the point quickly, there wasn’t much reason to keep going.

I learned something too.  Next time I facilitate, I’ll get out of the way.  Like, physically out of the way.   We have a couch and a couple of chairs in the area that are setup great for discussions, next time I’ll stand outside the circle.

I had done something similar with the other team as they had mentioned their last few retrospectives ‘sucked‘.  Their reasons were similar and they also added that they rarely have any tangible or actionable output to move forward with.  They just end up talking and talking with a lot of “we should…” language.

Next time you experience teams going through the motions or feeling like retrospectives are getting in the way of ‘real work’, try uncovering why they feel that way.  Chances are there are some problems under the covers that you can clear up pretty quickly and get back on track.

That reminded me of a recent sprint planning session our team had.  Our product owner considered customer value and done as being able to clearly show separation of presentation and data layers in a new service we’re developing.  I considered customer value being showing the user of the new service a simple interpretation of the data being shown through the service.  Very different perspectives.

For me ‘done’ is when the customer gets something valuable.  For our PO, ‘done’ is when he can be satisfied with the design of the service.  The team, done is when all the yellow stickies are moved to ‘done’.

The point is, my tax example is simple and very specific.  Just before I wrote this post I told my wife I finished both returns, filed mine since I get a refund and will file her’s at the deadline since she has to pay this year (booooooo!….for her!).  Before that, I have no idea what she thought ‘done’ was.

Software is much more complex than that.  One way of handling this is to periodically align the team during the sprint.  Oddly enough I did that yesterday.  Our standup felt kinda ‘status-y’ and there really wasn’t much talk about the actual work.  I pushed the team and asked them to say what they thought we agreed to delivering.  I asked the PO the same thing.

I was pleased to hear it was the same as what I thought so I wrote it down and stuck it on our release wall.  Might be tough to see in the picture, the green card on the left shows the sprint number and what our definition of ‘done’ is from the customer’s perspective since that’s what our sales and marketing team would find valuable.  They could care less if the service is de-coupled.

When you talk about ‘done’, be specific.  Scrum talks about delivering ‘business value’ and ‘potentially shippable’ software which is just a guideline.  Be specific and you’ll avoid a whole whack of ugle “hey, that’s not what I thought we were gunna get!” conversations later.

The textbook definition of a Scrum Master is someone who “removes impediments” and facilitates the process for the team.  I suppose from a process perspective the Scrum Master does do management type of work but in general terms the Agile community doesn’t agree that the team’s manager makes a good Scrum Master.    The general thinking is that a manager can circumvent team self-organization and creativity by directing the team and in theory this is fine but in practice it’s just not reality for medium to large sized organizations.

Let’s consider this complex, enterprise organization structure:

(click to enlarge)

This example is loosely based on an enterprise organization I worked with.  A Scrum Master will have extreme difficulty trying to cross the boundaries presented in an enterprise organization.  Removing impediments are going to be extremely challenging, if not impossible, in this type of organization and there are a number of reasons why:

1. Functional Department Objectives: Team members will be taking direction from conflicting objectives.  QA’s mandate may to be to reduce bugs while the PMO’s objective is to get the project out on time and on budget therefore sacrificing quality in the process.
2. Exposing Dysfunction: Managers are happy in their silos, crossing boundaries to remove an impediment can be seen as a threat to the responsible manager.  I encountered a situation where the team I was working in was consistently losing 1 – 2 days of productivity per sprint due to environment problems.  When I began removing this impediment all I did was piss off a lot of people and nothing happened.  They were quite happy with the current state because it was just too hard and expensive to have proper environments.  Even better when I asked “so what do you expect the team to do during these blackout periods?”.  The answer was:  “nothing”.
3. Team member fear: Having multiple managers providing process and direction to the team makes self-organization difficult.  Team members will struggle with the courage to do the right thing over getting into a conflict with their manager.
4. Impediment is technical in nature, control outside scope of department: I personally ran into this quite a bit.  In many cases a back-end system was not available and the organization had a complex support system that seemed to be designed to block all progress by bogging down people in process.  Let’s say the team is working on an application that interfaces with a service layer controlled by IT.  The process dictates a complex ticket system for resolution and escalation requires moving up your silo to the appropriate level, across to the responsible department, down that stack and then back up, across and down.  Sounds confusing doesn’t it?  It is.  This encourages silo-type behaviour, mis-trust and a whole host of other dysfunctional behaviour designed to follow process over getting results.
5. Resistance: I’m not a fan of the term ‘resistance’ personally.  Resistance is simply a symptom covering a reaction to change.  In the diagram above, if there is fear or resistance at any management level (and there usually is), a Scrum Master’s job is all that more difficult as the SM doesn’t have any power or authority to remove impediments.

So what’s the solution?  To be honest, I don’t entirely know.  Creating a matrixed organization where the team reports to the Scrum Master may work.  Firing all the managers and flattening out the organization may work.  Moving from a project-based organization to a product-based organization may work.  Pushing the fluff of “hey, can’t we just all get along and work together” may work (although I doubt it).  It’s probably going to be a bit of all of these actually but hiring Scrum Masters is the wrong first step.

Based on the sessions I attended at Agile Tour Toronto, no one has Enterprise Agile figured out to any degree of certainty and my opinion is that people are focusing on the practices, not changing the system in which those practices are used.

All I’ve figured out so far is that a Scrum Master in a large organization has no power or authority and a smaller sphere of influence to help with change. If you are expecting to hire a bunch of Scrum Masters to make your enterprise Agile, just wire the money you plan to spend on them to any registered charity, it’ll be money much better spent in the end and you’ll get some nice tax breaks.

Let me tell you story about a team I worked on and why we were successful despite the number of constraints on our team:

1. Extremely strong Product Owner: she knew the domain, she knew the politics, she knew was battles to fight and which ones to let go.  If our team was technically dependent on a group outside our influence and they wouldn’t help, she’d drop the backlog item and promote something else.  Then she was manage the stakeholders appropriately.
2. Achiever-level(1) Team Members:  We have 1 tester and 1 programmer who were very much achievers that were intrinsically motivated to learn about Agile and technical practices and were genuinely interested int he work they were doing.    They inspired the team and were greatly responsible for creating a high performing team.
3. Catalyst(1) Scrum Master: I don’t like taking any credit for the success, the team did the work, however I did get some great feedback that I was able to provide a team system that allowed them to step up and take risks.  I listened to their concerns, I had one-on-one sessions with them, I gave them timely feedback and I was a pain in the ass when I felt I needed to be a pain in ass.
4. The Perfect Storm: Having said all of that, this team had something special.  There was a great mix of personalities, domain and technical knowledge/skills and we had a very open and honest relationship across the board.

While this team and project was successful, as a whole, the adoption was not. (sidebar: it’s been 18 months since the adoption started and it’s just now hitting critical mass)  The point is, organizations often think hiring a bunch of Scrum Masters to make their projects ‘Agile’ and yet don’t consider the system is not designed to support Agile processes.  I spent most of my time at this organization acting as an Agile project manager all the while kicking up to influence change.   This organization perceived Scrum Masters as just Agile project managers and didn’t understand that in order to be successful with Agile, the system must change.

Before you decide you need a Scrum Master, take a step back and understand your system and context.  A Scrum Master that reports to a manager who may end up looking incompetent from the visibility Scrum will create, isn’t likely to help remove impediments.  There’s a reason why courage is a value of Scrum, without it you’re just left with a dysfunctional Agile process instead of a dysfunctional…whatever it was before.

(1) For more information about developmental models, check out Michael Spayd’s article on Agile leadership with references to Leadership Agility by Bill Joiner.

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.

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.

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.

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.

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.