5 mistakes organisations make while implementing Agile

What’s worse than waterfall? Bad Agile! Here are some common mistakes I’ve seen organisations make when they first implement Scrum (a framework for implementing Agile).

1. Forgetting about people

If we catch ourselves talking about ‘20% of that remote FTE ’, we may already be making this mistake. Having 20-30% of 12 FTEs is not the same as having five people dedicated 50%-100%. People have busy day jobs and multitasking and context loss kill productivity and motivation. In the original manifesto, the team is critical. In a truly Agile team, the team is dedicated, empowered, self-organised and thus motivated.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

2. Literally ‘sprinting’

I’ve met teams that think Agile is unsustainable because sprints are weeks where you work super hard to get work done at twice the speed. Uh. That is incorrect. The word ‘sprint’ that comes from Scrum and does not mean moving at 3X the pace. A ‘sprint’ is a time boxed interval in which work gets done at a pace a team can sustain. Moreover, the Scrum Master protects the team during this sprint, only adding work that is absolutely critical and removing equivalent work to keep the team sustainable

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Also read: You do not need to choose a methodology to innovate

3. Ignoring rapid feedback loops

In agile, rapid feedback loops are critical. These include feedback from the customer and from the team. By taking early versions of solutions to the customer, we can incorporate their feedback to make our product more useful for the customer. Similarly, by running regular retrospectives with teams, our teams get better at working together.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

4. Turning the product backlog into a required feature list

Not everything that’s on our product backlog must be done. And the priority of items on our backlog doesn’t have to stay constant. Truly Agile teams constantly refine their backlog and focus only on what has the highest value for the customer and the business. How do we determine customer value? By testing working software (and prototypes) with customers early and often.

Simplicity–the art of maximising the amount of work not done–is essential.

5. Agile means we don’t plan

I’ve lost count of the number of times I’ve heard this one. It is NOT true. There is planning in Agile, quite a bit of planning in the short run because we have visibility in the short run. Unless there’s an unprecedented earthquake, our teams can plan somewhat accurately for a couple of weeks at a time.
We should also have a high level plan for the medium/long term. We need to know which direction we’re moving in, after all. However, this high level plan should give us the flexibility to respond to market changes and customer feedback because if we are truly working in Agile, we will be capturing this feedback through point 3 above.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

When implemented correctly, Agile leads to better products and services for our customers, delivered to market faster by motivated teams. Going forward, if you feel like you’ve lost that ‘Agile feeling’, go back to the original manifesto to get back to basics!
—-
Editor’s note: e27 publishes relevant guest contributions from the community. Share your honest opinions and expert knowledge by submitting your content here.
Featured Image Copyright: snowing / 123RF Stock Photo

Search This Blog

Agile