How to be Agile
If you follow our posts, you already realize that Agile is rather a culture than a process, which at some point, also means a complete shift in behavior, collaboration fundamentals, delivery means, and also roles. It might sound like forgetting everything you already knew and relearning from scratch… Which indeed can sound frightening… But don’t get too scared yet. Today’s changing world made us way more agile than we think we are…
Interested to know how agile you already are? Feel free to take our quiz (add link) to find out! You can read more about how to be agile in our “How to get started with Agile” (add the link to the corresponding post) post.
How not to be Agile
Often, talking about new skills and unfamiliar ways of doing things makes people concerned about their job security, and the necessary effort and money required to learn new things. If that is what you are worried about, too, then you will be happy to know that many existing capabilities are easily transformable and transferable to an Agile environment.
That said, to become truly Agile, there are also lots of things that you should unlearn, including having a fixed mindset, inability to adapt quickly, not being curious, and focusing on yourself rather than being a team player.
We are in an era where we generally need to continuously learn and unlearn many things. Agile is all about having an insatiable hunger and desire for continuous learning while being capable to adapt to the one and only certain thing, change.
You may find the principles of the Agile manifesto on the official website.
We think that learning from negative experiences is as important if not even more important than success stories. Considering that, let’s talk about how to fail Agile!
Focusing on velocity instead of value,
Speed of delivery can be considered as a metric to measure success. Considering velocity growth as a performance indicator can make managers oversee the delivered value.
You probably already noticed that this is against the first principle defined in the Agile manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
At the end of the day, it is not important how fast you are if you are not moving in the right direction! Actually, if you are going wrong, it might even be beneficial to go slower…
No changes in backlog
Planning is indeed important in any project, yet requirements and needs can change rather quickly in the real world, which makes sticking with a fixed plan irrelevant.
A sprint backlog shall never be immutable. It is vital to continuously monitor and assess how relevant the backlog items are. This is also defined as the second principle of Agile:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Not keeping backlog and sprint items granular enough
Keeping tasks and todos in large chunks instead of breaking them down into smaller pieces slows down the customer feedback loop. This, in turn, affects the value delivery, as customer needs can change while the team is working long hours on delivering a complex set of features, rendering them irrelevant by the time of delivery.
This is all about the next principle:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
Not keeping business and software development aligned
Keeping product owner and development people in separate teams? This increases the risk of technical teams building software that is not what product owners want.
To mitigate this risk, Agile suggests the following principle:
Business people and developers must work together daily throughout the project.
Micro-management
Do you always want to be informed about who is doing what? Closely monitor the burndown chart and instruct team members on how to get things done? Does it sound like something you do? If so, we will definitely need to work on it.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This is about being people with people, serving them, and creating an ecosystem that fosters healthy culture, trusting and empowering team members to deliver their best in return.
Discouraging direct, real-life communication
The principle defined in the Agile Manifesto encourages face-to-face conversation for a reason:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
Written communication through chat applications or emails makes it more difficult for people to express themselves, clarify issues and remain on the same page. Team members only monitor their email occasionally, and they often prefer focusing on other things, such as making things work.
Face-to-face communication enables better understanding and collaboration and also fuels creativity. It is impossible to ever overestimate the power of conversation.
Prioritizing feature delivery
When you focus on delivering more and more features in a limited time, it will often result in buggy performance or software that is not doing what it is supposed to do.
Working software is the primary measure of progress.
The focus should be on delivering a quality product that actually works.
Pushing the team, getting them overworked to deliver sprints
Always want to push the limits further and bend the team to make it? While possible from time to time, it can only be sustained for a short period. Team members will burn out, and productivity will decrease.
Remember:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
It is important to work with the team to find a sustainable pace that will be possible to maintain. This will enable delivering better quality products and value delivery.
Taking shortcuts
Skipping code review? Spending less time on testing? Might sound compelling, especially if you are focusing on delivering more items in less time… Yet you can be sure that in the long run, it gonna backfire.
Continuous attention to technical excellence and good design enhances agility.
You gonna do more harm than good if technical excellence will not be a priority. This is all about having a more maintainable application and good architecture, which will require less work in the future to scale.
Not focusing on reduced complexity
Less is more, especially when simplifying solutions. Providing simple solutions actually require more knowledgeable and experienced architects.
Interestingly designing complex stuff can require less time and effort, yet it can take forever when it comes to implementation. Increased complexity also makes it more difficult to maintain the code.
Simplicity — the art of maximizing the amount of work not done — is essential.
Skipping the unnecessary and focusing on the most important and valuable at first is an art. Prioritizing work items and delivering them starting from the highest will always ensure that the team is working on delivering the most value in any given period throughout the project lifecycle.
Don’t promote autonomy
Strict processes and not considering dynamics between team members will not allow them to find ways letting them to best do their job.
The best architectures, requirements, and designs emerge from self-organizing teams.
Trust your team; they certainly understand better how they can work more efficiently. This will also promote ownership of the processes and results among them, increasing commitment levels and motivation.
Don’t learn from what went wrong
You feel like retrospectives are rather a waste of time? Then you probably are not doing it right… Remember when we were talking about unlearning and relearning? It is all about looking back to see what was done good, what went wrong, and what could have been done better… Learn from mistakes and avoid making them again in the future… In other words, do not avoid spending time on retrospectives!
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This is another principle that ensures continuous growth and moves the team toward excelling in value delivery. As Gichin Funakoshi, the founder of Shotokan karate-do, says, “To stand still is to regress.”.
How do you relate to the mentioned 12 points? Isn’t it much easier to be Agile than you initially thought so? We actually think it can be more fun too! As it’s all about being human-centric and dynamic instead of strictly process-centric and boring!
