Yesterday I mowed the lawn because I felt had to.  Our neighbours lawn company had taken care of their lawn and my wife was, um, re-enforcing her desire to have me get the yard-work done.

Since I’m on ‘vacation’ I wasn’t particularly motivated to get it done, but obligation was calling so I caved even though I would have much rather done just about anything else.

It was hot, I was tired and not motivated and ended up doing a really crappy job.   I didn’t do the trimming or weeding and took shortcuts to get it done as quick as possible and as a result, I now have some yardwork-debt.   Oh, there’s a point…wait for it!I generally enjoy doing yard-work. There’s something about the accomplishment of getting it done and seeing a nicely manicured yard that feels pretty good.   Sometimes people walk by our place and I hear nice comments about how great the yard looks.  It may sound nuts, but it feels pretty good.

The shortcuts I took yesterday have made sure I have extra work to do next time.  The grass around the edges will be higher and will take longer to trim, there will be more weeds in the garden so it’ll take more time to pull them out.  Maybe that’s an extra 30 minutes or so next time around but the more serious effect is how bad I feel when I leave the house and see the half-assed job I did.

Who cares, it’s just the lawn right?

Wrong.

Obligation can yield the exact opposite results that it is designed to get.  I felt ‘obligated’ to do something I had to do, but didn’t want to do.  I had a choice.  Do it right or don’t do it.  I chose to do it wrong.  I chose to not communicate with my wife and tell her I knew I’d do a crappy job because I was hot and tired.  I chose to not defer the task until later in the day.

So how does this relate to Agile?  Well, I learned something.  I learned that next time I feel obligated to do this, I’ll take an extra 5 or 10 minutes before I start to clear my head and remember how crappy I felt after doing a half-assed job and then make my choice in a responsible way.

Responsibility and discipline are the magical ingredients for being successful with Agile.  All the process, metaphors and skills don’t matter if responsibility and discipline are missing from recipe.   When your team has improvements that come out of the retrospective, it takes responsibility and discipline to follow through with them.  They aren’t going to magically happen and your manager isn’t going to force you to do them.

Responsibility and discipline are the magical ingredients that make a difference between writing good code and crappy code.

Responsibility and disciplines are the magical ingredients that make a difference between building the right thing and building the thing we “have to” build.

What I personally find useful to be responsible and disciplined, is to simply take 30 seconds to re-boot my brain when faced with obligation.  I literally shut my eyes, take 3 deep breathes and say to myself:  ”what do you want to do?  You know ‘it has to get done’, take an extra couple of minutes and sort out your thoughts“.  While I’m doing the thing I chose to do (even when starting with feeling obligated to do it), I remind myself when feeling the need to take shortcuts: “Remember, you chose to do this.  Do it right.”

It’s quite possible I do that because I’m an introvert and I think mentally preparing yourself can go a long way towards doing the right thing, not the thing you feel obligated to do.

No related posts.

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.

This was a hot topic at one point, maybe I’m missing the boat. Lately I’ve seen a couple of posts on Linked In about Agile Maturity Models and I guess it does sound like a really fancy, neat thing however is it really necessary?

Let’s keep it simple.

Are you using the data made visible by adopting Agile to make better business decisions by accepting reality?

If so, congratulations. You’re mature.

If not, wake up.

Yeah, it really can be that simple…if you’re mature enough…

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!

Related posts:

1. Excuses Might Be the Response, Not Necessarily Resistance I had an interesting conversation with a manager the...

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.

This is a quick and simple exercise I ended up doing ‘off the cuff’ but based on feedback from the class, had huge value that talked about why the conversation is the most important piece of the user story.

I focus heavily on making the point that the written word is less important and while INVEST shows us there are good ways and bad ways to write stories, the disconnect is always a result of lack of communication.

This exercise takes Mike Cohn’s “entree comes with soup or salad and bread” statement from his User Stories book and allows small groups to write down what they are giving me when I order that in a restaurant.

Tools required:

- whiteboard or flip chart to record the responses
- a few sticky notes or paper for the small teams to write on
- pens
- play-food could be optional to make it more fun!

Set the Stage:

Have the group split into small groups of 3, depending on class size.  I had 3 groups of 4 in this particular class.  As product owner, I want to order the entree with soup or salad and bread but I have to run to another meeting, I expect to get what I ordered by the time I get back.  You can leave the room, but I stayed in the room to hear the type of conversation that is happening.

Timebox: 5 minutes (up to you I suppose, I figured that was reasonable)

Expected result:

- ideally you will get at least 2 different orders.  In this case, each group gave me 3 different orders which was perfect to demonstrate the value behind the exercise

Observations:

- immediately I heard conversations like “what did he mean?  does he want soup or (salad and bread) or (soup or salad) and bread?”
- didn’t hear conversations like “we can’t do this until we can ask him what he wants to clarify” – all 3 groups just decided to guess and hope for the best

Learnings:

- the conversation is the most important part of the user stories’ 3 C’s.
- focus on the conversation, not the text in the story
-  the conversation to clear this scenario up is 1 minute or less as opposed to the effort required to revamp the documentation, then update the story in your tool
- business people and developers MUST communicate daily

I just thought about this as the class was starting so there was zero prep or thinking, just figured it was better than me blabbing on and on about why people should talk to each other!  I plan to try this exercise again, the feedback from the group was unanimous.  They all ‘got it’ that the point of the user story was the conversation.  I start each class with a focus question and this exercise quickly answered about half of the responses.  Most were concerned about the story missing details, how can I write better stories for the team etc.

Would love to hear your thoughts!

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.

Agile Coach Camp 2010 is coming the weekend of March 19, 2010 in North Carolina.    I’ve heard great things about Coach Camp and this is my first opportunity to attend.  You can check out their site here and for those who aren’t familiar with Coach Camp, it’s an Open Space conference focused on peer-to-peer learning and exploration as opposed to the traditional speaker/audience conferences I’m not a huge fan of.

Anywho, onto the position paper:  You’ll notice these are high-level points, that’s the point of Coach Camp.  The goal is to share experience and gain feedback from the Agile community.

Title: A Recipe for Enterprise Agile Transformation

Background and Challenges:

• large department within large organization
• tall hierarchy, great deal of office politics
• heavily silo’d organization
• complex product portfolio
• mix of full time, contractors, outsourced developers and teams
• limited people with Agile experience in the organization
• no recognized Agile champion

Speaking and Presentation topics I plan to share:

• transitioning focus of functional managers and other roles
  • there is much confusion about ‘where does my role fit’?
• breaking down silos between multiple groups
  • having to prove you are worthy of being trusted
  • demonstrating and sharing success and failures
• portfolio and team organization
  • how to structure your teams with the right skills for the project
• techniques for handling ’specialist’ groups
  • how these groups interface with teams
  • how these groups share information gained from working with multiple teams
• cross-project knowledge sharing (technical or process related)
  • getting people together to talk about experiences.
• How PMO and process teams evolve
  • more teaching and coach, less command and control
• spreading Agile culture
  • making it about the organization, not the coaches
  • teaching the organization to think for themselves

The above topics will be accompanied by some fancy diagrams I’m working on for an experience paper and due to the format of Coach Camp, if my paper is accepted and put into the plan, the topics discussed with likely be determined by what my peers want to hear about.

I am still planning on writing and experience paper I had hoped to have finished by now where I can share more details.  Interested in your thoughts and experiences!

Related posts:

1. The Agile Coach Manifesto The Agile Manifesto is the heart of soul of...
2. My First Whitepaper, What I’m Doing and Why: Feedback Welcome! I’ve been compiling notes over the years with thoughts...
3. What Makes a Successful Agile Coach? People often ask me “how does Agile tell you...

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