Agile in an Agency Setting — Things We’ve Learned at One of London’s Leading App Development Agencies

In a recent project, Nodes trialled a more agile approach to delivering a mobile application. A comparison between the typical approach and the recently trialled approach is detailed below.

In either approach, its still required that either Nodes is engaged to produce soft UX outputs (Competitor research, Personas, Problem framing, product vision, etc) or these are shared from client to Nodes prior to any design and or development. Failing to do this means creating a product based on our personal opinions and biases & is not a recipe for success.

Design before development

Wolfgang kept his word, and when the time came, he presented his invention. Footmen dressed in livery wheeled the contraption in, much to the surprise Typically Nodes projects have a discovery & design phase before any development begins. This is intended to efficiently use the development time by minimising possible blockages based on lack of clarity, required assets or third party integrations. The idea is to map out every screen, think through possible scenarios and design a product to meet the requirement.

Pros:

1. Better for client governance. If a project is done this way, a client can review and approve all app screens before the development begins
2. SOWs can be split up to give a client more control. E.g. After the design and discovery time box an updated estimate will be supplied for the development phase of the project. The client has an opportunity to either de-scope or go with another agency if the cost doesn’t fit within their budget at that point.
3. When development begins, developers only build a screen once, with the full design assets, so it is efficient.

Cons:

1. Complex designs
   While anything obviously difficult to implement would be checked with a developer before creating designs for it, it is unrealistic for a developer to be fully immersed in a project within an hour to be able to guide a designer on one question or another. This means the designer primarily leads based on their assumptions of complexity & can produce designs which are time consuming to implement which then takes up budget intended for implementing core functionality. If the designs are already signed off, it’s difficult when this is raised in development to then back track on that implementation to reduce the scope / cost for the client.
2. Unknowns
   At the beginning of the project, when we are not all working through a particular section, we know the least about it. It is common that we discover that something will not work the way we designed it once we begin to develop it. This can’t really be avoided, because it is only doing the development work that brings this into the open. In this case, it results in wasted effort by the designer because we need to redo or change the design and frustration from the client in having one thing promised and then not delivered.
3. Slower
   A design and discovery phase is minimum 3 weeks and often longer. This is time that the team could be developing and iterating a product

Design during Development

In a recent project, Nodes was given a brief and a total budget with a rough deadline. This was a more open brief than usual and a good opportunity to work in a more agile way to compare the benefits of such an approach. The differences were:

1. No design before starting. We would draw wireframes onto the whiteboard to begin. Design would then be done in tandem to development
2. No detailed feature requirements — We would empower the team to create acceptance criteria to meet an MVP which hit the over-all brief
3. 3 day kick off in co-located space, on-going co-location for first couple of sprints where-ever possible.

Pros:

1. Better ideas
   When sharing ideas, the full experience of all the team across their many projects put more options on the table
2. Planning to the budget
   As the whole team was creating the MVP scope together, we were able to plan the resources to deliver within the budget and timeframe
3. Fast
   We made decisions because we were all there together, documented those decisions and then began developing straight away. By the end of the first sprint we had already ticked off some stories and made headway into the critical features for the app
4. Alignment
   We defined & confirmed the acceptance criteria together, which the developers wrote their tasks from, directly, so the requirements were very clear to the whole team, including the Quality Assurance team and there were therefore less misunderstandings at the beginning of the project, which paid dividends later

Cons:

1. It requires a lot of engagement from a client for the initial 3 day kick off and then on-going during the initial weeks to continually align and update the plan to ensure you can release a MVP within budget
2. Depending on how involved the client was in day-to-day, it could be hard for the manager on client side to appear in control to senior stakeholders. It requires a large amount of trust / buy-in from client: lots of ‘keeping it simple’ decisions need to be made early on, often including significant de-scoping & this could appear to a client like they are getting less than paid for.

Case Study Results:

Due to the client empowering us to define how to solve the problem we were able to produce a minimum viable product within the budget and timeframe.

Key factors in making this happen:

1. Co-location for first 3 days
2. A relatively small project 8–10 weeks which we were able to estimate on a task level in the first 3 days (this also helped us know what we could fit in and plan to deliver)
3. An engaged technical architect who worked directly with back-end developer on day 3 of kick off to define upfront the key ways the backend and frontend would communicate
4. Ownership of both the frontend (iOS & Android) and backend(using Vapor framework) & ability to use out of the box components
   We used many ‘out of the box’ elements on backend and frontend to get us going very quickly. Within 2 days we had basic sign up and login working.
   (If we had to wait on third party integrations or work in a different way our estimates would have gone out the window)

Reccomendation on when you can start a project without a design & discovery phase:

• When Nodes is commissioned to do both backend and frontend
  (This is unlikely to work when the client does the backend or we otherwise rely on a third party service)
• When the speed is the most important factor
• When the client is willing to entrust Nodes to define the how of the solution (e.g. their requirements are not extremely detailed, they are top level) — this could also be described as: ‘The client has some level of buy in to agile methodology’ — e.g. They think ‘anything’ is better than nothing & that products should be iterated on based on customer feedback

In this approach the client is very clearly purchasing a team for a period of time rather than purchasing a set of features, this is in-fact always how we work, however often the expectation from the client is that they are buying a feature, and this misconception can be compounded if all the details of the feature are defined before starting any development.

Some key take-aways:

1. Embracing agile principles with less upfront specification empowers the time to deliver something that gives return on investment within the time and budget you set. (We already knew this, but this was just another example of it proving true)
2. Co-location massively speeds up and improves quality. Without our 3 days co-located kick off, we could never have planned & executed a product to meet the budget. Working remotely is often necessary, but more misunderstandings occur and lots of time is lost due to these misunderstandings, so the more time your team can be working in the same room, the more you’ll reduce your risk.
3. Forming a cross-functional scrum team & giving them decision making power (with a guiding star brief & defined success criteria) means you can move really fast. If you have a development partner or team that you trust it’s 100% the way to go.

Indlægget Agile in an agency setting — Things we’ve learned at one of London’s leading app development agencies blev først udgivet på Nodes UK.