Thursday, October 30, 2014

Trends for agile methods

I worked up this heat map of regional interest in scrum and then moved to a comparison between kanban, xp, lean startup and agile in general.  

Here's a look at the "hottest" agile states in the US:

From there, I looked at scaling methods.  The data here is pretty rational with scaling agile appearing largely around 2013 as a search item after Dean Leffingwell's talk at Agile 2012. Though many were figuring it out, he branded it! Hence it caught on. I also had to move to worldwide to get more data on DAD and LESS

Pretty interesting huh? I geek out on data from time to time so it was for me!

Tuesday, October 28, 2014

Anyone know this retrospective?

Here's a retrospective I am about to try and perform.  The intent is to get better at communicating between teams in a scaled environment.  My current set of teams are focusing externally vs internally and I am trying to come up with ways to visualize it.

The thought is that the product and services scrum teams can reflect on where issues are originating.  They can also visualize if they are only thinking externally vs internally.  I will likely at another item  at the bottom called "Them" to symbolize... "them" whoever they are :)

Let me know what you think!

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.