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?