Agile on Trayix

When an agile transformation stalls

Wed, 13 Jul 2016 09:00:00 +0000

The first six months of an agile transformation are usually the easy part. There is a kickoff, a round of training, a few teams producing working software every two weeks, and a sponsor who likes the energy. Then the energy fades. Teams go through the motions, and the old way of working quietly returns.

We see the same stall patterns again and again. Most are organizational, not technical, which is why they’re easy to miss from inside a team.

Measuring an agile transformation

Wed, 09 Mar 2016 09:00:00 +0000

A year into an agile transformation, the sponsor asks a fair question: is it working? The usual answers are not encouraging. “We’ve trained 400 people” describes activity. “Velocity is up 30%” describes a number that teams can raise by estimating more generously. Neither tells you whether customers get better software sooner.

If you’ve paid for a transformation, you deserve better evidence. This is how we think about it.

Metrics to be wary of

Two kinds of numbers show up in nearly every progress report, and both mislead.

Contracts that fit agile work

Wed, 18 Nov 2015 09:00:00 +0000

You can’t write a fixed-scope, fixed-price contract for work whose point is to change the scope as you learn. Yet many agile engagements still arrive wrapped in exactly that kind of paper. The contract and the method pull in opposite directions, and the people in the middle pay for it.

Because we are a consulting firm, we should be candid: how you pay us changes how we behave. Here are the common options and what each does to incentives.

Disciplined Agile and the case for choice

Wed, 26 Aug 2015 09:00:00 +0000

Every agile method comes with opinions, and every enterprise comes with exceptions. A team that builds a mobile app, a team that integrates an enterprise resource planning (ERP) package, and a team that maintains a 20-year-old billing system don’t share the same constraints. Disciplined Agile Delivery (DAD) starts from that observation.

Scott Ambler and Mark Lines described DAD in their 2012 book. It isn’t a single method with a fixed set of ceremonies. It’s a toolkit that borrows from Scrum, Kanban, Lean, Extreme Programming, and other sources, and it organizes them around goals instead of prescriptions. For each goal, such as “explore the initial scope” or “improve quality,” DAD lists options, trade-offs, and when each one fits.

LeSS is more: scaling with fewer roles

Wed, 11 Feb 2015 09:00:00 +0000

Most scaling frameworks answer the question “How do we coordinate many teams?” by adding things: roles, layers, planning events, and diagrams that need a large monitor. Large-Scale Scrum (LeSS) answers with a different instinct. It asks what you can take away and still have Scrum work.

LeSS comes from Craig Larman and Bas Vodde, who spent years helping large product organizations adopt Scrum. Their premise is that scaled Scrum is still Scrum. You don’t bolt a second process on top. You apply the same few rules to a bigger group of people and accept that the organization, not the framework, will need to change.

Rethinking the PMO for agile teams

Wed, 06 Aug 2014 09:00:00 +0000

When teams go agile, the project management office (PMO) is often the first group to feel the chill. Templates, weekly status reports, and compliance checks suddenly look like friction to people who want to ship. Some PMOs respond by tightening the rules. We think the better response is to change what the PMO is for.

Why the old model feels wrong

A traditional PMO works by standardizing. It asks every project for the same plan, the same report, and the same sign-offs, so leadership can compare them. That served a purpose when projects looked alike. An agile team shows progress through working software every few weeks, so a weekly document describing percent complete adds little. Teams see the report as extra work, and the PMO sees teams as undisciplined. Both are partly right.

The product owner problem

Wed, 14 May 2014 09:00:00 +0000

Ask a dozen enterprises where their agile adoption struggles and a surprising number will give the same answer. It isn’t the developers, the tools, or the training. It’s the product owner. The role looks simple on a Scrum diagram, and large organizations find it hard to fill well.

Why the role matters

The product owner decides what the team builds and in what order. Every sprint, the team asks, “What’s the most valuable thing we can do next?” If nobody can answer with authority, the team guesses, waits, or builds what the loudest stakeholder asked for. A good team with a weak product owner will deliver working software that doesn’t matter.

Scaling agile: a first look at SAFe

Wed, 19 Feb 2014 09:00:00 +0000

Scrum works well for one team of seven or so people. Big companies, though, have dozens of teams that depend on each other, plus portfolios of work that executives need to steer. The Scaled Agile Framework (SAFe), introduced in 2011 by Dean Leffingwell, is a popular attempt to answer that problem, and more of our clients are asking about it.

Why it appeals

SAFe organizes agile work into three levels: team, program, and portfolio. Its appeal is that it gives large organizations a recognizable structure for each level, so executives can see where agile fits with budgets, roadmaps, and governance.

Running agile teams inside a stage-gate process

Wed, 04 Dec 2013 09:00:00 +0000

Most large companies can’t drop their gate reviews overnight, and most shouldn’t try. Gates exist because executives need to decide where to put money, and that need doesn’t go away when a team starts using Scrum. The good news is that the two can coexist. The trick is translating what agile teams produce into what the gate committee needs to see.

Start with what a gate is for

A gate is a decision point: continue, change, or stop. Gate reviews often ask for documents because documents were once the only evidence available. Working software, a stable velocity, and a prioritized backlog are better evidence of progress. Your job is to present that evidence in terms the committee understands.

What PMI-ACP says about agile going mainstream

Wed, 18 Sep 2013 09:00:00 +0000

When the Project Management Institute (PMI), the organization behind the Project Management Professional (PMP) credential and the PMBOK Guide, launched its own agile certification, plenty of people raised an eyebrow. The PMI Agile Certified Practitioner (PMI-ACP) became available in 2012. Whatever you think of the credential itself, the launch tells you something: agile is no longer a side conversation among software teams.

What the signal means

For years, agile and traditional project management were treated as rival camps. PMI creating an agile credential says the mainstream profession now sees agile as part of the job. For enterprises, that has a practical consequence. Your project managers will be asked about agile, and your hiring managers will see PMI-ACP on résumés next to the PMP.

Waterfall isn't the enemy

Wed, 12 Jun 2013 09:00:00 +0000

Every few weeks, someone in a steering meeting declares that waterfall is dead and agile is the answer. Then someone else asks how agile will work for the data center migration. Both people have a point, and neither has the whole picture. The useful question isn’t which approach wins. It’s which approach fits the work in front of you.

What waterfall does well

Waterfall (and its cousin, the stage-gate process) assumes you can know most of what you need up front, then build it in order. When that assumption holds, the approach works well. Consider a regional bank that must meet a regulatory change by a fixed date, with the requirements spelled out in the regulation itself. Little is uncertain about what to build. The risk is in coordination, documentation, and proof that you followed the rules. A plan with clear phases and sign-offs serves that work.