How to Become Agile — An Agency Guide
Creating Ideal Conditions for Agile Client Projects
This article is also available in German.
Over the last few years, “agile” has become an increasingly popular buzzword in the agency scene. There is barely a single company that doesn’t profess to work agile. But what does it actually mean? How can one tell how agile a company really is? If one’s working in sprints, does it mean one’s already agile? (Answer: no.)
At Aperto Move, we have constantly analysed and refined our working methods in the last two and a half years, pushing our vision of agile in the workplace forward. One of the most irrefutable realisations has been that the transition to agile requires both time and experience. One can’t just make the switch to agile. While we are not yet where we would like to be, the improvements are clearly noticeable.
Applying agile methods in an agency is altogether more difficult than, for example, in product development; as one creates products for different clients, where conditions can vary drastically between projects. Therefore it is hard to believe that every agency suddenly seems to be agile. Luckily there are factors that can help to determine easily how far a company has come on its way to becoming agile.
The advice presented in this article is based on scenarios common for most agencies, which have arisen in our daily work and were resolved, once we identified them as problems. They are no cure-all solutions, but rather a collection of learnings which work best for us.
1. Clarify the terminology
When introducing agile, it’s crucial that everyone in the company has the same understanding of the term, otherwise one runs the risk of dangerous miscommunication. I have encountered people who mistake the agile approach as forgoing all concept phases, planning and regular meetings in favour of plunging straight into a project and seeing what happens. It’s not hard to imagine that such a project was anything but easy-going.
Others have simply heard of “Scrum” and harbour a certain reluctance towards it, dismissing it as “something for developers” that stifles the creative process. For the most part, these statements come from people who themselves haven’t explored Scrum or agile methods. Additionally, those who aren’t familiar with it, often can’t tell the difference between agile and Scrum, and classify them as one and the same.
Scrum and agile are not the same
Scrum is a framework which defines specific rules, roles and working processes to develop software. One example is the definition of time intervals in which a working product is delivered (so-called sprints). The implementation of Scrum contributes to agile software development, which is why the terms are often seen as synonymous, but they aren’t.
“Agile”, on the other hand, is a way of thinking or culture, that encapsulates a lot more than purely what Scrum does. The principles that define the agile culture are stated in the Agile Manifesto and are pictured in the following video:
Scrum is only one possible approach to follow the agile principles. One can also be agile without using Scrum. On the other hand, just because one adheres to the rules of Scrum, doesn’t mean one is actually working agile.
2. Bid farewell to the project manager role (say hello to agile roles)
In Scrum, the following roles are defined:
- Product Owner
- Scrum Master
- Development team
- Further stakeholders, such as the end user or those involved on the client’s side
There aren’t any other roles, nor are they necessary. The classic project manager is no longer required in this setup. He would only hinder the process, as all tasks previously conducted by the project manager are now covered by the positions listed above. The responsibility for the project’s success no longer rests on one person, but rather on the whole team.
Each additional role that exists in the project — and stands between the Scrum team and the client — is an obstacle to the direct and effective communication between the team and the client.
Take roles and responsibilities seriously
If one doesn’t need a project manager, wouldn’t it make sense to employ previous project managers in a combined role of Scrum Master and Product Owner?
No. On one hand, both the Scrum Master and Product Owner roles entail enough tasks that to execute both would result in the neglecting of one of the roles. Ultimately, the two roles have contradicting interests. The Product Owner remains in constant contact with all the stakeholders and ensures that the right product is delivered in the best quality. Amongst other things, the Scrum Master has to make sure that the team isn’t overworked or interrupted. Hence, the Scrum Master has nothing to do with the product itself.
An even worse idea would be to omit the Scrum Master entirely. Without an acting Scrum Master, there is no role to ensure that the team works productively, meets deadlines or learns through retrospectives and becomes more efficient. In short, they are the ones that guarantee that the project is conducted in an agile way. In our experience, it is a particularly important role in an agency environment with changing clients, stakeholders and conditions, because the Scrum Master also takes on a coaching role for the client.
This article explains the different functions of the Scrum Master and the classic project manager in terms of an easy-to-understand traffic analogy:
3. No more resource planning (establish the pull principle instead)
In agencies, multiple projects for various clients are often worked on simultaneously, making the effective distribution of work among all employees a challenge.
The classic agency approach is resource planning: a project manager creates plans for several days or weeks ahead, and assigns employees to projects or tasks respectively. This requires a lot of time for planning and coordination and results in inflexibility, as it functions on the assumption that all projections and plans for the allocated time are met.
Experience teaches us that, in reality, such plans never come to fruition: an important delivery is delayed, employees get sick or other unforeseen circumstances arise, which lead to individual tasks taking longer than expected. The consequences are an uneven work distribution among colleagues, more stress and overtime.
This so-called “push principle” (because employees have single tasks “pushed” upon them) is therefore not optimal. So, how is work distributed without a project manager in the agile constellation? This issue requires a different approach:
The pull principle
Agile work is based on a “pull” mentality. This means that employees proactively decide which tasks they want to take on. In order for this to work, upcoming tasks and their progress need to be transparently communicated.
In an ideal situation, this doesn’t only occur on the project level but for all upcoming tasks within the company. This includes scope assessment, creation of presentations, preparation of workshops, participation in interviews or even the writing of this article. This can be accomplished with a Kanban board, for example:
The pull principle helps to ensure an even distribution of work among employees where everyone has the freedom to decide independently, when they have the capacity to work on their tasks. This helps to eliminate the possibility of overworking certain employees.
In order for the pull principle to work, the following conditions must be fulfilled:
- Constant communication is crucial. At Aperto Move, project status is discussed three times a week at the board
- It requires people with the capability to take the initiative rather than waiting for others to tell them what to do
- It favours flat hierarchies and requires a willingness to implement them
- The company management needs to have trust in their employees to enable them to take on more responsibility
- There needs to be a clear differentiation between individual tasks and projects. Projects aren’t pulled by a single person, but by a team. This will be explored further in the following section.
4. Establish stable teams
It is typical in agencies to work for various clients simultaneously and urgent tasks (such as scope assessments, pitches or bug fixes) often arise at short notice. Therefore project teams are often created according to current availability. This type of resource planning effectively prevents agile projects.
Agile teams should be stable and ideally find themselves. Only close teams can develop optimally and sustain or even accelerate their pace by learning from one another, coordinating their processes and communication, and identifying and solving problems through retrospective analysis.
In order to avoid disrupting effective teams of colleagues who work well together and thereby eliminating all learning and routine effects, upcoming projects should not be planned with individuals in mind, but rather with stable teams.
However, it is unrealistic to think that the transformation of an entire agency with all disciplines into stable and balanced teams can happen overnight. It is conceivable that not everyone wants to work permanently in the same team. Thus, it is crucial to find a balance that works well for everyone.
5. Create agile proposals
A classic, simplified proposal phase between clients and an agency usually takes the following form: A client has a specific idea for a product and a timeline as to when it needs to be finished.
The client then briefs the agency on the requirements (maybe with a pitch) and asks for a proposal specifying a fixed price for the development of this product. In order to protect themselves, both parties spend a considerable amount of work to elaborate the proposal to avoid potential miscommunication.
From the client’s perspective, this usually seems like a viable solution: they know what they’re getting when and at what price.
Requirements change
What most clients don’t know at this point is that they often want something very different by the end of the project as they did at the beginning.
Since everything is concretely defined in the proposal, it is then close to impossible to change something within the project later on without renegotiation, such as:
- other features became more important in the meantime
- the desired project is no longer technically feasible
- user tests revealed that the product is misunderstood or that it doesn’t make sense
- a competitor has created a similar product which necessitates a strategic pivot
In this case, a re-prioritization is not easy if the old, revised scope is specified in the proposal.
Other major aspects of being agile are undermined by this type of proposal. A continuous, collaborative improvement of the product is much more difficult, as the product has to be clearly defined in the beginning to finalise the proposal. This leads to a typical waterfall workflow. Sprint planning, including planning poker, becomes equally pointless because a final deadline and deliverable have already been defined.
If the scope, the deadline and the price have already been set at the beginning, it no longer makes sense to try and implement an agile framework such as Scrum.
In this case, one can no longer use the main advantages of agile delivery, but still has an extra expense of Scrum meetings which don’t provide any real value. This process is also referred to as “pseudo Scrum”.
Another type of proposal is needed
It makes more sense to charge for the amount of work performed (so-called time and material contracts) rather than define the exact deliverables in the proposal. Only then is it possible to execute a project in an agile way.
How much and what the client gets for his money is determined by himself during the course of the project, by keeping the list of requirements up-to-date and prioritized together with the team.
In order for the client to get an idea as to what he can expect, one can give a rough estimation of how much is achievable in a given time frame, or how long it will take until a certain requirement will be implemented. The longer a team has worked together, the more precise this estimation becomes, since it is easier to gauge the general pace or “velocity” of the team. This is another reason why it is preferable to work with stable teams.
That being said, drawing up a proposal is still one of the most difficult elements of the agile transition. Hardly a single client who hasn’t already gathered experience in an agile environment, wants to sign an open-ended contract. To convince them of its merit, it is vital to demonstrate skill and to build trust with the client first.
In our experience, this challenge is easily overcome as soon as one has completed an agile project together. It is then that the project process speaks for itself; yielding quick and tangible results through iterative work, close collaboration and shorter feedback cycles, that are much closer to what the client envisioned than they would be in typical waterfall projects.
There is a lot of helpful literature available on the subject of agile proposals such as this book:
6. Involve the project team in the acquisition phase as early as possible
In agencies, the acquisition and proposal phase is often isolated from the project implementation. A new business team is responsible for new projects and the project team isn’t confronted with the details until the implementation phase, raising the probability for conflicts.
The proposal phase can already be crucial in establishing whether or not a project will be successful. It is therefore essential that the agile team is included in the communication as early as possible.
As a result, one can assess relatively early if an agile implementation is viable and how much time can be expected for it. The time expenditure, e.g. the number of required sprints in a scrum project can only be assessed by the team itself, if it knows as much as possible about the project.
Occasionally there will be more project requests than there is capacity to work on them. In order to implement the pull principle and to select the most suitable project, the team needs to know as much as possible about all pending projects. Only then can they can make an informed decision and meaningfully incorporate new projects into sprints of current ones.
When the new project begins, the team should know all the stakeholders and their requirements as early as possible in order to deliver the right product with the best possible quality. One effective measure to achieve this is to hold a workshop with the team and the client-side stakeholders.
Additionally, it is important to communicate the agile values to the client, to identify the primary contact person and to explain the collaborative procedure in detail.
7. Forget the service provider role (and work as a team with your client)
A client / service provider relationship is counterproductive as it is always based on the premise that the client has awarded a contract and expects a specific result. A successful project result, which satisfies all parties involved, usually requires work from all sides, in particular regular communication with one another.
An essential prerequisite for a successful agile project is communication on the same level. This means that the client and the agency regard one another as a single team, working jointly on a project and identifying and appreciating each other’s strengths. The agency is usually the expert in strategy, user experience, design and technical implementation; the client, on the other hand, is familiar with their own internal processes and requirements as well as their target audience. Only when this information is shared, can one create a truly user-oriented product that satisfies all stakeholders.
This requires that there is an appointed contact person on the client side, who is available to answer questions regarding the project or can provide the agency with any missing material. Not every client can or wants to invest that much time into a single project because their own internal work processes don’t allow it.
In our experience, clients usually notice at an early stage how much faster they get high-quality results through agile cooperation. This corresponds to their expectations and they are willing to invest the time.
8. Provide space for teamwork
Being agile means working interdisciplinarily and with continuous communication. This works best if the agile team sits together, which helps to easily coordinate their work. Ideally every team should have its own space where they can work undisturbed while minimizing disturbances for others, e.g. when designs or features are being discussed.
Agencies often paint a different picture: the grouping of employees according to their respective disciplines. This means that all designers sit in one corner of the office, developers in another corner, and testers and account managers often in different rooms altogether. Although this might make sense in terms of discipline-related exchange, it complicates communication within a project team. Writing each other is a possibility, but it takes much longer than speaking directly to one another.
It gets even more difficult when all team members aren’t in the same location. Everyone knows how bad phone or video conferences are, and if you haven’t had to suffer them before, this video is recommended:
9. Consider every discipline and the complete project process
As Scrum was born from software development, it may seem convenient to only execute the technical aspect of the project in an agile way, leaving the creative phase untouched. This however achieves relatively little, as the waterfall structure is then only resolved at the end of a project.
Let’s assume the agile team is made up purely of developers; the concept and design of the client website is already complete, but in the middle of development it becomes apparent that important states haven’t been defined or designed and the creative team is already engaged in their next project. What now? Should one take people off other projects? Continue to develop an incomplete product? There is no easy answer other than involving all relevant disciplines in the agile workflow from the beginning.
Feedback, Feedback, Feedback
A huge strength, and an important reason why the quality of agile-developed software is better than that of waterfall projects under classic project management, is the interdisciplinary collaboration and iterative improvement of products based on early and regular feedback among all stakeholders.
Put simply, this means: everyone reviews everything in every phase of the project.
- The client and the entire team give the Product Owner (PO) feedback to the user stories
- UI designers give feedback to wireframes and technical execution
- UX designers give feedback to user interface designs and technical execution
- Front-end developers give feedback to wireframes, user interface designs, to backend interfaces and, where applicable, the backend implementation
- Back-end developers give feedback to wireframes, user interface designs and front-end implementation
- The quality assurance (QA) gives feedback to wireframes, user interface designs and technical execution
- Users give feedback via usability tests throughout the project phases (wireframes, design prototypes, click dummies, front-end implementation)
- The client gives feedback to product increments during sprint review meetings
Regular feedback is the most important asset in agile development, and ensures that the product is developed at a level that satisfies all stakeholders. Naturally, this only functions when everyone is involved in each project phase.
10. Don’t expect everything to work immediately (make mistakes and learn from them)
Hopefully the previous sections conveyed that, on several levels, it is necessary to take different approaches to the ones that have probably been developed and established over years. This makes it all the more important to understand that the move to becoming agile is a process, and not necessarily an easy one, nor one with a defined end.
The implementation of the measures discussed above doesn’t automatically guarantee the transition to being agile. Similarly, it isn’t enough to only implement “technical” aspects, such as the adoption of Scrum. It is much more essential to change the company culture and establish a common, agile value system on all hierarchical levels.
It would be naïve to expect that such fundamental changes could be accomplished instantly and without a hitch. The changes in the company processes can also be treated as an agile project and rolled out iteratively.
Ultimately, this means one shouldn’t try and change everything at once, but rather implement one measure at a time. In this manner, one learns what works, what doesn’t and what can be improved. It would be wrong to stick to one measure that doesn’t feel right, just because a book or blog has recommended it.
External coaching can be equally helpful in initiating the right thought processes, however one can’t hope to find a quick-fix remedy, which makes one suddenly agile.
It is equally important to establish an internal exchange of knowledge and experience and to agree on a common approach. In order to achieve this, it is helpful to take a regular look at the twelve principles behind the Agile Manifesto and review to what extent one’s company has already adopted them:
In our team, the strict adherence to the guidelines of the Scrum framework has proven the best solution. Every time these processes were deviated from, it led to complications and more effort. That however doesn’t have to be the case with everyone. Each company needs to discover for themselves what works best.
Conclusion
Even before a client project begins, certain standard agency conditions can jeopardize or even make the success of agile projects impossible. This is where a new way of thinking is required on all levels and across all disciplines, which implicates changes which can not be implemented overnight.
The points made in this article can serve as a guideline to recognise and discuss situations and problems in the planning of agile projects, before they begin.
What are your experiences on this subject? Do you know other circumstances that make agile processes difficult? Let us know in the comment section of this article.
Further Reading
Aperto Move — An IBM Company is a Berlin agency for digital and mobile services with around 30 employees. How about you?
Follow us: apertomove.com / Facebook / Twitter
