--
Our clients are happy with creative and innovative thinking. A conceptual mindset and original ideas must be at the core of what an agency like us offers. However, the nuts-and-bolts of project delivery must sit alongside this creative and technical output.
Ultimately, we must get stuff done.
With multiple dependencies, complex technical requirements, and ambitious client goals, it can be tricky to streamline delivery. This is why project management frameworks are important. Every project is unique in its own way, but processes must be applied to get the job done.
At Lab Digital, we favour elements of the Agile approach. Like many agencies, we operate using the Scrum framework: sprints, standups, retrospects, etc. This is effective, but there are nuances. We don’t follow a framework for the sake of it, and we’ve adapted the gospel to suit our needs.
As this article by Janko Hofman outlines, Agile is not simply a framework. It is a set of values, and a mindset. Of course, practical actions sit within Agile approaches, but it is not these that define Agile in themselves. The list of twelve principles behind the Agile Manifesto is essential reading. If you haven’t consumed these, I’d recommend you do so now.
Scrum, on the other hand, is a specific way of working. It is a set of rules and processes, which define how a product is built by a team:
“Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum itself is a simple framework for effective team collaboration on complex products.” — Scrum.org
The Scrum framework is one part of the Agile family. Other Agile methodologies include Lean and Kanban Software Development, Crystal, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), and Feature Driven Development (FDD).
Agile is flexible, by its very nature. However, no matter how flexible an agency wishes to be, it’s uncommon to have clients with a boundless scope, timeline, and/or budget.
Fully-fledged Agile won’t allow for fixed budgets.
However, Agile is a popular trend. For many clients, Agile equates to innovative. They still wish to work this way, even within said confines.
Any set of principles creates emotional idealism, and Agile is no exception. It can be seen as something pure and ultimate. Therefore, diluted versions of Agile (semi-Agile or part-Agile) are often not accepted by the evangelists. It’s all-or-nothing for some people in the industry.
As Alan Hohn outlined in his excellent article, it doesn’t need to be this way…
“I understand that for Agile advocates, it can be frustrating to see teams operate with “constrained” agile or “partial” agile, run into problems, and then see Agile get the blame. Unfortunately, I think that frustration is just something we have to live with; the cost of discouraging Agile adoption in cases where the program isn’t “pure” Agile is to discourage Agile adoption as a whole, and to convince people that Agile methodologies can’t be that great if they only work on unrealistic “perfect” programs.”
He continues, sensibly:
“So if we’re going to encourage the use of Agile, even in cases where the customer doesn’t intend to be flexible about scope or schedule, we have to face that problem squarely. Of course, the customer is giving up the ability to adjust and prioritise the work in response to more information. If that’s not a priority for them, we can mostly ignore it, though we might still want to try to pull them in as much as possible to see what we’re building so we ensure we don’t disappoint them at the end.”
Hohn outlines the many advantages of using Agile in this type of contract. These reflect our own experience at Lab Digital. He promotes the lower risk of continuous integration and testing, the easier staffing options, and the efficiency of using cross-functional teams.
Hohn also makes a number of suggestions for how to deal with the tension of Agile principles vs. fixed scope. He recommends using scope ambiguity in your favour, and keeping the Agile practices, but losing (or changing) the jargon. Critically, he suggests building personal trust:
“At the end of the day, the individuals and interactions are more important than our processes and tools, even Agile processes and Agile tools.”
The world says you must embrace pure Agile, but this doesn’t mean that you should. It is flavour of the month (decade), but to accept any set of principles as gospel isn’t wise. The truth is that every agency is different, because it has its own workforce and a unique client base.
How do we combat the tension between “pure” Agile and a fixed budget at Lab Digital?
We find a balanced way, using existing principles and frameworks as a guideline.
We standardise a lot of our infrastructure. This delivers the nuts-and-bolts of critical infrastructure efficiently, and sets the foundations for Agile development thereafter.
Clients want a solid end-point on a strict budget. Agile doesn’t offer this luxury, but in practice we can (and do) agree an acceptable “zone” of completion with the client:
The lowest acceptable end-point is the MVP (minimum viable product), and beyond this would be a more highly-developed product. Our definition phase is incredibly detailed, which allows the team to accurately predict velocity of work, and confirm the ballparks early with the client.
Echoing my earlier point, these “compromises” are easy when there is trust in the collaborative relationship between client and agency. Skill, consistency, and communication are all key.
Also see: Should you involve the technical team in early sales meetings?
We use sprints, retrospectives, daily standups, and refinement sessions. This is Scrum, but not all Scrum. It is Agile, but not pure Agile. The recipe evolves according to clients and projects.
To deliver with any sort of ambiguity, you need trust. Trust can only be built with integrity and consistency. You need skilled people to deliver accurate and timely work, and you need team leaders to forge a strong working relationship with clients. Frameworks don’t provide this alone.
Agile also relies on people taking responsibility. The Pull Principle is a leading component, and so agencies must ensure their workforce is proactively engaged. Scrum sprint planning is based on team members “pulling” tasks to tackle, rather than having them “pushed” by a hierarchy.
There are lots of frameworks out there, but none are tailored exactly to your needs. Focus on establishing what works for your agency and its clients.
For us, the detailed definition phase, standardised infrastructure, and collaborative client relationship helps us offer ballpark predictions. These are not set in stone, providing room for manoeuvre. Certain features of a product may be optional, for example.
As a result, we can deliver effectively using the Scrum methodology — operating in an Agile way without sacrificing client needs. There is still work to be done. We often underestimate user acceptance testing and go-live processes, which can have implications for billing. But we’ve found a rhythm that works, and our clients are happy.
—
Chiel te Loeke is a jack of all trades and Operations Manager within Lab Digital. He is fuelled by coffee, loves mountains and skiing and is always awake earlier than the birds.