You are part of a team delivering software. At some point, it becomes clear that you need a process to increase your productivity and/or delivery. So, you pick an agile approach “M” and start using it. It is your first attempt to try the agile approach. You modify the process because not everything makes sense to you. Can’t wait to get started and see its benefits…

After a while, you don’t understand the hype around “M”. It seems to add more meetings and unnecessary work without any benefits. You and your team agreed that “M” wasn’t the right choice. You replaced it with “N”. After some iterations, it’s clear “N” isn’t any better. At that point, you may either stay with your version of “N” (probably mixed with “M”). Or you can try luck with another agile approach “O”. Or, you reject the concept of the agile process as unnecessary corporate stuff and continue in the organic process as you always did.

Have you ever been — or even still are — in a similar situation? Well, then I dare to say you were somehow sentenced to fail from the very beginning.

In this post, I will share my experience of why failing to start with an agile approach lies much more in the way you implement it than in the approach itself. I was personally doing it wrong, too. And later, observed other teams following a path similar to the one mentioned above.

Ready to give an agile approach one more try?

Agile approaches work. Period.

Admit it. Using an agile process does work. It does improve the team’s delivery.

I have direct, personal experience with several teams and projects. And observed many more. But, you may not find my personal experience solid enough argument. Valid point 👍

I listed several papers about the impact of agile methodologies on team delivery at the very end of this post. Consult Google or Consensus for more.

Note 💡
Although agile approaches are mostly used in context of software development, their principles are mostly universal and can be well used in different fields.

Six Common Mistakes when starting with agile

The most Common Mistakes I observed — and done myself — when starting with agile:

1. Not having a single person taking care of the process.
2. Not everyone on the team has committed to the changes.
3. Adding an agile process while keeping a non-agile way of thinking and/or working.
4. Modifying the process before you fully understand why it is that way.
5. Switching/leaving the process before it has time to settle and bring value.
6. Believing you are doing it right while you are not.

Let’s look at each of these in detail.

1 — Not having a single person taking care of the process

It requires non-trivial knowledge, skills, and experience to take care of your agile process. But too often this responsibility is assigned to already busy members like team lead or lead engineer. It seems to be easy. Not a serious business. These people are usually quite capable and weak at saying “no”.

2 — Not everyone in the team has committed to the changes

You will never push any change against the will of the team. You may try so and all you get is more or less apparent push-back. If you are lucky, it will take some form of open aggression (like loud disagreement, I don’t mean any physical one). If you are not, prepare for quiet quitting or similar torpedoing collective effort.

3 — Adding an agile process while keeping non-agile way of thinking and/or working

Being agile doesn’t mean adding some ceremonies (meetings) and artifacts (documents). Most agile approaches pivot around the concept of doing small steps and — that is essential — testing whether it is on the right path. If not, discard it and start again with the knowledge you just gained. In other words… fail-fast.

4 — Modifying the process before you fully understand why it is that way

While developing, I follow the rule “Not delete something you don’t understand”. It applies to new process onboarding, too. You may think some parts of the process just require too much effort or are not really necessary at all. Unless you are experienced with the methodology, don’t remove or modify anything. You don’t yet fully understand the reasoning behind. Early modifications may cripple it.

5 — Switching/leaving it before it has time to settle and bring value

Adding a new or changing an existing process to boost your productivity will, in fact, decrease your productivity in the short term. It will introduce something new requiring your attention and focus. Both are rare resources. Only once you get used to it and it becomes natural, you get the deserved productivity boost.

6 — Believing you are doing it right while you are not

If you lack any former experience with how it should be, you may think that you are done long before you actually are. Because you lack a reference point and experience with what is possible. So you may think what you have is all and it can’t get better.

There are definitely more things you can do wrong. But these are the most common I observed so far. So, let’s look at how to prevent them and/or how to approach them better.

My understanding of agile methodologies changed dramatically after I joined Datamole and was lucky to work with project leads knowing their job. Not only do they use it at work, but they spend their free time with Agile, too. To create posters like this one:

Before my experience with project leads at Datamole, I knew well what it means to be agile. In theory. In real life, not so. And in some way or another, I made all of the Common Mistakes mentioned above.

Implement it the right way

The most common reason behind failing when implementing the agile approach I observed — and one I did myself — is simple.

You try to implement something you have only theoretical information about. As a newbie, never experienced how it should look practically, on a daily basis. You only read or hear some theoretical information, both are often too abstract to grasp right on the first try.

To be more specific: let’s say the agile approach you want to implement says you should hold short, daily stand-ups to keep everyone up-to-date. So, you do. But how do you know you do so in the right way? What if you soon start to feel the meetings are just a waste of time and everyone hates them? Well, it only tells you that your approach to it is the wrong one, but doesn’t tell you much about what approach is the right one. You can iterate by tweaking it. But that is hard because it costs time and energy and you are likely not to have enough one or the other.

How to do it

The right way to implement an Agile methodology is simple and I would split it into the following steps:

1. Do not underestimate it in the first place.
   Any approach you take to organize your work effort — agile included — is a non-trivial discipline that requires certain hard and soft skills and experience. It should not be seen as just another hat on someone’s already crowded head. Otherwise, you just got trapped in the Common Mistake #1.
2. Have somebody who knows by experience what the process you want to onboard looks like. If not, you are risking Common Mistakes #4 and/or #6.
3. To get some gains in return from it, prepare to invest something first. Leave early is basically a Common Mistake #5.

For example, the Scrum methodology requires the presence of a Scrum master not by accident. It is the person responsible only for the Scrum implementation in the team and organization. Not the project, backlog, or whatever else… just Scrum.

But even though you do not follow Scrum strictly by book, you need somebody who already experienced the process to help you onboard it. If you can’t have such a person as a team member, try at least to find someone to coach you. Without it, you may have a hard time challenging all the six Common Mistakes mentioned above and without personal experience, you can’t ever be sure what you have is the desired state or whether there is still a place for improvement.

Real life example

I will briefly describe how teams at Datamole approach agile principles. You can take it as an inspiration but definitely don’t take it as the only nor right way. It is just “our” way, your may be — and likely is — more or less different.

For all phases, we use Jira as a project management tool.

Early phase of a project

When a project starts, the main focus is usually on gathering requirements, analysis, and design. The customer is strongly involved which means plenty of back-and-forth emails exchange. On our side, the most involved is the project lead who is supported by analysts or lead engineer when needed. The scope is unclear as well as the timing. You never know how quickly customer answers your questions as they are often non-trivial.

In this phase, we follow the kanban-like approach. On the Kanban board, there is a backlog with prioritized issues. Nothing unique here. If you are not familiar with Kanban, check for example Atlasian's documentation.

There are just a few ceremonies here. Usually just syncs of involved stakeholders on our side. They are regular so not forgotten, but it may happen that there is nothing to discuss on the sync. No plannings, nor groomings, nor retrospectives. The project lead is the only point of contact with the customer. Others — like architects or lead engineer — are involved whenever we believe it will bring some value.

This phase may take from weeks to months, depending on complexity, priorities, and (customer’s) time availability.

Main phase of the project

Once it is mostly clear what the project is about, the scope for the first milestone is defined, known unknowns are identified, and questions answered… the time is ripe for switching sprint-based approach.

This is where the whole development happens. Our process is inspired by Scrum and was modified to fit our needs. We were safe to do so as our project leads have plenty of experience and understand why Scrum by book is defined the way it is. This understanding allows them to safely modify the process for the sake of the project, not only to avoid something poorly working because of wrong implementation. Common Mistake #4 addressed.

So, our modified Scrum is typically two weeks long, starting with planning and ending with a retrospective. Before planning itself, some issues may require separate grooming sessions so they can be estimated. Quite often, grooming identifies blank spots in a task specification. So, instead of the task itself (let’s call it task A-123), the sprint involves a new task “Specify <something> in A-123”. In other words, you want to avoid planning tasks for upcoming sprints if the tasks are purely specified or lack some prerequisites (answer from the customer, data, API implemented, or at least specified…).

Dammed daily stand-ups 🤯

And what about the Daily Scrum (or stand-ups)? These are probably the most common sources of developers’ frustration caused by meetings. Daily stand-ups really are a waste of time too often. But they don’t need to be.

Daily meetings should basically ensure information flow within the team and clarify the progress of work made recently aimed towards the sprint goal. It is nothing hard in theory, but in practice, you may observe:

1. Developers feel like they already have all the information, forgetting there are other stakeholders.
2. Participants came unprepared for the meeting, trying to figure out what they work(ed) on since the last meeting.
3. No one moderates discussions that shift out of meeting scope. Like when the discussion turns into implementation details of some feature instead of sharing progress — these discussions should become a separate meeting (or, an email).

As with anything else, having a personal experience in properly holding daily syncs helps you get over most of the issues. Usually, just returning the meeting to its agenda whenever it shifts away can be a leap forward.
Motivating participants (especially developers) to show up prepared is the hardest part to achieve. You are in threat of Common Mistake #2 unless you keep explaining (and showing) why the preparation matters.

Asynchronous daily stand-ups

I guess this may sound like a heresy for some Scrum advocates, but we have good experience with breaking (the Scrum) rule “daily Scrums should take place at the same time and place every working day”.

As mentioned several times, tweaking methodology is fine as long as you know what you are doing and you have some mechanism (eg. regular retrospectives) helping you evaluate that your modifications are bringing more good than harm.

How it looks:
we have one separate chat space (thread, group… whatever your tools support) for each project utilizing asynchronous syncs (we call it async-syncs). Each developer actively participating in the sprint should write at the end of his/her working day (working till late at night? no problem) their progress with a focus on:

• blockers
• expected or happening delays
• anything that other developers should be aware of (a new common function, env variable that needs to be set on the local environment, …)

The one who writes an update first starts the comment with the current date and others add theirs below.

The next day morning, everyone has one place to find all relevant information. Starting your work day later than others? Covered! Just returned from vacation and need to get up to speed? Covered, you can check all updates happening when you are away. Forgot some information? No need to disturb colleagues, just search for it.

We use async-syncs in calmer periods of development. Meaning, that there is no risk of running out of resources (time, money, …) or no complicated feature is being implemented. Or, when developers are assigned to another project at the same time. This approach works best when the team is used to working together and requires a certain level of personal ownership as it basically moves the responsibility of daily stand-ups from the project lead to every individual developer.

Late phase of the project

The phase of maintenance or polishing the app once it was successfully released and all discovered bugs fixed. Here, we usually leave sprints and return to kanban as in the early phase. And we stay there until some new feature requiring significant development is requested.

Conclusion

Agile approaches will increase your delivery only when you implement them and fully utilise their potential. The ideal way of achieving this is to have an agile expert as a part of your team or — at least — coaching you. You should focus on involving the whole team by explaining why being agile helps them and listening to and addressing their concerns. Onboarding an agile approach may be a bit bumpy from the start and actually lower your productivity in the short term, though. Take it into account when planning. And be patient, if you feel like quitting because you see no benefits. Reach out for some advice first. It is not a good idea to modify the process unless you really know what you are doing. But once you know, feel free to tailor the process to fit each team, project, and phase of the project. You don’t have to stick with one set-up during the whole lifecycle of the project.

And, never omit retrospectives. When held properly, they are essential to keep your process sharp and beneficial over time.

...

‍

Some resources about benefits of agile methodologies

Pragmatic programmers are agile:
The book Pragmatic Programmer advocates for practices that are foundational to Agile methodologies such as early and continuous delivery, openness to changes, close collaboration among stakeholders, simplicity, team members involvement. (Mine own notes from the book; not a direct quotation)

Increased Development Productivity:
Agile methods promote a working environment that prioritizes the delivery of functional software, encourages continuous improvement, and supports rapid iteration. This approach results in enhanced productivity and efficiency in the development process. (Domann et al., 2014)

Higher Quality and Faster Time to Market:
Agile methodologies, through their iterative cycles and emphasis on customer feedback, can lead to the development of higher quality software that better meets user needs. Moreover, the agile focus on delivering working software in shorter cycles can significantly reduce time to market. (Mahanti, 2006)

Project Success Improvement:
Agile methodologies positively impact project efficiency and overall stakeholder satisfaction. Their emphasis on flexibility, customer collaboration, and responsiveness to change leads to higher project success rates. (Serrador & Pinto, 2015)

Enhanced Trust and Collaboration:
Agile practices foster trust among team members by empowering them to manage their work, which leads to improved project outcomes. Agile’s focus on collaboration and self-management supports a positive team environment. (McHugh, Conboy, & Lang, 2012)

Improved Management Practices:
Agile methods have been shown to enhance the management of development processes and customer relationships, leading to better project outcomes and satisfied customers. (Ceschi, Sillitti, Succi, & Panfilis, 2005)

Increased Job Satisfaction and Motivation:
Agile methodologies contribute to higher motivation and job satisfaction among developers by ensuring autonomy, variety, and feedback, which are crucial for worker motivation and satisfaction. (Tessem & Maurer, 2007)

‍