How to Execute Fixed-Cost Projects Using Agile Practices?

Agile development is not a buzzword anymore, and development centers worldwide have benefited from its adoption. While the core principles remain the same for most, almost every firm I know of has retrofitted the same to match their own unique flavor.

For a product engineering firm, using Agile development practices work best with Time and Material (T&M) engagements. While there are obvious benefits to T&M engagements, not all clients buy into it and want to control their spending foremost. In this blog post, I will dive into why and how we, at SoluteLabs, work with Fixed cost engagements leveraging Agile development methodologies.

Things that we will cover in this blog

• In brief, what are the principal agile practices we follow
• From a team perspective, why is this important
• What is the overall methodology while using Agile in Fixed Cost projects
• How do clients benefit from this engagement
• Closing thoughts

Agile practices at SoluteLabs

Agile development is more of a methodology and a framework than a set of tools. We primarily use the agile scrum framework to execute our project. In my mind, an agile mindset is implemented at two major places:

1. Project Management

2. DevOps

All three play crucial roles in bringing true agility to the team, the first being project management (PM). PM is crucial to the success of any product. Here is a list of tools/methodologies we use:

Project Management Software — JIRA

We use JIRA extensively — close to all projects that we’ve delivered in the past 3 years are using JIRA. We have used Trello, Asana, Basecamp, and a few others, but they were either too simple (Trello) or sometimes not built for larger teams (Basecamp).

We use JIRA to manage sprints, releases, user stories, understand timelines through Gantt and burndown charts, integrate with Git, and more.

Scrum Ceremonies — Sprint Planning, Daily Standups, Retrospectives, Demos, and Backlog Grooming

While the list looks long, using such scrum ceremonies will reduce time spent for management significantly. Before a 2-week sprint starts, the scrum master and the product owner start with the Backlog Grooming. This is where they reprioritize user stories based on overall progress, feedback from external and internal stakeholders, client feedback, etc.

At the start of a (time-bound) 2-week sprint, we spend ~4 hours detailing out, discussing, assigning, and estimating user stories that would be developed in a particular sprint. This is our Sprint Planning session.

Throughout the week, the team gets together (often at the start of their day) for ~15 min to discuss their progress, planning for the day, and any possible dependencies/impediments. The client, preferably also attend this Daily Standup.

The agile manifesto focuses heavily on working software. At the end of every sprint, we provide our progress by way of Sprint Demos. In the worst-case scenario, if a client isn’t able to make it — we send a Loom video instead.

Post the demo; we discuss our wins and losses for the sprint. What was achieved and what could be done better in the coming sprint — inculcating a continuous learning attitude in the team. These Sprint Retrospectives are aimed not just at a personal level but also at a team level.

Documentation — Confluence/Notion/Coda/Gdoc

While there is no huge focus on documentation as a whole, some form of documentation is important. We usually focus on functional documentation, and the technical documentation is done at a code level using comments. So ideally, if someone new joins, a combination of functional doc, code comments, and peer review should be good enough for them to get started.

While the tooling here doesn’t play too big a role, use confluence has the added advantage of being able to link to user stories/epics and viz. This helps the team navigate quickly when in doubt.

Instant Messaging — Slack

While I understand the importance of deep work and the (side-)effects of real-time communication, reducing chatter on email is equally important. I personally am a big fan of async communication and usually keep all my notifications off when working (such as writing this article) — including slack, email, Whatsapp, etc.

But slack really helps in discussions, brainstorming on particular topics, and such. There are some tricks to using slack (any IM tool) effectively:

• Turn all notifications off, check when taking a break/doing shallow work
• Do not expect real-time replies
• Try involving as few members as possible
• Keep queries brief
• Be specific about what you want to discuss. Don’t use stuff like — thoughts?

Here’s a blog that I like —

How to use Slack effectively: 25 settings and features to save your focus

Tired of Slack killing your focus, attention, and productivity? Learn how to use Slack effectively and set it up for focused work.

https://blog.rescuetime.com/slack-focus-guide/

Next up is DevOps. Without the right DevOps infrastructure, it becomes difficult to bring features to the client efficiently. Today’s development teams are expected to deliver higher quality output in lower times. We thus aim to improve developer productivity by automating everything that can be.

At SoluteLabs, we bring focus to two things under DevOps:

Continuous Integration (CI)

When teams grow, they make several commits to the git repository in a day. These commits are checked for code smells (through linters — we use SonarQube) and for functional issues by way of executing automated test cases. Through TDD (Test Driven Development), teams are encouraged to write tests first and code later. This helps the team to find issues with the software proactively.

Continuous Deployment (CD)

After the code is checked for consistency and quality, the code is then deployed onto the required infrastructure through scripts. This can happen with Mobile, Web (frontend), as well as backend code saving precious hours of development and deployment — making me almost cringe at how I was spending tons of time as a developer a decade back.

In the end, DevOps practices help reduce risk, increase developer efficiency, reduce custom software development costs, and increase accountability.

Why is this important? (From a team perspective)

The team at SoluteLabs knows if whatever project that they are working on is a fixed cost one or a time & material one but they don’t change their style of working drastically.

This is important because we don’t want our teammates to change their working methodology from time to time. It takes time to settle into a particular way of working and disrupting it makes it worse. Also, what if a teammate such as a designer is allocated to two projects partially — they’ll have to adapt to two different methodologies separately.

Also, we have noticed that teams became more productive when switched over to Agile methodology. Not only did this mean that we were able to coordinate better, reduce friction, and ship features faster — we were also able to increase developer happiness.

Also, as a teammate, it makes sense to build skills that are transferable and in demand. So, essentially it's a win-win-win for all, the teammates-client-and SoluteLabs.

How to execute such projects?

Executing fixed cost projects in an Agile fashion needs to get one thing right — estimation. Unless you correctly estimate (guesstimate) the time that the team will put into the project accurately, as an agency, you risk a lot.

When clients approach a product development firm like ours — they have varying degrees of clarity: from a tentative idea they were thinking about on weekends to sketching the screens that they think would really work, and possibly have them peer-reviewed by friends, colleagues, or even potential end clients/investors.

Either way, most of them are very flexible on the features that they want to develop. To give an example, if a client has thought about login through email, they won’t be averse to the idea of passwordless login through mobile number and OTP.

Such small variations, over larger features, can vary the timeline significantly. In order to reduce this, before we start the actual development — we work on something we call a “Discovery Sprint Week”. During this week, we take time to detail out the spec, create a very detailed SoW, and then estimate and agree on the pricing.

This helps us and the client by investing efforts only when necessary at the right time. Usually, the variance in the tentative estimation is 20%. This has improved over time and we’re able to provide a much better pre-sales experience to our clients because of the same.

The discovery sessions aren’t free because we also want to be held accountable for the work that we produce at the end of the same. Furthermore, the client, in the worst-case scenario has something tangible at the end of the sessions which can then be used further down the line.

Also, we have seen that during the discovery sessions — clients change their outlook and scope by varying degrees. This lets them be more comfortable with what they are building and investing in.

How do you, the client, benefit from this?

Clients come to us from different walks of life: from people who are working in corporate jobs to those who already have multiple businesses of their own and some who are looking to outsource work whilst working at a corporate.

For those who come with very fixed budget constraints unless they raise some capital (let us all agree that funding is virtually non-existent without a working MVP and possibly some users first) — a fixed cost engagement would ideally seem best.

While this has its own share of drawbacks (discussed in the next section), with a fixed cost engagement, the client is in control of the finances and an undisciplined one can easily burn money. In most cases, this forces the client to be more disciplined about what they really want with the product and what is absolutely necessary.

At the same time, with an agile development process, we’re able to share regular updates with the client. The invoices are also typically tied with the deliverables and thus the client ends up paying for working software rather than just because time was due.

Closing Thoughts

Fixed-cost projects come with their own set of drawbacks. Primarily the fact that there is no incentive to improve performance of working code, increase code readability and commenting, or decrease technical debt. Thus long-running projects are always best suited in a time and material fashion.

However, we do not live in a utopia and clients can’t keep investing (b̶u̶r̶n̶i̶n̶g̶) money forever. However, to realize gains of Agile development with a fixed cost project, this is our best way out!

I’m sure that we too will iterate and evolve over time — that is essentially at the heart of Agile, Continuous Improvement.