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 It Should Be Considered

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!

Prioritising Product Development

Priority

I want a big car (well, more than one), a large mansion, and definitely a yacht too. Now. We have all had this dream (or maybe you have better sense than me). But we know we can’t get all of it at the same time. We may get some of it gradually. So what do we do? We prioritise. And we work with what we have. So instead of a big car, I am happy to have a car big enough for my family. I am okay with an apartment that can house my family comfortably for now. I will work towards getting a bigger house but that would come later. The yacht might never come. This is true of the physical universe we occupy.

Software dreams aren’t very different from regular dreams. We want a beautifully designed app and having all the features we can think of (including a hair trimmer and missile launcher). Now. And guess what. Software reality isn’t different from the physical reality too. So, we prioritise. And we iterate over things improving them continuously till we achieve the desired result.

An Agile Development Plan for a product starts with the strategy and vision at the highest level. The next level consists of feature releases in-line with the high level strategy. The next lower level breaks down releases into iterations that build the features planned in the release bit by bit incrementally. There are two ways to look at the schema of things. Vertical drilling would involve peeling layers of the strategy as above. Horizontal panning would involve prioritising features across the timeline of the project development schedule. The whole gamut is prioritised – what would be required when entering the market to attract early adopters, what all features to build thereafter to strengthen the hold and enhance the customer base, and finally, how to add value to the product iteratively and incrementally.

You start by creating a Minimum Viable Product (MVP in short). An MVP is not a low-quality, half-baked product. It is a subset of the whole product with main objectives of getting initial traction and generating feedback. That feedback provides input into the prioritisation process (and release strategy) on what features need to be included in the next release. Each release generates more feedback that is fed back into the system for improvement. Within each release plan are features that are improved iteration by iteration. Each iteration encompasses a list of user stories which are again prioritised for delivery within that iteration. So even if something doesn’t make it to the release, it is always the lowest priority item for that iteration.

The key points to remember are:

  1. You do not plan everything in detail all at once. You plan in layers.
  2. Not everything has the same priority. Features and releases are prioritised along the development cycle.
  3. More emphasis is laid on the feedback in order to laser focus the product to the market rather than initial all-inclusive feature set of the product.

Better Sprint Planning

Abraham Lincoln on Planning

A Sprint Planning meeting produces the following artefacts

  • A Sprint Goal which is a short description about what the Product Owner (PO) and the team have agreed to achieve in the Sprint.
  • A Sprint Backlog which is a set of prioritised and estimated user stories and their respective tasks that the team has committed to in order to achieve the Sprint Goal

The team needs to have full clarity on both the above artefacts in order to deliver working (shippable) software in accordance with their Definition of Done at the end of the Sprint. So that the Sprint is worth the while of the team and worth the money the client is spending for that Sprint, each member of the team needs to understand the Sprint’s stories and the tasks included therein well. This also includes the UI designs or wireframes for each story included in that Sprint. While the stories describe the functionality, the UI designs / wireframes describe the form.

Let’s look at the Steps of a Sprint Planning meeting:

1. Review the Product Backlog

The PO starts describing the stories from the top of the backlog along with their respective UI designs/wireframes. The team usually asks questions regarding the stories being discussed which the PO answers. Once the team has complete clarity on what needs to be done to complete the user story, the team creates a list of tasks (usually technical in nature) for each user story. The QA person (if you have a specific person for this role) also mentions some test cases he would use for black box testing. However, he is free to include them during the course of the Sprint too. What is relevant and what is not can always be discussed among the team and the PO.

2. Estimate the Sprint Backlog

When the team feels they have discussed enough stories from the top of the backlog, they start estimating the same. The preferred way is to estimate stories in Story Points and use Planning Poker so that everyone is on the same page and the estimate has acceptance within the team.

3. Commit

Based on the team’s current velocity and the time available within the Sprint, the team makes a commitment on what stories it would complete at the end of the Sprint as per the definition of done without skimping on quality.

Now let’s try and understand a Sprint Backlog in depth so that we know the expected output from a Sprint Planning meeting. A Sprint Backlog has the following attributes:

  • It is a subset of the Product Backlog
    • Whatever the PO/Client feels needs to be a part of the product forms the Product Backlog. The Sprint Backlog is a subset of it i.e., it cannot include anything that is not a part of the Product Backlog. Sometimes, there is a need for some technical housekeeping for which the team can request the PO to include (and prioritise) in the Product Backlog. They can be included in Sprint Backlog too provided they are a part of the Product Backlog first.
  • A Sprint Backlog requires a commitment from the team on what would be delivered at the end of the Sprint. This team commitment needs to:
    • be clearly understood and agreed upon by every single member of the team and the PO too
    • be achievable without sacrificing quality
    • be achievable without sacrificing sustainable pace (it is okay to stretch once in a while but not every time)

So now we know what is expected out of Sprint Planning and what are the steps thereof. Let’s now consider some salient points that contribute towards a fruitful Sprint Planning

  • Fixed Start and End Days

A Sprint needs to start and end on the same days (I am considering Sprints that are 1-week, 2-week, n-week long). So if your Sprint cycle is Monday to Friday, it should never change. This helps get into a periodic rhythm that is felt by the entire team. All Sprints are equal sized and this never changes. A Sprint is all inclusive. Apart from the project development, it also includes Sprint Planning at the start and Sprint Review and Retrospective at the end.

  • Include Everyone

A Sprint Planning includes everyone on the project – the PO (and the client too if possible), the Team (including the developers, QA persons, UI design persons), and ScrumMaster

  • Sync Sprint Plan With the Client

If the client is not present in the Sprint Planning meeting and the meeting is chaired by the PO, it is imperative that the PO syncs up with client to apprise him of what all has been committed to in the Sprint Planning. The client might have a rough idea initially as he had prioritised the backlog but this sync up would make sure he knows for sure what to expect at the end of the Sprint.

  • Include Spikes

As it happens on most complex projects, there are functionalities / technologies which no one in the team might have experience with. Such functionalities require researching and building a proof of concept perhaps. For such unknowns, it is good to include a small time box within the Sprint (one or two days for example) for researching and checking the viability. This is done a Sprint in advance. Such a spike reduces the uncertainty when the team comes across implementing the functionality actually and helps them estimate the story appropriately.

  • Abnormal Termination

There may be a rare case that the Sprint Goal that the team is chasing becomes irrelevant in the middle of the Sprint. In such a case, the Sprint can be terminated in the middle and then a new Sprint is planned. However such terminations should be exceptions, not rules. Whenever you have changes being requested to the current Sprint, they should be prioritised to be taken up in the next Sprint. Only in the extreme case should one consider terminating a Sprint in progress.

Now that we have a good hang of what a Sprint Planning (and Sprint) includes, let’s look at Five Commandments for Sprint Planning

1. Thou Shall Stay a Sprint Ahead of the Team

The PO should stay a Sprint ahead of the team grooming the backlog, making sure that the epics are broken down into user stories, arranging the UI designs / wireframes for the stories in the upcoming Sprint, and identifying stories that might need Spikes to be included in the current Sprint.

2. Thou Shalt Not Extend the Sprint

It’s possible that the team is left with an incomplete story at the end of the Sprint. They might consider extending the Sprint by a day or two to complete the pending work and fulfil the commitment they made at the start of the Sprint. This should never be done. Never, ever. Sprint delivery includes completed stories and incomplete / pending work gets put back on the backlog for prioritisation. The Sprint is never extended. This ties in with the point above of having Fixed Start and End Days.

3. Thou Shalt Not Include Extra Time

Never factor in extra time (apart from working hours) in a Sprint. PO / team might be tempted to consider after hours or weekends to meet an aggressive target or complete stories committed in a Sprint. This can be considered only in the rarest of rare cases and should never be encouraged. This ties in to the principle of sustainable pace within a Sprint. While it can be permitted for a couple of days in the project, any longer than that and the team would be setting itself up for failure and lower productivity.

4. Thou Shalt Not Add More Work

Adding more work in the middle of a Sprint is something that Agile is strongly against. The team commits to a set of stories according to their Definition of Done that makes their Sprint Backlog. That backlog should not be messed with. The PO should not try to add / change stuff that is already a part of the Sprint Backlog. Only if the team agrees can the PO swap some item in the backlog with another equally sized item provided it doesn’t derail the Sprint. Any changes can be considered in the next Sprint. But no work should be added to Sprint. However, if the team finishes early, they are allowed to pull in more stuff from the Product Backlog into their Sprint Backlog but not otherwise. Adding more work to a Sprint in target would amount to hitting a moving target and is a sure shot recipe for disaster.

5. Thou Shall Deliver After Each Sprint

The team should deliver working software as per the Sprint Backlog and the Definition of Done after each sprint. No exceptions. This should be delivered to the PO / client for User Acceptance Testing and any changes / feedback should be put back on the Product Backlog for prioritisation.

There is the concept of a Sprint 0 that is a double edged sword. It can have its benefits if handled properly else it can cause you to slide back into Waterfall. The purpose of a Sprint 0 is to:

  • bring the team together and give them a high level overview of the project
  • set up tools (code repository, project management, story board tool, etc.) for the project
  • check tech feasibility of risky components of the project
  • get UI design and wireframes done for the first Sprint
  • break down epics into user stories for Sprint 1
  • arrange resources like App Store developer account, servers for development / testing, emails for support, etc.

Sprint 0 should not be mistaken for a mini Waterfall wherein all stories are attempted to be defined in detail upfront, UI design completed upfront, etc. All these tasks happen Sprint by Sprint (being one Sprint ahead of the team). The focus should be on emergent design (both architecture design and UI design) during the course of the project and not everything upfront.

Though the above seems like a lot (and probably it is) but once you get into a rhythm of doing it, it becomes natural. It is similar to learning to drive a car wherein you have to do a lot at the same time – control the steering wheel, keep the foot on the accelerator, change gears occasionally while pressing the clutch, look in front, look in the rear view mirror, look in the side view mirror, be ready to hit the brakes! After some time it gets so smooth that you can do all the above (and more *wink*) with ease. Same is true with Sprint Planning. If you learn to do it well, the project execution would be very smooth.

Scrum Roles

Scrum Roles

Scrum is by far the most popular framework under the umbrella of Agile software development frameworks. It allows for greater visibility to product sponsors while allowing the development teams to build incrementally and iteratively.

For Scrum to be successful, it needs a certain degree of discipline. That discipline requires that team members have specific roles and responsibilities even when they are encouraged to be cross-functional and support other team members from time to time.

Scrum defines 3 roles – Product Owner (PO), ScrumMaster (SM), and Team.

The PO is what it sounds like. This person owns the product from a functional perspective. He writes the user stories and puts them into the backlog. Before each Sprint, he refines the backlog to ensure that the stories are the right size in terms of effort and complexity for the development team to work on. He ensures that the backlog is prioritised at all times (highest priority stories at the top of the backlog and lowest at the bottom). He frequently grooms the backlog akin to grooming a garden – removes stories which would not be required in the future, adding new stories to the backlog, and refining the ones already on it. Whenever, the team seeks any clarification on the functionality or the priority of the stories, he is their go-to guy.

The way a PO owns the product, the SM owns the process. While the PO ensures that the team build the right product, the SM ensures that the team builds the product right. He works with the PO in ensuring that the all meetings required to make the product and process smoother (Sprint Planning, Daily Scrum, Sprint Review, and Retrospective) are held regularly and in the right spirit. He makes sure that the development team is not pressurised into taking on more work than they can handle. While the PO is busy gathering and giving feedback about the product, the SM does so for the process.

The third and equally important role is that of the Team. The Team comprises of anyone and everyone working on the product technically. It includes developers, UI designers, and testers. They are responsible for building the product as per the acceptance criteria specified by the PO while following the process set by the SM. They own the quality of the product. They have a right to take on only as much work as they can finish in a Sprint without compromising on quality. They are also welcome to request the PO to include stories that would benefit the product quality and maintainability.

Together, the three roles in a scrum form the 3 sides of the project pyramid and offer great stability to the development process. Together, they ensure that the right product is being built right. If any role takes on a weak or a dominating stance in the team, the project suffers. Thus, it is imperative for each of these three engines to fire consistently in order to move the ship forward.

The team is also referred to as “Pigs” (because they are committed to the project) while the PO and SM are referred as “Chickens” (because they are just involved). The following image lends context to this nomenclature.

Chicken and Pig