Product deliveries have become strikingly similar to waging a battle – a battle against deadlines, lack of predictability and changing market trends. Like any war, these are also won with a combination of skill and strategy. While some part of strategy is specific to the situation, there are a few things that are common to all. The part of strategy which becomes common across all projects is what gets termed as bootstrapping. So effective bootstrapping is critical.
Over the past few years, I’ve created a cheat-sheet for bootstrapping projects to ensure highest degree of battle-readiness even in the rush of things and reduce the time to hit the ground running. BTW, if you already have a smooth-as-butter process in place, then chances are that some of this may not be news for you. For others, read on.
Start with the Boiler Plate
There are a few infrastructural must-haves that I call the boiler-plate items. If you’re a first timer, then the following questions would be most useful
- Which version control system to use? Do you have a server for it?
- Which IDE needs to be used?
- How many systems don’t have the development environment or require an upgrade?
- Do we need a build server?
I had an instance when setting up the development environment on the HTML developer’s machine ended up consuming more than 3 days! It was an upgraded system, where the dependencies conflicted with the previous version. Those 3 days came to bite us towards the Sprint’s end. Having burnt my hand that time, I don’t take installations and upgrades for granted. This precaution has saved many a day for us since a prior knowledge of this, lets me put the right buffer in place.
The Technology Ramp up
Any product worth its grain comes with a high level technical design. Couple that with the database design and the underlying components. While most of us plan for these, being mindful of a few things here can help unearth a few areas which were previously in the dark.
- Have we hashed out the technical design for database and services?
- Is the Project scaffolding ready? Does it have any complexities?
- Would Exception handling require customization?
- How extensive is the logging?
- Is there any master data required which needs validation from the client?
A healthcare web app that we were once building on very stringent timelines had a massive logging requirement which lay outside the scope of what the framework required. At the time of requirements, the client had merely said ‘require logging’. If we had dug deeper into the nature of logging at the onset, it would have saved us a few weekends.
Know What You Don’t Know
Every project has some unknown aspects. If these are not part of the immediate deliverables, there can be a tendency to push these to the last, creating a risk of leaving the toughest battle for the shortest time. So some things to follow
- Identify highest risk areas and biggest unknown elements
- Map these to the project success/priority
- Start discovering the most critical and biggest unknown, even if the development is to take place later
- Do a POC if the idea has never been tried before
A rule of thumb that I follow is to start with One Known and One Unknown feature . This combination prevents us from over-spending time on features which are in the comfort zone and at the same time, not feeling deflated by the seeming lack of productivity when working on something new.
We Need to Talk
Establish the communication protocol from the onset. ‘That sounds like a no brainer, Duuhhh!’ you’d say. I agree. But you would be surprised how many times we overlook this and how quickly it derails the project. The fallout? Failure to set expectations or making disastrous assumptions. On many occasions, especially if you are working for a startup or a solopreneur, there is a high chance that they would not be aware of the process or the jargon that you take for granted. So it helps to ask some questions like
- How frequently should we talk to the client?
- Will we use emails on a daily basis with a call once a week, or should we do it fortnightly?
- What Scrum ceremonies are to be followed?
- Does the client even know Scrum?
- Is the client familiar with the Project management tool we will use?
- Are there any hard deadlines? Does the team know about them?
- Do we need to plan 2 sprints ahead or 4 (useful in hard deadlines)?
From this, it may arise that there is a need to educate the client, fine tune the process and/or the communication channels or change the execution plan. The payout? Setting the right expectations and knowing in advance if there is any change in the timeline.
Bring the Soldiers On-Board
You’ve dotted the i’s and crossed the t’s, but wait, are you going into this with sentinels or humans? My guess is that it’s humans (for now). Most of the times we share only the product requirements and the delivery timelines. We rarely get into building a connect for the product or for the client within the team members. And unless your team doesn’t have a buy-in in the success, it would be challenging to achieve it. So, I do my own version of KYC in the kick off with the team where the intent is to build an emotional connect so that the team can adopt this baby
- Share the client’s why. Why do they want to build this?
- Share the client’s vision, their hopes and the big picture
- Share how it will make a difference to those who use it
- Share the story of ‘how it all began’ i.e product’s ideation and journey
- Share the background of the client, anecdotes about them or any previous association
It doesn’t hurt to go back to our own organization’s mission statement to reconnect with the core values, specially if there are new team members.
I’ve seen this work beautifully when working on a disruptive mobile app for a small US based startup. The team’s empathy for the client left him touched and surprised – we happily went the extra mile to do the right thing. The result was a very successful app launch.
These are my battle secrets. I would be very interested to hear yours.