the accidental scrummaster

I’ve already posted about two other story types (The Secret Epic and The Hanging Chad) and now I have another one for you – The Void.

This is another one of those “if you’re not careful…” practices that can lead to a disorganized project in need of pruning. Another way to think of this story type is a catch-all with subtasks galore. I’ll admit it up front – we currently have one of these. It’s a single story that has amassed a hefty amount of subtasks (we’re talking Jira here) of various validity. As a sample, we have stories that touch on:

• improving the setup of our development environment
• platform configuration
• ideas for helper functionality
• standardizing libraries
• etc…

Notice anything about the items on this list? That’s right, they’re not very specific. Even if the tasks have descriptions below them, they’re not very actionable. This story was created a long time ago (months) and is basically nothing more than a TODO list that’s gotten very stale. It’s sitting in our project, hanging in the background, not serving much more purpose than a simple text document on a shared drive could. Beware these kinds of stories – it’s too easy to just say “oh, put that in the [insert name here] story and we’ll get to it later”. This leads to easily forgotten tasks. Since it’s so easy to let it get outdated, chances are that if the feature was important enough to add there “just in case”, you’re already planning it for a future iteration (or have already finished it and didn’t know it).

Don’t let your issue/bug tracker become a glorified TODO list – make only actionable items that don’t suck up subtasks like The Void.

When it comes to trees, pruning can save a tree’s life if done well. Dead portions are removed so that vibrant, thriving limbs can continue to grow. It’s upkeep and can be a hassle at times, but it’s needed. If you’ve done any kind of agile planning, you already know where I’m going with this.

I recently had enough time on our project to go back through our backlog (and “Known Issues” that were out of our control) and start the pruning process. With the help of another team member, old stories were dropped and duplicates were removed. As a result, the project started to feel a little lighter and less overbearing. As the numbers of pending stories dropped, the real priorities started coming out. It was easier to see what really needed to be done. One of the tenets of agile is that the project is a like a living, breathing thing – it’s constantly evolving and changing into (hopefully) something better than it was before. If there’s a lot of dregs hanging around, it’s hard for any living thing to really flourish.

It’s all too easy to forget to manage the backlog – it’s “out of sight, out of mind”, right? It’s compounded when there’s things you have to push off as “Known Issues” because of some external force that just can’t make it happen. It’s technology, there’ll always be issues that have to be worked around or adapted to, but don’t forget to revisit these things often. New knowledge gained through other development and possible new features on your platform could make these Issues a thing of the past.

Another thing I’ve been guilty of in my time managing our little project is making stories indiscriminately without checking around first. As a result, there were a large number of stories/bugs in our backlog/known issues that were either already fixed or weren’t a problem anymore due to an overhaul of a current bit of functionality. I’ve made a promise to myself that I’ll go back through these two areas at the beginning and end of the iterations to keep current on what’s there. Hopefully this’ll keep the dupes out and keep things cleaner and pruned well.

I want an agile project that thrives because it knows exactly what it needs to do, not be confused about work that may already be done.

So, as of a week or so ago, it was officially official at where I work – I’m the lead of the team I’m a part of (the only agile one in the company). I’d been performing the duties of it for a month or two before after we had two other people (our former team lead and our BA) leave the company. It feel on me to perform a lot of what both of those two did. I picked it up, though, and have tackled the might beast they call Jira to do it.

I still find myself pulled in a few different directions daily, though. One minute I’m coordinating things between team members or answering questions and the next I’m working on a chunk of code that’s been hanging around like a bad cold (had one of those recently too). I’m in the “?” space of my little diagram, though – I’m now in three capacities: developer, lead and the scrum master for the team. It’s an interesting positon (as I’ve mentioned before) and one I’m still coming to grips with. I don’t think the official appointing of me to lead has changed the feel of the group much, thankfully, but I did have to point blank tell my boss today that, because of other duties involved in keeping the team running, my code output has dropped to a fraction of what it was. Of course, I wish I could spend more time romping though our codebase and being a part of those major features. I just have to remind myself that everyone has different ways they contribute to the team and someone has to keep the wheels from flying off.

So, I propose the title of this post as an unofficial role for those of us out there living in three worlds at once with responsibility for code, for people and for the project.

Surely I’m not the only one like this – if you’re in a similar situation, I’d love to hear from you.

Thanks to a Thanksgiving sale over at Programatic Programmers last week, I picked up three new books that looked interesting. I’ve added them to my (ever growing) reading list….probably in this order:

• The Agile Samurai: Here are three simple truths about software development: you can’t gather all the requirements up front, the requirements you do gather will change, there is always more to do than time and money will allow. Those are the facts of life. But you can deal with those facts (and more) by becoming a fierce software-delivery professional, capable of dispatching the most dire of software projects and the toughest delivery schedules with ease and grace.
• The Developer’s Code: It’s hard being a successful software developer, with a career that outlasts the latest fad language or platform. You need to know the technology, the soft skills to work in a team and with clients, and you need to absorb the wealth of tacit knowledge that’s out there but rarely taught or written down.
• Agile Retrospectives: See how to mine the experience of your software development team continually throughout the life of the project. The tools and recipes in this book will help you uncover and solve hidden (and not-so-hidden) problems with your technology, your methodology, and those difficult “people issues” on your team.

They’re all from the Pragmatic Bookshelf. Now to find some extra reading time…

I spotted this in a video (and here) and thought it was interesting:

I’ve just added a new page to the site – a permanent place to share my findings (as added to a collection on Gimmie Bar) that I discover in my agile research – Gimmie Agile.

If you haven’t looked into Gimmie Bar it’s an excellent, super simple powerful way to record everything from entire pages (what I usually use it for) to videos to blocks of text – all with the ability to describe, put into collections and tag with whatever you want. They also have a great API you can use to pull the information back out. Oh…and browser extensions and bookmarklets to help make adding “gimmies” even easier. Go to GimmieBar.com for more info.

One of the things you hope for as a Scrum master (at least in my limited experience) is that you hope that your team will continue on in the same level of development even if you’re not around. I had this experience first-hand this week. See, it’s Thanksgiving week and I’ve been out since Friday afternoon. I took off and flew out to parts unknown (okay, so it’s northern Montana) early Saturday morning. Being the slight workaholic that I am, I still managed to set up our pre-paid cell to check my work email and checked in via IM with folks back at the office from time to time. I had to wonder, though, if the same level of development was happening in my absence.

See, one of the things I struggle with is the balance between a “manager” role and the “scrum master” facilitator. I think it’s too easy to slip into the manager role and have people report in during scrums and try to tell people what do to. From what I understand in my readings, the best scrum teams out there are self-managing. In practice, though, it’s hard for me to let things get that way. I spend some of each day worrying that I’m coming across as too much of a manager and less of a collaborator with the other developers.

Things get even more complicated when you consider a recent promotion I’ve been given – as of this post, you’re reading the words of a “Lead, Development” for our little group of scrummers. It’s a role I’ve been playing a bit already, but now it’s officially official and I wonder how (or if) things will change with the title. I hope that my fellow team members will see me as less of a manager for the project (they have the Product Owner…also our boss…for that) and more of someone that can get things done for them.

Does anyone out there have suggestions for this sort of thing? I have the sort of personality that it’s easier for me to play the authority figure, so I want to be sure I’m doing the right thing by my team.

Anyone involved in agile development can tell an epic from a mile away. When you start talking in generalities and the scope of the task seems daunting, it’s destined to be an epic. These overarching story types provide a framework of sorts for the rest of the iteration to revolve around. Traditionally, we’ve had two epics per two-week iteration and it seems to fit our team pretty well. (Though recently we’ve shifted our development practices so there might be one or there might be three – it just depends on how the (planning poker) cards fall.

There’s another type of epic to keep an eye out for – they’re sneaky beasts and can seriously trip up your team if you’re not paying attention. The “secret epic” starts out life as a story, but despite everyone on the team’s best efforts, evolves into something bigger. The time required for the story suddenly doubles because of technology challenges or teams outside your own with different time schedules. Unanticipated issues come into play and suddenly your humble little story has taken on a life of its own. It’s so much bigger than when it started that you almost don’t recognize it for what it really is.

Denial only causes more troubles and can lead to a spiral of extreme after hours work and a burndown that’s painful to look at and a velocity that makes previous iterations look at and die a little inside. Keep a keen eye out for these hidden trouble spots and identify them early – don’t let them drag the team down and don’t be afraid to change things up just because you’ve already committed. It’s only agile, right?

I got the title of this post from a comment my boss made about a story in our current iteration. It seems like the past few iterations, we’ve had a few stories that didn’t quite make it through to the end. Partly it’s our own fault for taking on more than we could handle during the iteration, and the other part has more to deal with the rest of the business. Having an API backend for everything is great until you find yourself having to work around the quirks inevitable in any software. We write out or stories for the best case scenarios and sometimes, despite our best efforts, things just don’t click.

This sort of thing leads to stories I’m going to call “Hanging Chads” – they’re planned work that just dosen’t get done. There’s the best of intentions in getting them done, but something comes up (as it always does). The development gets halted by an issue and suddenly the product owner and planners are left with a decision – move the story to the backlog and swap it out with something that’d fill the time left, or keep the feature hidden (a tricky process) and push it through to the next iteration. The more we do this the more I realize it’s a bad idea.

The whole point of planning an iteration is to estimate the amount of total work that can be done in the time given. When you don’t start with a clean slate, it’s like jumping into a half-filled pool. You’re not sure exactly how much is left to go, but you know there’s already a bit of something there. Looking back to past leadership in the planning and general upkeep of the iterations, I have a better understanding of why our business analyst discouraged this “move it forward” philosophy.

I’m still too early on in my agile management life to figure out exactly what to do with these, so any advice would definitely be welcome…

Let me start off by saying this, if everyone talked to everyone on a team, you’d spend a lot less time in meetings. Unfortunately, we – as developers and people in general – aren’t that good at communication all the time. One on one conversations are great, but there’s times when it’s just more effective to gather the troops. What’s the default way to get a large group of people relatively on the same page? Call a meeting!

One of the major keys to working on a Scrum/Agile team is communication (as I’ve mentioned before). Usually this means team members coming together as needed and working out the issues themselves. Ideally, this should be 99% of the communication that happens in your team. There’s still a little matter called the daily scrum, though. It’s the one meeting that should always be an important feature in your team’s day. It’s easy for them to become rote, though – so be sure you make it more than just a status update.

Here’s a few suggestions that have been made to me about our standup, trying to make it a better, more productive meeting and get the developers in and out as quickly as possible:

• Make it more than just a status update: Don’t let people get away with “I fixed some bugs” or “I’m not sure what I’m working on next.” These should always be followed with specifics and/or a new item from a list of needs. If your bug tracker is doing its job (and your devs are tracking correctly) everyone should know exactly what should be next.
• Bring up old topics: Think about things that were brought up as things to work on the last iteration and mention them to the team. These issues will come up again, that’s just human nature. Having a good list of things to point to and say “we should be working on this” can help the group improve.
• BEING ON TIME: I’m putting this in because it’s one of the most frustrating things to me. Sure, I’ve been on the other side of things as a developer. I know that a general meeting during the day (we do it first thing in the morning, so it’s a bit easier) can start to feel comfortable to some people and could cause a bit of slacking. It’s too easy to fall into a “I’ll get there a bit later and no one will care. As long as I’m there for my update, it’s all good.” Unfortunately, this is far from the truth. The daily scrum is one of the most important things that happens for the team. Not only is it a good place for leads/managers to come in and report things to the whole team but it’s very important for everyone to know the status of the project. People coming in late and asking questions like “Did someone already mention…?” waste time. Having everyone there, either in person or on a conference call, is vital to the project staying on track.