Scrumban.

At the moment, I am helping out on a slightly different team on my project as an “adhoc PO”. While the rest of our project is pretty much scrum all the way, this team works a bit differently. They are not strictly setup as a scrum team with one scrum master and one product owner, as well as development and QA teams. In this case, because of the size of the backlog, we have a pretty large development team that makes it difficult if not impossible to support with just the one product owner.

The main focus for this team is our backlog of “next-in-line-but-not-necessarily-vital” items AKA product maintenance. All of the pieces on this particular backlog are important, relevant and need to get done, but they don’t or didn’t quite fit in any of our scrum lane work over the past few releases. The tricky thing is that all of these items are not as obviously related or structured as the rest of our backlog, hence making it much harder to properly prioritize and stack rank for the PO on the team.

Also, since this team is also responsible for supporting and fixing any new enhancements or bugs that user report or request, the backlog is nowhere near as complete or static as the rest of our scrum lane backlogs. Planning a backlog on shifting sand as it where, meant that our project leadership decided that perhaps scrum wasn’t quite the right model for this team, although they were very keen on continuing down the agile road.

Enter Kanban – a model out of the lean toolbox that is often adopted on the factory shop floor and at it’s most basic form features a just-in-time and off-the-top-of-the-pile approach to development. In essence, the backlog is prioritized and stack ranked and as soon as any developer has an opening, either because they finished their current story or because they have some idle time while working on another story, they pick up the next item from the top of the backlog queue.

Because of this model, stack ranking in Kanban is possibly even more important than in scrum, to ensure that the flow of work doesn’t stop and the production line never breaks. And this is exactly why we decided to not only assign more than one product owner to this team, but also went for the slightly unusual approach of having “adhoc POs” – such as myself – to lend a hand and help groom the backlog to make sure we can maximize the team’s capacity and effectiveness.

I really am looking forward to getting a little more immersed and learn more about Kanban vs Scrum – so far, it’s an interesting new perspective.

 

The post Scrumban first appeared on Agile, Now What?

Location. Location. Location.

Over the next few weeks, I am lucky enough to be on location on the beautiful Island of Tasmania – better yet, I am here on vacation. 🙂

Since I don’t particularly want to spend my time writing about work while relaxing with my family, instead I will share some thoughts from others in the agile community.

Today:  Distributed Collocation.. an Oxymoron? by AccuRev

I hope you like it – see you in a few weeks!

Backlog Defect.

On my project, I am constantly challenged with trying to combine and separate our product enhancement backlog from our defect backlog.  Now, if you read this carefully, you will probably think, wait a minute, how can you combine and separate the backlogs? Exactly that is my conundrum!

In principle, I am of the opinion that it makes more sense that the two should be combined, so we can streamline the priorities, the sequence in which we should tackle defects over enhancements and so on. However since there are different teams of people that work on the different requirements and features it is difficult to get to one master list that everyone can work off, as it blurs the lines between responsibilities which can lead to some unnecessary confrontation.

And then there is the question of continuity. Just creating one big list at one point in time, so we have a complete view of what is on our plate, is definitely do-able, the problem starts when it needs to be maintained as such. Suddenly the list morphs into several independent lists, updated by different teams and prioritized without cross referencing other items, that is very difficult to keep track of and control.

In our project, particularly as we have to engage external vendors for some of the work we do, both to support our enhancement work and to help out with certain defects, having a disparate backlog causes a bunch of complications that make it difficult to communicate to the “outside world” with one product voice. What seems to happen is that various teams have parallel conversations that are not necessarily aligned internally, which is complicated and confusing – for everyone involved.

It’s a big challenge and one that I hope to find a good solution for – how do you stop your backlog from becoming a defect?!

Checklist.

I was actually very happy this Monday, strange I know, but right now, everything to do with my (part of the) project seems to be going very smoothly. My team is primarily focused on the technical discovery for the next feature, which leaves me with a bit of breathing time to focus on the backlog.

Not that it was easy to get to this point. It took us quite a while to get to a point where everyone was aligned and understood what our next steps should be. Now that we have switched to agile, everyone involved in the process is less and less comfortable with the idea of spending time on anything that may not yield shippable software. Problem is, this next feature we are working on is so complex, involving multiple systems, multiple skill sets and processes that we simply needed the extra time.

We already spent a few weeks digging into and defining the business process – we really needed to also allow the same focus on the technical discovery to make this piece of the puzzle work – and more importantly work well! But, how can we communicate what we need to do, show our progress and make everybody understand the value?

Well, we ended up trying various different approaches and quite frankly, in the end, the most effective way of communication was a checklist, albeit combined with a couple of fancy graphs to make it interesting. Having a clear list of what we needed to do and investigate in order to be able to move forward with this feature was ultimately what we all needed in order to move forward. For our team, it gives us clear direction on what to work on now and next and for our stakeholder outside, it gives them a good idea of exactly what we are going to deliver and when.

Being a big fan of lists – I make lists for everything, literally – it was more of a compulsion to create a list of tasks and I did it primarily for myself to get my head around the process. In the end however, it turned out that it gave us and leadership the direction we really needed to stop talking about how we might do what and just get started and get stuff done. We eventually turned our checklist into stories, so now they live as our spike backlog and we can create the usual burnup charts that show our progress and productivity – making sure our stakeholders are happy  and informed.

So, we are now back in the world of scrum, with backlogs, showcases and burnup charts, but in the beginning, there was my good old friend: the checklist. I couldn’t have done it without you!

 

Backlog grooming.

Reading about backlog grooming on other blogs and talking to other Product Owners, it seems that backlog grooming takes place primarily within a certain release or even just from sprint to sprint. What I am noticing in our project is that backlog grooming further into the future is proving a little tricky. Especially for all those requirements that we gathered when we were still planning to continue developing in waterfall as opposed to agile.

Those requirements were typically written in a different format and are a lot more specific, as is required in a waterfall project. Now that we have switched to agile, integrating the “old” requirements into our current backlog is not quite as simple as turning them into appropriate user stories.  Most of them have to be rewritten rather than just be updated into user story format, some are better off grouped into one agile epic and some really are just too specific technically, which would stifle the iterative process of agile. Not to mention the huge effort of sifting through the backlog of hundreds of “waterfall” requirements trying to identify those that were either implemented or made redundant by some of our more recent development.

At the moment, since we have switched over to agile earlier this year, I am not sure we have found the most effective way to manage our backlog for the future. Rather than having one source of epics and features that we would like to see implemented at some point, it seems there are various versions of spreadsheets, requirements documents and vision presentations. For the most part, these requirements and features are organised and categorized to make it easy to prioritize them, however that is largely true for the new additions, not necessarily for any of the older “waterfall” items.

I am not personally the keeper of this backlog, so I can’t speak to how easy it is to manage on a daily basis, what I can say is that as an outsider it is difficult to get the big picture. Perhaps compiling all of these into one centralized backlog is the obvious thing to do, but admittedly that may not be as easy as it sounds. While we have implemented and are using online software to manage our sprint and release backlogs, our product backlog still is very much an off-line beast.

Now that we have a couple of agile releases under our belt, perhaps it is time to develop a more transparent backlog process for the future – otherwise we may end up having to spend a lot more time grooming.

What’s the story?

For the next few days, it’s going to be head down writing user stories for a new feature. In order to get into the right mindset, i’ve been spending some time reading and re-reading some articles related to how to write a successful user story. there is a lot of information out there, but most of it boils down to the simple sentence of:

As a [user role], I want to [goal], so that I can [reason].

As such, the principle is very clear, however the output isn’t always as clear, unless of course you were the person writing the story. One thing that most articles and how-to’s stress is how important it is to discuss each user story with the entire scrum team. This conversation is the key to ensure understanding for all parties. The product owner can be sure that the stories are understood and also benefit from the feedback of the testers, developers and scrum master, to improve the story writing in future. The team of testers and developers can use the discussion time to ask any questions, clarify and start jotting down ideas on technical details and testing approach for the feature.

In my projects so far, unfortunately we haven’t spent that much time on discussing user stories, particularly for our last effort, as we actually handed over the user stories and all of our other output to another scrum team. Not having that discussion definitely caused some confusion and a certain amount of re-work for the scrum team taking over. As they were not involved in writing the stories and we didn’t have the dedicated time during sprint planning to discuss each of them, there is a level of uncertainty as to what each story actually means. Reading over the stories again myself, I was fairly sure that they were pretty clear, but then again, I wrote the majority of them, so obviously I would understand.

I think my take away after that exercise is that I need to be a lot clearer in my user stories; make a bigger point of specifying the who for each user story, whether there are multiple users or not, and most importantly really stress what the benefit or the why will be. It seems that as soon as people know the why of a story, they are much more likely to understand the what. And considering that we are working agile – whether their interpretation of the what matches my own doesn’t really matter, so long as it serves the purpose of the why for that particular who.

Having worked in waterfall for such a long time it still feels a little strange to not specify details upfront and even with all my good intentions to focus on the why, the output of my user stories was still firmly centered around the what.

I suppose, at least I notice my own mistake, so this next time, I can do better and truly focus on the who, the what and especially the why of the story.