Oh! Like Rugby!

So I have been a Scrum practitioner for many years now and sure, I was taught that it is called Scrum because of the Rugby term when the team all comes together and forms that circle and then I’ve pretty much always moved on from there because what the heck is rugby, anyway? All that has now changed for me.

This spring my incredible daughter decided that she wanted to join the rugby team. I admit, I was apprehensive. What little I’ve seen of the actual game made me nervous and confused. Haka anyone? I watched a few practices and didn’t learn much. Even the first game was just a confusing mess of girls knocking each other down, but by the 4th or 5th game it started to make sense and I even started to cheer in the right places.

I think it was the 6th game when the girls had a scrum that I asked a more knowledgeable  parent sitting next to me, “When do they have to scrum? ”  and she replied “When forward progress stops.”  And suddenly I got it. Finally.

My daughter is in that scrum somewhere

If you already understand rugby this next part will be very boring and possible not 100% accurate and for that, I apologize. You should skip to the next paragraph.

Like American football a rugby match starts with a kick-off. From there the teams try to move the ball down the field in a series of short runs and passes. When the ball carrier is tackled, the ball is still in play and can be handed off to a teammate or can be stolen by the opposing team. Play does not stop unless there is an illegal move, the ball goes out of bounds, or someone gets hurt enough to need medical attention. In order to score, called a “try”, the ball must grounded in the opponents goal area (the end zone). Points can also be earned in a conversion, penalty, or drop goal, but lets leave that aside for now.

After the light bulb went off I thought to myself, they really should have called it “rugby!” To me the game of rugby is made up of a series of sprints. Just like in the Scrum process the team has to work together and collaborate to meet their goal — to score. Maybe more-so than in most other sports I have watched. Several short runs and passes is the most effective way to score and any player can score. Sounds a lot like User Stories and Tasks. Helping and backing up teammates when they are blocked (or tackled) is essential for success. And (among other things) the scrum in rugby is an opportunity to regroup and re-set, as is the daily stand-up, or daily scrum.

Over the course of the season I watched my daughter and her teammates go from a confusing bunch of girls on the field to a real team working together and scoring a lot. (Thanks in no small part to their amazing coach.) This is much how a Scrum team gets started. It is rocky at first. Lots of adjustments are needed, but after awhile the team finds its strengths and its flow. The rugby team, like a Scrum team, has to make on-the-fly adjustments when unexpected things happen and therefore they both cultivate and value agility.


Why can’t we go faster?

I recently had a discussion with a Product Owner working with one of my teams. He was frustrated because a new feature that was released last week has a bug and he doesn’t want to advertise the feature until the bug is resolved. This is an established team that works in 3 week sprints and is releasing code to production at the end of every sprint. This team is also working for a global insurance company where process and regulation are part of breathing and Scrum is just starting to be accepted as a formal methodology. That’s to say that releasing code to production every 3 weeks in this environment is pretty darn fast.

The Product Owner’s question was, “Can’t we move to 2 week sprints so we can get the work out faster?” (I should also note that the team has been largely together for a long time and the Product Owner is the newest member of the team.) His feeling was that if we had shorter sprints then he wouldn’t have to wait as long to get a bug resolved. He is not happy about having to wait another 3 weeks to promote the new feature. I am not happy about it either, but I don’t think the number of weeks in the sprint is to blame. The team has been established on a 3 week cycle for a long time and nothing significant has changed to warrant making a change this drastic.

I suggested that the process is not at fault here. The issue was actually with the quality of work being turned out by the team. Testing should have been more rigorous (including his own, btw) and that would have caught the issue before it was released. He wasn’t crazy about this explanation as it did nothing to get his feature out there sooner, but I held strong to the quality problem. I said I would talk to the Scrum Master about bringing this into the next retrospective so that team would be aware that defects are being noticed and having a real affect on the product and the reliability of the team. After all, if the quality of work was better, he wouldn’t have to wait even 2 more weeks for a properly working feature. He would have it right when he expected it.

And if we  introduced a shorter sprint cycle velocity would surely suffer the pains of change.

Perhaps there are other issues we need to look at in this team as well. For example,  maybe they are just committing to too many story points? I would always rather see a team reduce their velocity in order to improve quality than rush to get a lot done and risking defects. Perhaps there was a miscommunication in test cases and something needs to be looked at there? Never underestimate the value of good test cases.  Whatever is causing the quality issue it is most important to identify the issue in the team even though it is easier to blame the process.

Agile Victory over Status Reports

Let me start by saying I hate status reports. I don’t think anyone who writes them tells the truth, but rather they are painting a picture of how they want the reader to see the project. On the flip side I don’t think anyone bothers to read them unless there is some glaring RED boxes or type. There are better ways to see the health of a project, but none-the-less, they are a necessary evil in the corporate world.

I was asked to start performing this necessary evil for a new project I am working on. The Program Manager sent around this suggested template for all the project leads to use every week.


This is on top of a weekly meeting where we will discuss all of these updates. Talk about traditional waterfall overkill and meaningless reporting!

After I wiped my tears I noticed that in the email the sender asked for feedback on the template. Aha! If I have to do a weekly status report why not actually report what matters. I started thinking about what would make a better template and then inspiration struck and I thought of the Daily Stand Up. The result of my inspiration was this:


Look familiar to anyone? Current update = what I did this past week, Focus for Next Week = what I am doing next and Risk/Blockers, of course. One simple RAG for all.

I sent the template out and all the other workstream leads liked it as well so the Program Manager agreed.  Hooray!

I consider that a victory for Agile within a waterfall project.

Sweater Weather

It is finally getting cooler here in the Northeast and therefore it is time to bring out the warm sweaters.


I love sweaters, but I hate the process of changing over and organizing my closet twice a year because it always turns into a full day project with straggling things like dry cleaner trips and Goodwill runs left hanging on for weeks.

A few weeks ago I was preparing a presentation on Kanban so I was re-reading Kanban from the Inside by Mike Burrows. Those of you familiar with Kanban know that one of the main tenets of Kanban is to limit Work-in-Progress (WIP).  The reason for this is that there is a limit to the number of things you can do simultaneously and still do them well and get to done-done. This got me thinking about my closet. My problem is that I try to do it all at once.

So, this year I decided to limit my WIP. I made a list of things I wanted to do (tasks) to get my closet organized for winter, I gave them a size (as in effort) so I could decide what I had time for, and I tackled them one-by-one over the course of a few weeks instead of losing a full, precious weekend day in my closet alone with my clothes and shoes. I mean, I love my shoes, but I prefer when we are out together. I also employed the “1 Minute Rule” which helped with things like “I’m not sure if that fits me anymore” and “Are these shoes too worn out to keep?”

I got through my list of closet (and dresser) tasks rather painlessly this way and it was done in about 2 weeks not including the Goodwill drop-off.  I wish I had tried it sooner. I was able to do as much as I had time for at a single sitting. If I had an hour I chose a bigger task, but if I found myself with 15 minutes there were a good number of small tasks on the list as well. And throughout I never felt like I “lost” any time to the job.

Kanban is the quiet cousin of Scrum, but it really deserves its own show.  I love it.

Here’s the checklist I created for this exercise:


Scrum in the Classroom

Using Scrum in the classroom is not a new concept. It has been tried in a bunch of different classroom settings and written about many times. One of the first articles I ever read about it was written by Jeff Sutherland and it has always been in the back of my mind since I first read it.

As I mentioned in my previous post I was lucky to have my friend Karen come for and extended stay this summer. Karen and I have known each other since we were in middle school so when we talk, we discuss anything and everything, including our careers. I was telling her about my blog and some of my career aspirations and she asked me a lot of questions about how Scrum works — especially the planning aspects and the retrospectives.  I mentioned some to her some of the classroom success stories I’ve read about as well.  We talked at length about how to run a retrospective because it was something she planned to use for a Teacher Inservice workshop.

Additionally Karen wanted met to talk her through the other Scrum ceremonies so she could apply them to a new class she would be teaching. Then time and life got in the way and we never had that detailed conversation (which I hope we still will!). Being the bright and resourceful person that she is, Karen went to my blog (this blog) and read my posts about the Kanban board I created for my daughter and she adapted the entire idea for her class.  The class is a new offering and it is a video production class. Karen said:

The kids came in and immediately wanted to start filming, but I told them there was a bit of prep work beforehand. So, I made them brainstorm and list what they needed for a successful broadcast.

We came back together and they told me their tasks. I wrote them on post-it notes and they decided how to prioritize them.

Sounds a lot like Sprint Planning to me!

Here’s her board:


Karen went on to say:

The discussion was amazing. I did nothing but facilitate.

Those kids are not often given the chance to do something like that. They rose to the occasion beautifully.

I was so pleased to hear this. I suggested that they do a retrospective as they complete each video so they can see how they can try and makes things better each time. I think the kids will like the format where instead of being judged just by the teacher, they all get to discuss and work on improving.

Another idea for them was to  create a full backlog of video ideas, in other words a product backlog. I cannot wait to hear more from Karen on how this continues to work in her class. I promise some updates along the way.

As we are very busy getting ready to start a new school year at my house I am readying our Kanban board again, I am even more motivated to keep this going.

P.S. Karen – I still owe you some more materials on Scrum. They are coming your way next week.

Not Quite Back-to-School Yet

Despite my work schedule not really changing summer always feels like a time of slacking off. I guess that explains the lapse in my blog posts. Plus the fact that my favorite person to experiment on has been away at sleep away camp for the last 4 weeks.  As you can see here, she’s been enjoying!


However, I have not been completely idle. I was lucky enough to have an extended visit from a teacher friend and we had several interesting conversations about applying agile practices in the classroom. She took away some ideas to try and now that school is starting up she has promised me some feedback on how they are working for her. Specifically she is going to try a retrospective format for teaching teachers a new way of getting reading concepts across. And she’s going to try some Scrum ideas with a video production class she’s starting up. I can’t wait to hear how these work out and sharing with everyone.

I’m also exploring some ideas I have on managing personal goals. The Bullet Journal is a great tool for this, but I am finding it needs some more structure. More to come on that as well.

Hope everyone is enjoying the rest of the summer!



Bullet Journaling

I’ve been using, or trying to use, my bullet journal for almost 3 weeks now.  Like any change in routine, it has been really good, but it also has its challenges. And without further ado, I will jump into the bullet points.

The Challenges:

  • Before I got my bullet journal I was using 2 notebooks and I haven’t been able to give either of them up yet so now I am carrying around 3 notebooks. That is at least 1 too many notebooks.
  • At work I tend to use my notebook for notes and to do lists and whatever else I need to write down. My bullet journal is too “fancy” and too specifically organized for that. I fear I will never get away from having at least 2 notebooks
  • I haven’t yet found the future logs to be very useful. Maybe that will come with more time?

The Good:

  • I’ve combined my work and personal life to do lists in my bullet journal and that has definitely made me more efficient. If there’s a small thing on my personal list it is right in front of me when I’m eating lunch or something and I can just get it done instead of forgetting it.
  • This type of journaling provides a delicious sense of accomplishment
  • I’ve gone onto to YouTube and looked at some videos of the really creative things people are doing with their bullet journals. Wow, some people take bullet journals very seriously! While I am not up to design themes for each month or much artwork I have added a few other trackers into my journal and I am enjoying seeing my progress in those areas too

Like any good Agile practitioner, I will keep on refining my process with the bullet journal.

My first goal is to get down to no more than 2 notebooks.

When the going gets rough

Up until this point I have been writing about Agile practices outside of work, but today I am going to focus on agile at work. Specifically on trusting the Scrum process — especially when crises occur.


My place of employment has been going through a lot of transition in the last few years and it has led to all kinds of frustration. Change always does that. As a result of the organizational changes both of my Scrum teams now include new developers and there are fewer of them. Some of the new team members are good, and some are not up to the same standard that we are used to. It takes time to build a good team.

As a result of these changes to my teams, work has been proceeding at a slower velocity. We are working on that in various ways, but recently I have had a couple of urgent requests from stakeholders come my way where the requestor specifically asked if we could do something “outside the sprint.” When I have asked what that means, I don’t get an answer.

I do know what that means, actually, but no one wants to say it out loud. It means I need this other thing (this unplanned thing) done ASAP and I don’t want to have to give up any of the other work that is already in progress and it cannot wait. It also means I don’t want to think about reality.

I understand urgent requests and am all for responding to changing needs (of course!), but I cannot advocate trying to work around or outside of the Scrum process. In my opinion the only thing that can happen is that all the work goes even slower causing even more frustration.

To all you stakeholders and product owners out there who get feel that Scrum doesn’t work in a crisis please try to remember:

  • Scrum is all about getting the highest priority work done first. If the focus changes from one goal to another sprint-to-sprint to resolve urgent issues, that is just fine. The process is designed to be flexible that way.
  • There are a lot of ways to work on improving velocity, but sacrificing the Scrum process is not one of them. You will end up waiting longer for everything instead of solving your urgent needs and the team will never improve.
  • Developers are not like coat hangers – you can’t go out and buy more or borrow from someone else’s closet just because you have more coats than you usually do. Developers need ramp up time on any project. QA is important.
  • In a crisis it is better to solve the problem than to create more with a band-aid.
  • It takes time to build a good team.

Bullet Journals are Agile

bullet_journalHave you heard of a Bullet Journal? If not, the Bullet Journal site will explain it all to you in detail, but here is my summary:

A Bullet Journal is a personal version of Scrum.

If you are familiar with Bullet Journals or have one yourself you may already have realized the goals and potential benefits of keeping one, but if you’re also a Scrum Nerd like me, you may have also realized how the techniques also line up to The Scrum Guide and the Agile Manifesto.

The Scrum Guide’s statement on Scrum Theory says:

Scrum Theory:

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

-The Scrum Guide

Transparency, inspection and adaption is exactly the process one follows when keeping a bullet journal.

Additionally Scrum is described as being:

  •  Lightweight
  •  Simple to understand
  •  Difficult to master

Again, I would say this is all also true of Bullet Journals.  It is a simple concept that takes time and refinement to employ in a way that is truly effective on an individual level.

Bullet Journaling is described as:

Bullet Journaling lives at the intersection between mindfulness and productivity. A system that adapts to your life every single day. The Bullet Journal is a customizable and forgiving organization system. It can be your to-do list, sketchbook, notebook, and diary, but most likely, it will be all of the above. It will teach you to do more with less.

– bulletjournal.com

Let me explain my thinking:

  • Rapid Logging is the first instruction in getting started with Bullet Journaling. Rapid logging is the technique used and it consists of four components: topics, page numbers, short sentences, and bullets.
    – In other words it contains just enough information as is needed.
  • Future Logs and Monthly Logs are used to help establish the daily log
    – Sounds like a Product backlog and a Sprint backlog to me
  • The Daily Log and Migration – the daily log is established the night before for each day and tasks or items from the day before are migrated to the new day.
    – Daily Stand Up anyone?
  • Refinement – the process of bullet journaling requires constant refinement. Indexes and symbols and habits need to be established over time to make it work on an individual level. This requires practice and reflection regularly.
    – Refinement of the process is an important goal of the retrospective
  • Goals – Just like a sprint, Bullet Journals help users establish and keep track of their progress towards defined goals. Those goals are personal.

I made an attempt at bullet journaling about a year ago. To be frank, things in my work life became so haywire that I abandoned a number of practices and am now establishing new ways of working for myself. I have decided to re-start my bullet journal to see how it aligns with my agile practices both at work and at home. I will periodically post on my progress.

Anyone who’s interested in hearing more about Bullet Journaling should definitely visit the website, but also watch this great TED talk by Bullet Journal creator Ryder Carroll.