PM confession #2 – From product ideation to functioning web app

Just as in life some situations are more memorable than others, it is also true for the projects we run. This particular one had firmly embedded in my memory, because not only we have managed to achieve the desired goals and deliver the value that the Client was looking for, but also it has allowed us to acquire completely new skills and develop the ones we had already had. And what’s most important – to calculate the carbon footprint my Honda produces when commuting to work? What was the project about and why am I recalling it? Keep reading to find out.

Chapter 1 – Background

As usual, I received the basic information about the project before the deal was sealed so I could generally estimate how many people and how much time we would need to complete it. Our Client’s scope of work includes analysing the CO2 production and suggesting changes that would allow to reduce the level of carbon dioxide emissions and consequently the costs associated with the process, making the company more environmentally friendly. The work was based entirely on the knowledge of their consultants and a very extensive spreadsheet in which all the calculations had been made. However, with the growth of both the number and the size of organizations that required our Client’s support, the limitations of the spreadsheet made it very difficult to scale the activities further. Thus, forced the tool to be improved and transferred to a web application. Why am I mentioning this? Because our Client had limited experience with software development and entrusted us to be responsible for the whole process from the ideation and design of a web app to delivering the final product. It was a challenge, of course, but also an opportunity to develop skills related to the overall project management. In many other projects, our people are expanding the Client’s internal teams and as the PM on the Software Mind side, I only support the internal PM. Here practically all the responsibility was on me and despite the related challenges, such scenario is much more interesting.

However, let’s get back on track – scrolling through the Client’s spreadsheet during the preparations showed me that I wouldn’t be able to grasp it myself. That’s why the Client’s Analyst – who later worked very closely with our team, hosted a short presentation to explain how their analysis work and what the business context looked like. Having a broader view on the subject, I was sure that in order to prepare well for the web app creation we need to dive much deeper into their service. The best way to achieve complete understanding seemed to host workshops and go through all of its intricacies. So, we invited the Client representatives to our Headquarters and that’s where the real fun has begun.

Read also: What is a Single Page Application?

Chapter 2 Ideation

Preparation

Before we move on to the workshops themselves and the ideation process, I have to mention that it was all possible thanks to the team I had – 3 young but very talented and creative guys, who were ready to go the extra mile and were not afraid to take up challenges. That’s why when during an internal discussion about how to conduct the workshops, one of us threw the name “Event Storming” everyone picked up the idea and started to prepare. Our previous experience with this method can be described in the words “heard something, know something”, so prior to our Client’s arrival we spent a lot of time learning it and preparing to conduct workshops in this methodology. I remember that just before the workshops started, we found on one of the boards in our office, the remains of an internal Event Storming session that once took place. So even at the last moment we used it for the final discussion about how exactly should it look like.

Event Storming session

The room was booked, post-its, markers, and, of course, cookies, were waiting for us on the table – we were ready. After the first handshakes and getting to know Client’s representatives, we presented them with our plan for this meeting and the process of getting to the preparation of stories and writing a plan for the app development. Firstly, we proposed to conduct an analysis of the process logic “from the end”. Illustrating it with an example – the user sees the graph, what has to happen before? The graph is resulting from the calculations made inside the system – the user should enter the data – so what has to happen to enter the data – the user should prepare it. In this manner, we came from end to end, through the whole flow – to even the simplest things like “home page is displayed”. The Client liked the idea very much and both sides were very active. Then we started coming up with ideas of what the app should include, which was later confronted with the possibilities provided by the spreadsheet. At the beginning, we considered all the ideas to be good, everything wrote on the post-its was sticked on the board. In the next step we started to unify the style (e.g. we kept all the actions in the past tense – “user logged in” instead of “logging in”) to have a more friendly flow and start to make arrows that let us define the paths in the application. Next, we defined areas, and this allowed us to go smoothly to the spreadsheet description. The first presentation of this tool included only me, so taking advantage of the fact that our whole team and the mentioned Client Analyst were on site, he showed it once again. But this time going into deeper details, presenting how it works and how its mechanisms correspond to the stories we prepared during the storming. Importantly, we identified the biggest limitations of Excel and assigned them to the corresponding post-its.

Knowing what must be counted in the application and why the user cares about it, we had to understand how exactly it happens. Although, at this stage we were focused on the more general aspects and knew that the time to get into the most complex calculation would come in the future, it was crucial to get more understanding. We also started to prepare development tasks. Already before the meeting, we had prepared the whole dev pipeline (databases, flow, servers, and also Jira environment), so we started to convert the stories from the post-its into the Jira. In about 2 days we created enough stories for at least 2 months of work. I must also mention that due to budget limitations we had been imposed with, we chose what must be done in Phase 1. We wanted to create the app which will be useful for our Client’s clients and what remained would be developed later. We photographed all the post-its and the effects of the Event Storming so, at any time, we are ready to go further.

Design

At this stage, it is also worth to mention the participation of our UX specialists. As I wrote, we were responsible for the whole thing so creating the design was a part of our job. Our designers used the meeting in Cracow to present and pass on to the Client the survey, by which they collected preferences concerning the appearance of the application. I remember that our Client liked this idea very much, was very committed to filling out the questionnaire and even send it to other employees to have a bigger test sample. Then our designers, based on their experience and the preferences specified in the survey, prepared visual projects. Often in B2B applications, less attention is paid to the appearance of the product – in this case, I think that we managed to find the golden mean without spending too many resources, but still making this application really “nice” and accessible. Maybe it is not as important as in B2C apps, but anyway, we buy with our eyes. So, besides the pure business value that the product has to provide, if it looks appealing, it is easier to sell to the customers or even investors. Recently our Client’s representative has even mentioned that in his opinion they have the prettiest charts on the market. So, we managed to achieve the assumed goal 😀

Chapter 3 Development

Kickstarting the work and introducing Agile

As I wrote, our Client did not have much experience with software development. Their CEO was a developer 20 years ago, but he changed the career path during times of Waterfall methodology, while the Analyst responsible for the project until this very moment had no experience with the software creation. They had one person in the company who knew Agile and the realities of software development. However, because she was not our main contact person, we introduced them to the processes from scratch. We presented them with our Agile vision and assumed that we would start with a 3-week long sprint to do more things and get the motor running. Then we would move on to permanent 2-week long sprints, with 3 refinements weekly and after each sprint, we would control the progress of the work and show the effects during the demo. After some time, however, we gave up on some Scrum elements – e.g. retrospectives because it didn’t bring the intended results. Instead of identifying the problems and solving them, it boiled down to the proverbial patting on the back. Of course, we run these internally, but the Client’s participation in this meeting was just a budget burnout that we didn’t want and couldn’t afford. However, the Agile approach was very well received, the Client was very pleased with the short feedback loop and constant control over what was going on. Even their CEO mentioned that this approach seems much better then methodologies used when he was programming himself.

From Carbon Footprint analyst to Product Owner

Since our goal was to provide the business value and the environment of carbon footprint analysing was something new for all of us, we decide to make the Client Analyst responsible for the project the Product Owner. As I stated he had no experience with software development so at first, we had to introduce the role to him, and the tasks related. That wasn’t necessary during the first weeks of development since we had to start from the scratch and build basic components. However, after some time we reached the stage where it was crucial to decide what should be done at a given moment. Whether it was for example the Admin Panel so that its users could learn how to use it or providing the possibility to enter existing clients and their data. Since he knew all the ins and out of the business, he was a perfect man for the job. Additionally, he was always ready to dissolve any doubts we had – as I mentioned, the spreadsheet was very complex and due to the fact that none of us had been dealing with carbon emissions before, we sometimes came up with additional questions to clarify something. We maintained close contact during the whole cooperation, so it was never a problem and the relationship built during meetings (both formal and informal ones) will certainly stay with us for many years to come.

New sprint = new Scrum Master

In the beginning, I wrote that during this project I managed to learn a lot, but it was also a chance to grow for our developers. Since the team was small and the contact with the Client was flawless, I decided that we will change the ‘Scrum Master’ who leads the whole sprint and is responsible for the demo after each sprint. This allowed all team members to gather new experiences and learn new things regarding Client-team communication. It worked very well and during the post-mortem analysis we did once the project was done everyone was very satisfied with this opportunity and happy to use this experience in the future.

Second workshops and the hunt for a pub

After a few months, when the first part of the development was completed the time has come to create carbon footprint calculations inside the app. To make it possible we organized one more workshop in our Cracow office to precisely analyse this part of our Client’s work and prepare for transforming it into the code. This time our meeting lasted 3 days, during which we went step by step through all the calculations necessary to prepare the analysis and developed mock-ups of “screens” that showed how it should look like in the application. This meeting compared to the first one was much more technical than conceptual and allowed us to further develop the product. But not everything went so seamless. I mentioned the great relationship we built with the Client and during this workshop, we had the opportunity to take advantage of their favour and, in hindsight, strengthen it even further. As we did not reserve a table in any of the Cracow pubs for the evening after the second day of the workshop, we went into town looking for a place where we could sit down and talk over the pint. However, our whole team comes from Rzeszow, so we didn’t know where is a/good food, b/noise-level allowing to talk freely and c/free table. That’s why we spent more than an hour looking for a suitable place in the city centre. Of course, as good Agile practitioners we learned the lesson and in the future, we will always book a table beforehand with the support of someone local. However, now when we talk with our Client and mention this hunt there are lots of laughter and zero negative emotions ?.

Chapter 4 – Phase 1. finish

After the second workshop, the project was moving forward and we managed to deliver the release candidate for testing after 6 months and the finished product with all the features for phase 1 after 8 months. Meetings at our office, as well as many hours of online conversations, allowed us to fully understand the product and optimize many of its features so that they not only copy the excel but also improve various functionalities. There were no half-measures in the project, it has 100% automated test coverage, and everything is done following best practices. After the first phase, our team has been diminished to a single developer who is still expanding the product and maintains very close contact with the Analyst or as we can call him now – the Product Owner. It was a cool, intensive 8 months, during which we had a lot of challenges, but we were able to learn a lot – from initial Event Storming, through calculating the carbon footprint, as well as further improvement of our remote cooperation skills. Despite the fact that we ramped-down for a while, we still have a lot of “post-its” left from Event Storming, so both we and the Client assume that this is only a temporary slowdown and there is still a long way to go. After all, at this moment the app already excels the spreadsheet possibilities, but it has a lot of development potential. In the meantime, we will gladly take up new challenges to use and develop the knowledge gained here or learn something new again. But this time we will book a place for the less official part of the meeting 😀

Krystian Szczepanowski – Project Manager/Software Architect who is a part of Software Mind since 2012. His innate ambition, combined with a strong passion for the latest and most innovative technologies make sure that he never runs out of energy and ideas to convince others to his vision. When he is still turned down, he blows off steam by hopping on his motorcycle.