The title for this post sounds seemingly impossible. But in our experience, everything can be done if the development team and project manager have deep expertise and, along with the product owner, carefully listen to each other and keep themselves open to cooperation.
Here I aim to show how experience, respect for discipline, and an insistence on following good project management practices can go a long way to help to develop successful software projects in spite of many challenges. We’ll show how to cope with a project that has no clear scope, tight deadlines and a limited budget.
As a project manager at an IT company working with many non-technical startup founders, our clients, I often get to resolve a variety of interesting issues that relate to technology and communication. To be clear, we will not discuss how to start a software development project or which steps you should take to kick it off. You can read all about that in the Project Management Body of Knowledge book. Instead, I’ll share my experience of getting a complex fintech project off to the right kind of start, on a strict deadline and with a few challenges already evident. Let’s begin.
Deadline and Unclear Scope vs. Agile: Project Challenges We Faced
When starting a new project, its manager, obviously, needs to carefully map all the steps, from project planning to its release, and even further. For that purpose, it’s a must to have as clear as possible image of the end product in one’s head. It is necessary to know the business expectations for and values of the end product and plan the steps that have to be fulfilled to achieve them. In the meantime, at the start of the software development project you have to be aware of the legal requirements, your end-product must meet – for instance, in terms of security, personal data storage, server requirements, etc. as these must all be taken into account while developing the product.
That’s what the project should ideally have at the beginning. But there is no growth without struggle. Here are some of the challenges we faced in our project.
Challenge 1. A complex project with a lot of unknowns
Project complexity is a subjective and relative notion. What it means here is the sum of the following peculiarities of the project. Firstly, when we met with one of the startup founders and the product owners, we found out that they had an ambitious idea to create a product with no equivalent in the region. It had to be the first of its kind. But after having had a closer look at their vision of the product, it appeared there were a lot of undefined elements. The initial requirements for the project included only desired features for the end product, a budget, the deadline and the technological stack. But they could barely define the product’s business value. In addition, the scope of the Minimal Viable Product (MVP) features was not fully clear. As a result, the development team could not estimate how much time it would take to release the MVP and the software development was impossible to make.
Read more: Your Guide to MVP, MMP, MLP, MDP and MAP Startup Stages
The next unknown was that the state in which the product had been planned to operate was terra incognita to us. To be clear, we’ve worked in fintech a lot. We knew how to make fintech products, but we’d never worked in the client’s state. We didn’t know either peculiarities of its legal regulations, or the local users’ culture and morals. Given that, it wasn’t clear what integrations we would have to make to the product to comply with the potential local requirements regarding the product’s security monitoring, regulation of financial operations, and personal data storage.
All these, accompanied with the challenges described below, made this project seem almost impossible at first glance.
Challenge 2. An ambitious and fixed deadline
Our clients had a fixed deadline set by investors. The problem was that when they came to us, that deadline was getting closer. They had spent a lot of time choosing the technological stack and discussing technical solutions with outside consultants. But the closer the deadline got, the more inappropriate the discussed solution became. And they got stuck between their strict deadline and solutions that could not be completed in those time frames. How much time did they have? They had 5 months to develop the MVP. Given that they didn’t even know what the MVP should look like, it was quite an ambitious goal.
Challenge 3. Burnt-out business side team
The last, but not the least, a challenge worth mentioning is the state of the business side team. When we met them, they had been already exhausted by the search for a development team that would commit to the project. After spending almost a year on choosing the right technical solution with the help of outside consultants, they found themselves with a strictly limited budget and the deadline reaching its end. And what’s more, the predefined technical stack was inappropriate for such a strict deadline.
We discussed the MVP with the client, estimated how much time we would need to develop it. It appeared that implementing the stack they wanted would take 2.5 weeks longer than the project timeframe allowed. It became clear that the customer’s technology stack was in complete conflict with their deadline.
As a result of those challenges, the clients were completely burnt out and tired of waiting for the development stage to start. They asked us to start the development with the predefined tech solutions, believing that it would be faster. We had to hold a lot of meetings not only to discuss the most appropriate technical solution but also to convince them to trust our expertise.
How We Dealt With Project Challenges: Key Insights
Here I’ll show you what we did to meet the strict challenges of the project and how we managed to stick to an Agile approach in a deadline-driven development environment.
Insight #1. Discuss everything with the business side team, many times.
When you have a project with as many unknown as this one, the key to success is two-way constant communication between the business and development teams. In our case, we had a number of meetings discussing everything, starting with the product’s features, its business value, relevant technical solutions, and team composition. Every tiny detail was discussed and agreed upon. Thus, we helped the customer define the business value of the product, while they advised us on the specifics of local regulations. By discussing details in advance, you’ll save a lot of time in the future.
And the most important thing here was to agree on the technological stack with the client. As you remember, they came to us with a predefined tech stack, which, after performing rough estimates, appeared to be in complete conflict with the deadline. We spent several meetings with the client explaining the benefits of switching to Python for the development as a more effective development route.
When time-to-market is a key factor, Python is a great choice. It has a variety of libraries and ready-to-run solutions that makes development comparatively fast and easy. In addition, Python is “agile”, so using it enables you to solve tech tasks of any complexity. Given all that, Python allows you to develop an MVP faster than with other options.
Read more: Faster, Easier, Better or Why Python is the Best Programming Language for a Startup
Also, one of the key issues to discuss with the technical team is the scalability of the product. Our clients had a plan to scale up the product in the future to meet the estimated user number growth. Python would allow us to do this quickly and without too much additional work. Moreover, having experience with similar projects with many unknown unknowns, we knew that, using Python, we could solve any problem and thus guarantee on-time delivery of a high-quality product.
Insight #2. The more in-depth research, the better.
It is common practice in Agile for the development team to spend 4 to 6 hours in each sprint in planning meetings and discussing what is going to be done in the next sprint. In the meantime, during the active sprint, team members may take on so-called “investigation tasks.” This means that they may take a task from the backlog that is planned for the next sprint, and research it. They can ask the client for details if needed, analyze the task, and look for an optimal solution. As a result, when the time comes to develop that task, the team already has an idea of how to solve it, which saves a lot of time.
In a deadline-driven development situation like the one we found ourselves in, such a practice was a life-saver. Sometimes we spent 2-3 days planning in the sprint, which would have been unconventional for a common project. But it helped us avoid mistakes that happen when you do a job in a rush. Instead, we knew exactly what we were about to do, how much time we needed for it, and what resources we required.
Insight #3. Form the right team.
Usually, the development team consists of engineers with different expertise, with the mid-level professionals at its core and the seniors at the top. But we had a strict deadline and too many unknowns with regards to the MVP scope. Because of that, we simply didn’t know how many developers we would need to make this project, as we didn’t know which technical tasks we would have to solve. In the meantime, the product owner had already planned a certain team size and had a specific budget lined up for it. In this situation, project estimates were not estimated in the usual way due to the high level of uncertainty we faced.
Because of the not-fully-predictable nature of the industry and based on past project data, we added 30% to the calculated time estimates. In such a way, we indemnified ourselves from the possible risks that might come true during the project because of the variety of unknown unknowns both in the project and in the industry.
Our initial time estimates + 30% of “insurance” revealed that the current team composition was not enough to meet the deadline. Thus, we advised the product owner to agree with a team expansion and rotation of senior software developers towards the delivery. We agreed to form the development team with senior developers who had extensive experience and could work on an intense timeline at the MVP development stage. As a result, we finished the MVP 5 working days before the deadline and went with a standard team composition for the rest of the project to stick to the budget.
Our Slip-ups and How We Handled Them:
1. 3rd-party service integrations affected the roadmap. We didn’t know that testing integrations with 3rd-party services (the ones that support the work of the fintech product, like banks or payment systems) would take so long. It appeared that you can’t test things whenever you want. The service books you a “testing window” once per month, and you can perform testing only during that time. We hadn’t taken that into account while planning the roadmap. So we developed a solution that allowed us to test the integration internally in our “sandbox” and use the “real” testing as the final verification.
2. 3rd-party service impacted data architecture. When we started to design a software project, we didn’t know how much integration we would have to make to create a properly working product, or how the integrations would provide data. Partially attracting product architects at the first stages of the project helped to solve this issue, as they tried to estimate at least the approximate number of such integrations.
3. No common communication tools for the business and tech teams. While the development team used Jira for project tracking and Slack for communication, the clients kept working with Excel for tracking and SMS for communication. We showed the business side the benefits of using Slack and Jira and taught them how to do it effectively.
An Agile Approach in a Deadline-driven Development
Agile in software development projects has proven to be a best practice. It’s flexible, versatile, can be understood by both sides in the process - business and engineers. It also pays a lot of attention to planning tasks in advance. However, Agile in a deadline-driven development can be quite a challenge. As noted above, Agile assumes flexibility; while deadlines mean, well, deadlines.
Agile vs. deadline: How to make it a win-win
Completing an ambitious project with a short deadline for its first stage required involvement from every team member. Having empirical information on projects of this type, it became clear that the key task was to minimize possible risks by fostering a very specific type of project “culture.” When speaking about risks, among other things, we mean that the product owner was not strong on the technical peculiarities of the project. They just knew what functions the product should have in the end. To achieve these, they turned to outside consultants who in the end created serious risks for the startup due to their non-optimal advice. Something had to be done to address these risks.
Approach decisions
When the stakes are high and there is no margin for error, creating an approach — almost a culture — with high respect for discipline at the core is possibly one of the best non-technical decisions you can make.
Things we did:
- Highly meticulous sprint planning — sometimes we spent up to 3 hours of planning, which allowed us to dive deep into the tasks for the next sprint, get all the team members on the same page, and get them highly involved in the sprints.
- Spike-type tasks — team members performed a deep investigation of the tasks assigned to them for the next sprint with code drafts of possible integration of their solution as the definition of done. This saved significant time during the active sprint when the team members just didn’t have enough time to figure out all the peculiarities of the task.
- Proper communication with the product owner — we constantly consulted with the product owner, because they had a clear understanding of the stakeholders and could remind us what the product should be like.
- Respectful communication between QA specialists and developers, with QA team members preparing test documentation in advance and developers having access to it by the time they started writing the code.
As a result of our approach, we didn’t have a single failed sprint. We achieved accuracy between the estimated and actual project time and cost, nurtured good team spirit, and delivered the product one week ahead of schedule.
Five Deadline-Driven Development Takeaways
If you’re customer oriented, experienced in the field, and quality-focused, your product can still succeed, even when the cost of an error can be catastrophic and you’re working with Agile on a strict deadline.
To wrap things up, here are five tips that even senior project managers can use for complex product development:
1. Have only the right people in the room
If you have limited time and budget, you can’t spend these scarce resources on people who can’t bring anything valuable to the project. This means that at every stage of the project you should evaluate both its needs and your resources. If you need fast delivery, attract senior developers who will do it in time, instead of using more junior employees who’ll take more time for development, miss the deadline and, as a result, ruin the whole project.
2. Really listen to all of the Product Owner’s ideas
Don’t interrupt, but do write things down and ask clarifying questions to get to the bottom of what business problem they are trying to solve with their product. It will help you understand what product you’re developing.
3. Explain tech choices in business language
Your expertise is valuable, but business people don’t speak “tech,” so learn to communicate your ideas in terms of timelines, numbers, and advantages to the business, both now and over the long term.
4. Take spikes, or investigation tasks
Explain to the product owner that assigning team members tasks for investigation is not a waste of productive time in the active sprint, but an investment that accelerates further sprints.
Read more: How to Successfully Set Tasks For a Development Team
5. Document all tasks as fully as you can
Document everything. First of all, developers track their work in Jira – so if you want something done, make sure you create a task for it. That way, it will never be lost. Also, take time to describe what you want in detail using print screens and examples. If you save a few minutes when writing a task, you’re taking that much more time from each person working on the task, who in the end will only waste their and your time clarifying what you meant to say in the first place.
And finally, just don’t be afraid of tight deadlines. We hope that our case will inspire you to take on seemingly impossible challenges – and that our takeaways will help you to cope with them.
This case study on how to combine deadline-driven development with Agile — and Deliver is written by Nataliia Peterheria - PM at Django Stars. Read the original version on Django Stars blog.
Top comments (0)