Sometimes it’s hard to be in multiple places at the same.  Ok, it’s not possible to be in multiple places at the same time so with 10 teams and 100 or so people in the organization I’m working with and only myself and another coach I’m working with, I decided to create a retrospective room so teams can get some helpful tips and advice when we’re not able to help facilitate.

I had one goal in mind when creating this space which was to make it safe for teams retrospect in an environment where not all folks were accepting of doing retrospectives.  As a coach sometimes the best thing to do is back away and let the team figure things out on their own.   I had just finished facilitating a retrospective with a new team and could sense they wanted help improving but the ‘gotta have it all by this date‘ was too strong to influence them to try new things.

In the spirit of trying something new, I decided to just flat out ask them if they wanted me to sit with them for the next sprint and help out with a finger vote.  A few people had 5 fingers up and the rest averaged about 3 fingers.  I asked them again, but this time be honest and don’t worry about offending me.  “I am here to help, if you don’t feel like you can accept help based on the deadline just tell me“, I said.  The folks with 5’s kept the 5’s in the air but the average dropped to 2 fingers.  I thanked them for being honest and kept the door open in case they decided they wanted help later.

I figured creating a retrospective room was a good way for teams like this to experiment on their own in a safe environment.

The room:

The room is a nice, big open area with lotsa wall space.  It’s also the first thing people on the teams see when they come into the building.  This is near the backdoor entrance that only the team members use.  The point is, there was no need to advertise or tell people to use it.  People naturally came in and looked at the stuff on the walls to see what the hub-bub was about.

What’s in the room: Getting Started with Retrospectives

There’s an area that has info on the value of retrospectives, a sample meeting format and a sample checklist of things to do before getting started.   Posted on the papers are:

• The Agile principle for retrospectives (At regular intervals the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.)
• Outline from Esther Derby’s and Diana Larson’s Agile Retrospective book (set the stage, gather data, generate insights, decide what to do, closing)
• A section to post questions that myself and the other coach will answer
• Kerth’s Prime Directive (summary: people are doing the best they can with the situation at hand)

What’s in the Room: Sample Agenda

This area is helpful for teams to find a focus for the retrospective.  It’s marked as a sample, not the rule and the sample follows these steps:

1. Decide on a focal point
2. State agenda and do appreciations
3. brainstorm what went well, what didn’t go well in context of the focal point
4. brainstorm stop/start doing things
5. create action plan
6. re-usable area for well/not-well stickies

There’s also a basket labelled “Retrospective tool kit” that contains the stickies, markers and handouts of various techniques teams can try from Agile Retrospectives.

It also happens that there is a kitchen in this area off to the side so it becomes a great conversation piece when I grab my morning coffee.  When talking with folks I can reference the value of retrospectives and use fancy techniques like pointing to Kerth’s Directive to re-enforce the importance of retrospectives.

At the end of the day, it’s about doing anything I can think of to help my client and I love the creative aspect of what I do.  Oddly enough the team that inspired me to create this room has asked for help after that first retrospective.  While the whole team is struggling to accept change, there are a few people on the team that want to improve how they work and hopefully this room has shown them that I want to help while at the same time helping them feel more comfortable and safe about these changes.

Of course, now that the room has been in use for a couple of months it’s time for a refresh, Retrospective Room, Phase II is underway.

No related posts.

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

“Wait a minute, I thought we were Agile?  What aren’t things better and why do we have more problems now?”

What happens after the honeymoon is over?  Going from blank walls and cubes to a lots of stuff on the walls and a nice wide open space and should have made a difference by now shouldn’t it have?

There’s a lot of noise on Linked In, Google Groups and twitter (to name a few) that all seem to try and find fault in a person, team, organization or practice because the results aren’t matching the rhetoric.    So we’ve been at this Agile thing for a while, we found a shitload of problems, came up with a plan to fix them, didn’t see results right away because we chose to not prioritize actually fixing these problems, blamed the methodology and decided to go back to the old way of just ignoring said problems.  Voila!

I remember that fantastic exciting and new feeling when I first met my wife some 15 years ago.  It was fun.  New.  Exciting.  Fast forward to marriage and kids and after the honeymoon was over life got hard and complex.  It takes work to manage our house and family.  Real work.  Any problems we have are our problems and if we chose to ignore them, we suffer the consequences.

According to these stats, 1 out of 2 marriages in the US and Canada fail.  Why is that and what does it have to do with Agile?  Plenty.  When stuff gets hard, we as humans give up.   This Business Week article talks about 5 reasons why we tend to give up on our goals.

• Ownership: thinking “I’ll give this a try and see what happens” instead of thinking “this will work only if I make it work”
• Time: holy cow, I didn’t think it’d take this long, is it worth it?
• Difficulty: This is waaaaay harder than I thought!
• Distraction: Sorry, can’t work on my goal, have a bunch of other stuff to do.
• Maintenance: ah, good enough….I don’t have to keep working at it do I?

Adopting Agile is no different than any change in a company.  It’s a change.  A big change.  A really big change and change is hard.  All the mental models, coaching models, change models, methodologies and such are fine and dandy but sometimes you just need good old fashioned gumption.

Sometimes it’s time to nut-up or shut up.

No related posts.

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

My wife and I were working on our monthly budget last night and were looking at where we could free up some dough so we could put more money aside for un-expected stuff, debt, vacations and so on.

Seems like every once in while we talk about the same ideas for managing our budget without anything coming of those discussions.  Sound familiar?  How often in your personal life or work life do you have the same conversations over and over again only to never realize the benefit?  What’s the problem?

Discipline.  For us, there just hasn’t been any sense of urgency to change anything about how we manage our finances.  We know we “should” do something differently but we’re not disciplined about executing on it.

What I often hear from teams is that ‘we have no time’ to do our improvements.  There is just too much work to get done.  Bullshit I say.  What they are really saying is we haven’t made improving a priority.  Discipline is really, really tough.  It forces organizations and teams to prioritize and make real decisions instead of simply deciding not to decide.

A colleague I used to work with brought this phrase to my attention. If we keep doing what we’re doing, we’re going to keep getting what we’re getting. If you want your outcome to change, change your behavior and be disciplined with your approach.  If you choose not to behave differently and use “no time” as the excuse for not being disciplined the only results you’re likely to get are metrics that mean absolutely nothing.

No related posts.

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

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.

I had a great conversation with a colleague the other day about how “agile ain’t what it used to be” (fodder for another post)  and recently it seems like I spend a great deal of time either replying to people or having conversations about the proper use of “methodology or practice X“.

Technically I’m on vacation and since I don’t really consider what I do a ‘job‘ (read: I love what I do), I’ve been catching up on email, forums and other conversations on Linked In.

Is the Agile community sending the wrong message?  Do people just not get it? Why does it seem there is this overwhelming need for something to give the gold stamp?  Are Agile values and principles at odds with fundamentally how the humans behave?

Dramatic?  Maybe.

From metrics to methodology, what seems to get lost is doing the right thing or doing what’s necessary for a project/product to succeed.  Reflecting back on previous lives of being “in charge“  I don’t know how many times I’ve either talked out of my, ahem… or flat out asked the team what they think we need to do in order to be successful.  It hasn’t always worked of course but I’ve worked with some great folks who could take the data presented to them and do what they felt was the right thing at the time.

Stakeholders, project sponsors and customers really don’t give a shit if you’re using XP or Scrum or Waterfall or Shabadoo Methodology (that one is mine, TM pending…), they want results.  Whether the goal is project success, more money or whatever, however you get there doesn’t matter.  Chances are the next situation will be different so doing the same thing again probably won’t work.

This has been a source of confusion and frustration for me a few times with clients, but I think there comes a time when you work for a boss or organization that seems to get it.  Sometimes you find a boss or leader who is very much a catalyst, somebody with that “it” factor.  Somebody that knows the direction of organization whether is be selling off the company so we all get rich or somebody who understands the market and is trying to blow a vertical wide open.   I feel lucky enough having experienced this rare phenomenon  twice and whatever the goal was in those situations, it was loud and clear.

Strong leadership and a purpose seem to drive how we get results, not a process or methodology.   So what’s the point? Am I just rambling on or what?  The point is, the manifesto was created for a reason.  Use it as a guide, not the rule.  Sometimes you need less rules and process, sometimes you need the reverse.  At the end of the day, people are complex.  Teams are complex.  Throw them into another system (read: the organization) and the waters get even muddier.

That’s why I love what I do.  Each situation is unique, each challenge is different and I really dig that.

No related posts.

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

For those who are familiar with some of my other posts, I seem to follow a similar pattern when talking about Agile.  Based on using Agile as the tool to help implement the Rockefeller Habits when I was working at Q4, I’ve always thought that the focus and goal is always to help an organization be successful based on how that company defines success.

This was the focus for a session I proposed at Agile Coach Camp this weekend in Waterloo.  First off, I love Coach Camp!  The energy, openness and shared learning that happens is simply amazing.  It is truly inspiration for me to see how passionate everyone is about Agile and giving back to the community.

I had originally titled the session “Focus on Success over Focusing on ‘Being Agile’” and I was pleased with the open dialogue that came out and helped me sort out the thoughts in my mind around this topic.    I’ve mind-mapped and framed a mini-book based on a post I wrote last December that I feel very strongly can help bridge the gap or remove the disconnect between organizations that want to adopt Agile with the message being communicated from the Agile community.

While I am a firm believer in the Manifesto and the principles of Agile, I don’t think that message resonates as well with clients and organizations that want to adopt Agile as much as using Agile as a tool to reach a goal does.

The whitepaper I had hope to publish many months ago started evolving into this mini-book but not having written a book before I am struggling a little!  This is a great chance to eat my own dog-food and use Agile as the tool to accomplish my goal of writing this book.  Well, I think that is enough ramblings for now, you can view the summary of the session here!

Related posts:

1. Position Paper for Agile Coach Camp 2010 Agile Coach Camp 2010 is coming the weekend of...
2. The Agile Coach Manifesto The Agile Manifesto is the heart of soul of...

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

The organization I’m currently working with is suffering from ‘we have no time’ disorder.  Demand is exceeding capability which is leaving little time for ‘non-contextual’ learning for the lack of a better phrase.

While one team has been making some great strides with root cause analysis, they have been struggling to turn those learnings into actions simply due to the volume of work that needs to get done.  In addition to ‘we have no time‘ disorder, they have also been diagnosed with ‘we have to‘ syndrome.  A dangerous combination of diseases indeed.

Enter Open Space.

Now that this particular team has gathered a bunch of data that narrows the focus of what parts of the application are causing the most problems, (amongst other organizational causes that are out of scope here), I’m planning on conducting an Open Space to gather the more subjective data as well.

So why an Open Space as opposed to a typical brainstorm session?

I see this as an opportunity to teach within context which will help the team with:

- self-organization skills (facilitation, time-boxes, collaboration)
- spreading domain and application knowledge amongst the team
- gaining perspective from multiple disciplines (QA/DEV/Business)
- giving everyone on the team the opportunity to speak up (team has some dominant personality issues)
- developing a framework for problem solving and brainstorming so they can be as effective as possible with future meetings
- having fun! get folks together and excited about their work!

These are the mechanics I’m planning on using, as I think some tweaking is necessary to get this to work in context:

1. Setup the open space concept: give team members a few days to digest how an open space works and why we are trying this approach.  This will be wrapped in the business goal for this session (gain consensus on the part of the application that will become the focus for this quarterly initiative.)
2. Open Space Intro: 10 minutes – re-state how an Open Space works and state the business goal of the session.
3. Lightning Talks: 30 minutes – each team member will be allocated 2 minutes to present what they want to talk about.  Ideally we will post this in the wiki ahead of time and I suspect folks will pair up.
4. The Twist!: 1 – 2 hours – Here’s where it gets risky.  Now it’s ideal for all team members to be part of each talk since there will be actual work derived from the output of this session.  Depending on the number of ’sessions’ that are created, as a team, we may agree to do “X” number of sessions and everyone will participate or we will vote on what 2 sessions to do.  I suspect based on the hard data gathered there will only be 2 – 3 major functional parts of the application chosen by the team.  The backup plan is to use the hard data in conjunction with voting, fist of five or other consensus techniques to decide what topic(s) to drill down on.  The sessions themselves will functional much like a typical brainstorming session.
5. Retrospective: 15 minutes.  For me to see how effective this was as a coach and for the team to see if there are techniques they can use going forward to have more effective meetings.

I’ll follow-up this post after the session has been held, but would love to hear your thoughts and suggestions!

No related posts.

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

It’s amazing how the meaning of this simple word can dramatically change by how it’s written.   Agile (Big A) has structure and is comprised of set of disciplined practices designed to get results, whereas agile (little a) is simply ‘do-whatever’ with little or no discipline and structure.

I often find that people are confused by the differences.

Want to be Agile?

• educate yourself:  understand what it is and what the impacts will be to your organization
• educate yourself:  no, that isn’t a typo.  Get educated.
• hire a coach:  no, not because I am one, but because it’s really a good idea.
• listen to your coach: we don’t have hidden agendas.  We want progress.  You are the people doing all the hard work. A coach can help guide you there but they can’t change your culture, define your requirements, develop and test your software and automate your deployment process.
• do not fear failure: through failure comes learning.  The saying  “failure is not an option” should be rephrased to “failure is not optional”
• empower your teams and invest in people:  managers need to foster learning and lead by serving. Help your people.  Get them training and cultivate those relationships.
• attack your problems: Agile will create visibility.  Deal with it.
• resist temptation to panic:  Agile will not fail you.  You will fail Agile.
• be open to crazy ideas:  it might sound nuts to have a programmer and tester sit beside each other and work together, but it just might work.

Want to be agile?

• do it yourself:  don’t hire a coach or even better, hire one and ignore everything they say.  The benefit of this is that you can waste more money.
• use agile as an excuse:  are your processes too bloated? Spent too much time planning and only have a week to build a system that will probably take 6 months?  Call the project ‘agile’ so you can fast-track it and skip all the internal bureaucracy.  Then blame Agile (yes, big A) when it doesn’t work.
• strive for mediocrity: want crappy results only faster?  agile will get you there.
• don’t listen to the teams: duct-tape that 8 year old application together at all costs.  Time spent improving the code would be wasted when you can be adding more features.
• don’t plan: change priorities early and often to be as ‘nimble’ as possible.
• buy lots of expensive tools: the pricier the better.  If they cost a lot, they must be able to make you agile.
• invent solutions to problems that don’t exist:  force process onto the teams to make your life easier, even if it means longer time to market, increased cost and overhead.
• multi-task: if you have one high-performing team, take away team members to work on other projects at the same time.  Since they are high-performing, they will definitely be able to handle it.

Agile is comprised of a disciplined set of tools and practices.  And they work.  While there are subtle differences between Agile and agile on paper, the difference between becoming Agile vs becoming agile are the differences between great success and catastrophic failure.

Related posts:

1. 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.

I had an interesting conversation with a manager the other day about how to gain more insight into changes that are ongoing in the application one of our pilot Scrum teams is working on.  First, what’s the problem?  Group A was doing independent regression for a release and uncovered some ”defects’ that were a result of changes in the application by our Scrum team.  Truth be told, those ‘defects’ are actually de-commissioned functionality.

Manager:  We need to know what’s being changed in the application, we can’t be chasing down defects because of changes we don’t know about.

Me:  Agreed.  We’ve extended the offer for you to come to our end of iteration demos and until this week we haven’t made any changes in existing code so I agree, with these changes we’ll have to invalidate some of the old regression tests that aren’t needed anymore.

Manager: I don’t have time for that.  Is there some type of documentation about the changes?

Me: Yes.  We’ve started using javadocs to document the code and our functional information is in Rally.  Brief, but explains the functionality well enough.  The team members would easily be able to figure out the impact of the changes since they all know the app well enough.

Manager:  I can’t ask my team to waste time sorting through Rally to find this information.

Me: We can export a list for you and email it, it’s a 4 or 5 column XLS with a good summary.

Manager:  Do you know how much email we get?  I can’t agree to that.

Me: Ok, how about you and the members of the other groups who need insight into the changes come to our demos?  We do a 15-minute quick overview before digging deep into the stories we completed.

Manager: They can’t do that, we don’t have approval from their managers to go to your demo.

Me: Ok, we do send a summary of what’s being updated when we make our iteration commitment and we send a summary output after the iteration demo, I can include you on those.

Manager: There’s too much to do, I have to worry about this project, that release, aligning this team with that team, I get too much email now, we need a process.

Me:  Ok, so how about we just have the people from the other groups attend our demo, we’ll give them the 15-minute overview and send the summary of changes before and after the iteration.  If we need to do a more in-depth session, we’re happy to.

Manager: I’ll go talk to the managers to get permission for the other resources to go to the demo.

Me: Great, that should make it easier and really efficient to share information between our Scrum team and the waterfall and regression teams. Thanks!

At the end of the conversation we were right back to where we started.  A quick and efficient session to share knowledge with the people who are programming or testing the software.  I had continued this conversation with a few folks to get to the real problem and the challenges being faces are typical.

So what’s up with all the excuses?  Did we have to fill up the 30 minute time-slot for the meeting to be effective?  I decided to dig deeper:

Q1) Why was the initial response that people couldn’t spare 15 minutes every 2 weeks to get visibility?

A1) Because we are too busy.

Q2) Why are we too too busy?

A2) Because regression testing takes 3 weeks.

Q3) Why does regression testing take 3 weeks?

A3) Because our testing is manual.

Q4) Why is our testing manual?

A4) Because that’s how we do it.

Q5) Why do we choose to do it that way?

A5) Because there are too many projects and we don’t have time to do it another way

I’m sure there were a couple more excuses tossed into that first conversation, I started losing count but the underlying problem of having too many projects in progress at a time are causing a whole host of downstream problems.

At this stage, portfolio management isn’t something we can focus on, especially in a large and complex organization.  First step is to create visibility to outside teams and trim down the regression suite so there is less waste with manual testing.  Our team has already started looking at automating end-to-end regression for happy path scenarios which will also reduce the amount of time spent on manual testing.

It’s a small step, but we need to start somewhere but the message in this post is that things aren’t always as they seem.  The initial response is often a gut-reaction based on stress or other factors and it shouldn’t be confused with resistance to improvement or efficiency gain.

Related posts:

1. A Week in the Life of An Agile Coach – Friday 8:15am - Ah, the end of a long week,...

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.