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