Unit Testing, DevOps and Flow Agile

DZone 's Guide to

Unit Testing, DevOps and Flow Agile

It used to be ok to organize around three-week sprints. But these both now look like long-term plans, the kind Agile was supposed to do away with.

· Agile Zone ·
Free Resource

Scrum Agile techniques are coming under pressure as business competition intensifies. It used to be ok to organize around three-week sprints with periodic acceptance testing, but these both now look like long-term plans, the kind Agile was supposed to do away with.

Against that backdrop I've been talking with people in the Flow Agile community about how they go about organizing work for the cadence of delivery you get in a DevOps/continous integration environment.

In particular, I have been talking with people at Paddy Power Betfair (transparency notice: I wrote the book Flow, with the ex-CIO of Paddy Power, Fin Goulding).

Redhat says of Paddy Power's daily performance:

"Paddy Power Betfair serves more than 3.5 billion application program interface (API) requests every day—a number similar to Netflix, eBay, Facebook, or Twitter. In addition, Paddy Power Betfair handles around 130 million transactions daily—more than 10 times the number of daily transactions as the London Stock Exchange."

How does it do that? Well, specifically, how does it organize work in IT?

The first thing is that Paddy Power's IT leaders have delegated a lot of authority to developers, encouraging them to question product owners about the value of any particular piece of work. The developer can push back.

Second, that can happen because they now organize work in a 3-5 day cycle-time. Fin, who has moved on to Aviva, has cut cycle-time down to 2 days.

That means a developer is looking at a unit of work that he or she can make a valid judgment on. Does it add value or not?

That also means the role of the product owner is becoming more variable and flexible. They tend to be embedded within developer teams but have a voracious appetite for seeking out stakeholder concerns and feedback.

Third, they also need to be good at negotiating whether a change, in a just-in-time environment, needs to be made to the code or to business objectives. That flexibility between work and objectives is another crucial element of speed.

Fourth, the developer teams collaborate on breaking the work down in short cycle-time units of work (there is an extended interview with Sean Twomey, one of the leads at Paddy Power here).

Fifth, that collaboration not only gives them short cycle-times; they have created a very visual representation of how work flows through the organisation and that visualisation is now the plan .

Finally, work is broken down a week or two ahead of time, which allows for a just-in-time unit testing environment and a kind of conversational acceptance testing.

Acceptance tests are a quick meeting at the Team Kanban wall, a work-up of 4 or 5 use-cases and an assessment of whether or not code meets the requirements of those.

And that's probably one of the keys to speed. Here's Alan Murphy who is responsible for quality testing policy:

"Managers and other stakeholders perceive unit testing as adding cost but that idea, and the elimination of unit testing, is a completely false economy because you will be breaking something in production later and then you will have to fix it in production. 

It is very easy to look efficient by pushing code into production quickly but it will just be coming right back at you as bugs.

There's also a tendency to allocate test development to inexperienced developers, often people who are young and new to the company, who you are asking to write quite complex test suites for acceptance testing. It never, never works and it always ends up needing more development work. When you have broad unit testing coverage you can blaze into production with very small changes and very little blowback."

To summarize those key points: ultra small units of work in a very visual environment gives you the opportunity to empower developers to query value forces; it allows product owners to become better at parsing business objectives via code; and it allows for a broad spectrum of unit testing with just-in-time acceptance tests and a higher level of quality upstream from production.

agile, agile approach, dev ops, flow, unit testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}