By Rebecca Jones
In Episode 35 of The Board, we talk about:
Paul Flewelling: Hello and welcome to Episode 35 of the Board. My name is Paul Flewelling. I am an Agile Coach here at Boost. I am joined today by my fellow coaches…
Kirstin Donaldson: Kirstin Donaldson.
Gavin Coughlan: And Gavin Coughlan, also an Agile Coach here at Boost.
Paul: Today, we’re going to talk about Agile Fluency and, in particular, the next stage of what I’ve been calling the “next stage” just to confuse these guys. So…
[crosstalk]
Kirstin: [laughing]
Gavin: …So you’re calling it the “next level” now?
Paul: The next level, OK.
Kirstin: Oh no, you keep changing things.
Paul: Yes, changing it up.
I was talking to these guys earlier and I’ve got a team who I’ve just started working with over the last couple of months. They’ve started to focus on business value and I’m considering the next stage for these guys in terms of my coaching with them.
We’ve already started to shift in certain directions. I just want to have a conversation about what you think would be good directions to move in and so on. And what your experience of working with teams…
[crosstalk]
Gavin: …So at the moment, first of all, what do you mean, you’ve got them focusing on value? Is that focusing on business value?
Paul: That’s right. There’s been a shift from traditional requirements gathering to user stories. The user stories talk in the user voice. Because you’ve got the user voice aspect, you tend to focus more on delivering business value. You’re delivering value to your end user, which ultimately, is what pays your business’s bills.
Kirstin: I’m looking at a diagram we’ve got up on our laptop here, by Martin Fowler called “A Team’s Path through Agile Fluency.” The start of it is building codes that would be what your team that you’re working with is doing before you started working with them, right?
Paul: That’s right.
Kirstin: Now they’re all focused on value, the next step there is to deliver value. So the focusing on value is concentrating on getting those requirements…
Paul: That’s right, and getting them…
Kirstin: Defined in a way that focuses on the…
Paul: Prioritized so that the key thing here is getting the product owners to…I heard of a really great thing the other day, which was how to know if you’re a product owner or a Scrum Master. Product owners focus on growing products, and Scrum Masters focus on growing people.
The product owner is…what we’ve done in the first stage is get the product owner really focused on business value, in terms of those user stories, and breaking those requirements down into discrete chunks of work.
Gavin: Was that a difficult transition for them?
Paul: It was a bit, because they were firmly in the mindset that everything was of the same priority and so on. So we had to get them thinking in terms of the value they were delivering, and particularly about the personas or the people they were delivering the stories for, and who with. Getting them focused on the most important features or aspects of those features.
Gavin: Have they created personas? Did they say, “What’s this…?” [sigh] Some of the starts of some of their stories, as opposed to as a user, do they have…have they redefined the service?
Paul: No. They have insurer, supplier and repairer.
Kirstin: They do have types?
Paul: Yeah, they do. But I think they could go a step further and trump, especially their insurers — some of them are quite big players. They could break those down a little more. I don’t know. It’s really up to those guys, but we do have personas as an insurer, or as a supplier or as a repairer.
Kirstin: What are the changes that you’ve seen in terms of how the team are working and what they are delivering since there has been a greater focus on value?
Paul: The key thing I’ve seen, has shifted to understanding that not everything is needed in the feature to make it worth, or releasable, or shippable.
They’ve realized, now, that they can go anywhere for one of the stories they are currently working on, which was estimated around the 40 points as an epic, 40 to 50 points as an epic. They’ve broken it down into discreet chunks of roughly 3 to 5 points.
They’ve realized, for a releasable piece of software, they can actually just deliver just under half of that. They’ll gain back 20 points.
[background siren]
Kirstin: This must mean then that they are actually able to move more features through a sprint.
Paul: It also means that they can get…
Kirstin: …or stories released.
Paul: It also means that they can get their endthrough in front of their actual client much sooner. They obviously got many different clients. Their software is used by…I can’t remember how many they said, but it’s used by a lot of different people.
Gavin: A few thousand, at the moment. Three to four thousand, I think it was.
Kirstin: Do they get good feedback from their clients, or any feedback? Did you notice their mechanism for feeding back on new features?
Paul: I don’t know how they gather that information. They do…
[crosstalk]
Paul: …the product vendors do talk directly to their clients. They do get good feedback. They’ve got some key liaisons at each of their clients who they will talk to regularly about what’s been delivered and whether it suits their needs or not.
They are doing some key work for one of those people, in particular, at the moment. They’re talking quite in detail with that company to get the requirements right or to use their stories correct. All of those things.
But they’ve realized, and their client has realized, that they don’t need all the 40 to 50 points of that epic delivered in order to have something that is usable or of value.
Gavin: That’s a really good point to get to because, I was saying that to a lot of people, that’s really hard for them to change that sort of mindset where you have to have absolutely everything on your wish list done before it’s worth anything.
I think that’s a really good stage for the team to be at to understand that you can deliver early.
Paul: Now, of course, there will be a period, probably, where the client goes away and assesses what they’ve got and comes back with further changes or enhancements and so on.
In the meantime, the team can continue and work on other features for other clients and there’s no block of the other client’s work. They’ve delivered something that’s usable in two sprints.
Roughly, maybe a bit more work this sprint so there’s three sprints of work. They can now focus on other client’s needs while that client goes away and thinks about what they’ve delivered.
It’s a really a good way to break down the work and still deliver something of value and get that feedback as soon as you can.
Gavin: Absolutely. That’s the stage that they are at now, which is focusing on value. The next level is delivering value.
Kirstin: Surely, if they’re focusing on value, then they are already delivering value at the same time. What’s the difference between the stages?
Paul: The deliver value is where you start to increase your capacity to deliver value. What that deliver value is really talking about is increasing quality, for example. Mike Cone, for example.
There’s two schools of thoughts around story points, I was reading an article he wrote the other day about this, you either have story points associated with items on your backlog that deliver value i.e. new or enhancements to features. Everything else that comes through that team’s backlog is not scored in terms of size. It’s just a meteor or a critical bug or a spike.
Nothing else is sized. There’s no attachment of story size to it. It only focuses on what the team can deliver in terms of value and everything else is just maintenance work or business as usual. If you work in the alternative school of thought…
Gavin: I quite like that, just want to butt in there. I like that idea, actually, because that means that, say your philosophy, at the end of each sprint, is going to be really how much value you delivered as opposed to how much work you got through. I think that’s a pretty interesting sort of slant to it.
Kirstin: Goes back to this idea of focusing on delivering value after focusing on value. Would that mean then, rather than focusing on getting features through the sprint, you’re then looking at making the features more valuable?
For example, ensuring quality. It’s not just on what you’re delivering, it’s the quality of what you’re delivering and how you’re delivering it.
Paul: That’s right. Some of the problems these guys have got, for example, to ensure quality — a lot of software companies do this — they have a regression test. The regression test is so long, it’s days at the moment. They’re working on automation.
Kirstin: They do that after all of the stories or is it on a story by story basis?
Paul: They basically do that in terms of releases. They will do a regressions test and able a release. I think that’s the way they are doing it. It’s outside of the sprint. It’s nothing to do within the sprint.
Of course that regression test will feed work back into them, at some point. They’ll have to pick that up in a subsequent sprint.
Kirstin: It’s weird that they might not find out about it until quite far down the line, that they left behind a couple of sprints ago, basically.
Paul: Exactly. There are some problems with that in the sense that, one, you’ve got the distance in terms understanding what the problem is because it was two sprints ago. You’ve moved on to something else and then you’ve got to fix the problem. It takes a while to get back into that context with someone.
The other thing, of course, is that the person who originally did that work probably isn’t going to be available. It’s going to be a picked up by another team member anyway.
The regression test thing is, for example, talk about how we can help them deliver software value, that they can deliver value much sooner if their regression test was happening in their sprint.
Kirstin: Can you check if we have any questions? We might not do that.
[background noise]
Paul: …just something from Ricker about what we’re talking about.
[crosstalk]
Kirstin: …Oh right. Thanks Ricker. [laughs]
Paul: That’s what we’re really focused on now is the deliver value aspect so and how we get that work close those sort of feedback loops down as quickly as possible to get them to deliver something of quality, because of course, if it’s not of quality then they will be working…they’ll be doing that other work in their sprint. So they won’t be… They won’t be delivering value they’ll be delivering…
[crosstalk]
Kirstin: How feasible is it to have an open regression test within a sprint rather than doing it at time of release? Is that going to hold up things more?
Gavin: Well, if it takes days it’s problematic to fit in to [indecipherable 10:54] and like Paul said they’re working on automating tests at the moment. Which is…
Paul: The kick in the regression test is that you’re testing, not only are you testing the software that you’ve changed, you’re making sure that everything else works.
Kirstin: Is there another approach that a team can look at rather than doing this sort of usual regression testing like continuous integration? Or…
Paul: Absolutely. That continuous integration but they need an automatic test way to do that, that’s the key…
Kirstin: It’s quite a bit of work to get it in place but the benefits longer term surely point towards it being a good solution.
Paul: My understanding is they are doing continuous integration they’re just not testing it before they integrate, which of course causes problem because then you are doing the regression test to get your confidence levels high before you deploy. Of course that regression test means they’ll always find problems…testing will always find bugs.
Kirstin: Which is one of the reasons we will edge our practices, do it as they go so for test and development.
Gavin: The…still the difference between focusing on value and delivering value…still curious to know about how the… how you make that leap? How you bring it to that next level? How do you coach a team through that? And obviously this is something you are thinking about at the moment…
Paul: …Just to go back to yeah…Sorry.
Gavin: Do you have any ideas about that just to know exactly what delivering value means as opposed to focusing on value?
Paul: Interestingly enough, they’ve asked me recently about …they need a consistent approach to the way they story point their work…Whether they estimate everything or they estimate just the stories that deliver value or just the value and they just want a consistent approach across the company.
Like I said, the alternatives is you only estimate work that delivers value or the other school of thought is you estimate everything that comes through your system. So all you’re doing then is the first way you are measuring the team’s capacity to deliver value the second way you’re delivering the teams capacity to work.
Kirstin: To deliver work.
Paul: What you’re never going to get from that second approach is how much value they’re delivering. You’ll never be able to measure how much value they’re delivering.
Kirstin: Yeah, amazing. It could be a page.
Paul: If you go for the first approach, where you actually estimate the stories that deliver value then you’ll have a very clear understanding, because if a team’s velocity drops it’s going to be for two reasons. One, they’ve stopped working or two they’re actually busy doing other stuff.
Kirstin: Which is a problem.
Paul: Which isn’t delivering value for them.
Kirstin: This is one of the ways of shifting the focus to delivering is to have these conversations around estimating…
Paul: That’s right.
Kirstin: And how they could identify value.
Paul: Once you start to focus on the value only, kind of, then everything else doesn’t get attributed to the story size, then you either say, “Well this sprint we delivered nine story points, three meteors and a spike or two spikes.”
You’re just labeling the other things you’re saying we did do all. “We did all of this work but we are only actually dealing with nine points of value.”
Kirstin: And you know you can still see… say management comes along and says, “Why have we only delivered x points of value this [indecipherable 14:20]
[crosstalk]
Kirstin: …And still visibly see on a board, presumably, the reasons why. We’ve had four meetings.
Paul: The four meteors for example, if the team is under that kind of load in terms of meteors then that’s a critical bug. They need to work out how they can solve that going forward to stop that from happening, because they really want to deliver value. Value is where the fun is or the explore, that’s the exciting part of our jobs.
Kirstin: Well nothing…everybody wants to deliver value.
Paul: That’s right and so…the story points have highlighted that they aren’t delivering enough value so now they can focus on how to reduce the other things that are happening in their sprint and how they go about that is really up to…
There’s different ways of skinning cats of course. But I would be focused on testing early and reducing the number of meteors or regression test bugs that were coming into my sprint, so I can focus on value.
Gavin: Interestingly just as a bit of an aside, as far as this team when you started working with them really wanted to increase productivity and the value that they are providing and when scrum was introduced they saw a dip initially. That worried them, and once they’ve gotten into that…into the groove of things I suppose they’re starting to see it.
Kirstin: Which is quite often what happens when people make a change from one way of working to another way, particularly with scrum.
It can be worrying you know to start a new project with a client that’s new to scrum to see the first sprint maybe not be as productive as they might have imagined. Like I said to coach them on.
[silence]
Paul: …coming from that regression test that they have to fix. Interestingly enough what they’ve done now is set up what they call tech teams.
One tech team is called the A-team and it focuses on fixing problems that are cropping up in terms of regression testing and so on or critical bugs or meteors and so on.
I think it’s a reasonably good approach you know taking the…allowing some of the teams, the feature teams, to deliver our new feature work and value.
Kirstin: To keep moving forward rather than going backwards.
Paul: And then you’ve got the tech team, who they…the A team…who they rotate…each team rotates a member each sprint into this…
[crosstalk]
Kirstin: …right so everyone has got that.
Paul: Now my focus with these guys is to say, “Right. No one wants to be in the A- team the A-team is you know…”
Kirstin: Despite the name.
Paul: The A-team is a great team to be in right now but the aim of the A-team is to make itself redundant.
Kirstin: You want to eliminate the A-team. What’s the other team called?
Paul: They’re just the… essentially, tech.
Kirstin: They’re not called the “B-team” then? [jokingly]
Paul: No, they’re not called the B-team. [laughs]
[laughter]
Gavin: There is no B C or Z team or anything.
Kirstin: There’s two teams ones called the A-Team.
Paul: So those guys… so there’s also a separate operations group. The tech team’s focused on support in terms of infrastructure and support and operations focused on infrastructure entirely.
Gavin: I’m interested about… because obviously we are taking this from the flow chart of the road map to Agile fluency…
Kirstin: Can we look at that?
Gavin: …And we’ve talked about focusing on value and delivering value. Just be interested to talk because there’s four stages.
Kirstin: We’ll pop a link up to this afterwards
Gavin: Yea we’ll put a link up to the diagram afterwards. The next few stages are optimize value and optimize for systems and the fourth stage of agile fluency is very rare for people to actually get to.
But I just wanted to maybe just quickly talk about what that third and fourth stage mean, beyond focusing and delivering value, so there’s optimized value.
Paul: The simple way of putting this is that when the scrum teams get quite efficient at what they’re doing, they will start to work much faster than the organization around them in order keep up with, and so they generate friction points, basically.
So optimizing value is about analyzing the friction points, and working out where their external teams are effecting their delivery teams’ ability to deliver value.
Simply put, that means basically, and depends on the organizational set up, but you’re looking at breaking down the silos the organizations have created. And this is where we start to analyze what we call a value stream.
The value stream is everybody that’s involved, from the point that the idea happens, to the point that you deliver something that solves…or gives…
Kirstin: Provides value to a user.
Paul: That’s right. So you look at each person involved in that chain, and you analyze. You might actually value stream map it, so you’re looking at touch points for different people, and you’re also looking at the hand-offs between the different stages as well.
Gavin: So you see where delays are actually occurring.
[crosstalk]
Paul: You’re trying to reduce the waste as much as possible.
That’s specifically the teams that are affected, so the immediate touch points for the scrum team, usually, that you start to optimize that value delivery on.
Say if you have a separate operations team sitting outside of the scrum teams, then you will start to optimize how you engage with the…or have the scrum teams engage with those operations.
And what this particular organization have done is they’ve got their ops team, which is their the team, who liaise with the ops team to get things set up in times, like in different environments and so on, for the teams to test them and so on.
That’s sort of the next stage of optimizing value, and that still hasn’t changed the organization as a whole, that’s just changing the delivery of value.
Gavin: So optimizing the fourth stage then
Paul: And so that hits the program, that’s the ceiling of, there is the program level and then the fourth stage is really when you’re going up higher into the executive level, I guess.
Gavin: Optimizing the entire system basically.
Paul: Optimizing the way they want work to be done, and educating to understand how they can get the best out of their delivery teams.
Gavin: These four stages of agile fluency, would they apply more to enterprise organizations? Or would it be any sort of an organization?
Kirstin: I don’t know. I don’t think so. I think a lot of organizations regardless of their size set up along quite traditional lines.
Gavin: It certainly seems to me that would be easier to gain complete agile fluency in a smaller company than a larger company.
Kirstin: Oh yeah absolutely, but they would still need to identify the changes they need to make in order to achieve that. You are right, I think that it’s going to be a lot swifter. So it is going to be much swifter when you’ll send it in together, you can just communicate much like across the room.
Paul: So for example, the scale agile framework, what they call the third stage is where you create your agile release train. The agile release train is entirely focused on…It’s everybody that’s needed to deliver that particular product or program.
And then the top level stage, or the fourth stage in the scale agile framework is what they call the portfolio level. They specifically talk about the House of Lean, for example, which comes from the Toyota production system.
They specifically talk about how companies need to grow people, and then people will grow products and so on.
They’re essentially focused on educating their management to become leader teachers, and have that leader teacher kind of mindset, where their expertise is needed and wanted.
It’s just the way that they spread that expertise or share that expertise with the people that are building the products, or delivering.
Gavin: I was reading a few things this morning, and see that there as a talk over in the Rally Conference in Washington at the moment, called “Scrum is dead.” Obviously quite a controversial title and something that I’d like to see, so I’m hoping that we’ll [indecipherable 22:57] that talk.
Kirstin: It’s talking about working beyond scrum, wasn’t it? It sounds a bit dramatic.
Gavin: Yeah, well you see, teams that are using scrum, they have a rise in productivity and rise in team morale and everything’s great, but then a lot of them reach a point, possibly a stagnation point where things start to drop off a little bit.
So what do you do beyond scrum? That’s an interesting idea.
Kirstin: Well it’s something we’ve been looking at over the last six months with one of our teams here, isn’t it, and I don’t think we’ve come to any conclusions yet.
Gavin: No but when we do trainings, a lot of the times when talk about “scrum locks,” people are completely new to agile and scrums is a good way of getting that idea across to people. I think scrum is a really good — like you’ve called it a few times — set of training wheels.
In fact you have a great way of drawing the scrum process where it actually looks like a tricycle with training wheels, very impressive.
Paul: Looks like Cartman riding a tricycle.
Gavin: Yeah that’s right.
[laughter]
Gavin: Scrum is really great for that. Sometimes I think teams who want to be agile jump into Kanban possibly too quickly because they don’t fully understand that they need a bit of a framework to help them be agile as far as…
So that’s something we’re looking into, if anybody out there has any great ideas about how to coach a team, whose reached that point where they’re starting looking beyond scrum, would be really interested to hear that stuff.
Kirstin: We’ve been thinking here about what’s next [laughs] for that particular team, other newer teams that are still working on scrum?
The advantage for me is scrum is that it’s a very set group of activities and roles, they’re very simple to follow.
And because the same things happen during each cycle, it’s pretty simple for everyone to get on board with. And I don’t think it’s simple for everyone to master straightaway, but it’s really simple to understand at the outset.
Paul: Gavin and I had a conversation last time where we were talking about scrum versus Kanban, for example. The scrum approach is really…We build a lot of new products here. We work with a lot of new clients who are building, innovative…
Kirstin: Just recently, yeah.
Paul: …And scrum really works really well with that because it’s an empirical process. We can test something out, we can test ideas out for the client and they can see whether it works or not. We always got that constant checking, whereas I think Kanban is more suitable to something that’s gone into a “business as usual “state maybe or…
Kirstin: Yeah I think so as well. It’s really just helping people focus on, well my understanding anyway, prioritization and moving things through the cycle, rather than taking in those set points to reflect and test, use this for example.
Paul: That’s right.
Gavin: Actually I think we’re running out of time a little bit,
Kirstin: Five minutes.
Gavin: We’ve got five minutes?
Kirstin: Yeah.
Gavin: But I do want to explore this “beyond scrum idea” a little bit more, perhaps that’s the title of another episode of The Board.
Paul: I know of a lot of organizations its finally got to that stage. A lot of organizations started experimenting with their jobs by having scrum teams, and they either created more scrum teams or it kind of died.
But usually, most organizations we know of, if they’ve experimented with a couple of scrum teams, and they are at that stage now where they are moving beyond scrum. And that doesn’t mean necessarily scrum isn’t appropriate for their teams still, it’s just that you need different ways of…I was going to say control but it’s along with the process.
Gavin: On the flip side, I’ve seen a lot of teams, recently was talking to a team who they brought on scrum, but they actually got rid of the bits that they found difficult.
Kirstin: Such as?
Gavin: Such as retrospectives and … It was utterly terrible. These people had some problems within their scrum teams and I said “Oh, well here are you guys addressing these and the retrospective?”
Kirstin: And they address those, yeah.
Gavin: And they said “Oh we don’t do retrospectives”
Kirstin: It’s very hard to address problems if there’s never a place to sit down and look at them, identify them.
Gavin: Yeah that’s what happens. Either team experiments with scrum, and they lose bits like that, and lose a lot of the benefits, or else they stick to it, see a lot of the benefits then start to really create value and then, I suppose, look beyond that and try to modify it themselves…
Kirstin: So you’re saying you think people need to feel like they’ve nailed scrum before they can move on?
Gavin: Yeah. I do it’s like Picasso…
Kirstin: Not just dip in it
Gavin: Picasso didn’t get into cubism at the start. He was an artist before he started throwing away the rule book.
Kirstin: A proper artist before he was a cubist? [laughs]
Gavin: He was a proper artist, yeah [laughs] .
Kirstin: The stuff you could actually try…
Gavin: He could actually draw proper pictures like…
Kirstin: You could see that it was a house.
Paul: I’m not going to get into the conversation about the local library having useful art sections and art sections…
Kirstin: Do they? Interesting.
Paul: Useful art in arts.
Kirstin: Oh yes, I [indecipherable 28:02] you said.
Paul: But anyway, I think…interesting enough, and there’s people like Woody Zuill who we talked about previously on the show in terms about the No estimates movement and the mob program.
They’ve moved well beyond scrum. They do use a Kanban type system to flow their works with this. So they’re focused on flow, so I think Kanban…
Kirstin: But it depends on what you want. You’re saying their focus is on flow, and then the other ten focuses might be on quality.
Paul: That’s right. What they found with the mob programming is they get ultra-high quality because everybody is involved in building. And then the no-estimates approach is just because they’ve optimized the product backlog items to flow through the system.
Gavin: And that’s controversial, We had lunch with a group of people a while back and you mentioned the no-estimates movement and you got up and walked away from the table.
Kirstin: [laughs] Was he left alone or what?
He wasn’t impressed by that thought, was he? But you know, I guess it takes decision to break the rules like that, doesn’t it?
Paul: That’s right, and you’ve got to experiment.
Kirstin: It’s experimenting.
Gavin: And I think you want to break the rules to make things better, not just break the rules because you’re finding it too hard.
Kirstin: Yeah that’s right. So you want to give things a go first.
Gavin: Anyway I think that’s about…
Kirstin: Yes I think that might be us for today, so thanks for joining us.
Gavin: Yeah, and we’ll be back in two of weeks to talk about beyond scrum, maybe.
Kirstin: [laughs] If we don’t change our minds.
Paul: I look forward to it.
