Agile in Practice — Actionable Guidance

Many companies think and claim they “do agile” instead of being agile. This phenomenon is called the agile theater.

In short, this means mechanically following ceremonies and practices in a way that was “adapted to our unique context” without real understanding. Often the hard parts, such as resistance of management, product or engineers, was the real reason for such adaptation. In these cases, it leads to waste and lack of agility while wholeheartedly believing the organization is agile.

An example is lack of feedback from customers — a company that is using Scrum, holding sprints with all the ceremonies but deploys to production twice per year.

The Agile Manifesto

The Agile Manifesto was created in 2001 in an attempt to alter the command-and-control, documentation-driven and heavyweight software development processes:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Read more about the 12 agile principles.

You probably know first hand of companies that believe they are agile, but heavily rely on process and tools or follow a plan that doesn’t make sense anymore.

Agile in practice — actionable guidance

The agile principles sound great and there are several flavors, such as Scrum, XP, Crystal and Kanban.

As a technical leader, how do you effectively implement these principles in real life?

By setting guidelines for the teams and keep repeating them. This is for example what Newstore did.

Things may be different when you deal with hardware or build spaceships. Even though many principles are still applicable, let’s assume you work in a SaaS company.

Engineering Practices

1. Continuous Integration/Continuous Deployment (CI/CD): Early on create automated pipelines to integrate and deploy your software. Such pipelines include linting, building, testing, security scans and other steps, which ensure rapid and reliable releases.
2. Automated testing: Implement a suite of automated tests. First of all to identify regressions, a safety net for upcoming changes, and also to improve code design, reliability and serve as documentation. Do not rely on manual testing efforts, which are more error-prone and cost-prohibitive. There are unit tests, integration tests, system tests with varying definitions. I recommend following Luís Soares posts on the topic.
3. Test-Driven Development (TDD): Writing tests before the production code forces us to know what we really want to achieve and improves design and code quality.
4. Pair programming: Collaborate in real-time to enhance code quality, skills, techniques and knowledge sharing. Pairing reduces the context switches, prevents waiting for code reviews and increases the bus factor. In practice, it means engineers, and when needed also UX or PM, pair by default on every story they work on.
5. Refactoring: Regularly improve the codebase to enhance maintainability and reduce technical debt. It is not about initiating a big “technical revision” project. It is continuous and ongoing, also known as the boyscout rule — leave the property better than you found it, often before you work on the actual change you want to deliver. A clean code, that is, a code that is easy to read and change, is faster and cheaper to maintain.
   While it is a bigger investment, encourage the teams to not only refactor, but also to re-architect for the ever-changing business needs. Keep evolving the system.
6. Observability, alerting, runbooks: have metrics, aka telemetry, in place, to know how the system operates. It’s way more than CPU, disk space and memory — it’s latency, traffic size, errors, cache hits and usages of business flows. This not only tells us about the health of the system but drives meaningful architectural changes.
   Alerting makes sure we know quickly when something is wrong or about to go wrong. We can respond swiftly when we have runbooks that explain what to do to resolve issues. Post-mortems and long-term solutions take place soon after the problem has been mitigated.

Ways of Working

1. Iterative development: Deliver work in small, manageable increments to gather feedback and adapt quickly. This is not only about code changes or pull requests — it’s about experimenting to validate business solutions and delivering to production over “projects”, which are usually defined and planned when we have the least knowledge. The smaller the change — the better.
   This includes “technical work” as well — any change like upgrading the database or changing RabbitMQ to Kafka has some customer benefit.
2. Customer collaboration: Engage with customers regularly to ensure the product meets their needs and expectations. What does it mean?
   We want the team to solve customer problems, needs and desired, hence, everyone talks to customers directly — continuous discovery. Not every member has to be in every customer meeting, but some do and it has to be frequent and meaningful — researching their problem, presenting a solution idea, demoing an initial solution and gathering feedback. This is important for both B2B and B2C with the aid of usage metrics.
   Working on ideas coming from management and demoing to the company have less impact because results are external to the organization.
3. Cross-functional teams: Form teams with diverse skills to foster collaboration and reduce bottlenecks. The team is then the unit of execution and does not rely on and wait for other teams to unblock them.
   This is a true “You build it, you run it” mindset — the team can do mobile, frontend, backend, infrastructure, data, testing, security, documentation, support, or anything needed to get the job done. DevOps culture and shift-left are good terms to describe such teams.
   The team has full ownership over the business domain and is best equipped to handle any task or question about it. It also has as few dependencies as possible and can run fast and adapt to ever-changing circumstances.
   This means that the team members must gain product mastery — know the customers, the use cases, and the benefits for the company. They cannot focus only on coding.
   While a separate backend team, frontend team, ops team and QA team are disappearing in favor of cross-functional or stream-aligned teams, the Team Topologies book mentions other types of teams when necessary.
4. Daily stand-ups: Hold brief daily meetings to synchronize team efforts and address any blockers. This is not a status report for the manager, this is for the team to focus, unblock and decide how to get things done for the day. Checking who needs help and revising the priority will ensure things are getting done, instead of starting new things and busywork. A rotating role of the facilitator can help show that it’s not for the product manager or the engineering manager.
5. Retrospectives: The teams conduct regular reviews of what went great, celebrate success, and what can improve, followed up by action items with target dates and a responsible individual. This is how teams improve themselves. Ways of working are also agile.
6. Measuring: Measurements, which are simply observations to reduce uncertainty, remove subjectivity. By looking at DORA metrics, time breakdown, number of support tickets and bugs, etc. the team can have a meaningful discussion and can decide for example to invest more in fixing root causes of issues or productizing (providing self-service to users) to reduce support load and move faster.

Managerial Principles

1. Empower teams: Give teams autonomy to make decisions and fully own their work. The Teams that are waiting on leaders or stakeholders for every decision are very slow and are not learning from the market, they are order-takers.
   This needs to be balanced in order to make sure all teams are rowing in the same direction — align or make sure the teams’ goals and health metrics are aligned with the company goals. This is why providing the “why”, the direction, is important. Both for business goals and for guidelines such as “prefer short recovery time over targeting perfect uptime and stability.”
   Teams sometimes need support with defining goals, making sure they are measurable and time-bound, whether using OKRs or other systems, and the ability to divorce a goal if we learn it’s not beneficial. Weekly tracking of progress further manifests agility and making decisions early on.
2. Roadmap now-next-later: The roadmap includes the order of problems the team will work on now (this quarter), next (next quarter) and later (anything beyond). It doesn’t include solutions, features and dates — rigid Gantt charts created when we know the least are not realistic.
3. Focus on priorities: Remind and repeat, focus on the most valuable work items. Members may love serving others who ask for help, jumping from topic to topic or falling in love with a specific solution. The teams need to adhere to the priority (without starving or neglecting KTLO activities). At the same time, frequently make sure the priorities are correct on the task level, do not hold on to irrelevant priorities set in the past.
   Nudge to build only the core and buy commodity. It wouldn’t make sense to implement your own database or email service when you offer a car rental SaaS.
4. WIP limit: Whether using Kanban or any other methodology, limiting the amount of concurrent work items is a good idea. It encourages finishing over starting, which results in more value delivered earlier and more feedback. When a task is finished but a new one cannot be picked because the limit has been reached, members join other members in order to help get their tasks done.
5. Transparent communication: Foster an open environment where feedback and ideas can be shared freely. It means having an easily discoverable public board for the teams’ work and setting psychological safety that is proven to have better outcomes, share knowledge and prevent errors. This promotes meritocracy, data-driven and “disagree and commit” decision-making over the highest-paid-person-opinion (HIPPO).
   Encourage documentation and share guidance about the right communication tools, e.g. when to use meetings, when to use shared documents and when to Slack.
6. Dedicated learning and creativity time: Weekly learning time of 10% to learn and experiment on the product or anything else, intermissions, knowledge sharing sessions and guilds — besides the higher motivation and cross-pollination, people can come up with ideas about the product, simplifying the architecture and reducing efforts. All these can support agility by increasing interaction and collaboration, gaining skills and working for the customers.

Agile anti-patterns

There are some smells and red flags that indicate that an organization or part of it is “doing agile”, but not really being agile:

• Long detailed iteration planning: 4 hours of planning the next 2 weeks or 8 hours planning the next 4 weeks — rigid plans leave less room for adaptation as we learn more. This doesn’t mean not having a goal.
• Long projects without feedback: Working on a project, either new product features or a rewrite, without deploying to production, getting real feedback is very likely to not meet the needs of the market.
• Unimpressive DORA metrics: Low number of deployments, long lead time, long time to fix incidents or high rate of faulty deployments — mean the speed and or the quality is low, whether due to a harmful policy, a suboptimal technical setup or ignorance about how good things can be.
• Fear of deploying: Fear causes teams to be discouraged from deploying frequently and learn more quickly, accumulating many changes per deployment and increasing the risk.
• Product Manager as gatekeeper: PM who is “the voice of the customer” or responsible for spitting out solutions in the form of requirements, making engineers an execution arm disconnected from discovery and feedback, aka “feature teams” which are not empowered. It’s also a low bus factor and a dependency on a single person.
• Estimations by default: Estimating projects (again, when we know the least), stories, and constant pressure to yield more precise estimations. Read about the pointlessness here.
• Sprint reviews: While they are nice to have for sharing what other teams worked on, in case you have that capacity and interest, they often turn into a feedback session from stakeholders or the HIPPO, while they cannot predict how the market will react.
• Not measuring progress: Not tracking the progress on goals, OKRs or health metrics doesn’t allow improvement. The same goes for measuring only in the middle of the quarter and the end.
• Focus on output and vanity metrics: Ignoring outcomes, that is, how the customer behavior changed, and focusing on efforts, lines of code, ass-in-seat hours, meticulous employee time tracking, trainings done — they show a misunderstanding about measuring what makes a difference for the customer.
• Unsustainable execution: Consistent long hours, high support work and numerous bugs, incidents, stressful on-calls, frequent context switches — these lead to a team that is on the verge of burnout, less interested in solving customers’ problems and doing the bare minimum.
• Steering committees: A group of senior managers who decide what goes into a version is again going against experimentation and gathering feedback from the only place that matters — the customers. Such committees also encourage political deals and compromises over the highest business priorities. Naturally, they also slow things down.
• Mini-waterfall: Disparate steps of development: collecting requirements, analysis, design, implementation, testing, releasing, maintenance — especially when each stage is done by another team or a designated person. These slow down the entire process and reduce the ownership.
• Manual efforts: manual QA repeatedly testing the same things after every change, manual deployment and reverts, security and compliance, linting, sign-offs before deploying, etc. They are error-prone, boring to humans and take a long time to execute.

Summary

If you play chess against a grandmaster, you’d probably lose. But if you can make 5 moves for every move they make, you may win.

Agility is a competitive advantage — it allows us to conduct more experiments per time period, gather feedback and adapt. While the strategy is long-term and more stable, having flexible and adaptive tactics, goals and ways of working help us achieve it.

I hope you now see that it’s about being agile, not “doing agile”.

When in doubt — refer to the Agile Manifesto.

Effective leadership is learned
To learn more or reach out, visit my website or LinkedIn