Most of what is published about agile/scrum methods doesn’t talk about this area very much. It tends to be focused mainly on a team dedicated to getting a single product to market. As an internal team, we often don’t have that luxury. We run multiple concurrent projects, some with different members, as well as numerous operational tasks & enhancements.

We manage our work, we looked at having multiple Product Backlogs (basically a prioritised list of work the sponsor would like us to complete). This naturally led to multiple Sprint Backlogs (which contain the work the team has committed to doing in the next 2 weeks). This was going to be very difficult to manage. Particularily when it comes to the team keeping focus on their activities. Multiple projects and backlogs all over the place.

What we really needed was multiple Product Backlogs that each project sponsor could manage, but one pipeline for the team to work off during their 2 week sprint.

Mingle to the rescue!

We’ve been using this tool by Thoughtworks for a few months now, and the more I use it, the more I love it. We’ve pretty much ditched Microsoft Project completely as this tool is powerful and simple enough to do all that and more (albeit very differently).

It was quite easy for us to create a number of “card walls” to filter out the work for each project or operational area. We then use these separate lists when we sit with the sponsor to have them prioritise the work.

From that, the team picks off the top ‘x’ stories and commits to delivering them during the next sprint. Mingle makes this very easy for us to manage.

The tricky part is knowing how much from each project we can commit to. Currently, I communicate the number of hours we should be dedicating to each project each week. Hours are one thing, but I’d like to get to the stage where we track our overall velocity. This way, we can more easily determine how many “points” we can take off the backlog from each project and commit to doing.

We’re not there yet, but should begin getting some metrics in the next few weeks. I’m keen to see how this pans out and whether the idea above will work in practice.

I’m a tool/model addict. I love them all. Anything which makes my thinking easier is a bonus. I sometimes struggle with forming my thoughts into cohesive structures, so I find models an invaluable additional to my arsenal.

One of the major benefits to an agile development process is the Inspect-Adapt loop. Reflection, or retrospective as it’s usually termed, is an integral part of continually improving what we do. In a Scrum Retrospective, the standard questions to ask are:

1. What did we do well?
2. What could be improved in the next sprint?

I believe these fall short in many ways. These two questions aren’t targetted enough to generate any real actionable outcomes. Instead, I would use the reflection model. We used it today in our Scrum Retrospective and I think the result was quite good for a first shot.

Like all useful models, it is extremely simple…

Spend a few minutes in each quadrant and ask yourself (or your team), what you should do more of, less of, and what you should keep, add and delete. You can work around them one by one or take random suggestions and add them to the appropriate box.

A nice outcome for the visuals amongst us is that you can see right away which areas you haven’t spent enough time on. I find it useful to focus on these for a few extra minutes  little more and force yourself to stretch your thinking.

It is also a way to subtly celebrate the things you’re doing well and come up with practical suggestions for those things which aren’t so great. When reflecting, it is important to phrase your words in actionable terms. “More communication” won’t get you anywhere, but “Update Jane once a week on progress” is much more useful.

The best thing of all about this model is that it is not only useful for work. When it was first presented to me, it was used for personal reflection. What in your life do you want to do more/less/keep/add/delete. You can really use it for anything you need to reflect and improve on. The more specific the topic, the better the results.

At Melbourne Business School, we’ve started using Scrum to manage our software development projects. Over the last few months, we’ve used it very loosely on a project as a trial run. The elements we picked up were the very basics of scrum. I’m nervous to even say that we were “doing scrum”. Even so, the results were so much better than I expected, and we completed our project ahead of schedule.

In the beginning …

The daily stand-up meeting was the first “ceremony” we instigated. It’s quite simple, we meet every morning for 5 - 10 minutes, standing up and we each answer three questions: what did you do yesterday, what will you do today, what obstacles are you facing?

The idea is that people want to get it over with quicker if they’re forced to stand up during a meeting. It really does tend to keep us focused and to the point.

It took a little while for people to warm to the idea initially, but we soon developed a bit of a rhythm. People were keeping to their time limits, mentioned salient points only and our ability to actually get stuff done increased considerably.

Most interestingly to me, was the new opportunities this created for the team. The opportunity to share every day has made it easier for us to offer help to each other when obstacles come about. I wouldn’t hesitate to say that the 10 minutes invested in the stand-up has returned us numerous hours a week of muddling through things as individuals.

Now …

Lately however, things have started to become more like a status meeting. Going through the three questions just because that’s what we so. I realise now that keeping this meaningful and actionable is not a trivial task. It’s even more challenging for us as the team is constantly working on multiple projects. Sometimes what you’re working on really doesn’t effect anyone else in the team.

We may be headed for “Daily Standup Withdrawal.”

Stacia from the Scrum Alliance writes:

Many teams really, truly believe that the purpose of the daily standup is to “just answer the three questions without exceeding fifteen minutes.” Maybe it’s that the questions (what did you do yesterday, what will you do today, what obstacles are you facing) seem so simple. They are not. There is so much underneath the surface of the three little questions. Coach your team to think about these questions and come prepared to the daily standup [...]

In other words, think about the tasks, the accomplishments, how it may impact John’s work or Mary’s next task, and keep in mind who you are working with to complete the task. Go into the daily standup with answers to the three questions that are meaningful, insightful, and proactive.

Later …

Taking on some advice from that article, I intend to spend some time actively coaching and giving more feedback to the team members. I also need to ensure I don’t contract the same disease myself. A bit of team reflection may be in order too.

Disclaimer

To date, I have avoided writing much about my work environment. Having thought about this quite a lot lately, I believe the net effect of writing about such things will be a positive one. So, it now needs to be stated that this clearly is a personal blog. The view and opinions I express here are my own and not those of the people, institutions, or organisations that I may be related with.