Quality Q&A

Last week when I was looking for inspiration for my blog, a colleague suggested “Why don’t you write about QA?” The simple answer is, I hadn’t actually thought about it that much. Sure, I do my own share of Business Acceptance Testing, but I never really thought that much about how exactly our QA team have had to adapt, now that we are working in agile scrum as opposed to waterfall. I guess I was so busy with all the changes to my own process, I didn’t take the time to look around and see how exactly it impacts everybody else. It’s not that we forgot about Quality, naturally during the change process, it came up in meetings and planning sessions, I just never personally thought about how to best integrate the QA process.

At least until now. After my colleague suggested it, I spent some time talking to my colleagues who are currently on our QA team. Our testers are integrated in our scrum teams, as is usually the case and we use both manual and automated testing. Initially, it was challenging to adapt the process to test during the release, to write test scripts on the go and to avoid testing in silos. The team has made huge progress and is really getting some great results, finding defects much earlier in the process. There is still a bit of a culture of not wanting to find defects, then again that is inherent in the process rather than a symptom of the agile approach. If anything, the fact that business analysts, testers and developers are now on the same scrum team has helped in bridging the gap and reducing the “blame game” when it comes to finding and resolving defects. Being on the same team inspires greater collaboration and also greater confidence in each other.

Following the initial conversation, I did a little snooping around the web to see what other interesting thoughts are out there regarding Quality Assurance in agile, and came across this article on The Agile Warrior. It discusses the changing landscape within software development, changing from clearly defined roles of Analyst, Developer, Tester to more of a hybrid, where analysts also develop, developers also test and testers also analyze. No longer is it each man on their own island, the roles, responsibilities and skill set overlap and get intertwined. I wouldn’t say that we have reached a point where anybody can jump in and do any of the roles, certainly not in my organization, but it is an interesting thought, as knowing all areas of the process certainly would add value to any team and ultimately improve its Quality.

Technicalities.

My team and I are taking a new direction this week: technical discovery! For me, this one is going to be particularly challenging, as I have a lot less experience working with the technical details of a proposed solution. Since I come from an operational background in hospitality, my area of expertise is truly the business and functional side of things. Of course, I know how the system works, what sort of integration and downstream systems play a part, but all of that knowledge is very much from the eyes of a user – not of a technology savvy expert.

Working on this project, of course I have learnt a few things about the underlying technology of it all, I would have to be deaf and blind not to, but I am looking forward to learning more. As a product owner, I always feel a little bit silly, that I don’t understand all the jargon, that I sometimes make suggestions that seem totally logical from a user perspective but really are not the best idea technically. I often wish I really knew what goes on in the minds of our Solution Architects when investigating different options and what influences their decisions. Hopefully, working on this effort to explore the technical intricacies will get me one step closer.

In addition, I hope to get an inside look into how the technical team comes up with their estimations for a particular item or feature. I can pretty much get whether an estimate sounds reasonable or completely crazy, but that’s about the extent of it at this point. Most of the time, that level of understanding is perfectly fine, especially in my organization, where all of the budgeting efforts are done and dusted before a new feature or project makes its way onto my desk, but at the same time, I am always curious to learn more, understand more and be able to contribute. Plus, it really would make me better as a product owner, allowing me to make smarter and more informed decisions when prioritizing the backlog and understanding the capacity of our scrum teams.

So, who knows?  I feel like at the end of this, I might have a whole new appreciation for all the technicalities.

Managing Change.

During a recent internal stakeholder meeting, our leadership team brought up the challenge of dealing with changing the working model for a technology project and how we experienced it in our team(s). Since we are (one of) the first teams in our company that have adopted the agile scrum model, it’s often all eyes on us to try and determine whether it is something that should be rolled out to other projects and teams within the company.

While it is easily communicated, documented and supported with facts how working agile has improved out productivity and product quality, it is not so easy to also share the process and the challenge of managing change. Changing from waterfall to agile is not just simply a change in the way we do things day-to-day, more like a huge fundamental upheaval of everything we do and the ways in which we do it.

For myself – and I assume everyone else in my extended team – it was a very big adjustment. Working agile is an approach so completely different, that it was almost like starting a new job, rather than just adapting how we work. During our change process, this was more often than not accompanied by feelings of uncertainty, sometimes confusion and frustration along with it. More importantly, it was more than just a little difficult to suddenly have to work so closely together within our scrum teams. With everyone feeling a little uneasy and overwhelmed by it all in the beginning, it didn’t exactly create the best atmosphere for productive team work. Moving from a process that is known, that I was good at, that I thought I had mastered, to this new thing called agile was a big deal!

Luckily, in my organisation, we had a lot of support. We had consultants who helped us learn the process and apply the methodologies in our project. And honestly, without them and their constant push to keep going and keep looking towards the benefits, I think a lot of us would have cracked and revolted to get back our nice, comfortable waterfall approach. Especially in the early days, when we were working through our very first agile release, it really isn’t all that obvious upfront, that agile really does improve the project, not just the output, but the day-to-day working within. For anyone wanting to implement agile in their organisation, the one thing that I would say you simply have to do, is get an expert in to help you, not just to explain the process, but have a “cheerleader” there to support, guide and motivate your team to keep at it during the tough times at the start.

Now, a few releases later, I can clearly see how working agile is benefiting us, both in terms of project output, as well as enjoying the daily interactions within and across our scrum teams, getting to know the colleagues specializing in their respective disciplines and gaining a much better insight into how we can collaborate and help each other achieve our goals.

I am pretty confident in saying that most of us have converted to agile scrum. We learnt it. We do it. We like it. Change is good.

Juggling.

This week, it seems that somehow there are never enough hours in the day, I am constantly getting interrupted and I seem to have regressed to the attention span of a goldfish… *sigh*

While I normally really enjoy writing the blog, this week, I just can’t seem to get my thoughts together and concentrate long enough to form a decent idea to write about. Perhaps there are just too many things going on. In my scrum team, we are finalizing not just one but several solution proposals, and that for ever changing requirements, I am trying to finish up some documentation on the discovery phase, assist some users with production issues and help out another colleague about this other thing … plus did I mention I also have to get ready and organised for a two week stint of business travel?

Anyway, long story short, while I am trying to juggle all the bits and pieces on my plate there doesn’t seem to be enough time to write something truly meaningful. So, since I am a big believer in not wasting people’s time, I shall follow that rule and not keep you any longer.

Instead, I’ll practice my juggling…

Zero value.

I’m going to be blunt and honest: today’s post is going to be pretty short. Not that I don’t have new stories to share or ideas to promote, but today is one of those days, where I simply have too many things to do and not enough time to do them all!

So, instead of me writing a big long post, I thought I “cheat” and instead refer to you an interesting article I read just yesterday on the ScrumAlliance. The post is about “what is sprint zero?” About what it tends to be used for in many organisations and what it ideally should be. I found this is actually an interesting gauge to try and figure out how agile our organisation really is – and I think we might still have a way to go before we can claim that we have really and truly switched both our working model and our mindset to agile…

As described in this article, sprint zero is frequently used to plan your release, groom your backlog and put together design ideas – which, when you look closely, very much resembles a mini-waterfall. I have to admit to doing this myself, probably because I am relatively new to scrum and I think I am not quite there yet in being comfortable to just start “sprinting”.

Naturally, it takes a while to trust the process, and perhaps there is value in not trying to do things to soon – however there is still a little nagging voice in my mind that urges me to be careful and check myself so that sprint zero stands for “zero value sprint” and not “zero agile process”.

Showcase Discovery.

This week my team and I are once again faced with the question: How do I showcase work done in a discovery phase? Since our team is running on a sprint cycle like the other development focused lanes on our project, we are also expected to showcase our work every 2 weeks. In our organisation, and I presume elsewhere, showcases are not only use to actually showcase the new functionality and code developed, but also to keep track of the teams’ progress, highlight risks, challenges and get feedback on future development work if needed.

Of course, we can easily give updates on our progress, highlight risks and challenges, that part is simple, no matter what you do. Where I struggle is to find a good way to actually showcase the work my team  and I have done. Demoing work completed is all fun and games when you are showing fancy new software, but it seems a bit dull when what we have a produced is a required mapping document, written a bunch of user stories, maybe drawn up some flow charts and logged our work on questions, answers and follow ups on a spreadsheet. All of this work is necessary, important and very relevant to ensure we are discovering and documenting the best possible solution, but it doesn’t make for a very entertaining showcase…

And then, there is the other, far more important aspect, that the showcases are supposed to be a forum to gather feedback, float opinions and ultimately leave with suggestions on how to make our solution even better. This part is especially important to my team, since we are working in a “pre-user engagement” environment, where our only feedback comes from internal sources, most of whom are the people attending our showcases.

So, the question is, how can we condense all the complicated discovery work we have done into a bite-sized, easy to understand solution overview that will allow us to get the feedback we need to get to the best possible solution for our product and our users? At this point, I’m afraid I don’t yet have the answer, but I’ll keep trying different things until I find one that works…

Any suggestions or ideas?

Transfer complete.

I’ve been pondering for a while now on what will be the most successful method to transfer our findings from our discovery sprints to my fellow product owners… I work on a pretty big project and we have a team of several POs who each work with their own scrum team. Since one scrum team cannot handle the work required for the functionality me and my team have been researching, we need to be ready to hand most of it off to other teams. We already handed over a couple of smaller pieces of functionality to be developed, with satisfactory results, however the remainder of the items is significantly more complex and therefore I expect it will be much harder to successfully transfer all the knowledge over to our colleagues.

One thing I found challenging is how to educate the team on the priority of the various epics and stories at a glance. We do prepare and provide them with the key user stories we believe are going to drive success, however it can be overwhelming to go through a big excel sheet of data, trying to figure out which items are the most important, which are related to or dependent on one another and what would be the most logical and effective sequence to work on them – not to mention the fact that often these epics and stories need to be slotted in next to other items on the team’s backlog slated for the same release…

I hadn’t yet come up with the ideal solution, so I went snooping around the web and came across this article on the ScrumAlliance website by Andrea Gigante about using story mapping to manage the product roadmap and release backlog. Being a very visual person myself, this approach immediately struck a cord with me, as it represents the product backlog not as a long list of items, but a clear visual grid, already prioritized by both feature and story.

I was hoping to find a model that provides a quick yet comprehensive understanding of the functionality we are targeting, which stories are related to which epic and their respective priorities, but without going into too much detail, so as not to interfere with the teams’ individual estimation and sprint planning processes. This application of story mapping may provide me with just that: my team can provide the basic structure of the story map by feature and related stories, whereas each scrum team can then go their separate ways and slice and dice the pieces as it fits in their sprint schedule, based on their estimations and velocity expectations.

I think this easy to grasp concept will be a great basis for handing over my team’s discovery work to our other scrum teams and POs, which we need to be ready for in a few weeks, so thank you Adrea for sharing!

I will report back when the transfer is complete.