A long time ago in a galaxy far, far away…
As a matter of fact, not so long ago and exactly in the very galaxy, we live in, Joanna (a Jedi Knight of Product Owners 😉 and Paul approached DeSmart with an idea for a mobile app. “We want an app that could be used to report hazards, incidents and exemplary behaviours on construction sites which would give recommendations on how to improve safety on-site”
Why we don’t start with UX prototype anymore
As we did until not so long ago, we have proposed to make a prototype of the UI for both the mobile app for gathering reports and the web application for reviewing reports in order to use them to prepare recommendations. Ewa, our UX designer, spent 4 weeks with Joanna and Paul figuring out what they wanted the application to do and what it should look like.
When the prototype was ready, a team of developers (two PHP developers, one JS developer, and two iOS developers) joined in. Ewa introduced us to the outcome of the discussion about the user interface, but we noticed many gaps to fill in with an understanding of the whole process of submitting a report and reviewing reports in the web application. As a result, the prototype has started to change.
Sometimes the domain process is well known. In other cases, it has many implementations, for instance, a sale of a product. Even in such cases – going into the details will bring out the differences. Some sell only online. Some do both online and ePOS sales. Two online sale scenarios are rarely the same – different delivery options, gift wrapping options, and many more.
As we often work with startups and brand new ideas or attempts to revamp an existing idea – what we have to find out, first of all, is how those things are supposed to work. In order to figure this out, we need to understand what the goal is.
So we have scheduled a call with Joanna with an agenda focused on understanding the mobile app goal. Because we hate to come to meetings unprepared, we gathered all the information we had and attempted to make an educated guess of what are the goals of the project, and what are the objectives of personas identified in the project. How completely wrong we have been!
My advice for you when dealing with a similar situation – don’t guess, just ask. We have identified 3 personas – Lorenzo the Reporter, Joanna the Administrator and Paul the Client. I thought that one of the incentives for Lorenzo would be to improve the safety of his work environment, but in reality, he was simply ordered to submit the reports, and his goal was to fulfil his obligations with as little hassle as possible.
What we do start projects with now is a couple of days of workshop, where we build together Product Canvas, Personas and User Stories. Although we don’t start with UX prototypes now, we still do the prototyping process along with the workshop, sketching draft mockups on meetings, simply using pen and paper. This way we can quickly visualize what is being discussed and make better decisions. It’s also a great way to make sure that we are all on the same page. Afterwards, a proper mockup is prepared based on the outcomes of this workshop.
Be realistic and have priorities
Before the project has started, we were asked for estimation, and it was one of the most reasonable questions we were ever asked – is this project going to be done in weeks, or rather will it take months? We have answered – weeks. The next request for a more accurate prediction came when the prototype was done. Still, you have to remember that the estimation is always only a guess.
When it comes to guessing how long it will take to develop a software project, it is far from straightforward – math ain’t gonna do it. There are a lot of factors that influence the process: the choice of technology (is it well known or experimental), knowledge of what we want to build (is it a copy or are we inventing something new), the issue of people and communication, just to name a few. Our best guess at the moment was that it was going to take around 8 weeks of work or 4 two-week long sprints.
When the developers joined the team and dug deeper into the process, we have gained a lot of new knowledge that resulted in new user stories. The process of gathering this knowledge continued during the first 3 sprints. After 2 sprints, we already knew enough to tell that 4 sprints won’t do for the whole backlog, so either we extend the timeline or drop out some features.
That’s the value of agile – the uncertainty is reduced in time, as we gather information, we are able to take yesterday’s weather as the best approximation of what weather we can expect the next day. Since Joanna has prioritized the backlog according to the value she saw in each of the features, identifying must-haves and would-be-nice-to-haves, we were able to estimate what would fit in 4 sprints and what would not, and how many sprints it would require to deliver the remainder.
With this knowledge, Joanna was able to convince Paul to extend the development by 2 more sprints, but it was the maximum budget that could be afforded. Fortunately, with this budget, we were confident that all the must-haves will be delivered, and there was a pretty good chance to deliver a few of the would-be-nice-to-haves. The general rule for Joanna was – if a specific feature is part of the mobile app and necessary for the reporting process, it must be done, but if a feature is only automation of the work she would have to do manually otherwise, it can wait for the next stage of the product development.
So the lesson to be learned here is: know your budget limits and be picky on how you spend your money.
What went well? What should be changed?
When I worked on my first project at DeSmart, I was a bit sceptical about the retrospectives done together with the client as a Product Owner. I thought – shouldn’t we keep our dirt inside and deal with it on our own? Won’t it keep people from sharing issues? Yet, I was surprised. Honesty brings more trust, more transparency. Sharing our issues encouraged the client to share his issues, and we are able to avoid a common hide-and-seek game, where every party acts as if they were superhuman, not capable of making a mistake.
Joanna is a great Product Owner, not only because she understands that getting things done requires effort, so she was able to prioritize and manage the scope. She also did a great job during the retrospectives – giving feedback about how happy she was with the results, and whether she was concerned with the issues brought to the table. She has followed the actions planned for the retrospectives.
When we found out that the team is getting lost in the information shared, as the main channel for exchange was email, and a list of recipients was limited to a few most involved people, we have decided to move the communication to the common Slack channel – Joanna was using it right after the call. This way information was out there for everybody to read, but we could tag the message with the recipient, so he got a notification. When we said that we miss Paul on the meetings, she made sure he joined the next meetings we had, and he had brought valuable stakeholders insights to the project that we would have missed otherwise.
Never skip a retrospective, even if you think everything is going fine, it is still great to hear what are the good things that are valued most by the PO and by the team. It’s your best opportunity to learn.
So, now you can see some screenshots from the mobile app which we have built together:
Did I mention already that once again the whole project was done communicating online? Unfortunately, Paul and Joanna didn’t manage to come to our office for the backlog refinement workshops, as it was initially planned, so Skype calls had to do.
Remote regardless of timezones
We’ve organized work in 2-week long sprints. Each sprint was finished with a review, planning and retrospective – these calls took around 2 hours and were done on Skype. Also, backlog refinement was done through Skype with screen sharing. Friendly advice – if you are going to use Skype calls, make sure you have a good camera – it’s great when you can see your interlocutor and he smiles or frowns. Don’t underestimate the value of body language in communication.
For daily information exchange, we used Slack, a great tool if you want to leave somebody a question or a file for review. Thanks to mentions, a referred person gets email notifications, even if she is offline.
When it comes to project management, we gave Taiga.io a shot. In the end, we are not convinced and will switch back to Pivotal Tracker for our next project. Mostly for the icebox, clear current and backlog columns, as well as a quick view of stories when you scroll over one on the list.
On top of that – we managed to successfully deliver the project on time, regardless of the challenge of 6 hours time zones difference. When we were starting our calls at 2:30 pm, it was 8:30 am in New York – fortunately not too early for Joanna to be there, always ready to share her observations during review and retrospective or to discuss details of the product features.
Key takeaways from this project
This project was a great experience, and large credit for that goes to the Product Owner. This role is so important in the project, we can’t talk enough about it. Knowing what you want to build (i.e. from workshops with domain experts) and which features are key, will make difficult decisions easier, when it comes to budget and scope adjustments.
In the case, startups of you are discovering your product in the process of making it, so it’s not an area that allows for precise schedule planning. You walk forward with some degree of uncertainty. The earlier you will tackle this uncertainty, the better your predictions will be, but you must always be ready to adapt, be agile and lean.
Here is proof of great cooperation:
