What are some of the most important things we have learned about agile and how do they show in the way we approach our projects?
What are some of the most important things we have learned about agile and how do they show in the way we approach our projects? And why do we think planning by coding is usually a bad idea?
These days, everyone and their mother claims to use agile methodologies in their workflow. However, even though the basic principles of agile are generally agreed upon between its advocates, there is still much variance in just how they’re understood and applied to the actual work.
Simply put, what being agile truly means in practice depends greatly on who you ask.The purpose of this blog post is to shed some light on what we've found to be some of agile's most valuable lessons – and how our observations can be seen in the way we handle our projects.
Modern agile development has its roots in the Manifesto for Agile Software Development – a 2001 statement created by seventeen software developers in Utah. The original manifesto is in many ways a reaction to the clunkiness and non-adaptive nature of the waterfall methodology.
Here's a somewhat somewhat simplified explanation of the problem that agile as a working philosophy seeks to solve:In the waterfall method, the phases of the project follow each other in succession. First, we write down the requirements, then move on to design phase, followed by the implementation phase and so on. The problem with this approach is that it is a bit like a train, whose direction can be difficult to change midway through even if the situation changes.
Agile methods, on the other hand, emphasise working in smaller sprints that allow the results to be constantly tested and validated throughout the project. Essentially, the idea is to sacrifice some long-term planning in favour of being able to adapt and make changes to the product based on testing and feedback.The agile manifesto has spawned a great number of methods, all with their distinct characteristics – Scrum, Kanban & Lean, to name a few.
Interestingly enough, there are two statements in the original Agile Manifesto that, in some cases, may end up clashing with each other: “Working software is the principal measure of progress" and “Simplicity—the art of maximizing the amount of work not done—is essential”.
As anyone who has ever been involved with an IT project could tell, starting the actual coding too early on will most probably end up significantly increasing the workload. Planning by coding in itself is time-consuming – but most importantly, it is a much bigger task to make changes to code than to something that has been drawn but not yet technically implemented. Even seemingly small changes may sometimes cause programmers sleepless nights and cries of agony. What looks like a “minor tweak” can often require major changes when it comes to actually coding it.
To put it shortly, beginning the technical implementation prematurely will, in all likelihood, make things more complex in the long run and not vice versa. And with that being said: yes we do believe in writing code that is as flexible as possible. And by no means are we advocating a model where last minute changes are simply not possible. But, and this is a big but. Treating working software as the be-all and end-all means of progress can lead to situations where a tremendous amount of sweat and money has been spent to implement stuff that would never have entered the programmers’ task lists had there been a greater emphasis on thorough planning.
The ideas should be continuously tested both within the team and with potential users from the get go. But this does not, at this stage, necessarily require any heavy development work.
Of course, not firing up our development environments straight away does not mean that the first planning phase should be done in total darkness and without any external feedback. Quite the contrary: the ideas should be continuously tested both within the team and with potential users from the get go. But this does not, at this stage, necessarily require any heavy development work. The role of the developer in the planning phase is instead that of a technical consultant: he/she is there to evaluate the ideas from technical perspective and offer insight on what is possible within the budget, which technologies should be used etc.
The Agile Manifesto emphasises code because it was written from the point of view of software developers. However, building digital services includes other equally important aspects as well: although the service eventually has to be developed in order to exist, concept, service and UX design are by no means "lesser" measures of progress. The trick is to approach these aspects with an agile-influenced mindset as well – by working in sprints and constantly re-evaluating the work done.
We are of the opinion that careful planning is the way to go when creating digital products. At the same time, we strongly stand for the basic values of agile methodology: working in sprints, constantly communicating with the whole team and – most importantly – continuously collecting feedback and adapting to it. As of now, our design process is not tied to any particular agile method (although it is perhaps most heavily influenced by Kanban).
Throughout the design process, we emphasise creating user profiles and customer journey maps, conducting user interviews, surveys and test workshops. This allows us to validate the ideas from the very start, without necessarily writing a line of code until later on. In most of our projects, we use a variety of prototyping tools such as Flinto and Framer to quickly showcase new ideas for all parties to test and evaluate.
In the picture above, you can see the basic process template for our projects: we begin by immersing ourselves in the world of the customer and their clients (by using a combination of service design and research methods) and create an outline for the service. Our UX Designers then create models and prototypes which, again, are tested and re-evaluated by all parties. This is usually a good point in time to start the actual coding. Again, testing continues throughout the development phase and the subsequent learn phase. This is where we once again use research and analytics to start planning the next, even more refined version of the product.
For us, starting technical development too early is counter-intuitive to the agile mindset. Instead, we are of the opinion that at the end of the day, the key to successful agile development cycle is feedback. Feedback from the customer. Feedback from the team. Feedback from coders to designers and vice versa. Feedback from the end users. And when done right, this approach does not exclude meticulous planning – it encourages it.
