A case study of our first product launch with Agile methodology
Why we succeeded with Agile development and what we should have done better. From concept to launch in 6 sprints.
After running 6 sprints to release an e-commerce insurance product, I made a case study of our journey with Agile methodology and presented the key success factors to the Executive Committee, as well our mistakes.
In this article, I describe how I switched from Project Leader to Product Owner, and detail the various challenges, from defining a Minimum Viable Product to setting conditions to be Agile in an organization where this methodology was new and mostly unknown.
(1) The key success factors in Agile development
1. spread the vision 💌
Everybody in the company knows what they do. Most of them also know how they do their tasks well. But how many know why they do things ? How well do they really know the purpose of their individual job functions, and how they all fit together.
- I applied what Simon Sinek describes in his Ted Talk ‘Start with Why’ to the whole ecosystem.
- During the whole conception and development phase, we managed to keep a single version of truth: our sponsors, stakeholders, and scrum team were aware, at least, of our vision and purpose, all together summed up in one sentence.
In a few words, the Product Owner is converted in a storyteller. I emphasized the link between the business vision to development. I dedicated plenty of time explaining why we were prioritizing this feature versus another. I mailed the scrum team the minutes of our steering committee meetings and shared key insights of sales reports with them once our product was live.
You could ask any person, any time, and they would always have the same story about our product. Everyone being aligned, we would be almost conflict due to misalignment.
2. Focus 🔎
We took our project as a challenge, and left ourselves no option but success.
Odds were against us: Agile methodology wasn’t widespread in the company, and even to our team it was new. So, we protected ourselves from the big-organization disease: dispersion.
- We were Stakhanovists in the respect of the Agile methodology. The scrum team consisted of a developer located in India. He was taking part in our dailies, sprint planning, and retrospectives by call conference. Business owners were invited to attend the dailies but they could not intervene. The Product Owner was only one empowered to prioritize the backlog.
- We stuck to our purpose and did not let our team be distracted by exogenous events. Often, the team was requested to work on bugs, UX, or other projects by various stakeholders. There was not a problem with those people asking, but we were had to make a special point of having backlog prioritization go through the proper channels, starting with the product owner.
3. Trust, and real teamwork 💙
Our Scrum team was made of a Scrum master, two developers and myself. We knew it would save us a lot of time to trust teammates and embrace problems collectively.
- Loosening control is not an easy thing, but we were good at trusting those who were in the know. As developers trusted my decisions, I trusted them in theirs. I would always explain and justify a decision of mine, but when we were in a hurry to change some feature development in the middle of a sprint and there were little room for discussion, they would trust me and do it with trust.
- We had a strong sense of collectivity: whenever a problem was raised, the whole team was committed to jump on it all together and solve it. For instance, we had accumulated (from the past 2 years) a technical debt that made our code fragile. We decided to block some time so that the whole team could work on it four days per sprint till the issue was solved : the scrum master would look for special topic experts, I would accommodate the backlog, and the two developers would focus on the code cleaning.
4. Continuous improvement ↪️
We were all new at Agile methodology, except our Scrum master. We were doing our best to improve the way we applied the methodology by upskilling ourselves, improve our processes and delivery capacity.
- We took every opportunity to upskill ourselves. The two developers followed a ‘fast-it’ training during five mornings, I followed a product owner training. As a team, we also got trained from the whole Agile methodology through the Lego City game and the Artist game.
- 1 item per sprint had to be prioritized to improve our process, technology, website performance. Once, we decided to improve the website performance: we compressed images, put the CSS at the top and Javascript at the end of the HTML page to enable progressive rendering
- We measured our tasks to increase our ability of estimation and prioritization. We were counting the time spent on new feature development, meetings, bug solving, emergencies, trainings.
(2) What we should have done better
1. A more down to earth MVP 🌍
At the end of the design phase (which I describe here), when the scrum team just had been created, we were proud of having designed our MVP. But it was far too conceptual to translate it in technical terms.
Out IT Partners were used to receiving specifications, but we had none, and business owners (who knew roughly how the system was working) would jump too fast at a proposed solution. It took us few weeks to set some rules and give the proper specs to IT to work on the MVP:
- From the business side, we should have restrained the rules earlier : (i) We would not create a new insurance coverage, as the internal and external process would have taken us minimum 3 months (ii) Itshould be calculated with the same tarification than the other e-commerce products
- From the IT side, we should have defined some rules like : (i) The product should not involve backend development. (ii) We should be able to choose whether to display it or not. (iii) It should be recognizable by any mean in the reporting (even if it would take some manual tasks)
👉 If you are not ashamed of your product, then it is not an MVP.
2. Test versus Talk 👀
We spent at least 3 weeks talking how we could build our MVP technically without impacting backends, get the right pricing, and able the display rules correctly.
Instead of making a hypothesis and testing things in a QA environment, we kept arguing on the theory.
👉 Confront ideas to the ground reality is the best way to know if they will work — as well as how and why they wouldn’t. We lost time at the beginning and started the sprint 0 with delay.
3. Monotasking vs multi-tasking ☝️
After a few months, the team was running very well. The company was looking for skilled product owners and I was requested on another project to take care of the redesign of an interface, and the developers were asked to dedicate a bit of their time to another project.
- I was unable to deep dive in topics and understand technical issues. I could spend less time with the team, so I cropped on the time we would explain decisions.
- The scrum team spent more time switching task and lost in productivity.
👉 Monotasking is the best way to succeed in Agile. If you still have to share your time, then one of the two product must be a priority to avoid the dilemmas in backlog prioritization.
4. Think forward
Agility is often assimilated to emergency. I see it more like a marathon than a sprint, but we were often unable to plan well our events as we were in the run always. If I would have to redo it :
- I would dedicate more time to sprint planning. Often, I ended up the week on Friday 7pm and still had to prepare for Monday’s sprint planning session, and thus couldnt get the maximum information we would require to make decisions in session.
- I would have anticipated the time and capacity needed for iteration. After 3 months live, we realized we hadn’t anticipated this question : how do we let the product live and keep testing without wasting the team’s time ? This is when the project A becomes project B and the team has to deal with 2 products at the same time.
👉 Prepare sprint planning with the team by sending them the backlog so that they can ask you their questions before the session and you can dedicate this time to realy make decisions.
Long story short
- We shared the same vision across all the stakeholders, we trusted eachothers and loved working together. We were also crazy about improving stuff.
- We struggled, at the beginning with a conceptual MVP, spent a bit too much time talking vs testing, and at the end being requested on other projects.
Probably the best team and experience I have had so far. It made me grow, think, laugh, support, lobby, do, test, make mistakes, learn, and love, so… Thank you guys !! 😍
Credits to Yemsel Bougherara & @Elsabernard for the proofreading
Building A Web Or Mobile App?
Crowdbotics is the fastest way to build, launch and scale an application.
Developer? Try out the Crowdbotics App Builder to quickly scaffold and deploy apps with a variety of popular frameworks.
Busy or non-technical? Join hundreds of happy teams building software with Crowdbotics PMs and expert developers. Scope timeline and cost with Crowdbotics Managed App Development for free.
