Cutter Consortium Senior Consultant Jon Ward’s Agile Lineout is a new approach that uses behavioral theory, Lean principles, and Agile wisdom to help teams create high-value solutions quickly. Scrum embodies Agile ways of working and new organizational constructs, but does it consistently deliver the Agile promise of improved performance? Agile Lineout — another metaphor from rugby — is a new approach that uses progressive steps to increase predictability, quality, and delivery efficiency.
In a recent webinar, Ward answered some questions about the approach.
Q: In Agile Lineout, is there still a product owner and the equivalent of a Scrum Master?
Jon Ward: Yes. There is a product owner who defines the product. If you are doing a transformation, the transformation director could be the product owner. If you are creating a new marketing campaign, it might be the head of marketing. It's still that personality, if you like, defining the solution that is required. There is also a team coach, and it's a bigger role than a Scrum Master, but it mirrors the Scrum Master role.
Q: In which contexts do you suggest using Agile Lineout?
Ward: It can be used in almost any context. I don't think you would use it in continuous delivery, because I think Kanban is absolutely superb in that space. But other than for continuous delivery, where you're doing small incremental items, you could use Agile Lineout in any sort of context. I'm seeing it used in marketing, finance, mergers and acquisitions, software development, new product development — all those sort of contexts.
Q: Is there an overall product architecture in Agile Lineout?
Ward: No. You could use Design Thinking to come up with the product architecture, but that would not be any different than any other technique for creating product architecture. You could use Agile modeling to get to the requirements. That could be something that you could define in the team’s ways of working. But I haven't actually gone as far as that.
I think there's a basic set of elements in the new ways, or Agile ways, of working that is almost standard. You need to have a means of defining the requirements. You need to have a means of building those requirements. You need to have a means of testing and checking the quality of those requirements. And you need to have a means of releasing those requirements or getting the outcomes that you wanted. You could say there are four or five elements that the team needs to think about when they're starting to decide their ways of working.
Q: Do you think Agile Lineout will work well for hardware development?
Ward: Yes, I really do. I've got a team in British Telecom that's doing a hardware development at the moment, and they asked me today about whether they could actually start to use this.
Q: Why would I choose Agile Lineout instead of Scrum?
Ward: That's a really good question. If you've got a novice team that you want to get up and running, Agile Lineout will give them the tools and techniques and the team behaviors beyond what Scrum features. Basically, Scrum has a certain degree of process, and that's the sprint planning, and the product backlog refinement, and the daily stand up, and the retro, and the sprint review. Agile Lineout allows a novice team to actually start to understand there is more to the picture, there is more to being agile than just the daily standups.
In truth, what happens with Scrum is that the Scrum Master has to train the team, or somebody has to train the team, in what quality techniques they're going to use and so on. If you said that Scrum was training things like Behavior-driven Development (BDD) and pair programming and all of those sort of techniques, I wouldn't argue with you. But that’s not all it is. Scrum has got some values. For example, Scrum says that the retrospective is where the team assesses quality, but it doesn't give you any tools or techniques that the team should use. Therefore, with a novice team, how do they learn those? Agile Lineout gives the team the tools they need to use from day one.
Q: Does this approach scale planning across a large enterprise?
Ward: Yes. Because you've got the context assessment and the product goal, you would need to break the product down for each of the teams. Then in that increment definition, you would break the work down. For example, if you’re using SAFe® and you are doing the backlog preparation for Program Increment Planning (PI planning), you would break the work down, and you would probably get it aligned to teams before you start the big room planning exercise. You’d do exactly the same with Agile Lineout. Or, you could use Sprint Planning One and Sprint Planning Two that's based in Large Scale Scrum (LeSS).
Q: While improving performance and building high-performing teams has been the focus for a while, having sustainable performance and building diverse and innovative teams is a better goal. How does Agile Lineout address building diverse and innovative teams and sustainable performance?
Ward: Again, this is based on context. You may not want innovative teams, in terms of solution, if you're trying to deal with a compliance activity, for example. Or, if you’re doing an enhancement to an existing software product, you may want the teams innovative about the delivery process, but not innovative about the outcome.
I think that sustainable performance is absolutely right, but don't forget that one of the principles in Lean is continuous improvement, and the whole essence of the PDSA Cycle (Plan-Do-Study-Act) in Deming is that we're looking for learning and enhancement and improvement. I think that sustainability is fine, but I'd like to see sustainability and continuous improvement, and that doesn't mean I'm continually stretching the team. I'm rather suggesting that it's about the team learning better ways.
The other thing is, by looking at the metrics, you can stop the team from becoming complacent. I really get concerned about the concept of servant leadership taken to its extreme. If you go back to the original articles and books around servant leadership, it's about leading with the context of the team in mind. But there's still an element of leading and I absolutely support that. So I think challenging the team is good. If the team is producing 30 story points every sprint, then why can't they produce 31? What would they need to do to produce 31? It may be that the ecosystem that the company has provided doesn't allow them to do it, but there might be some other things that they could do. Agile Lineout deals with this by looking at the context of the team before deciding how to proceed.
Q: To perform the retrospective in the middle of a sprint sounds like a great idea, but how do you deal with sprint metrics changing the horse’s behavior in the middle of a sprint?
Ward: The answer to that is to try it. Have you ever watched a football — even American football — game where they say it's a game of two halves? The team comes off the field at the half, they get coached, and they go back and they play a totally different game. This is a huge opportunity.
Think of timeouts that coaches call in basketball or American football. The timeout is all about coaching in the middle of the game. When dealing with sprint metrics, you wouldn't change the sprint metrics for the sprint. The sprint would still be a static goal because you're not changing the goal; what you're doing is saying how can we improve what we're doing today?
If when you set out when you do your sprint planning you say we're going to achieve 60 story points, the team will be asking in the middle, are we going to achieve 60 story points or could we achieve a little more? That could give you some corrective actions in the middle of the sprint. The sprint review is where you really consider the metrics. Did we achieve the 60 story points that we said we were going to achieve? What's the current risk level? What's the burndown like? What was our control? All of that stuff. The sprint review is the status report at the end of the day; it's not the retrospective. The retrospective is around improving performance and improving quality.