What’s New

Things a Scrum Master should NOT be doing

One of the most common traps a Scrum Master falls into is that of turning into a Project Manager. Here are some other pitfalls

A Scrum Master Should NOT Become a Project Manager

By far the most common mistake made in an Agile environment is the Scrum Master taking on the role of a Project Manager. When thinking of what a Scrum Master does, keep in mind the keyword “facilitate”. If the team doesn’t have a separate PM (which can typically straddle more than one Agile team) or a Product Owner (PO) then maybe that role needs ot be created.

A Scrum Master Should NOT Block Change

One of the key tenets of an Agile framework is to remain, well, Agile. If Stakeholders want to change the direction of work, delivery and outcomes the Scrum Master should not block changes in direction because they want to maintain throughput of User Stories and the headline Velocity metric.

A Scrum Master Should NOT Solutionise

A Scrum Master typically has very good knowledge of the project(s) he or she is working on. But, whether during scrums or other meetings, they should not be tempted to stat offering solutions unless the Stakeholders, PM or PM ask for advice – for example if the Scrum Master has experience and specific domain knowledge.

A Scrum Master Should NOT Chase Progress Beyond the Daily Scrum

A daily Scrum should be sufficient to allow the required facilitation and progress of a Sprint. If a Stakeholder asks the Scrum Master for a snapshot of where a Sprint is, they should have that information to hand. What a Scrum Master should not do is chase a developer every afternoon asking if it’s done yet.

Got a Question? Ask Agile Unpacked…

Do those un-delivered User Stories at the end of a Sprint really need rolling?

It is a mistake to continually roll unfinished User Stories from Sprint to Sprint. Instead pay attention to them and consider what is going on.

When prioritised backlog items have not been completed during a Sprint it is worth taking a look at them at least to find out if they are still required, correctly annotated and have useful Acceptance Criteria.

Rolling unfinished items “automatically” can use up a significant amount of bandwidth in the next Sprint, blocking other potentially more highly prioritised items.

The first step should always be to check with the Product Owner who should be able to make the decision on whether to roll, park or seek further elaboration which may require a re-write of either the User Story of the Acceptance Criteria.

Splitting

Another option for the Product Owner and team is to split a User Story into smaller pieces, although if the sizing had been done correctly up front this should not be needed, unless new information has come to light, especially if a third party is involved.

Velocity

If a User Story is rolled or parked, the team will not be credited with the Story Points which can affect their Velocity. This is not necessarily a bad thing as it reflects the reality of what’s happening. Perhaps an Agile Coach is required to help the team(s) with sizing and engagement with Stakeholders to better define the Definition of Done.

Outcomes

The aim of any Agile Team is to deliver the outcomes required and prioritised by the Stakeholders. The wrong thing to do here is to blindly throw resources at a User Story proving difficult to close out, without escalating. It may be the case that a User Story can be cancelled if it begins to roll without a clear end in sight.

Got a Question? Ask Agile Unpacked…

How disruptive to an existing company culture is the Agile Framework?

I am asked this a lot, most often by Program & Project Managers who are wary of persuading Stakeholders to allow it’s adoption

The short answer is that company culture is mostly about what a company is doing and why (e.g. developing FinTech enabling better and faster portfolio rebalancing for clients worldwide), and the Agile Mind-set is mostly about how a company achieves this.

A company with vision and great teams can deliver anything anyhow. Even, dare I say, using a traditional Waterfall method.

If Agile delivers anything, it delivers a framework, top-to-bottom transparency and a cadence to the way Stakeholders prioritised outcomes are delivered.

Got a Question? Ask Agile Unpacked…

How Can the Agile Framework Help a Start-up?

There are three key ways adopting an Agile Framework can help a Start-up whether IT based or not

As we’ve mentioned in previous posts, Agile is not just for IT departments or IT-based start-ups. Adopting an Agile Framework from the get-go can significantly help a start-up in these three ways…

Agile delivers clarity top to bottom

An issue in any start-up is being able to track all the tasks, projects and must-do-now’s.

An Agile framework (and associated tools) will enable you to answer questions such as:

What are we working on right now?

What’s next?

How can we articulate progress to our Stakeholders?

Agile delivers transparency of what you’re doing and why

Agile Mind-Set aside (that’s a number of posts which we won’t go into here) adopting an Agile Framework will enable everyone in your start-up to see what the Management Teams vision is, how that breaks down into headline outcomes (Epics) which enables individual team members to be clear on what they should be doing THIS WEEK to move the start-up forward.

Agile makes it easier to track progress and make objective decisions about prioritisation

The Agile approach enables a start-up to clearly articulate what outcomes have been identified, how success has been defined, how those outcomes have been broken down into User Stories, what has been prioritised and when, and how fast the Agile team members have been tackling the work.

Got a Question? Ask Agile Unpacked…

Agile for Management Teams

What is an Agile iteration when it comes to Project and Program Management and how can it improve the quality and timeliness of delivery?

When IT teams use the Agile method to deliver software, the bi-weekly Sprint provides the cadence and framework required, along with the other usual processes and meetings such as the Scrum and Retrospective.

For Management teams it can be a little more difficult to see how an Agile framework can operate, but operate it can.

The main benefits delivered by an Agile framework for Management teams are transparency, prioritisation and robustness.

Transparency in Agile Management

Project plans existing in documents or in emails is of limited use even if one individual is responsible for the “golden copy”.

Using tools such as JIRA and Confluence, Management teams are able to contribute collectively to the definition and decomposition of high-level outcome definitions.

These “Epics” are available for Program and Project Managers to see and for Product Owners to review, seek elaboration and to decompose into User Stories.

Prioritisation in Agile Management

A key benefit of having Management Teams’ required outcomes in tools delivering transparency is the ability to make prioritisation an ongoing “delivery” of the Management team. Prioritisation’s never stay the same for long and it is fatal for any project to pretend they do.

Robustness in Agile Management

With transparency and the ability to deliver ongoing prioritisation’s, the Management Team can deliver robustness in direction which in turn drives resourcing. If you know what you’re doing, why and in what order, you can massively improve the robustness of your projects and so decrease risk.

Got a Question? Ask Agile Unpacked…

Myth: Agile is only for IT

It is usual for management and stakeholders to view Agile methodology as being for IT only. This is not the case.

One of the strengths of an Agile framework is that it allows for change during the flight of a project and it is a rare project which is planned in advance and then executed without experience some kind of change in priority or as a result of external events.

Implementing an Agile framework for management and stakeholders sharpens everyones engagement with what is being done now and what comes next and why.

Unnervingly, it also delivers a high degree of transparency to stakeholder prioritisation’s and estimations which of course some do not enjoy.

Got a Question? Ask Agile Unpacked…

Do Agile Teams Really Self-Manage?

Agility & Resilience

During a time of huge global upheaval, it massively advantageous to have an agile backbone to help deliver resilience

This article is being written in May 2020 as COVID19 appears to be on the decline, looking at globally reported death stats.

With many people being furloughed or let go it is a perfect time for organisations large and small to re-think how they can best grow again in such a way to make being resilient a part of their DNA.

Agile is not a panacea but it can contribute massively to developing resilience all the way from the Board through to Senior Management, Stakeholders and to individual Agile team members.

How can it do this? By focusing less on each individuals job title and location in a hierarchy and focusing more on broad skill sets (the elusive T-shape), creativity and the willingness and ability for members of an organisation at all levels to contribute to the Agile Mind-Set which in turn delivers Outcomes.

A true Agile Environment allows an organisation to easily change direction (I didn’t want to say “pivot” here, but here it is), whether that change is minor (e.g. reducing 50 features to 10 and doing them differently) to major (e.g. changing the actual nature of the products and services an organisation delivers).

Got a Question? Ask Agile Unpacked…

At the End of a Sprint

Along with a Retrospective, the end of a Sprint should result in a useful & readable update for Stakeholders

It is not enough to close a Sprint, have your Retrospective, roll any incomplete User Stories, close the Sprint in JIRA and open the next.

Stakeholders need to be updated in a clear, consistent and useful way on the outcome of each Sprint.

High Level Sprint Summary

Before any detail is articulated it is useful to summarise a Sprint in an easy-to-consume fashion. I have found that a simple table is of most use which can ideally be standardised across Agile teams.

This may include Velocity and/or Burn Up (more on that on another post), as well as Average User Story size, percent complete (for User Stories and Acceptance Criteria) and percentage of User Stories rolled to the next Sprint with any headline reasons.

Product Progress

At a high level it is useful for Stakeholders to know which products (whether technical or business relates) have been furthered by the Sprint and which have not.

Epic Progress

As products can straddle more than one Epic, it is useful also to report back to Stakeholders what progress has been made tracing back to a User Story’s Epic. This will help Stakeholders understand how accurate their sizing has been.

User Story Progress

This may include completed User Stories and their contribution to the development of products. At a more granular level some Stakeholders may want to see the progress of each User Story which has been rolled into the next Sprint. For example a User story may have been sized at 5 days and four days have been completed vs. the Acceptance Criteria. There’s a big difference between saying User Story 123 has rolled, and User Story 123 has been rolled at 80% because of an external dependency.

Got a Question? Ask Agile Unpacked…

Stakeholders and their Epics

Stakeholders should write, size and prioritise their Epics, but watch out for the signs it’s not working right

For Product Owners to decompose Stakeholders Epics into User Stories & Acceptance Criteria, the Stakeholders must first write their Epics, size and prioritise them.

Here are some sign to watch out for which can indicate that the Stakeholders Epic sessions are not working properly and need to be addressed…

The Epics don’t make sense

If you read an Epic and it doesn’t make sense, then A) Product Owners cannot decompose it, and B) It means the Stakeholders have too much in their heads (probably assumed) and haven’t articulated it clearly enough.

It can typically fall to the Product Owners to have an Epic clarification session with the relevant Stakeholder(s) to re-write the Epic to make it decomposable.

The Epics are really long

An Epic doesn’t have to be War and Peace (despite being called an Epic). The longer an Epic is, the more open it is to ambiguity or misinterpretation. Encourage Stakeholders to keep their Epics short and to the point.

Epics without Acceptance Criteria

If an Epic doesn’t have any Acceptance Criteria how will the Stakeholder(s) know whether or not it’s been delivered? Product Owners should encourage Stakeholders to write a number of Acceptance Criteria which collectively are the Definition of Done.

All Epics are Sized as SMALL or HUGE

It doesn’t help if Epics are either sized as small (e.g. one Sprint) or huge (e.g. 8 or more Sprints). If Epics are estimated using t-shirt sizes (XXS, XS, S, M, L, XL, XXL and OMG) then any Epic at the more obese end of the scale really needs to be decomposed by the Stakeholders into smaller sizes otherwise they risk becoming a Waterfall Project in themselves.

Stakeholders are unavailable to agree User Story decomposition

Any Stakeholder genuinely interested in how their Epic has been decomposed should be willing (if not champing at the bit) to sit with you and knock out what the User Stories are. Ideally the Product Owner should drive this session – the aim being to come out of the session having worded the User Stories and agreed them with the Stakeholder(s) in real time.

Got a Question? Ask Agile Unpacked…