Trying to be Agile

I'm working with a client that's adopting agile. One thing they've done is build their own agile PM tool. It's not bad, but not as good as Rally or VersionOne.

One thing the tool allows is to assign user stories to the "front burner" or "back burner" with the idea that if it's on the back burner, you get to it if you have time...but you still assign it to an iteration.

From an agile perspective, I think this is a bad idea. Iteration planning is about getting the team to commit to the work of the iteration. A story is either in or out. This tool allows you to put a story somewhere in between. It's assigned to the iteration, but it doesn't show up in your story point count or the standard view of the story board. The product owner may think it's in, but the team can easily forget about, leading to disappointment when the iteration is over. 

It's important to have transparency across the project. The product owner and team need to be on the same page without any ambiguity about what may be in or out of scope for the iteration. 

I was with a client this week that was just starting their agile journey. They had been through the training and knew the basics, but watching one of their stand-ups made me think about how green I was when I first started doing agile.

At the beginning of the journey, it’s important to learn the basics. The team I watched still wasn’t getting the stand-up right. It didn’t start on time and just kind of rambled, rather than addressing the 3 questions.

My kids played in the jazz band in high school. Learning agile is like learning jazz. First you have to learn the rules, then you practice them. Finally, you evolve to know when to break the rules.

The team I saw was still learning their scales. They had a way to go. What’s important on this stage is that they get good feedback and direction, a coach that can play the role of band director and move them in the right direction.

The Pomodoro technique is not something unique to agile, but it's one of those productivity techniques that agilist know about and use. I'd group it in the personal productivity category along with other technuques like personal kanban. It actually works well with personal kanban.

I was recently using this for an important tasks I had to get done. I had a report to write and not a lot of time to do it. So I took advantage of pomodoro to focus on the task at hand.

If you're not familiar with that the idea is that you sit down for 25 minutes completely focused. You don't let distractions like email or instant messaging keep you from doing that work. At the end of 25 minutes you take a five-minute break. This is your chance to check email or look at your Twitter feed or whatever you want to do. You continue this for usually three or four cycles and then you take a longer break. It's that simple.

I find the 25 minutes don't seem overwhelming in terms of how long I'm working on something and the breaks come pretty quick. But I also feel that this approach helps me to stay focused longer, rather than trying to work on something for an hour or more at a time without taking a break. I find for 25 minutes I'm able to keep distractions away. When I'm not using the technique and working for longer periods of time, I find distractions creep in on me.

There are apps you can find for you smartphone, or simple get a basic kitchen timer. The technique is named because of the tomato shaped kitchen timer the originator of the technique used...pomodoro being the Italian word for tomato.

I came up with the idea for this blog while listening to a presentation by Dave Prior at Agile 2014. He was talking about our agile journey and how do we know when we get there. The reality is, we don’t really get there, we continue on a path.

As an example, I've been working with a client that thinks they're doing agile but the reality is they're not really being agile. They put some practices in place that are agile-like but the actual mindset hasn’t really settled in. For example, they are writing user stories but for every user story they write a use case that's a very detailed requirement. They are writing this all up before the first iteration planning session, so in essence they’re still planning a waterfall method but just using user stories.

I think one of the reasons they reached this point is that at some point a couple years ago they were trained on agile but after the training they started following some of these practices without really understanding the principles behind them. As time went on they started to drift back towards some of their waterfall practices and without continued coaching and mentoring they drifted farther away from being agile.

Whether we’re looking at our individual path or an organizational one, agile is about inspecting and adapting. Frameworks like Scrum might be a good starting point, but we need to continue to adapt those practices to fit our needs. We need to continue to ask “How can I do this better?”