Agile Development at Slash • Slash

Clients are often confused as to how to get started, whether it’s a new project or a takeover of an existing one. The main challenge is that there is a gap between the clarity they think they have and the clarity we need to provide project costing and timelines.

To overcome that confusion and form a clear, mutually comprehensible action plan, we at Slash have developed our own approach. In a series of articles, we will present the predefined phases of our processes. Let’s talk about Agile Development.

***
In this phase, the idea of the project starts taking shape, and we have to answer 3 key questions to proceed. With the answers, we will have the clarity required for getting on with the phase.

Decision 1: Do we want to optimize delivery for flexibility in scope or for contractual definition?

Decision 2: Is the existing definition of the scope of work 90%+ clear or does it still need further specification?

Decision 3: Do we need design sprints to prepare the specification at the right level, how many weeks of lead time should the design sprints have on the build?

Table of Contents

The Agile way

It might seem that if the requirements are clear for a project, the development team just follows the plan and the client only has to review the team’s work once it is completed. In practice, it is impossible. Ideas evolve, requirements change, new requirements arise. This is when the agile methodology comes into play.

Agile development takes the design and product briefs, created in previous phases, and breaks down specifications in terms of what needs to be done: it schedules sprints, allocates teams to sprints, develops the product. This system operates like a factory floor, where every group of employees performs a specific task.

Requirements get cleared up during the design sprint to get them ready for building by software engineers. Typically we design a few weeks ahead of the engineering schedule, so the designs are complete well before the engineers may need them. This way, the process never gets stuck.

The product design phase does provide detailed product specifications (epics, user stories, UX and UI), but in practice the requirements won’t be followed 100% and there will be changes. The beauty of Agile is that we can optimize for flexibility in scope AND for predictability in delivery speed, by setting up a streamlined design-build process.

By allowing flexibility in scope, clients can make some changes. By following disciplined agile delivery practices, we can then protect the team from getting confused or stuck by those changes.

Every sprint takes 2 weeks. We at Slash usually try to design 4 weeks (2 sprints) ahead of the build. This gives us a sufficient buffer for big discussions and changes, without risking the build process.

Design Sprint

Whenever a user story is not “ready” to build, we put it through a design sprint. For more information on user stories, see our article on product design.

These are the key steps of a design sprint (note that some of them are optional and can be skipped):

Feature scope and delivery plan
Agree feature value and assumptions
Story breakdown and acceptance criteria
Tech investigation (if needed)
UX design (if needed)
UI design (if needed)
Agree API contract
Feature scope sign off

This is how a typical design sprint goes. We determine in detail what features we want to have and how much time we need to deliver them. Based on that, we agree on feature value and assumptions, i.e. understand if we need the feature at all and if yes, then why we need it. For instance, you have a hairdresser appointment app and you want to add a chat to enable customers to book an appointment directly with the hairdresser or ask clarifying questions. In this example, we could ask ourselves if the chat is really needed or if we can keep it simple and just include 20 FAQs in the app.

After that, we break down the feature into user stories and define acceptance criteria. Acceptance criteria refers to a set of predefined requirements that must be met in order to mark a user story as complete.

The next three components (Tech investigation; UX design & UI design) are optional and depend on whether a feature requires further investigation for tech feasibility or visual design.

API is the information exchange layer between frontend and back end, including the key data parameters that the API will be providing to the frontend. We design the API contract in advance, specifying the parameters, so the frontend knows what to expect and where to display the information. This has the added benefit that in case the data is not available yet for the API, the engineering team is not held back and can already proceed to integrate the API – once the data is ready, the API contract and integration doesn’t need to be changed anymore and the data can be consumed by the frontend.

As a final step in our Design Sprint, we can sign off and get on with the build sprint of the planned features.

Build sprint

Here is what we do during the build sprint:

IT architecture & data privacy if needed
Story preparation with acceptance criteria for build
Update backlog
Sprint planning
Daily standup
QA testing
Definition of done
Deploy
Sprint review (demo)
Sprint retrospective

As we start a build sprint, the tech lead or solution architect typically considers whether what we’re building can impact the architectural runway. The “architectural runway” consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay. If the runway is “long enough”, you’re fine. If the end is in sight, you need to consider how to extend the runway by rearchitecting part of your system. If a new feature that you develop may impact this runway, you need to assess the impact and the right course of action.

Similarly, we evaluate whether a new feature in the build sprints meets or impacts the privacy design of the system. Typically privacy has been designed into the core architecture. Sometimes though, a feature may require us to reconsider this.

Next we do backlog grooming and story preparation. Not every build sprint requires a design sprint. Typically 2-4 weeks prior to each build sprint, the product owner and scrum master would review the build backlog and groom the story as needed. This involves verifying that the acceptance criteria are well defined and understood, refining the criterias needed, ensuring all the feature requirements are clear, any design assets or integration documentation is available etc. If a story is 90%+ clear, it goes into a build sprint. If a story is not clear enough, it goes into the design sprint we outlined above.

Once the actual build sprint starts, we conduct daily standups with the entire team: everyone in the team shares what they did yesterday, what they’re working on that day and if they face any obstacles. Standups, as the word suggests, are usually no more than 15 minuhtes.

Once a story has been coded, the code is pushed to the central code repository (e.g GitHub, BitBucket). Each developer typically works on a sub branch of the code and before the code can be pushed to a parent branch or the main branch of the project, it needs to be reviewed and tested. This is where QA testing comes in. QA is a rather broad topic that is often misunderstood and underappreciated by business stakeholders, so we will devote a dedicated article to this. Suffice to say, it’s critical.

Before the code of a story is merged into the whole project, it has to pass what we call in Agile a “definition of done” (DoD). The Definition of Done is an agreed-upon set of items that must be completed before a project or user story can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done.” The exact Definition of Done is often company, team or project specific and depends on the DevOps & Security infrastructure of a project, the documentation, the application objective and service levels, the mindset (startup speed vs enterprise IT) etc.

After that, we deploy the code of the story to the main project. Typically deployment consists out of 4 (or more) application environments: the local environment (engineer’s laptop), the ‘dev’ environment of a project is the first cloud-based shared environment where all the devs push their code, staging environment (when the story is ready to be pushed live, you try the new feature in the exact replica of production environment – a dress rehearsal so to speak to see if something breaks in a safe space), and finally the production environment that live end-users interact with.

When features are built and sprints are completed, we review whether what we’ve done corresponds to what the clients and we want. In conclusion, we hold an internal meeting – retrospective – to talk about how we worked to understand how we’ve worked and how we can improve. Such meetings take place typically every 2 weeks at the start of a project, and as a project matures they become less frequent (4-6 weeks).

These are the design and build sprints. The way they are constructed is a big part of the agile methodology: there is a constant dialogue between the developing team and the client, and the flexibility that is built into the delivery model allows us to provide a predictable delivery process despite changing requirements.

Collaboration mindset is important

In terms of the challenges that arise with this method, what clients need to know beforehand are the key principles of Agile development (Agile Manifesto). They are as follows:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

The methodology of agile development is about collaboration, not contracting. Some clients are used to the model in which they agree on something after lengthy negotiations and then commission the work, then don’t look at it for months until the final outcome.

This is not how we work. While clearly a contract is a critical step in any commercial relationship and we take it very seriously, our mindset is that we seek a partnership with a client where we optimize for successful outcomes. This requires trust and dialogue.

In practice this means that we expect our clients to be open to adopting this Agile mindset, and to have a more active role to play throughout the delivery process. Typically we expect clients to be involved 1-2 hours per week to ensure we are fully aligned throughout on what business value we deliver. Our Agile process enables this ongoing dialogue in a predictable and structured way.