quality

Agile delivery: what could wait so the important work can finish?

In Tuesday’s post, I explored why agility needs boundaries: clarity about what we protect and what we can change.

Now consider what happens when those boundaries meet a difficult deadline.

There is more work left than the team can realistically finish. What changes next?

Make scope the conversation

DSDM offers a deliberate approach: protect time, cost and the agreed quality standard, then vary the features delivered.

Try bringing that thinking into your next planning conversation.

Agility needs boundaries

Being agile means being willing to adapt. But what, exactly, are we willing to change?

Consider a team approaching a deadline with more work than it can finish. Should it extend the deadline, squeeze in extra hours, reduce testing or deliver fewer features?

That choice deserves a conversation before the pressure arrives.

Decide what to protect

DSDM, the Dynamic Systems Development Method, makes the trade-off explicit: fix time, fix cost and fix the agreed level of quality, then vary the scope.

Lower-priority requirements provide room to adapt. They can be deferred by agreement when the work proves harder than expected.

The aim is to deliver a useful solution within the agreed constraints. That requires clear priorities and enough flexibility in the feature list.

If everything is a must, there is nowhere for that flexibility to go.

Last year was, without a doubt, the year of remote working. I now spend most of my days and evenings sitting at my desk. During November I began to realise just how painfully uncomfortable my chair had become.

After much research, I’ve bought myself a new Secretlab TITAN XL series gaming chair and even though I’ve only had it for a week, I love it.

The primary purpose of a development team is…

Before you read further, take a moment and answer the following question for yourself: what is the primary purpose of a development team?

Don’t worry, I’ll wait…

Okay, what was your answer? Is it to create working software? (Well, yes.) Is it to complete everything on the sprint backlog (Hmmm… kinda.) Is it Henry, the mild-mannered janitor? (Could b… No!)

Above all, the primary job of an agile development team is to build quality into the product.

That focus on quality is important because it informs us and shapes us in everything we do as a team, from planning through to delivery.

When I introduced agile to one team with whom I worked, it took me a long time to help them get beyond their misconception that agile meant quickly hack things together and shove it out the door. Release early and release often—yes; dirty hacks—no! Done well, agile should be more disciplined than other traditional methodologies and focus on quality.

The first principle of the agile manifesto reads, “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The agile manifesto values “working software over comprehensive documentation”. Valuable software is working; working software relies on quality.

The fourth principle of DSDM/AgilePM is “never compromise quality”.

What small step could you take now to improve the quality of your work?

How and why we QA

At a conference recently one of our team was speaking about how we organise our work using Trello and the Kanban-style workflow we have settled on. A number of people told her afterwards that they were impressed with both the simplicity and effectiveness of our rules around the QA (quality assurance) or testing phase.

As Wikipedia explains, “Kanban is a method for visualizing the flow of work, in order to balance demand with available capacity and spot bottlenecks.”

At its simplest level a Kanban board needs only three columns or lists to track your tasks:

To do
In progress
Done

We have added a fourth column, ‘QA’, between ‘In progress’ and ‘Done’.

This post explains why.

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Tag: quality