Unit Testing, DevOps and Flow Agile
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.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
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).
"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:
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.
Opinions expressed by DZone contributors are their own.