Manage expectations, not results

Due to the support we received from another experienced product owner, Gosia Maksimczyk, the initial scope of the MVP was well organized. The client knew exactly what we could deliver in around 4 weeks and agreed on the risk. They were aware we weren’t going to build a space rocket in that time and would need to cut corners in many areas.

Most importantly, though, they had the trust and confidence we would make the best MVP possible under the time and scope constraints. While it required our client to give us the benefit of the doubt, we made every possible effort to ensure that his faith in us was well-placed:

                     
• We prioritized features ruthlessly from the start. The purpose of this was that once we ran out of time, we would have at least delivered the key functions.
                     
• We made a point of adjusting our small roadmap after each sprint. In turn, the map showed us the next achievable steps.
                     
• We followed the principles of iterative planning closely. Thanks to that, our client was kept in the loop every step of the way, his expectations adjusted sprint-to-sprint.
                   

Our efforts were not in vain, and the client was extremely satisfied with our work. However, it wouldn’t have been possible if he hadn’t trusted us in the first place. Some clients are particularly open-minded, and working with them is always a blessing.

Know your stuff

Undertakings like this only work if the team of professionals working on it is in sync. Even though each individual is a specialist in their own right, it’s good to have the option to fall back on the others and count on them to help you in need.

All of us had what it took to meet the expectations of our client, but the process was always very much a team effort. That’s what knowing your stuff truly means: being prepared yourself, while also having others prepare you whenever necessary.

Here’s what we did in line with that philosophy:

                     
• Product discovery workshops
                   

When we entered the earliest stages of the project, the only thing we knew for certain was that we needed to make an MVP in 4 development weeks. What we had a much fuzzier idea about was the exact nature of the project.

With that in mind, our whole team participated in intensive product discovery workshops before entering the development phase. The workshops lasted 2 days.

                     
• Product design
                   

The product design phase, which took about a week, was the next crucial part. Thanks to Adam Srebniak—a devoted UX specialist and dear colleague of ours—we got a deeper understanding of what we were building.

To our advantage, we had a chance to engage nearly the whole team before we got to writing the code. This helped us a great deal, since we became familiar not just with the output idea, but also the reasoning behind it.

When in doubt, we could always go back to the mockups or the product tagline in order to get back on track and regain our focus.

                     
• Experience
                   

BIC, SWIFT, IBAN, BTC, FX—all of these fintech acronyms and the ideas behind them can make your head spin. They can also form a huge obstacle on your path to meeting the deadline.

Fortunately, we had had prior experience with finance and cryptocurrencies before working on this MVP. With our degree of preparation, it was only a matter of several sprint refinements—working as knowledge sharing sessions—to get everybody on the same page.

                     
• Execution
                   

You know the quote, “An idea is nothing without execution”? It’s extremely relevant when it comes to building an MVP.

Planning is one thing, but implementation is something else entirely. Our team managed to overcome the many challenges of execution thanks to our expertise in both frontend and backend, as well as strong support from our tech-savvy QA.

Everyone knew how to get the most of the technology we used, how to build things fast, and most importantly, how to recognize when something was just good enough.

Set the stage in advance

When you have only 4 weeks to build an MVP, and a completely new team to do it, setting the stage in advance to minimize risk is a must.

You simply can’t afford 2-week-long sprints. If one of them fails, you’re left with just one more shot to inspect and adapt.

That is why during the planning phase, we had settled on 1-week-long sprints. The choice allowed us to validate, learn, and adjust—fast.

Working in Scrum in 1-week-long sprints, frequent meetings are your bread and butter. You need to make room for those in everybody’s busy calendars and start coordinating the date and time of each as soon as possible. It’s also good practice to book the rooms for the meetings in advance, so that you don’t have to worry about it at the last minute.

You can also set up some rudimentary tooling for the project in advance. Jira, GitHub, Jenkins—you name it. Doing this isn’t very time-consuming, and if your project starts right this instance, you’ll be grateful to have a place to store your stories or stash, build, and deploy your code. Third-party tools like email, AWS, or API rate providers also fall under this step. Note that SaaS tools offer free tiers for startups, which you can upgrade to paid plans later on.

This depends on the company you work for, though. Sometimes the teams have to handle the tooling themselves during the first sprint. I was actually surprised—very pleasantly, I might add—to learn that at STX Next, all it took was a couple of simple requests to the administration department. The entire tooling was right there waiting for us the next morning. Mind you, it may take significantly longer at other companies.

Speaking from (this) experience, I can’t stress it enough: the better you prepare beforehand, the easier it’ll be to adapt to the changing circumstances—which happens pretty much always—and keep moving forward with the project.

We cooperated in 2 different time zones. The execution stage constantly evolved. Meetings got pushed and moved. There was a lot to juggle. Seriously, so many moving parts. We wouldn’t have made it if we hadn’t been as prepared as we were.

Implement the core values of Scrum

Okay, let’s say you’ve planned and designed your product. The tools are all set up, the stories written and estimated—the only thing left to do is, well, actually putting the work in.

For this MVP, we relied on Scrum and Jira. The Jira board was the blueprint for what we needed to build, while the Scrum guide served as the manual for how to build it.

The core values we implemented into our development process were:

                     
• Commitment
                   

Every member of the team was fully committed to meeting the sprint goals, even if it meant working overtime, be it an hour or an all-nighter (an occasional one, at most!). The quickest way to deliver on the promises we had made was to prioritize completing the tasks we had already opened. That way, we deployed a great deal of the stories, instead of starting them.

                     
• Focus
                   

Focus is an absolute must in short sprints. Our whole team concentrated on specific sprint goals and tasks that were essential at any given point. In order to execute with efficiency, you can’t allow yourself to lose focus, not even for one moment.

                     
• Respect
                   

Respect needs to go up-and-down, as well as side-to-side, so to speak.

We respected our client, and got respect from them in return. We spent their money chiefly on the features with the highest business value, instead of possible redundancies. We were also realistic about the expectations for each sprint, and included only the truly finished features in the demo for the client. Some crashes were unavoidable during the demo, but they happened sporadically thanks to the unwavering support we had from the QA.

In addition to respecting our client, we also respected each other. We all had our strengths and weaknesses, and being understanding and reasonable about both was the only way to ensure smooth cooperation on every end.

                     
• Openness
                   

An invaluable quality in any teamwork environment. We had all worked on getting better at it from day one with the team, and each and every one of us benefited from doing so.

It’s vital to create an atmosphere in the workspace where all team members communicate their blockers, seek help, and exchange opinions. Everyone should be given the same right and opportunities to be heard.

Accomplish that, and the individual members will truly become a team. The decisions reached will be supported and executed, even if they are reached through compromise.

                     
• Courage
                   

Very frequently, you can only reach your planned sprint goals if you’re courageous. We allowed ourselves to focus more on coming up with new ideas to get the job done at all cost, rather than make an effort to meet every acceptance criterion down to the last detail.

It was courage that helped us create action points for improvements during retro meetings and implement them in the next sprint.

It took courage to give an extremely time-sensitive assignment to a bunch of guys who had just been hired.

There was courage in every single commit we merged in the source code. See for yourself!

Adjust and repeat

The moment we began coding, we had a precise idea of what our goal was. Our ambition was through the roof and it seemed like there was no commitment too great for us to take on. We were confident we would overcome every challenge in our way and nothing could stop us from meeting our deadline.

Which is why it’s no surprise that our first sprint report looked like this:

Off to a good start, am I right? We took on too much, too soon, and jumped right into the sprint without estimating the stories. Because of that, we were only able to finish some of the stories, having finally estimated them during the first meeting. How many stories did we finish, you may ask? The answer is 3. We finished 3 stories.

Thankfully, we learned more and more sprint by sprint, taking retrospective action items and bringing them to life. 4 iterations in, our sprint burndown looked incomparably better:

And therein lies the beauty and simplicity of Scrum: building things with transparency, inspecting them after every sprint, and adapting your process whenever possible.

I’d love to tell you it’s a one-size-fits-all solution and things always go your way. Sadly, I’ll be the first to admit that more often than not, you need more than 4 iterations to reach your goal. Could be just a couple more, but, you know, still more.

(Also, I know I forgot to close the sprint. Sorry!)

What’s next?

The MVP is currently in the product idea validation phase, looking for further development directions.

What does it mean for you?

It means our dream team of developers has a bit of spare time on their hands. So if you happen to be in need of some results-driven, problem-solving, software-engineering magic—let us know if we can help!

In the meantime, there’s no rest for the wicked. For a while now, we have toyed with the idea of designing and building an MVP for a commercial product in half the time it took us with this MVP. Yes, you read that right—this time around we are setting our sights on a deadline of 2 weeks.

The work is in progress at the moment. Want to know how it goes? Stay tuned for my next blog post, or better yet, subscribe to our newsletter and get notified the minute the post is up.

Thanks for reading, and see you when I see you!