4 things you're getting wrong about Agile Scrum

Agile is a tricky thing to get right, To the uninitiated, it appears to be more relaxed and less rigid than waterfall or other project management methodologies. This could not be further from a well-oiled Agile Scrum project

When done right, and supported by the correct mindsets, framework, and disciplines, Agile combines a perfect blend of innovation, risk-taking and structure. However, when done poorly it’s a broken, nerve-wracking and ineffective approach, otherwise known as (Fr-agile).

As a consultant, I get to see how dozens of organisations operate their projects each year. I have listed below the four most common mistakes I see organisations making:

1. It is not just about going faster

Going faster can be a side effect of several key Agile practices, but you're not going to reap the rewards of Agile immediately.

Many teams practice all the Scrum ceremonies and begin moving quicker than they ever did under Waterfall. Soon they come to realise that they are simply building the wrong things faster.

While it’s true that you can indeed go faster with Agile, twice as fast when done right.… The other benefit is value, which requires a deep understanding of the business, what the customer/user values and their priorities

2. Assuming anyone can be a Product Owner

Many of our customers make the mistake of nominating one of their staff as Product Owner, but not provide them with any formal training, or frameworks. This is setting them up to fail, as even the most seasoned product owners who are familiar with defining a product vision, roadmap, and software solutions may still not fully understand context, constraints, stakeholder personas, business rules, non-functional, and transitional requirements.

In Patient Zero's way of working, we operate with a Client Product Owner and a PZ Product Owner. This has been a highly successful arrangement as it takes a lot of the pressure off of the Client Product Owner in terms of having to be intimate with Agile ceremonies & disciplines guiding them on the journey while ensuring that their insights and industry knowledge are incorporated into the final product. 

A big part of my job is guiding the Client Product Owner through the more technical or process-oriented aspects of the job, and I learn from the Client Product owner, the nuances of the industry and customer sentiment. It's a highly collaborative and productive way of operating.

I also act as the Scrum Master, whose role is to insulate the team from impediments and distractions that jeopardise the commitment and ensure the team is performing and stress levels are managed.

3. Going Agile, but tracking to a Gannt Chart & Weekly Status Report

Most of the time, organisations shift over to an agile methodology, but still expect the same reporting (Gannt charts, deadlines and weekly status reports) This is where many businesses get it wrong, as agile reports such as the burndown are an essential and powerful tool in measuring progress. 

Agile reports operate more or less like the instrument panel in your car and indicate how the team, individuals & project are performing and can predict roadblocks, challenges and indicate when to add in more work or take some out.

For instance, an Agile Sprint Burn Down, at its core is a way to measure progress in a sprint and detect potential shortfalls and blockages, but it’s also used like an oil temperature gauge to measure stress levels.

If the leadership team wants the deadlines agreed upon before, while simultaneously undergoing an agile transformation and not to be impacted, I'd be the first to say that Agile isn't going to work that way.

Many of the reports in Agile are simple in appearance but they are highly contextual and useful when measuring performance so by not utilising them you are missing out on some of the biggest benefits.

4. Not Respecting the Sacrosanctity of the Sprint

In the ideal environment, the whole agile team is focused on the same work items identified and agreed upon by the team, and only those work items are being worked on by the team members for the current sprint. We say the sprint is in a vacuum, or sacrosanct.

I think this is a big piece of the magic behind Agile, as in every sprint the team collectively set their own goal and will "sprint" to honour the commitment working toward a broader objective one small goal at a time.

However, if for any reason team members are regularly and consistently expected to do work outside of the sprint, it cannot just be absorbed, those additional work items should be reflected in the velocity.

The burn down chart, the missed sprint goals and the reduced capacity of the velocity should provide transparency to how the resources are allocated and the impact should be accessed and communicated to show the real cost of these "Priority Tasks".

Recently I took a client through all these "priority changes" that were insisted upon, which I earmarked as "variance" in the title. They were shocked that when I added them all up, they would equate to several thousand dollars in work and delay launch by 3-4 weeks.

We determined that only 2-3 of these items were really a "Priority " and we developed an exceptional product which finished on time and on budget.

Now that being said, I hope this does not dissuade you from embracing Agile, true it takes discipline and rigour to get the most out of it, but we can help you on your journey. To learn how we can help, get in touch with us here.