I used to play basketball for my school and in amateur leagues.  Early on, I always thought the strongest, fastest and fittest teams would win.  However, with the benefit of a coach, I learned quickly that the best teams had more in their arsenal than just fitness and skill—they had set plays. We spent hours practicing plays to perfection; giving them code names of our favourite Hollywood actresses; and paying in push ups for any mistakes. Games were never the same. On offence, we were no longer just trying to muscle through or find an opening, instead, every player knew what to do when our point guard called, “Jessica Alba”.

Software development is similar in that while coding skill is crucial, it is only half the game.  How are features defined? What happens when there’s a change? When do we tackle bugs? How do we stay on time and on budget? What do we do with technical debt? How often do we release? How is progress tracked?

These are questions that we often get and this post is intended to answer those questions by giving you a look into our playbook and sharing our development process. This is not a post about why we work this way and how it ties in to Agile principles, nor is it to say that this is the correct way to do it.  The “best process” will be different for every team—there is no one size fits all.

_________________

The “best process” will be different for every team- there is no one size fits all.

Every client comes from different backgrounds and are at various stages in the development of their app. The development process below is for an early stage startup that we’re doing a turnkey project for. From start to finish, here we go!

1. Requirements Engineering Workshop

Often clients have little more than an idea and some specifications on the app they want to build. Additionally, the odds are stacked against them. 90% of apps fail!  Often due to lack of planning, expertise, budget or all three! What hope does anyone have?

This is where our Requirements Engineering Workshop (REW) comes in. The REW is our roadmapping process that transforms ideas, napkin sketches or pitch decks into a development ready blueprint.

REWs typically last 1 to 2 days depending on the scope of the project. In this time we will chat, create, curate and consult, not only to define the technicalities and features of the app, but also to analyse important aspects such as the purpose, justification, commercialisation / monetisation and target market.

In the next few days, our team works on the selection of deliverables:

• Time & cost estimation

• Process flows

• Persona / target market analysis

• Product backlog

• Wireframes

• Relational database structure

• Technology stack list

2. Designs

Humans understand things much better when we can visualise it. Wireframes or designs are imperative to helping investors and developers understand what you want to build.  No one apart from your mom is going to read your 10 page specification / feature list.

_________________

No one apart from your mom is going to read your 10 page specification / feature list.

Which were you more drawn to?

Hence, the next step is to take the wireframe deliverable from the REW and turn it into a clickable prototype after we do a round of interviews with the client on their preferences of the look and feel of the app.

Flow by flow, our designers will design and upload the screens on Invision (a design collaboration tool) where the client will be able to view, comment and approve screens for our designers to see and respond to in real-time.

Ideally, all the designs should be complete before the development starts to avoid “bottlenecks”.  This is when the development is hindered because designs were not ready. However, this is not always feasible due to tight timelines.  For such cases, the design and development effort needs to be managed well, to ensure designs are always ahead of the development.

3. Early Stage Sprints

We use Scrum as our primary project management framework.  As opposed to the Waterfall Model, all Agile frameworks work in iterations. This gives us the ability to cater to changes and provides the client with working software every iteration (or Sprint), rather than only at the end of a project.

You can read the official Scrum Guide online, but this is Scrum in a nutshell if you’re interested:

Sprint Planning

• The Product Owner, developers, designers and the Scrum Master (myself) meet together to to plan the scope for the Sprint.

• Stories from the Product Backlog (compiled in the REW) are moved into the Sprint Backlog.

• In early stage Sprints, we recommend 1 week Sprints.  Although this requires more time commitment from the client, it expedites feedback loops and the building of relationships, which is crucial when just starting a project.

Daily Scrum

• A 15 minute time capped meeting that is held at the same time and location daily.

• It opens communication channels and gets everyone on the same page for what everyone is doing that day.  

• Work and progress is made transparent. Impediments are highlighted. Feedback is obtained.

• This is particularly important if we are working in tandem with the client’s developers.

• This is arguably the most crucial meeting in Scrum. Skipping it would be shooting yourself in the foot.

Sprint Review

• At the end of the Sprint, the team gathers again including any stakeholders that wish to join.

• The developers demo the work that has been done and request for feedback.

• The Sprint Planning session takes place immediately after.

4. Later Stage Sprints

There’s no set timeline for what counts as “later stage”, but essentially it is when we and our client feel like we have a good rhythm going.  At this point, we transition into 2 week Sprints in order to reduce the time the client has to commit to the project. Although Scrum allows for up to 4 week Sprints, we don’t recommend Sprints that last any longer than 2 weeks.

Although the formal feedback loops are reduced, keep in mind that the Product Owner should be available throughout the Sprint to answer questions and clarify requirements.

5. Post Release Sprints

When the app is pushed to production, the development process changes once again. Apps in production present development teams with a new agenda—keeping users happy. When there are real users paying real money to use your app, the priority has now switched from building features to catering to the user’s needs.  Here are several common tasks that will come up:

• Fixing bugs.  There is no such thing as a bug free app.  From the new environment to the number of users and new user behaviours, there are too many variables for anyone or any machine to foresee.

• Performing admin related tasks (e.g. retrieving user’s accidentally deleted data, or resetting passwords)

• Responding to feedback (e.g. if users can’t find the checkout button)

• Clean up.  With all the rush to launch an app, everyone is busy and stressed, making it easy to miss things out.  These tasks could include spelling errors, dead links, incorrect translations (if your app supports multiple languages), etc.

You’ll notice that the above list contains tasks that come up ad hoc—unplanned.  With high priority ad hoc tasks coming in on a daily basis, Scrum is not the ideal framework to use.  What ends up happening is that the planned tasks will be overshadowed and deprioritized by bugs or tasks coming in from user feedback.

_________________

What ends up happening is that the planned tasks will be overshadowed and deprioritised

So instead of Scrum, we switch to Kanban. Kanban is an Agile framework that is much more apt to dealing with an environment where requirements and priorities change daily.  A crude summary would be that Kanban is simply Scrum without all the meetings. We work off a backlog where tasks are entered ad hoc by the client or ourselves as we discover bugs.  We always work from top to bottom to ensure that the most important tasks are tackled first. We are in constant communication with the client for feedback and clarification, but there are no formal meetings where we review the items done. Everything from logging stories, to development, to testing and receiving feedback is done in real-time as and when requirements arise.

When the heat of the launch has cooled down, the bugs have been exterminated and the client has defined features for phase 2 of development, then we revert back to Scrum. So once again there is routine, order and consistent meet ups with the client.

And that’s how we run our plays.