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?

Visual Aid.

When I am writing User Stories and Acceptance Criteria, sometimes I really do wonder how my poor developer teammate is supposed to understand the garbled descriptions and instructions I put together. Sure, sometimes it so obvious, there is no danger of mis-communication, but more often than not, my stories are complex and complicated and convoluted.

Personally, I am a big fan of visual representation of what I would like to achieve. Actually, truth be told, I almost always draw a plan or flowchart of whatever it is I need to then put in writing. Not sure why, but when I can follow the flow of an arrow, I’m much more likely to find gaps in my thoughts, than trying to read through a script. Likewise, when trying to imagine changes in our UI, I prefer to create a few mockups instead of writing descriptions.

The downside for me is, that it usually takes longer to create a mockup or flowchart. Simply writing down what I want is absolutely quicker, but then again, more often than not, writing doesn’t accurately convey what I was trying to explain, so I end up having to go back and forth to explain anyway. After all, there must be a reason people say a “picture is worth a thousand words”.

Naturally, it usually pays to not rely only on my drawings or scribbles and I pretty much always write up everything, but I absolutely think that nothing beats a good visual aid.

 

The post Visual Aid first appeared on Agile, Now What?

Backlog Button.

I have spent so much time over the past few weeks reading, updating and prioritizing items on our product backlog, I feel like we could have literally built a whole other system at the end of it…

I exaggerate of course. The list is not that long, but it certainly felt like it at the time. It can be so time consuming when not enough care is taken to write down the requirements or problem steps in the beginning. Trying to decipher somebody else’s description of an item really is challenging, it almost seems like  some of them are written in a foreign language. I mean, I know we have users in China, but i’m not sure that means that our backlog has to be written in what appears to be Chinese?!

Nevertheless, there’s only one way to deal with this and that is grit your teeth and fight through it. Unfortunately, diligently updating and prioritizing the backlog really does take time, far longer than I ever thought possible… and of course, nobody wants to wait until we have checked everything before choosing what we will work on next. Surely we already know what the biggest priority items are anyway, right?

Well, truth be told, at this point in the game, we don’t. By “we” I speak of our collective Product Owner team. Of course we each have our own opinion as to what we would like to get done first in the next release, but a clear and definite answer to what is the next big thing? No, I can’t honestly say that we have that. Not yet anyway. We have a good idea, we have a strategy and a plan to get there. What we don’t seem to have is enough time to actually do it.  And I really really wish we did, because it is more than a little demoralizing to have to say that no, the list is not ready yet. Especially when most people seems to think that the one (and only) thing we POs are responsible for is that very same list.

After all that the top priority item on my new list will be this: a Backlog Button! 🙂

Choosing Change.

Something I find particularly difficult to deal with sometimes is how to handle all the suggestions, ideas and requests we receive from our end users. I am not talking about feedback regarding functionality that we are currently working on and where we specifically asked for feedback and user input. I am talking about all of those little things that users would really really like us to change or add to the application – particularly those that may not necessarily be a good idea.

Of course, users always have a specific reason in mind why they want the system to do something. However, not always are these requests really born from necessity. Especially in our case, where our application is replacing another system that many of our users have been working with for years, in some cases even decades. It’s no surprise really, that a not-insignificant number of enhancement requests could be simplified into one user story:

“As an experienced user, I want the system to handle this process the way my old system did, so that I do not need to change.”

Like I said, nobody is at all surprised that we receive requests like that, however somehow we haven’t yet figured out the best way to deal with them. Yes, we do have an extensive team of trainers, support staff and even a specific change management department, but requests such as these seem to bypass those teams entirely and in the end, tend to end up as enhancement requests in our product backlog.

For us product owners, this makes the process of prioritizing and grooming the backlog that much more difficult, because not only do we need to evaluate, prioritize and write user stories for all the very valid and great suggestions we receive from our users, we now also need to figure out what to do with the undesirable ones, who frankly just clog up our queue.

I do believe that the product team is responsible for choosing change – but we are probably not the right team to manage its undesirable cousins and the users who request them…

Don’t Get Emotional.

One of my least favorite tasks as a product owner is having to prioritize the backlog and stack rank stories to make sure we develop the right things at the right time. In principle, I don’t have a problem prioritizing items, what I do find rather frustrating is how emotional and subjective prioritization often is.

I myself am a huge fan of logic and formulas and empirical research (geek alert!) to reach a conclusion as to which items are important, rather than just going with my gut. Having said that, sometimes it is necessary to go above and beyond what the data says, because there is a specific item that triggers a lot of emotion – negative or positive – from the overall user community, that warrants an increased priority.

On my project, we have a lot of those very vocal, very passionate users, that are sometimes rather difficult to temporarily drown out, so the product team can objectively assess and prioritize enhancements to our application. Furthermore, a lot of us product owners, myself included, have worked in the field as a user at one point in our careers and therefore still have some emotional ties to what is was like being a user. On top of that, we have spent a lot of time and effort to foster a culture of actively soliciting user feedback and enhancements requests, which makes it very difficult and rather uncomfortable to say no to requests, even though sometimes we probably should.

With all of this emotional baggage, a product owner’s judgement can easily be clouded – not deliberately, but subconsciously. Even more reason to develop a clear-cut, fact-based system to rank and prioritize stories and features based on their attributes. But which attributes are the right ones to look at? Do they all carry the same importance? Do we rank technology over user experience or vice versa? If the system crashes, because we overload it with data and logic, that is obviously very bad. But at the same time, we also cannot ignore the user emotions and aggravations. Instead, we need to find a way to quantify the user reactions to be able to compare and contrast them other measurable aspects of the product. Only then can we determine whether a screaming user is just having a bad day or it is a clear indication that something is very very wrong…

I don’t have all the answers yet, but one thing I am certain of: if you want to improve the prioritization of your backlog, be objective and don’t get emotional!

User Advantage.

A big part of agile development is engaging users, regularly and frequently, to get feedback on the product developed to date. Since our product spans multiple user groups in many different locations, it is not always the easiest thing to get a good subset of users together to evaluate what we have done so far.

Even the simple choice of choosing the location can be quite a challenge. Do we meet at our corporate office? Do we spread out and schedule various sessions on location? Do we just run the whole thing via video conference?

While we have done various versions of the above, the one thing we have yet to try out is do the entire interaction online instead of in person. The one main benefit of trying this out is fairly obvious, it would save the project both time and money if everyone could simply run the meeting(s) from their own location. No lengthy plane journeys to foreign locations, no rental of meeting space, no expensive printing of workshop materials. Sounds great! …or does it!?

Perhaps an approach like this might work if our entire user base was American. (I realize I’m going to stereotype a little bit here, and I apologise in advance if I offend anyone in the process.) In my experience, our American user base is very engaged, very critical and not shy to voice their opinion. For them, having a few shorter online sessions to review the product might actually work quite nicely. They can work it in to their day-to-day and still provide the valuable feedback we really need.

However, a significant portion of our users are based in Asia. And Asia is a completely different story. Not that our users aren’t as engaged or keen to share their feedback, they are, but they are also a lot more reserved and more careful about what they share. Also, a lot of them are newer to the software and have never been involved in feedback sessions before, unlike their American counterparts. For me and my team this means we need to spend some time making them comfortable to really say what they think, not what they think we want to hear.

In the end, it’s up to us to find the right balance and approach for each of our user groups, and to make sure we don’t accidentally favor some of them, only because they make more noise…

Remote Possibility.

These days, more and more people are engaged in conversations about distributed agile. Is it really necessary to have the entire team be co-located in an office all of the time?

I have a strong opinion that agile can work just as well with distributed teams, as long as the basic principles are followed. Starting first and foremost with trust. I am a product owner who works remote. My situation is perhaps not very common, in that I am one of several product owners in our organization working on the same end product. The other product owners all work in the same office along with the majority of our development and QA teams and of course our scrum masters. I on the other hand work in a different location and even a different time zone than the rest of the team and have done for several years.

Initially, our company was working in waterfall, which means that this arrangement, albeit unusual in our organization, didn’t raise that many eyebrows. After all, working remote is becoming more and more popular these days, although admittedly it is still relatively new to the hospitality industry. Developing in waterfall, my working remote meant that I was able to spend many focused hours writing detailed requirements, without interruptions or distractions that naturally occur working in an office. I was able to produce a lot of quality work, delivered on time and with no adverse effects on any other member of the team.

Then came agile… all of a sudden working remote became somewhat of an enemy. Agile says teams should be co-located. Period. Or so people thought. In my situation, re-locating to be with my team at all times simply wasn’t an option. Luckily for me, my managers and team members were open to exploring slightly more unconventional setup of remote scrum. So for the past few releases I have been the remote PO of a scrum team, sometimes with all other team members located together, sometimes with some of them also remote. And I can honestly say: it works.

I wouldn’t go as far as to say it’s just as easy as doing scrum when you are co-located, although I can’t say that with complete certainty, as I never have done scrum without being remote. I can say however that being remote makes me far more organized and forward thinking than I believe I would have to be otherwise. Because my team is working for a portion of the day without being able to reach me, I need to be extra clear in our daily meetings, always make sure I prioritize making myself available to them when I can and ensure that the teams’ priorities are crystal clear, so we don’t run into any bottlenecks.

For me, the key to being a great scrum team is trust. To be successful as a team, I have to be able to trust the developers, the developers will need to trust the QA, everybody needs to trust the scrum master and trust the product owner. Without trust, there simply is no team, without trust, we are just a bunch of people giving and following orders.

While it might seem that working remote scrum makes trusting each other harder, in my experience, it is actually the opposite. Allowing the arrangement where some of the team are remote, is an immediate sign to them and the outside world, that they are members of the organization that can be trusted to work unsupervised. In remote scrum, there is no space for micromanaging or looking over people’s shoulder, we just trust that we each get on with our work. And when we do get together each day, we make sure our time together is focused and used effectively, because we know it is limited.

I can’t say whether working remote has made me a better product owner, but I can say that our team has been able to deliver just as much value as any other co-located scrum teams. So for me, distributed scrum is more than a remote possibility.

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.