Monday, March 17, 2014

Cross post for scaling retrospectives

Check out my recent entry to the blog for scaling retrospectives in a tiered environment.  I am now holding retrospectives at multiple levels for teams.  It's amazing what you find.

Scaling Retrospectives

Thursday, November 14, 2013

Building Boats - A Kanban Team Game

Here's an "Old" original game that I used in Kanban trainings.  I liked all of the learning for me from the different days and personas.

Monday, November 4, 2013

Kiddie Kanban: The Going To Bed Kanban Board

Made for kid friendly reading... try it out and let me know what you think!

My 6 year old loves responsibility.
He loves being able to know what he has to do and getting it done himself.
He does not love when his dad tries to bark commands.

He is 6 though and tends to try to do too many things at once.

Often when he goes to bed, he might still have one shoe on, or his night time clothes on over his day clothes.

Last night we tried something new that was super fun.
We listed out all of the things that he needs to do before bed on sticky notes.

  • Take a shower/bath
  • Read a book
  • Change Clothes
  • Go Potty
  • Brush Teeth
  • Hugs and Kisses
  • Say Prayers

Then we put them on the wall.

    After that, he said, "I feel I don't know enough about one of them."
    I asked, "Which one?"
    "Prayers." he continued, "I want to learn some new prayers."

    We added it right away to the wall.

    Technical Debt :)

    Then, he took a step back and looked at the board. 

    He said, "This is like a Todo list for bed."
    I labeled it TODO.

    He mentioned, "We need to be able to tell when I am done."  I suggested a "Done" label.  

    I hung up a "Doing" label so we could see what he was working on.  He liked the idea.

    Next, we moved all of the things he needs to do before bed that he had already done to the Done label.

    He took another look at the notes on the wall.  He started moving the notes around.
    I asked, "What are you doing?"  He said, "I'm putting them in order." 
    "We call that, prioritization."  I said, "But be sure to move Potty before Shower, that's a professional tip."  He agreed.

    He started working.  He moved one thing at a time as he finished it across the wall to Done.

    We said some prayers after reading together and we learned a new one together.  A simple one.  "Thank you for today, Amen."

    So we accomplished "learn some new prayers" along the way.  Unfortunately, we never fit in the bath so I guess we'll be stinky together tomorrow.

    Monday, October 14, 2013

    My Personal Kanban in is a pretty cool tool.  Here's a personal kanban board that I am currently using in it.  It took about 2 mins to create and is online which is most useful for me personally.

    I can trash the board in a few seconds.  I can create about 20 boards beside each other.  It's pretty simple and useful.  The "stickies" are a click away so I'm pretty happy with that.  Now I have to find a good mac pomodoro.

    What are you using for your personal kanban boards?

    Monday, October 7, 2013

    How Agile is your backlog?

    I wanted write about backlogs because I have seen them mismanaged in a lot of ways.  This is about one of those ways.  The name.  Seems simple, yet many get it wrong in their organization.

    When taking a look at agile backlogs, we tend to call the backlog a product backlog, maybe a release backlog layered under or over the top of said product backlog.   I call them agile backlogs because they themselves need to be nimble and open to change.

    A realization in the agile community born out of maturing agile teams, business need, and let's face it, some zealotry, is the need to remove the term release or product backlog and just go with backlog or some derivative that represents what the business and customers actually need.

    I'm no zealot... but
    Yeah, so I'm no zealot.  Said the zealot.  That's how it usually goes.  But I promise, I have a reason for disliking these words.  Words carry connotation.  Release and Product are two that are recognized throughout the organization.  Release certainly can imply dates, scope and all kinds of good stuff that can and will be mismanaged.  Hence my plea.

    Release Backlogs
    Now don't get me wrong.  In a complex environment and for the right business model, a product and release backlog are essential.  However, if you release daily, do you have a daily release backlog?  No.  What if you release weekly or monthly?  Still no release backlog.  The need for a release backlog stems from sets of sprints that total 3 calendar months (or longer) being tied together.  Multiple teams  being tied together often mean that you need a release backlog.  At times, the term can be detrimental to organizational maturity.  The quarterly approach can lead to a more waterfall mindset, "hardening" sprints, etc. by immature teams.  Is that a bad thing?  Only if they can't change it later.  Otherwise, they may indeed need these steps.  Especially in complex environments.

    Product Backlogs
    I have never really liked this term.  Sure it sounds good.  I personally have never worked in an environment where one team worked on one product.  There were either many teams working on one product line broken out into sections or components if you wish.  Otherwise, there are many products that single teams work on.  I have yet to see the perfectly sized product for a team of 5-9 people.  I'm sure it's out there, I just haven't seen it.

    So, what to do.  Call it what the business wants.  This should be a natural feeling term.  Keep backlog, it fits.  Replace the other word with something else.  Most backlogs I have seen also change from time to time as the business stays nimble and quickly adapts to change in the market or customer need.  That's what the backlog is supposed to do anyway.  So how about we just call it <your team name> backlog.  If the organization has a tiered system (that's great!) you might have multiple team levels.  They still have names.  <your program/portfolio name> backlog still works.  And... it influences the organization to keep the team together.  And...  please don't name the team Team A/Team 1.  Talk about not valuing people above the process!

    Lastly, don't misread this to say get rid of your release backlog.  Rather read it as, do what makes sense for your business.  If all you have are daily releases (and good for you if they do!) then don't have a release backlog.  Besides, you are probably on a continuous pull system if that's the case anyway.

    Good luck with your backlogs! .... that never sounds right.

    Friday, September 27, 2013

    Enabling Distributed Agile Teams

    I recently did a talk on enabling distributed agile teams for the Atlanta scrum users group.  Check them out, it's a great group.

    Here's the slide deck for the talk with some talking points, lessons learned, and pictures of the games that we played during the presentation.  Before getting into it, I have to admit that I do have a point of view on distributed teams.  I'm biased.  I had to put myself into a certain middle of the road view point where I was neither for nor against distributed teams.  I am so glad I can do that (it's a talent), because I was able to let this session change my own viewpoint.  That's pretty powerful.

    We started the session with a brief definition of distributed teams.
    Then a 10 minute discussion of the complications of distributed teams.

    I then asked the audience to stand up and split them into thirds due to the size of the audience.  I had them form three separate lines arranging themselves from one to ten where one represented that they never used distributed teams and 10 meant that they always used distributed teams.  I then took an "equal" sampling from each group to represent the entire belief spectrum.

    Then we facilitated a 20-ish minute game session where two games were played.

    The first game was a negation game.  This game used four scenarios to give different points of view.  The idea was to have several different scenarios for distribution.
    • Team augmented with an offshore resource
    • We were the augmented team members in the US for a resources based in a London project
    • Each team member was a distributed resource
    • The individual had a paired twin resource that was distributed.  This was a last minute game I had to throw in because of the size of the audience.  It was a take off of My Worst Nightmare from
    During the game, I gave a scenario to each of the split out teams.  They would ask the question, "How can we make the resource's life miserable and less productive?"  After a brief session of answering that question the team members prioritized their results.  I then traveled to each scenario and negated the top two items.  This led to potential "working agreements" like "The team will not schedule meetings when the distributed team was asleep." I am paraphrasing because I didn't take a picture of the output of the teams... boo... next time.

    Here are the game pics:
    Negation Game - Team Augmented with Offshore Resources

    Negation Game - Foreign Team
    Where we are the Augmented Offshore Resources
    Negation Game - Team  Fully Distributed
    Negation Game - Pairing Twin
    (Loosely based on My Worst Nightmare innovation game)

    In the second game, "King for a Day", I had two teams imagine they were CIO's considering outsourcing.  One team took why they would like to outsource and the other took why they wouldn't.  They discussed for about 5-10 minutes.  They prioritized their results.  When I traveled to these two boards I had a realization and ran with it.  

    The team that had the "Wouldn't consider outsourcing" scenario had come up with the traditional "complications" that we had partially discussed.  They came up with a few more in the game and some common issues with distributed teams like "they need more documentation up front."  

    The other team came up with Business Needs like "Global workforce for hiring", "lowering costs", etc. 
    The place we ended up was fascinating.  I could relate the complications back to a business driver.  Basically, if our complications were worth less than the business driver, we should rightly be distributed.  It was powerful.  It also quickly disarmed the "business is outsourcing all of our jobs because it's cheaper" notion.  That's often not the case anyway.  However, the business intent became apparent  even in our fake business.  Good stuff!  Maybe this would be a good way to have teams with outsourcing needs accept it more readily.  Again, I'm not an advocate, just pragmatic for the business.

    Here are the game pics:
    King for a Day Game - CIO wants Outsourcing 
    King for a Day Game - CIO does not want Outsourcing 
    After the games we discussed several enablers we could implement like the communication kata.  I went over a few tools that I know that are collaborative whiteboards, mindmaps, etc.  That seemed to also hold the attention of the crowd.

    Overall, the discussion was a great success.  I learned a lot and other said they did as well.  Both myself and the crowd wanted more time for collaboration on the games.  Hopefully I can better time it in the next iteration.  I also realized that another discussion was potentially needed for patterns of structuring distributed teams.  This talk focused on enabling distributed teams and I am of the opinion that although the structure is important, most structures can be successful in certain contexts.  It's a tool in your toolbox, you don't always use them, but it's nice to know that you have them if you need them.

    Monday, September 23, 2013

    Some Cool Collaboration Tools

    • (everyone should have this)
    • (Online white board)
    • (sticky notes, images, go visit, it’s cool)
    • (Collaborative writing with
    •  (Online white board) -free for 2 users
    • (Free corkboard)
    • (Collaborative mind mapping)

    Or check out my mural at