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.

Root Cause.

I read a few interesting blog posts recently about the value of root cause analysis when investigating product defects. I myself am actually a fan of the principle, since there is nothing more infuriating for a user than having a problem fixed without understanding how to avoid it in future.

However, sometimes a root cause analysis simply doesn’t help in avoiding or even fixing the problem as Mike Cohn so beautifully describes in this post:  http://www.mountaingoatsoftware.com/blog/root-cause-analysis-of-the-failure-of-root-cause-analysis

This doesn’t exactly convince me to never do a root cause analysis again, but it certainly makes me wonder whether we sometimes spend too much time analyzing that could be better spent fixing the problems right in front of us…

Instead, it is a lovely reminder that one solution most definitely does not fit all – and that we have to be a little more creative in trying to figure out what went “wrong”.

Quantity or Quality.

It seems the QA testing team is the one interested party in agile scrum that tends to get a little neglected. Nobody disputes the necessity or indeed the importance of testing the new code, however in my experience, our testing team have received the least amount of training and support to change to this new methodology.

In our project, we are very lucky in that the vast majority of our testers have been with us for many months, they are familiar with our application, have met some of our users and are therefore very well equipped in understanding what we need the system to do. Each of our scrum teams have their own QA resources that are involved in the discussions around each story. Of course, in agile, testing happens much sooner in the development cycle which has certainly helped us in mitigating risk before going to production.

However, I am personally not quite convinced that we haven’t shifted our focus ever so slightly away from the quality of our QA. It’s not that we are finding more defects now or that the team are putting in less effort to trouble shoot everything. But to me it seems that we have taken away some of the focus off QA, as it no longer functions in its own testing cycle. Where before, everybody on the project team was 100% focused on QA and bug fixing for several weeks, now that the process is built in the scrum cycle, it really is predominantly the testing team that are in charge of QA.

Is that a problem? Frankly, I am not quite sure… Based on our recent experience, I get the impression that there are ever so slightly more defects that we are surprised with when going to production. It’s not that we would have fixed every single defect prior to go-live previously, but I do think that we usually  found them beforehand and were able to mitigate that risk by communicating with our user community.

So, I do ask myself the question: Is the constant push for production ready code at the end of every sprint putting too much focus on quantity at the expense of quality?

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?!

Bad Handwriting.

I was doing some research for the blog and found this article by Mike Cohn and I honestly almost laughed out loud!

Hard to Read Handwriting Is Best for User Stories

It basically states that research has proven that people have a harder time remembering information that they read in an easy to read font, such as Arial, as opposed to trying to decipher someone’s crappy handwriting. So, for any information that you really want people to take in and remember, make sure you write it by hand and don’t even try to make it pretty!

For somebody who often struggles with handwriting, particularly on publicly displayed items, such as flip charts and whiteboards – I tend to write relatively legibly, but typically “horizontal” is a very inaccurate description of my writing direction – this is a very welcome revelation! I now not only have an excuse, but rather a reason to continue to write in this less than perfect manner. Not only that, I will also have this fun fact to throw at any smarty-pants colleague who decides to make jokes about my less than ideal scrawl…

Mike & the scientists – you made my day! 🙂

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!

 

Sharing is Caring.

Starting out as a product owner in an organisation that has only recently switched to agile scrum and where pretty much all fellow product owners and scrum masters are also new to the agile game has been challenging at times. While it is nice to discover new ground together and not feel like the new kid in school all the time, sometimes it would be nice to have someone more seasoned and experienced to bounce ideas of and get inspiration on how to do things better. This lack of agile guidance within the team has often prompted me to go in search of knowledge in other places, mostly on the internet and often in the form of other agile blogs.

Since agile is primarily used for software development, naturally there are many others out there who talk about it on the web. Interestingly, I have mostly come across blogs written by men. I wonder why this seems to be such a male domain? Of course perhaps it’s just a coincidence that my online research has almost exclusively uncovered content by men, but then again even in discussion forums and agile communities, there don’t seem to be many other women who are engaged in the conversation. I am not a feminist by any means, nor do I think that there needs to be an equal amount of men and women in every profession, I am merely curious as to whether there are less women or whether they are just less vocal?

I was very pleasantly surprised when one of the women in agile found my blog the other day! Ladies, glad you are out there! 🙂

Rather excited to find another female voice, I went and took a look at her stuff myself. Cindy, thank you for introducing me to your lovely blog, beautifully designed and cleverly written. I particularly love your clever use of post it notes – inspired! I look forward to following you along and reading more about your experiences in the world of agile and I am very happy to be able to share your blog – a new favourite: http://cinderellascrummaster.com/

After all, sharing is caring.

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. 

Information is Power.

I have spent the past couple of weeks handing over our discovery work to the scrum teams who are now in charge of developing the feature for our application. My team spent a lot of time and effort developing materials, preparing mock-ups and user stories and essentially produced a wealth of information to share with the product owner, business analyst and technical team due to take over the project. Since this was one of the first times we handed over a project with this level of complexity, naturally, we came across a few snags in our process…

While we spent a lot of time defining a lot of details and answering questions, it seems we should have spent more time and effort condensing the information into manageable bites, as opposed to giving the team all the info upfront. We were very thorough and tried to think about all the variations and problems that might occur, in order to build a certain level of trust and comfort in our work and our findings, on the flip side, all the information makes it more difficult to really focus on the core requirements as it’s too easy to get lost and confused in the detail.

They say “information is power”and this is definitely true, however too much information seems to result in uncertainty, rather than empowerment. We learnt a big lesson this week, that while it is great to have all the detail available to refer back to it, it seems to be better to start with a much more high level overview of what we are trying to achieve and why. Only once the big picture is actually understood can the thought process be followed that prompted certain questions to be asked and decisions to be made and ultimately will allow others to understand what led to proposing a certain solution. 

Based on our experience over the past weeks, we definitely haven’t found the perfect balance between the big picture and the detail. Doing the discovery in advance, as opposed to just in Sprint Zero certainly accelerated the understanding for the development team, but not quite to the level that were hoping for. Then again, expectations are probably too high, hoping that the team would literally be able to just “run with it” and we should accept that a certain level of re-discovery is needed to fully get the information across.

We will continue to seek feedback and tailor our approach, so ultimately our information will put the power in the hands of the scrum team.