What the heck is an MVP and Why you should build it

MVP

As an entrepreneur, you are probably aware of the buzzword called MVP. Maybe you understand it to some extent. But do you REALLY understand it well enough to build it? Let’s see if I can help you garner that understanding.

MVP, as you might already know, stands for Minimum Viable Product. Now, you might have this belief that you must take all the features you have thought of to the market at once. You want to make a big impact and for the same you want each one of those features in there. I am inclined to agree with you but I have learnt that it doesn’t work like that.

Let’s say you have a set of features that are at the core of your product. This core defines your product. This is how you set yourself apart from the competition. Or this core helps you create a new market altogether. The MVP revolves around this core. It encompasses those features that you absolutely must take to market lest your product would be non-functional.

It is with this MVP that you make your first launch. Relax. I am not talking about launching a half baked, incomplete product. I am talking about having just enough features that makes your product identifiable. At this moment, you are looking for feedback from the market. You are looking at early adopters to test your product and provide you insights into what they like, what they don’t, and more importantly, what they want in addition to the MVP. This last bit helps you identify those features that would make it to your next release. Maybe you had a different feature set in mind but is that something the market is seeking. Would those features help you gather more customers? Maybe or maybe not. But the key to answering that question is your MVP.

Structure your product features in a way that you can build your product iteratively (adding more layers to existing features) and incrementally (adding new features altogether). All along the way, you keep testing the market and have your ear to the ground trying to listen to what the people are needing. You let them PULL features into your product and not PUSH fears onto them. This is the essence of Lean from which the concept of MVP stems.

Always look at your product with a beady eye and scalpel in hand ready to cut out the fat and trim it to what you can do with. Let the market test it out and let you know where it is thinner than it should be and where it can be cut further. In order to streamline your product development while achieving the maximum, you need to focus on the minimum.

Plan BETTER, Not MORE

Plan

How many times has it happened that you had a perfect plan for a holiday or some event that you were organising and the plan fell flat owing to some scenario that you hadn’t anticipated? Well, we have all been there. German Field Marshall Helmuth von Moltke the Elder put this succintly – “No plan survives contact with the enemy”.

Perhaps you were able to recover in some of those snafus but, as would agree, it was because you improvised, you adapted to the situation, and reacted accordingly. Well, that is being Agile truly.

We have grown up thinking we need to plan for the future down to the smallest detail. But the reality is something entirely different. Yes, we need to plan. But not as much as we think and not as far in the future as we are led to believe. We need to plan better, not more.

This couldn’t be more true than software development. The Waterfall model of software development relied on heavy upfront planning that was documented even more heavily. Then the software teams were made to march a thin line that was their plan. But after all these years and a lot of frustrated clients and money poured down the drain, we have realised that Waterfall probably wasn’t the best way to go forward. This is why Agile software development model came into being. It includes various levels planning but each detailed appropriately and not focussed on having all details mentioned upfront.

You begin with a high level list of features duly prioritised (called the Product Backlog). Then a few items are picked from the top of the list (highest priority items) and details thrashed out. These detailed items (called User Stories) are estimated by the development team and then a few of them are selected to be completed within a short timebox (one to two weeks long) called the Sprint. The list of items to be worked within the Sprint is called the Sprint Backlog. During the Sprint, the team implements the features selected in the Sprint and at the end of the Sprint you have working software in accordance with your requirements. This process is performed iteratively over the product backlog and during the course of the development, you can release the working software to the market multiple times.

Effectively, we don’t plan the entire project in advance. We plan at a high level and then refine bits of the plan iteratively. This helps us incorporate ground realities in our plan as we go about refining it. Things change all the time and we make sure that we are in a position of reacting accordingly. Quoting the famous American General George S. Patton – “A good plan executed today is better than a perfect plan executed at some indefinite point in the future”.

The Power of Retrospective

Retrospective

They say hindsight is twenty-twenty. Things always seem to fall in place when looked back upon – the causes, the affects, the problems, the solutions, and more problems. The key is in learning from it and using that learning to guide our actions in the future. Agile has formalised this wisdom into a meeting called the Retrospective.

A Retrospective (called retro in short) in Agile terms is when you reflect back upon a certain period (say a Sprint or a Release) or the entire project (in case of project-end retrospectives) and see what went well, what could have gone better, and what experiments to try out in the next sprint / release / project. Some key questions could be:

  • What went right? What went wrong?
  • What could have been done better?
  • What challenged / excited you?
  • Any events / activities / tasks that you would want to highlight.
  • Your overall feeling about the sprint.

Each team member involved with the project (even the client if possible) sits in the retro. There are various ways of conducting a retro but the book Agile Retrospectives by Esther Derby and Diana Larsen offers a structured approach:

  • Set the Stage
  • Gather Data
  • Feelings
  • Generate Insights
  • Decide What to Do
  • Close the Retrospective

In a nutshell, the team highlights issues (both positive and negative) they want to raise. Then the related issues are grouped together and thrashed to arrive at the root cause. The objective is to look for causality so that negative issues could be avoided and positive ones reinforced in the future. It is possible that some of those negative issues were the direct result of individual actions. However, the team never falls into the trap of blame-game and no fingers get pointed at any individual. The principle behind this is the Prime Directive framed by Norman Kerth – “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”.

A retro is a great platform to uncover those feelings / events that may be hampering the process. In Scrum, whilst the Sprint Review is an opportunity to implement the inspect-and-adapt philosophy to the product, the retro does so for the process. If a team continues to hold retros in spirit and word, it would identify actionable items at the end so that the process is improved and the impediments uncovered are removed or the experiments outlined are accomplished. It helps the team vent out feelings of frustration / sadness without making anyone look bad. It also lets the team highlight positive steps performed by individuals that helped the team. Most importantly, because Agile is a framework and allows you to tweak things without compromising on the principles, the team can identify some hypotheses it might want to test in the next Sprint / project. This helps the process to evolve and strengthens it further.

Seeing the power of retros and the value they bring to the table, a lot of teams have started using them. I have seen even support staff (HR / Admin) use retros to help them improve their effectiveness and chip out at their weaknesses.

Summarising the above, by holding regular retros, you can make identify areas of improvement that maybe plaguing your team performance or strengths which can be leveraged in doing a better job.

Leave Some Slack

Choked Traffic

Let’s say you have a list of tasks to do and some time at hand (say 8 hours). In order to be efficient, you full in your schedule choc-a-block. But guess what happens, less tasks get done and you end up exhausted. Sounds familiar?

This is the reason the wise have advised to include some slack in the schedule. Include some buffer time, some time for context switching, or maybe some time for a coffee or two. Consider a highway that can accommodate 100 cars. But if all the 100 cars are there at the same moment, the traffic would come to a standstill owing to the congestion. For a free flow, it is imperative that the cars are spaced apart so that they can drive along smoothly and not crawl.

It is a similar situation with software development. In order to deliver early, some teams pack in too much work in their day. As a result, they are not able to complete all the planned features. Or if they are able to do so, the “definition of done” is not adhered to. And worst of all, the quality suffers. Not to mention that the team burns out while rushing through the work. We are not talking about letting the teams kick back and relax and not do any work. We are talking about doing work with a sense of urgency while not forgetting to take the occasional break. If you plan to work for stay in office for 8 hours, don’t plan work for more than 6 to 6.5 hours else you will end up tired and your work might not be as good as you would want it to be.

If you plan well, you can have just enough work in a day and build a schedule over days that would allow you to deliver stuff regularly, while keeping the quality alive and enjoying sound mental and physical health. True, one can not have enough time to do enough stuff as work never seems to come to an end. But, simply rushing through work ALL the time doesn’t help either. Move with a sense of urgency but take time to breathe. This reminds me of an old Zen adage: “You should sit in meditation for 20 minutes a day, unless you’re too busy. Then you should sit for an hour.

What is Unit Testing and Why You Should Consider It

Vader and Unit Tests

Unit testing might sound a little technical but don’t let that scare you. I would try and explain in simple terms what it is and why it should be done.

Let me first put some context in place. If you put carrot in a juicer at one end and you get nice carrot juice at the other and you are not aware of the internal working of the juicer, then that juicer for you is a black box. You couldn’t care less whether there is complex machinery inside or just a small gopher that squeezes the juice out of the carrot and pours it out. That’s what a black box is. You provide input and you get output while being oblivious to internal processing.

Black box testing gets its name from the above concept of a black box. You provide input on a form in a software application (consider fields like name, occupation, organisation etc.), you get output (for example, a neatly formatted visiting card layout), and then you test that output against the expected result. This testing is not concerned about the internal working of the application that did the job.

The opposite of black box testing is called white box testing (also called glass box testing or clear box testing). Here the focus is on the internal working of the object in consideration (piece of machinery, piece of code, etc.). White box testing in software looks at how the code runs on the inside. Unit testing is a type of white box testing. There are classes (abstractions of real world objects, for example, a phone), their methods (functions that a real world object does, for example, make a call), and their properties (attributes of the real world object, for example, phone number). Unit testing checks each of these classes and their methods (and some more).

Consider a login page page of an application that allows the user to login by specifying his email and password. A simple way would be to check for the presence of entered email in the database and then match the password with that in the database. In case of absence of the email in the database or mismatch of the password, an appropriate message would be shown to the user. Implementing this kind of logic would require some kind of if-then-else code (called conditional logic). Greater the number of conditions in the business case, greater would be the number of if-else blocks within the code and, ergo, the number of permutations that can result.

A good developer would test each of these conditions to ensure that no scenario causes the code to break. However, doing this testing via black box approach would not be possible. This is where white box testing comes to the rescue. Unit tests (a unit can be considered a small piece of code that can be tested independently) are written within the code that test each scenario. Every time the developer makes a change to the code, he runs all the test cases to ensure they are passing (meaning no change is causing the code to break). This greatly increases the quality of the code, raises the confidence level of the developer for his code, and, most importantly, makes the code maintainable. Every time you make a change, just run the test suite (all the test cases combined) and, voila, you would know whether all’s well with the application or it is behaving erratically somewhere.

The above scenario is just one example of how unit testing can help the code. Unit testing goes a long way from testing simple if-then-else blocks. A good test suite (and the corresponding pass/fail ratio) can be a good metric of the code quality and maintainability. However, writing unit tests takes time comparable to writing the original code itself. So writing unit tests can be a little expensive if cost is the primary focus of your application. But if you are looking to have a robust application that can be built iteratively while keeping the quality intact (or raising it), unit testing would be your best friend.

When software projects are handed over from one vendor to another vendor for maintenance, one of the primary metric that gets looked at is the quality of unit tests – pass/fail ratio and the code coverage (how well do the existing unit test cover each scenario). Anyone who has read a programming book can write an application that can satisfy business requirements. But what separates the men from the boys is the level of unit testing done and code quality. So if you are looking to build an application that you would like to continue to improve upon and tune as per the markets, make sure you ask your developers, “hey, do you guys do unit testing?”.

Are You There?

Are You There

At Appster, we practice Scrum as our software development methodology. The upside of this incremental and iterative philosophy is that we can deliver working software very frequently (every week) and yet be open to change during the course of the project. The downside is that it requires active involvement of the client. Clients who could sit back and relax after the heavy exercise of requirements gathering during Waterfall days find this challenging and, sometime, even revolting.

The team requires client presence (physical or over video conference) during Sprint Planning Meetings. This is the time when the team needs clarity from the client on the high priority user stories that can be picked from the top of the backlog as Sprint Backlog. The team might require client involvement during the course of the Sprint when it is faced with a priority decision (which stories to complete in the remaining time available) or maybe some clarification on an existing story or maybe a decision on the multiple options possible for implementation of a story. And finally the team requires the client to do User Acceptance Testing (UAT) of the build that the team generates at the end of the Sprint. This part is of key importance. UAT actually generates feedback for the team on how did it deliver against the requirements of the client. Even if it was spot on, the client might get “aha” moments during the UAT and might suggest changes (which are welcome in Agile) that would go on to improve the product.

While clients are available during Sprint Planning (actively or passively through a PO), it is hard to get them to do a thorough UAT. Maybe because they also have a day job or maybe because they are busy in other aspects of their business as an entrepreneur. Whatever the reason be, the lack of timely UAT hurts the project and demoralises the team. The team feels sad when it don’t get timely feedback as it feels that it is working on something not important enough for the project sponsor. It feels orphaned. The project suffers because the team might go off-course for lack of a corrective action that the UAT could have spawned.

As a result of delayed / improper feedback, client feedback accumulates towards the end of the project. At this point, two opposing forces come into action – the client who is giving feedback (which might have lost relevance due to lost time) and wants all his points to be considered; and the team which is wanting to wrap up the project and is inclined to ignore those points that the client is suggesting. This force completely dries up the agility that was intended into the project. The client is welcome to add more to the project provided he takes out an equivalent amount of work from the plan or allows more time to the project. The above scenario keeps the deadline but tries to add more work which might be relevant (for example bugs in the application discovered by the client).

For a successful project release and happy stakeholders (development team and the client), it is imperative that the client does timely UAT and provide feedback that can be fed back into the product backlog and the product can be developed with a sharp focus on the market. The team should not have the chance to ask the client, “Are you there?”.

Don’t Snooze Technical Debt

Snooze

Beep! Beep! Beep!…. goes your alarm clock. Yawwwwn! (what the hell). Snooze!
After 15 minutes…
Beep! Beep! Beep!….. (the darned clock). Snooze!
After 15 minutes…
Beep! Beep! Beep!…. (damn it, I am late)!!!

Sounds familiar? Most mornings (especially the ones on Mondays) are like this. I am wondering if this behaviour of being lazy has made its way to other aspects of our life too, particularly, software development.

We are in a mad rush to meet the launch deadline so we decide to skimp on some quality, cut a corner here and there, essentially creating a product held together with gum and baling wire. We agree to attend to those quality issues later, replace those quick-fixes with a better solution in the next release. The product launches and is well received. And in the process we receive some rich feedback on what new features to include. Or maybe the launch isn’t as exciting as we had anticipated and we consider some features to add more teeth to the product. Either way, we are in the mad rush all over again to quickly add the new features to our product. So we decide to postpone replacing those quick-fixes again and in the rush to release soon, we accumulate some more quick-fixes and cut corners. The release happens and thereafter we create another list of features to include in the next release. We also include, rather grudgingly though (as we are in a rush again), some quick-fix replacements that we had promised earlier. But now, while working on this release, we realise it is getting difficult to add new features. The product breaks at unanticipated areas whenever we make a small change. Those quick-fixes have rendered the product unmaintainable. So we are spending more time managing the mess rather than making improvements / changes. In the process of becoming faster, we have actually become slower. In short, we are having challenges repaying our technical debt that we have accumulated and now the interest for the debt is more than the principal. This is what happens if you keep hitting the snooze button on your technical debt.

While it is acceptable to prioritise quality issues and work on the most urgent ones for now (do some quick-fixes for now), it is imperative that those quick-fixes get replaced by more elegant solutions as soon as possible. If you fail to keep a check on the accumulating technical debt, the product soon turns into spaghetti that no one can segregate (or even eat). The old adage “a stitch in time saves nine” emphasises the above points. Looks like our forefathers were wiser than us after all.

So, if you want to have your product grow continuously, you would have to keep the technical debt low.

Don’t snooze, wake up!