Dr. Dan Rawsthorne

Large Scale Scrum and Cosmic function points with Dr. Dan Rawsthorne

Back in 2007 I worked with Dr. Dan for a number of years. I don’t always agree with Dan … and in fact we’ve had long arguments about many of the topics in Scrum. I remember a cold and wet road trip with him in his 1980’s Jag, travelling from Seattle down to Portland. We debated all the way there and all the way back!

I’ve always found that every time I talk with Dr. Dan I’ve learn something new, and our conversations have always been in good humour with lots of laughter. This conversation is no different … the conversation wanders through a variety of topics from Dr. Dan’s introduction to the Scrum community, his book and the new book that he’s writing.

Dr. Dan’s book is called Exploring Scrum: The Fundamentals and you can buy it online.

About half way into the interview Dr. Dan starts talking about Cosmic Function Points. I almost sounds like a new age approach to Agile software development but he’s really talking about the complexity of the data flow between components in a system. It’s an interesting concept, although I think he could have chosen a better name!

Update: Wow, I suck! Dr. Dan points out that COSMIC is an abbreviation of Common Software Measurement International Consortium which is

“.. a voluntary, world-wide grouping of software metrics experts. Started in 1998, COSMIC has developed the most advanced method of measuring a functional size of software. Such sizes are important as measures of software project work-output and for estimating project effort”

As I mention above, I learn something new every time I speak with Dr. Dan, and this has been no exception!

Dan spend many years in the Military and this comes across in the interview as he frequent draws analogies with Military practice and life. I especially like this quote from the end of the interview were he talks about the how the Army scales and says:

… the pattern works. We know it works; it works in a complex domain called warfare and it’ll work in a very complex domain we call software. -Dr. Dan Rawsthorne

Here’s the interview:

Transcript

Q: What I would like to talk about is how you got into Scrum? That’s really what I would like to talk about, and I don’t know if you have any stories — I’m sure you do. But, what I’m looking for, are any stories that you might have about what sort of… brought you to the Scrum community? And you know, what are some of your thoughts about Scrum and finally, what are you currently doing now? So, the way that I see it, the interviews are really in three parts. The very first part are, you know, what brought you here, what are your thoughts about Scrum and finally, what are you doing now? Really, the idea of what you’re doing now, is to find out, what’s current in your life but also, for you, if you want to promote something,
Dr. Dan: Okay.
Q: …if you have a book or something that’s coming up, that you’d like to promote, then feel free to do so.
Dr. Dan: Okay, well for its interesting is that what brought me to Scrum, is, I have to go pre 1990 actually, before Scrum existed.
Q: Yup.
Dr. Dan: And I was, well maybe, 1991. When did Rebecca Wirfs-Brock’s book on Responsibility Driven Design [come out]? It was about 1991 or 1990, something like that — and just before that, the Small Talk Community was just, there was no internet too, to worry about so, it wasn’t being spread as fast as it was but, you kept hearing about it. So, the first few OOPSLAs [ed: a conference on object orientation] that I went to, in the early 90′s and I was into use cases and object orientation and small teams and the whole low-ceremony stuff that was going on at the time.
And it already actually matched, what I had been doing in the military for the previous decade. And what was funny is, I’ve always, how do I put it? My teamwork philosophy comes from the military, with this, the small team tactical self-organizing teams, what we call in the military as, ‘Small Unit Leadership Training’, which I had in the 90′s. And as it turns out, as I found out later, after I learned about Scrum, that Small Unit Leadership was exactly Scrum, you know?
Daily meetings, self-organized discussions, a single commander making decisions about ‘what’s next’, people helping — ScrumMastering everywhere — trying to make people better as you bring them up. And so, it was very cool. But, so I guess it started in ’94 or so, with object orientation, moving into it, I met Linda Rising. I met Kent Beck at a ’94 PLOP [ed. conference on Patterns], where we talked about XP. In 95, I was at the same conference, I was actually talking at the same time, as Ken Schwaber introduced Scrum.
I was talking about Agile use cases and incremental use-case development, in order to support an XP team that, because you know, XP is only about the coding and . . .
Q: That’s right.
Dr. Dan: . . . how about the onsite customer? And so I said, ‘The onsite customer needs to be another XP team’ and so we were as busy, experimenting with that and then along came Ken, and said, ‘Scrum.’ And I said, ‘Oh, that’s exactly, that’s the word. That’s what I’ve been talking about for the last two years.’ So, that was funny and Linda Rising came into my room and said, ‘Oh, I was at Ken’s talk’… oh, she came in first, ‘I’m not going to come to listen to you Dan, I love you but, I’m going to go listen to Ken’ and then she came afterwards and says, ‘Too bad, you weren’t there’, but I was doing my thing over here.
Q: [laughs].
Dr. Dan: And so, that’s kind of, when it started and I was doing a lot of DoD kind of stuff and trying to do this, Agile stuff.
At the time, there was nobody calling it Agile, except the army because ‘Agile’, is the army’s word. In 1982, it’s a funny story, it’s a funny story, it’s in my book, I do have a book. But, in 1982, we started doing Agile Software Development . . .
Q: Yup.
Dr. Dan: . . . in the military and we called it Agile Software Development.
Q: Were you still part of the military, at this point?
Dr. Dan: In 82, I was, yeah. In 96, I was doing DoD contracting. . .
Q: Right, okay.
Dr. Dan: . . . and so, and I stopped that in 96 and I had ten years and went and did other sorts of contracting, I decided I didn’t want to do DoD stuff anymore and came to, came to Washington at that time, in about 97. I was working on a gig, down in, actually a gig down in Northridge [California]. Worked building an Avionics System for the Australian Navy. . .
Q: Cool.
Dr. Dan: . . . which is kind of funny. We were using RUP. And we used a very agile form of RUP, where we divided into small teams, which were made up of like, four person cubes. So, we had four people on a team and they were busy working and we were use case driven and Agile and having daily meetings and lots and lots of feedback from the Aussie pilots. It was kind of a, big Scrum Team. We were calling them XP Teams because we didn’t have the word Scrum, but we had XP teams that did the coding and XP teams that did the analysis and XP teams that did the management and XP teams… you know. And it was all connected in a network. And, it’s no different than the same pattern I’m using now but, now calling them Scrum Teams.
Q: Right, yup.
Dr. Dan: So, and then along came the word Scrum. I first heard it in 90, I heard it in 95 but, I wasn’t using it and so, probably I started using it in 98-99, something like that. And so, I started training in Scrum, which was where I first met Michael. . .
Q: Michael?
Dr. Dan: . . . Michael James.
Q: Oh, yup, yup, MJ.
Dr. Dan: Yeah. I was at Net Objectives, I mean I was already training at Scrum, at that time. Agile use cases, Scrum, we were teaching . . .
Q: I didn’t realize that you and MJ went that far back?
Dr. Dan: . . . yeah. I was teaching at, I was working at Net Objectives and he was at Danube. And I actually taught Scrum to Danube.
Q: Oh, interesting.
Dr. Dan: Yeah.
Q: Oh, that is interesting. I didn’t realise that. . .
Dr. Dan: And so, the first time I met MJ, he was in a room, we were talking about it, I was projecting, we were talking. He was sitting over there being very snarky and interested and stabbing back, and it was great fun. And you know… that great sort of love/hate relationship you have with MJ very easily, because he’s just such an asshole… but he’s such a smart asshole that’s it’s worth talking to him, you know?
Q: [laughs].
Dr. Dan: And I’m sure he feels exactly the same thing about me, very sure he does actually, [laughs]. So you know, we’ve gotten closer over the years but, that’s where it started. So I don’t know what year that was, probably 2001 or something — 2002 at the latest. And then what happened? Then I was in the first or second Scrum class, the first one that was in Washington, I was Scrum master number 27. . .
Q: This is Washington state, not Washington?
Dr. Dan: . . . Washington state, yeah. Evidently, it was like the third course or something. I think he taught one in Europe and then one in, a small one in Europe that, Bas [Vodde] was in, like the very first Scrum class and then he taught another one, in Boston, in his hometown. He taught another one, in Seattle.
Q: These aren’t proper….
Dr. Dan: These are the first three CSM courses, the first ones that he labeled CSM course and gave out certificates. . .
Q: That was 2003-2004?
Dr. Dan: . . .2003, 2003, I think May, 2003 something like that. I think he started in February and taught a few classes and so, we took, we put a lot of people there. I was in it, Doug Shimp was in that class, Rod Claar was in that class and all three of us are trainers now, you know. So, I loved it, the Agile stuff is just the right way to go and I’ve always thought it was the right way to go and so, I came to it just organically, I was doing it already. . .
Q: Yeah.
Dr. Dan: . . . and I felt like. ‘Okay, the community moved in my direction’, they had the Agile manifesto, which I’ve never actually signed, nor will I, because I don’t believe it.
Q: [laughs] And why do you say that?
Dr. Dan: It’s one of the things on the second page, that you’re also signing up for. The 14 statements on the second page, that Alistair Cockburn wrote… and one of them is, ‘We believe that the best architectures are built by self-organizing teams’ and I don’t believe that. I believe — my statement is: ‘I believe the best architectures are developed by geniuses, but you don’t have one so you should use a self- organized team.’
Q: [laughs] You could use that as an excuse for just about anything though. Couldn’t you say that for, just anything, anything done by a genius is better than, something done by an average person?
Dr. Dan: Well, that’s the only one stated like that though.
Q: Okay, fair enough.
Dr. Dan: It’s the only one that has an absolute, we believe that the best, you know. I mean, I love the manifesto itself, the preferences… and it’s not dogmatic and… You know, I used to, it’s a rant against large, it’s partially a rant against large agility like Scrum, like RUP, and I like RUP, RUP, when done correctly, is a nice agile little thing, it’s just . . .
Q: Yeah, we’re going to have to agree to disagree on that one, yeah.
Dr. Dan: . . . No, I don’t mean it that way. It can be done in an Agile way. No, it seldom is, I’m not going to disagree with you, it seldom is, because it’s so heavy weight, you get lost in the details and you can’t find your way to the agility. There’s no doubt, of that. But the point is, that the philosophy of it, is very agile. It’s just, it made the mistake of being very big and have to be tailored down, whereas Scrum has the advantage of being very small, and then it gets tailored up.
Q: That’s right.
Dr. Dan: So that’s… and that’s what I liked about Scrum actually because it came at it from the right direction, I liked that, because it’s the big tent… Scrum is the big tent. . .
Q: Very minimal.
Dr. Dan: . . . and so that’s why I shifted to Scrum, as soon as it became something I could shift to because it was the big tent. It allowed me to fit all the tips… and put all the agile tips and tricks that I learned over 20 years into that tent. Including the large framework stuff, which by the way, I don’t like either. Bas’s framework or SAFE, for lots of reasons but, that’s another issue. But I believe there are some really good, standard, patterns one could use to build a large organization using Scrum. I don’t think that’s the same as a framework, but it’s essentially the same. I think there’s patterns to use… it… I’m finally writing those down, by the way.
So, that’s how I came to Scrum and I was Scrum Trainer Number eight. I got certified in the same class with Esther [Derby], me and Esther and Ken. Ken got a class in 2005, in Seattle . . .
Q: Mm-hmm.
Dr. Dan: . . . and so, that’s when I got anointed. And, I really liked all the trainers that I met early on. Clearly, we disagreed about lots of things but, they were . . .
Q: But it’s, I mean that’s part of the life.
Dr. Dan: . . . that’s supposed to happen, otherwise it wouldn’t be a living thing.
Q: That’s right, that’s what makes it fun.
And been at, was Agile for 20 years before there was such a thing, as Scrum. And I’m not going to say I was smart enough to be Agile, that’s the way the Army does everything, in a tactical way. Tactical military work is agile and so that’s how we ran software. We consider it as a tactical thing, and because we had to produce a product in a short amount of time… and poof, next thing you know, you’re doing a pretty good simulation of Scrum.
Q: And the Defence Forces are big users, aren’t they? The Defence Forces world wide, seem to be very big users of Scrum.
Dr. Dan: Yes and yet, the contractors don’t want to do it. So, it’s like, there are local teams, the ones you actually have control of, they’re doing Scrum. When they actually have a big contract, it comes out — not agile. And that’s because it, you make less profit, doing Scrum.
Q: [laughs] And that’s bad for, whom?
Dr. Dan: It’s bad for the contractors, they’re the ones who don’t want to do it. The Government has mandated it, actually, it’s actually federal law that, DoD contracts will be Agile. It was passed in 2010.
Q: I thought that was an option. I thought there was the option to be agile but, it wasn’t necessarily . . .
Dr. Dan: That’s the way it used to be . . .
Q: . . . okay.
Dr. Dan: . . . but the National Defence Authorization Act of 2010, Section 804, I can send it to you, says, ‘Thou shalt be agile.’
Q: [laughs], I’ll trust you on this one.
Dr. Dan: And, ‘Please respond within 270 days’ and the response was basically, ‘Ah, we don’t want to do it’, from the contractors. . .
Q: Right.
Dr. Dan: . . . and so, it kind of just, slowly got, buried. There’s still some active work on it, you know, some PMP DoD types, that are happen to be trainers, they’re still pushing it, like me, and Cheng [Richard Cheng] and, you know, a few others but. Personally I’m thinking, I’m going to have to stop my focus on going to Scrum Gatherings and XP and just spend all my time going to PMI (Project Management) sorts of conferences and attack it from the other direction… because attacking… trying to move the Agile community towards proper project management and big projects and DoD and Government work, isn’t working so, you’re back at pushing in the other direction, after a while. So, anyway that’s the first thing, that’s where I came from.
And what was your second thing?
Q: What are you doing now?
Dr. Dan: Well, I’m doing more of the same, I’m writing. I published a book in 2011, I don’t know if you got a copy? It’s called, ‘Exploring Scrum: The Fundamentals.’
Q: I haven’t got a copy.
Dr. Dan: I’m really happy with it. It’s still has legs and I’m coming out with a second edition, pretty soon. We’re basically getting a prettier cover because the cover sucks …
Q: [laughs].
Dr. Dan: But I got some really good… I got Jeff Sutherland, Ron Jeffries, Jeff Mckenna and Johanna Rothman to write forewords for it. . .
Q: Cool.
Dr. Dan: . . . So, I think I got best set of forewords around.
Q: So, tell us a little bit about the book. What’s the premise of the book?
Dr. Dan: Well, the book is, the book basically says, ‘Okay, here’s the Scrum framework, it’s really trivial’ and I used the four major sources. The ’95 talk. the 2002 book, the 2004 book, and 2007 book… and I guess the Scrum guide. And I say, ‘This is what it says, you can see how it’s morphed through time.’
Q: Yup.
Dr. Dan: Now, what’s really going on? That’s why it’s called Exploring Scrum, ‘What’s really going on? What do you really have to do, to make it work?’ and so on. So, it’s a 300 page book, that talks about things like, what’s missing, like, ‘How come the daily Scrum doesn’t actually actively talk about reorganizing your day and just talks about gathering information?’ So everybody thinks it’s a status meeting. Well, that’s wrong, it’s actually about reorganizing, it’s an inspect and adapt point. Where’s the grooming between the review and the plan, in the planning meeting? When does grooming happen, it’s left out? That’s also a bug in the system. BurnDowns are evil, that is the first one that really pushed the fact that BurnDowns are evil and now it’s been removed, pretty much removed from Scrum.
Q: Yeah, that I actually agree. The Sprint BurnDown is bad.
Dr. Dan: Yeah, even the product BurnDown is bad. Maybe less bad, but still bad. Because any proper project, by the time it ends, should have more things on the backlog than when it started. So, then the backlog . . .
Q: Why do you say that?
Dr. Dan: . . . because you have to have good stuff to choose from, up until the very end, you know? And you get — the concept of getting done with a feature, makes no sense. And I’m a use case guy. There’s always more stuff, you just have to decide when to give up.
Q: That’s right, yeah.
Dr. Dan: And so, when you give up, you have to know, what’s you’re deciding you’re not going to do. So, there’s no way, you get to the bottom of the backlog, it just doesn’t make any sense. So, you’ve got to do it some other way. And so, that’s one of the big things. Things like that in the book, talking about velocity and story points and why they’re not about effort but, more about size and exactly, what does that mean? And stuff like that, on how they’re useful for project management, although that book doesn’t go into it, the second book I’m writing now, does.
Q: And so, your second book is the continuation of the first book?
Dr. Dan: It’s about project management. And the concept being that, project management is, itself, needed. Project managers are not necessarily evil, but also, project managers are not on your team. They’re outside the team, observing the team and that, it’s okay to have a management team whose job it is, to control the many to many relationship between projects and teams, somebody has to manage that. And somebody also has to make sure that the project plans match the reality of what’s really going on.
Q: Right.
Dr. Dan: And so, I come at it from the PMI perspective. I got my PMP as well. I didn’t have it when you and I left but, I have it now. And that, how’s it go? The Project Manager has two fundamental jobs, one, create a plan in the first place and two, keep the plan consistent with reality. Bad Project Managers try to change reality to fit the plan and good project managers know they’re supposed to change the plan. So, that’s an inherently agile thing. So, I talk about the contract between the team and the project manager… visibility, give him all the information he needs — good decisions on this side.
And so, I had a hierarchy of leadership you know, The Scrum Master, the product owner, which is really a role, not a position. So, the Scrum master, the team lead and the project manager and different leadership positions, two formal, one informal; and talk about the different things that they balance, what is it that they’re balancing. So, the Scrum master’s helping the team balance speed versus quality. Product… team leader’s helping balance chores versus capabilities, and the project manager is balancing cost, scope and schedule. And then, what flows up is a given to you, how fast a team moves is not something you can influence, you’ve already got people doing that.
So, this is a whole tiering of agility. That’s part of the scaling patterns.
Q: So, is your second book about scaling?
Dr. Dan: That’s what I’m trying to work on, now. Scaling is like, one sixth of the book but it turns out that scaling’s so big, I’m actually going to divide the book into three. I was thinking about that yesterday. One book on Sprint Planning, which, I mean release planning, which talks about how to calculate story points, how to do a release plan, how to monitor a release plan, that could be one subject. Another subject is on analysis, which is about Jeff Patton Story Mapping, because he’s never going to finish his book and he gave me permission to write about it and also Storyotypes, which I’ve been talking about for almost a decade now.
And then another one, on the scaling — project management and scaling. And those might be three different things, it might be one big book, it was originally designed as one book but, I might just decide to release it as three short booklets, haven’t decided, short books.
My book, is self published through Amazon’s Create Space. . .
Q: Okay, cool.
Dr. Dan: . . . so, I’d show you a copy but, I sold them all today.
Q: Well, I was about to say, I might try and grab a link to it, if that’s alright. I’ll try and grab a link and I’ll put it, when I write a blog post about this, I’ll include the link as well, so that people can link through, to your book. I’m assuming that . . .
Dr. Dan: Here’s the name [pause], that’s the name, ‘Exploring Scrum; The Fundamentals, 2011. You can find it on Amazon for sure.
Q: Okay.
Dr. Dan: And.
Q: I’ll do that, I’ll look it up and I’ll include a link so that, if people are interested, they can go through and buy the book.
Dr. Dan: I really want to keep the project manager outside the team, that’s the key lesson. I think, the current trend towards thinking that the Scrum Master can be the project manager, is just the stupidest thing I’ve ever heard.
Q: Yeah, not a good idea.
Dr. Dan: No, it’s, in your typical droll understated way, it’s just the stupidest thing I’ve ever seen. That is truly evil, there’s no way that could possibly be good.
Q: Yeah, I agree with you there, absolutely.
Dr. Dan: And technically, if you only had a project coordinator, it could work, if you had a very mature team and you had a safe organization. But you know what, it’s still risky. So I think, for the same reason the Product Owner and the ScrumMaster should not be the same person, the Project Manager should be neither of those people, for the same reason… because it’s always about the mischief, you can call it. The mischief you can change and not having the right conversations, being had in the open, you need these people to fight in the open, that’s the idea.
Q: Yeah, absolutely.
Dr. Dan: And so, you need that project manager to be yet another person, so that the appropriate fights can be had in the open as well.
Q: You got to have that separation of responsibly?
Dr. Dan: Separation of responsibility and accountability, absolutely. Your head hurts, if you try to do two of those things at the same time.
Q: Absolutely, absolutely.
Dr. Dan: And you know, luckily nobody fights with me on that. They do say that, ‘There is no Project Manager in Scrum.’ I say, ‘Absolutely, nobody said there was but, that doesn’t mean you can’t use Scrum to do project management.’ You know, and certainly, a team that is using Scrum to build their stuff, often has to be managed. So, there must be some project management there somewhere. I agree, it’s not part of your Scrum toolbox but, it is in your management toolbox.
You know, just like XP isn’t part of Scrum but, God knows, we’d love to have that on our Scrum team.
Q: Yeah, certainly.
Dr. Dan: You know, so, you know, there’s a lot of true believers, they really don’t understand what’s really going on, it sounds like they never really developed anything or maybe, they had one successful project using Scrum and now they’re born again Scrumsters, I’m not sure. And sometimes I think, some of the trainers are doing more harm than good, by being you know, very evangelical . . .
Q: Yeah.
Dr. Dan: . . . instead of pragmatic. I mean, that’s one thing I liked about you, I always thought you were pragmatic, we may have disagreed on what the answer was but, it’s always about building something, not about following the rules.
Q: Yeah, absolutely. Getting value for money at the end of the day, is really what it’s all about. You need to deliver a product at the end of the day.
Dr. Dan: Yeah, one of my current arguments which, I think you’ll appreciate, even if you don’t approve is, you know, you’re supposed to maximize ROI. But, how can you do that, you’re not actually getting any R. You know, I look at… on a Scrum Team that’s doing software development, the development team, not the management team, they’re two different Scrum teams but the, the development team’s ROI is maximizing the value of the feedback for the money . . .
Q: Yeah.
Dr. Dan: . . . because that’s your return so, you’re trying to maximize the meaningful feedback every Sprint, for the money you spend, which leads to some very interesting things, that can cause some major, wars. For example, maybe it makes more sense, to actually produce a prototype, to maximize feedback, to do a spike, right? Some sort, to maximize feedback, rather than the real thing. And so, this leads to an interesting definition of what product is… or potentially shippable, which just drives me nuts or whatever. And so, I have a chapter in there, that you should read, it’s at the beginning of the product section, it’s like, ‘What is Product, anyway?’ And I thought that we were headed in the right direction.
Let me just tell you, for a moment, in 2010, Ken wrote a Scrum Guide that stopped calling things product and called them Work Results.
Q: Yeah, that’s right.
Dr. Dan: And for a moment, I was going, ‘yes, yes, yes, yes’ and then, he went back to product. ‘What happened?’
Q: [laughs] Actually, that’s a really interesting point of view, that you should be maximizing feedback, every single Sprint.
Dr. Dan: Maximizing the value of the feedback.
Q: Yeah.
Dr. Dan: So, that the whole purpose of agility, the way we practice it, is to modify your priorities based on, frequent meaningful feedback.
Q: Absolutely, yeah.
Dr. Dan: One sentence discussion of, what agility is, as we currently do. And that the product owner’s job is to maximize the value of the feedback and then it’s the Project Manager’s job, to put the right stuff in the backlog, to get the delivery out the door, for the right product. And that… Scrum tends to conflate that project management and team leader job, together, which is what causes evil product owners because they’re trying to do both the project management and maximize value, and those really aren’t the same thing. And so, I’m saying, ‘No, separate those, the same reason we separated the project manager in the first place to a product owner and a Scrum master, in the team. Let’s separate again and pull just the management out and then the flow management… is a project. The team leader’s about flow. Having the team maximize value, sprint to sprint and maintain its ability to maximize value, sprint to sprint, and those are the two things you have to do. And, if you start acting like a project manager, you stop maximizing the ability to provide value, by creating technical debt because you value short term gain over long term gain and all this other stuff.
And so, that, I think, is the issue we’re fighting now. . .
Q: Yup.
Dr. Dan: . . . with teams and that are trying to, because somebody sold people on Scrum — Scrum is a way to get product out the door faster and they think that’s the goal, product out the door faster. Then try to explain, ‘No, that’s a by-product of doing the right stuff. It goes out the door faster because you do this other stuff. You concentrate on this and then that just happens.’
Q: Yeah, I’m not sure, I haven’t thought about it enough to either agree with you or disagree with you. That’s a very interesting take on it, it’s quite different too. I think it would lead to some really different points of view, that particular thought. I’ll have to think about it, I’ll think about it and get back to you.
Dr. Dan: Well, that’s why I’m telling you. I’d love to have you think about it, I value your ability to think about it.
Q: [laughs]
And I can’t say that about everybody, okay?
Q: That’s interesting, maximizing the value of feedback.
Dr. Dan: Maximizing the value of feedback. That’s actually what the Team Product Owner is trying to do. Because, you’re maiming the value of your work result, right? And what is your work result? A reviewable increment, right? So, what’s the value of reviewable increment? The quality of the reviews you can get from it.
Q: Yup.
Dr. Dan: Because you’re not actually shipping it, and that’s why you have different kinds of sprints. Most sprints are just about the review but, some sprints actually push things out the door. So, the product doesn’t actually get reviewed because in the middle of the Sprint you put it out to production. So, there isn’t actually a review. It’s a review of, ‘Is it out there or not?’ It’s not a review of the product anymore. So, that becomes an interesting issue, you know? So, that’s not even a sprint, the way we would normally think of it, with a feedback loop, there’s no feedback loop in a release sprint. You pushed it out the door, you’re done. You know, there’s no feedback for that.
Q: Well maybe, the feedback is the fact that it’s being used by customers?
Dr. Dan: Yeah, exactly. That would be, what you would review. Is it actually out there, is it actually being used?
Q: Are people actually using the product? Do they really care about it? Are they paying money for it?
Dr. Dan: But, you don’t have a sprint review for that, right? It’s not in your sprint review. That’s the ongoing review, after release.
Q: You could do, you could use sprint review, as part of that.
Dr. Dan: Absolutely, you could. So, you know, did it get released? Is it in people’s hands?
Q: Yeah, yeah.
Dr. Dan: You know. But you released it yesterday. You don’t have any feedback of whether it’s worth a shit. You know, so that’s the long term and you know, that’s the feedback that the project manager, product manager, is going to be getting through time because that’s his job is ‘How did my release do, in the field and did people like it and what they want next?’ I mean, he’s the product owner in the sky, right, the product manager, he’s got multiple teams working for him. He’s got project managers working for him, they’re all part of his management team in some sense and then, down here, you’ve got developers doing the work and they can’t possibly figure out or determine if it’s really useful in the field, that’s this guy’s job, up here. And he might even have a marketing team or something, that’s actually doing that, that’s their product, you know, is determining, what needs to be done next.
So, when you get the big organization is whole team’s everywhere. Each of these little teams could be a Scrum team because they’re doing something complex and each of them needs a product owner to, determine what to do next and then it all ties together. And then, the next thing you know, you’ve re-invented, an army type structure. . .
Q: Yeah.
Dr. Dan: . . . you really have no choice. You know, because it’s the same problem and the army has had 5,000 years of designing the solution and so, it’s pretty optimized at this point, you know? [laughs] And plus, they’ve also optimized it, so just about anybody can do the job, you don’t need heroes. So, that’s another good point, I think you know, because we have too many organizations that are relying on a hero, filling two or three jobs at once, and you don’t happen to have a heroic person, filling that hero job, so [makes noise] you know?
You know, so that’s another issue but, these are the things I coach. I love coaching more than training [inaudible 00:33:43]. So anyway, I don’t know what to do with the book, I’m thinking about it. I’ve written 80 pages, just on story points.
Q: That’s a lot of pages on story points, I have to admit.
Dr. Dan: It talks about, well, it talks about lots of stuff. It talks about what you want them for like, story points are your poker chips and you earn story points and you spend story points and you budget with story points and story points are not about actual effort. That, at any given point, the conversion rate changes, based on environmental variables, like technical debt and how good your team is, stuff like that.
Q: Compared to the [inaudible 29:21] stuff. . .
Dr. Dan: And then I have a couple of really good pages, really good chapters about estimating epics and why we can’t, we have a tough time estimating the number of story points, required for a use case, for example and I bring in COSMIC Function Points . . . [ed: COSMIC is a standard for functional size measurement, see www.cosmicon.com/index.asp]
Q: COSMIC Function Points?
Dr. Dan: . . . COSMIC function points yeah. It’s about, COSMIC function points, is about data movements. So, if you look at a sequence diagram, here, okay, how many times does an arrow cross the boundary of your system? And that’s how complicated that flow is, okay? And the idea, which has been around now, for 30 years, is that basically, a use case point, which is pretty much like a function point, is counting the number of function points involved in a given flow. And so, what I do is I say, ‘Okay, so a use case is implemented by scenarios, scenarios have single acceptance tests, single acceptance tests means there’s a story, it also means, there’s a sequence diagram, at least conceptually, which means there’s a size, function point size and that’s the number of story points you should have.
So, you’re trying to approximate the functional complexity in some sense, for your story points.
Q: That sounds awfully, awfully complex.
Dr. Dan: No, it’s actually very simple. You do it with the same estimation game but, you just have to use estimation game with stories that have known function point counts. And then you just… then talk about size and moving parts and not, effort. You have to ignore the, in the book I mention, I talk about inherent complexity.
Q: Mm-hmm.
Dr. Dan: And in the next book I talk about ideal effort, how much effort it should take. If you had a great team, there was no technical debt, your subject matter experts were available, how much effort it should take. And the beauty about how much effort it should take is it falls right into the project management’s earned value stuff because earned value is the effort it should take. So, you know, you’re familiar with earned value?
Q: Yup, absolutely, yup.
Dr. Dan: So you know, that’s the effort it should take and so, I have been doing CPI and SPI for years, based on story points and the project managers. And so, the project manager uses story… uses story points as his budgetary instrument, rather than dollars and then he has a conversion to dollars, another assumption, you know, hours per story point or dollars per story point, which is another variable he has to monitor against. And so, that’s what I’m working on now.
And, it’s pretty straightforward I think, from a project management perspective, it’s much simpler than the project management we currently do.
Q: Absolutely, I don’t disagree with that, I think that’s absolutely true. . .
Dr. Dan: And it ties much more closely to the way, to the way we’re supposed to write good software, with XP and that actually, if you’re writing software the right way, you know, project management is easy. If you’re writing software the wrong way, project management is hard. So, it becomes a… project management… trying to do it becomes a motivator to actually, write good code, which is kind of interesting.
The first book really talks a lot about technical debt, as the killer. Second book talks about technical debt as well; how do you manage it, you know? And my idea there, by the way, is that you separate it, you think about it separately. I have to deal with it the same time as the functional stuff, but in terms of stories, I have one story that’s adding the functionality and another story, that’s mitigating the technical debt. Each have story points, even though I’m doing it at the same time, but that’s makes it easier to manage.
Q: So, why does that make it easy to manage? I would have thought, that made it harder to manage, if you separate the two out?
Dr. Dan: Well, because I know the size for the functionality, in terms of the COSMIC function points. Then, I have a time-boxed story point estimate for the mitigation of the technical debt. Even though I’m doing it at the same time, this allows, it makes it easier to manage from a project management perspective; because I can have a budget of chore points, for removing technical debt and bunch of function points. Now I can say, ‘Oh, this one needs, it’s this much functionality… because it’s a mess, have another eight story points to clean things up.’
Q: Right, okay.
Dr. Dan: Eight story points worth of clean up.
Q: So you were talking about making it explicit, so that product owners can understand the difference between new functionality versus technical debt?
Dr. Dan: Yeah, the whole idea is more project management perspective. You don’t want to see a beautiful velocity and think you’re actually getting something, when really, a lot of these points are being spent to mitigate technical debts… you’re really not getting anything. So, you want to break them out explicitly and say ‘ Yes’ and actually make decisions to do it.
Q: Or more correctly, you’re not getting anything new, in terms of new functionality but, you are getting something, you’re getting cleaner code but, you’re not getting . . .
Dr. Dan: Yes, exactly, cleaner code, you’re getting the ability to maintain your velocity, there’s lots of things you’re getting. What you’re not getting, is functionality.
Q: . . . yeah, new functionality.
Dr. Dan: You’re not getting any additional size.
Q: Yes, yes.
Dr. Dan: But you are getting additional value. And so, this whole issue of value versus size versus business value versus effort, is when that can make your head hurt…
Q: Absolutely, absolutely.
Dr. Dan: …. but, it’s also one, that you need to understand, if you’re actually going to manage an active project.
Q: Yeah, yeah.
Dr. Dan: And so that’s why you get 80 pages. You know, so that a project management type can understand that this isn’t just, sitting down and managing a spread sheet, you have to make decisions, you have to understand what’s going on, and we on the development side, are going to make these things visible to you, so you can manage. And you’re going to make good decisions based on what we tell you, so you better fucking understand this. [laughs] Right? It’s going to require a whole new category of Scrum masters, that can go in and describe Agile project management to organizations and be part of the transition ScrumMastering thing. And how do we move to proper, and scaling and all that kind of stuff and a whole new category of ScrumMasters.
Q: You don’t see that, as being part of an Agile coach or the role of an agile coach?
Dr. Dan: Yes but, I don’t know the difference between an Agile coach and a ScrumMaster. I mean, I agree that, I think a ScrumMaster has that agile coach facet. If you want to, I’m fine with saying you know, the ScrumMaster is on the team and when he comes out… and outside the team, he’s an agile coach. I actually call the ScrumMaster the Team Coach because ScrumMaster’s a role and then, I have a team coach and another coach up here, as the ScrumMaster of this management team and another, you know?
So, somebody who comes out, would be called a Team Coach but, of a different team but, from the Scrum perspective, he’d be that team’s ScrumMaster. Say, of a management teams’ ScrumMaster, who would be an agile coach. And we’re putting together, this kind of, mastering agility series concept, to fight the scaling guys. Say, you know, ‘I don’t want to teach people how to follow a framework. I want to teach people a set of patterns they can actually use and teach another user’, which is different.
Q: And is this work that you’re doing with 3Back or is it part of the PLOP stuff that’s currently going on?
Dr. Dan: I’m not doing any of the PLOP stuff. I look at those patterns and I just want to retch. So, it’s so naive and simple and it is just, it’s just disgustingly bad, from what I can see. And so, I’m just not going to go there. I gave people permissions, to put my patterns I have a pattern on a, I have two GASPs on the startup sprint and the release sprint — very simple patterns but, they already caused a shit storm. ‘There are no special sprints’ and I say, sure there are.
It’s not a Scrum thing, but, it’s a way to use Scrum. And so, somebody said, ‘Are they posted anywhere else’ and I said, ‘They’re posted on the agile atlas, where they should be posted.’ He said, ‘I mean, for the PLOP stuff’,
‘If you want to go and put it in PLOP and reference the agile atlas and where they’re in, go right ahead.’ You know, but, I’m not going to worry about that. I’d rather put my own patterns together. I tried to see if any of the patterns were useful, and I said, ‘No, these are all over the map.’ It’s like reading 70 random pages of you know, the Ward Cunningham Wiki. It’s just, so, maybe it will come together as a pattern language, maybe but, that won’t be the medium for it, probably.
Q: Yeah. So, what is it that you and Doug were doing? You were putting together some patterns for large scale Scrum?
Dr. Dan: I am putting together some patterns and I think it will be part of our mastering agility series that we’re putting together. Because right now, we’re teaching a lot of people how to be very dogmatic about Scrum.
Q: Yeah, yeah.
Dr. Dan: And that bothers us.
Q: I think that’s almost universally true, where I’ve seen people do Scrum. So, whether in the US or here, in Australia, there is quite a lot of dogma.
Dr. Dan: Yes and that’s scary. Because where there’s dogma, there failure and then, you can blame it on the dogma… and… rather than the fact that you didn’t think about what you were doing. And, I don’t know what to do, I explain it to my classes, that the key lesson is, ‘It’s not about the framework, the framework is trivial, it’s how you think about the framework and what’s the course is about, what to think about.’
Q: And how do you apply it?
Dr. Dan: Yeah, exactly. And are you doing it with good intentions? And are you doing it while living the values? Are you doing it you know, those are the things that count and when you look at the framework, the values don’t even show up in the framework and I say, ‘But the values are like… or values in general are like… the most important thing.’ I mean, just the simplest thing, it’s a very simple rule, it has nothing to do with Scrum but, Scrum takes it for granted and that is, ‘Don’t assign people to projects, assign projects to teams.’
Q: Yes, yes, absolutely.
Dr. Dan: And we see all the time, matrixed organizations putting together Scrum teams out of part timers and then you look at that, you say, ‘How can you even think that’s Scrum?’ I mean, what?
Q: As soon as the project’s over, they disband them, they form a new team, from another group of people.
Dr. Dan: And the thing is, what I’m talking about, no, each individual in the team is working on three different Scrum teams, part time — 40% on this and 40% on that. I see that all the time and you know, ‘how can that possibly?’, ‘What, what are you thinking? How is it going to work?’ I mean, having teams that get disbanded, yes, that’s terrible. This is just, not even Scrum by any stretch of the imagination. And yet, there’s nothing that I can find anywhere, that’s written by the luminaries, in Scrum, that says, ‘You can’t do that.’
Q: Yeah, that’s right.
Dr. Dan: Except, you see some stuff, your teams are supposed to be you know, full timers, that’s about, as far as they go. But it doesn’t say, they must be full timers, otherwise they can’t self-organize. ‘So, don’t even try it without doing full timers, don’t even go there, don’t even go there.’ It’s not stressed. And so, it’s just one more trivial little rule to break, which of course, you can break because we’re self-organized, so the rules are just rules. So, we just mix shit up and call it Scrum.
[laughter]
Dr. Dan: Right?
Q: Yup. That sounds very much like the argument that, these are agile methods and because they are agile methods, we can change the practices because we’re supposed to be agile, because agile means that we can change things at will.
Dr. Dan: Exactly. And then that immediately segues into, ‘This is the same shit we’ve always done, just with another name.’
Q: Yeah, absolutely.
Dr. Dan: I mean, those are kissing cousins, right there.
Q: Yeah, absolutely yeah.
Dr. Dan: [laughs]
Q: Next thing you know, six months down the line, doing waterfall again.
Dr. Dan: Yeah and it’s not working and now you’re blaming Scrum. [laughs] I mean, that’s the thing, it is and somehow, we as an industry, have to fight back and say, ‘No, that ain’t Scrum’, you know? There really has to be some things that are sacred, there’s not many but, there should be a couple.
Q: Iterative waterfall, is actually quite common here, in Australia.
Dr. Dan: Iterative waterfall is perfectly okay. It’s not as good as Scrum would be, if you did it right but, it’s better than Scrum done wrong.
Q: It’s very common for people to do Iterative Waterfall and call it Scrum, not call it well. . .
Dr. Dan: Well, I’m actually okay with that.
Q: Really? Why do you say that?
Dr. Dan: Well because the Scrum team could decide to self-organize and have their sprints as being waterfalls, as part of their self-organization. If that’s all they know how to do, and it’s all they could possibly do. There’s nothing wrong with having a sprint being a fixed length in time waterfall.
Q: But, there’s nothing changing the behavior?
Dr. Dan: Yes there is, because they’re doing feedback every month instead of… so there’s nothing changing the coding behavior… but, the feedback every month is completely changing the project behavior.
Q: The project behavior may change but, the individuals within the project, their behavior never changes.
Dr. Dan: But, the project behavior is what’s going to provide the success for the organization. So, from the standpoint of a more successful organization, that increases the probability of success for an organization, therefore, it’s not a bad thing. It’s not what I would like to see.
Q: True, absolutely, yeah.
Dr. Dan: But, it’s not a bad thing. It is… changing one big waterfall into five small waterfalls, is a significant improvement.
Q: Recently, what you’re doing RUP?
Dr. Dan: Yes, it is exactly, what doing RUP. You’re right. RUP was a iterations of waterfalls of iterations of waterfalls, which is just like, ‘Ooh, that is so cool.’ And it is, if you do it right.
Q: If you like waterfall.
Dr. Dan: No but, you know, there’s nothing wrong with waterfalling one story at a time either. We’d rather swarm on a story but, there’s nothing wrong with waterfalling, a story at a time, through members of your team.
Q: I’m not sure that I would agree with that. Simply because it doesn’t change the behavior of the team and for me, that’s the important thing.
Dr. Dan: I’m not, well it depends on where you are, where you stand. I believe it’s an important thing but, I believe, the important thing is increasing the probability of success for the organization, that’s why we’re here. It would be nice to make the people into better developers, which would also increase you know? But, you can make them into developers and more agile, as a team within the concept of a waterfall, at the project level.
Q: True, yes, absolutely.
Dr. Dan: And that would be much worse, than changing the project into iterations, each of which, was a waterfall.
Q: Yeah.
Dr. Dan: You know? Now clearly, the right thing to do, is to do both. But, if I was going to pick one, I would change the product ownership behavior before I changed the developers’ behavior.
Q: Yeah, yeah, good point, yeah.
Dr. Dan: If I only had to pick one but, and we usually go the other way. We really focus on the self-organization because it’s really cool to the geeks teaching Scrum to focus on the self-organization.
Q: I think you get more bang for your buck, if you change or if you optimize the product owner role. I also think, that’s a very difficult thing to do.
Dr. Dan: I don’t, that’s something you can come at, from the PMI perspective and work at it, the PMO and change the, and do the military thing, where you’re supposed to be agile and saying, ‘We are going to deliver in increments, that we get feedback on and we’re going to deliver, every three months.’ So, you change it from a three year project into twelve three month projects. And that really increases the probability of success of the project and that’s product owner behavior.
But, the military talks about it, they talk about physical agility versus mental agility and the framework in Scrum, gives you the physical agility. You have the ability to get feedback. But, if you don’t react to the feedback and be smart, then you’re not mentally agile and the framework doesn’t matter. So, you need your product owners to be mentally agile, that’s the number one thing, I think, that would make a difference.
Actually, I talk about the three biggest problems, that ScrumMasters face and that’s one: Proper decision making in the business, which is product ownership and the second one is, re-write that code. So, we write code that won’t change easily . . .
Q: Mm-hmm.
Dr. Dan: . . . and then, the third one for me is, self-organization. Because I really wouldn’t expect self-organization until we are in relatively safe environment and we’re not ashamed of our code. Then, we can become self-organized.
Q: Yup.
Dr. Dan: And so, you know, that’s the way I see it and so I want to focus, personally on the product ownership, as usually being the biggest problem.
Q: Yeah.
Dr. Dan: And then simultaneously, get an XP coach in there, to work on the – or the Scrum coach to come in and work at the self-organization and the better code writing practices, at the team. I think you want to attack both of these things, and the one I’m interested in, is the one up here, because nobody else is doing it.
Q: Yeah.
Dr. Dan: And the people that are talking about frameworks, are talking about frameworks as if, they are magic processes again,
[inaudible cross talk 52:29]
Q: Yeah.
Dr. Dan: And I’m saying, ‘No, no, no, the practices can’t do anything, it’s the people that do it, the practices just give them a framework within which, they can think correctly.’ The same reason, you can’t just pluck anybody off the street and make them a battalion commander. You’ve got to learn how to make those decisions. And establishing a framework around you will not make that happen.
Q: Yeah.
Dr. Dan: So, that’s where I’m coming from… and by the way, trying to write that down in a book, so it won’t be misunderstood, is proving to be virtually, impossible.
Q: Writing is hard, writing is really tough.
Dr. Dan: Writing is really hard and writing about that sort of thing, where you’re fighting the culture and trying to change the culture, and trying to make it so people can’t misunderstand i…, because every Scrum book that’s been written so far, pretty much, it can be willfully misunderstood very easily.
Q: Yes, absolutely.
Dr. Dan: My book is 360 pages long and I keep trying to plug all the holes and say exactly what I mean and then, somebody says, blah blah blah, I usually point to a paragraph that says, ‘No, exactly not, here’s the paragraph that says, that’s not true.’ You know, so if you’re actually, really hard to wiggle through there incorrectly. But then, it also makes the book hard to read. It’s like being beat over the head by me and you know, that’s no fun. When you got a conversation, where I can beat you over the head for hours, and so the book is kind of, like that but, hopefully. . .
Q: [laughs] I always learn something and I always laugh a lot, it’s always good.
Dr. Dan: . . . well, that’s my job. I’m also learning too. I like the way Michael says it, ‘Dan will, he’ll listen to your argument, he’ll say, ‘You’re absolutely right’ and then tell you why you’re wrong. [laughs] And I say but, you are absolutely right. ‘Telling you, what you exactly meant to say.’ Because that’s the thing, everybody’s got in their head right, it just doesn’t come out right, all the time.
Q: Yeah.
Dr. Dan: But the trainers that I respect, it’s in their heads right but sometimes, it doesn’t come out right.
Q: It’s hard, communicating is hard.
Dr. Dan: Absolutely, it’s a tough job. You know, I always thought, you were fairly good at it. You’re a little more formal than me.
Q: Yeah, yeah, and I think in a large part, because of you know, just my experiences in software, I went through very formal project management training and I’ve tried to leave that behind but of that, I still find very difficult to leave behind. And formality is, what I do tend to find hard to leave behind.
Dr. Dan: Yeah, I understand, I had to learn how to do formal military briefings. But . . .
Q: I’m sure, that was fun for you.
Dr. Dan: . . . never actually did them. You know, I was once castigated for, ‘Your pointer management looks like you’re sword fighting.’ Was a comment from a two star general, one time and my response was, ‘Thank you General.’ And he didn’t know what to say to that. [laughs] He had no idea what to say to that.
Q: Oh, too funny.
Dr. Dan: But yeah, the thing is that, a lot of that formal project management stuff, you need to go back and look at it, look at the theory and a lot of that theory, that we learned back in the ’80s, formal project management, the under…, philosophical underpinnings, are correct, absolutely, totally correct. What isn’t correct, is the taylor-istic management principles that go along, that are the next level up, about how to apply the theoretical underpinnings. But, you can use the theoretical underpinnings about the math and sizing and things like that, that talks about project management and work breakdown structures and all that kind of stuff, and do it in an agile way, the next layer up.
What happens at first layer, we get the taylor-istic fungible human being management, which is coming out the working way but, you can take all that stuff and move it directly, into Scrum and that’s what I’ve been piecing together for the last ten years, is trying to plug all the holes and make all the Lego blocks fit and come up with a unified theory. And, I think that I’m there now.
Q: A unified theory of Scrum.
Dr. Dan: No, the unified theory of getting project management into Scrum. The unified theory of Scrum already exists. I mean, it is pretty simple. Where are the variables and where are the simplifications, and stuff but, now there’s some interesting stuff about, the S shaped curve of the value delivery and things like that, that. Like , just for example, to give you one, the standard S shaped curve for value delivery, that we learned. It says ‘This is effort’, so think of that as an expenditure of story points and this is accumulation of the value, think of that, as function points. Story points going this way, function points coming out this way, and you can draw a really nice curve, the S shaped curve, completely matches what you would get by, actually doing the stories in exactly the right order.
All the architecturally significant ones first and then the must-have scenarios and then the nice-to-have, you get this graph that goes like this and this and then this and it completely matches the standard S shaped curve. It’s amazing. And the of course, that’s not what really happens because you do them in an opportunistic way, so it kind of like, wanders, it doesn’t go up the curve.
Q: Right, it goes up and down and all over the place, sometimes.
Dr. Dan: But the beauty of it is, what that tells me though, is that if you use the curve as a way of estimating how much effort you need to produce so many must-have scenarios. Right, because the middle part of that S shaped curve is the must-have scenarios. So, if you know, that the must-haves are this big, you know, you need this much effort, well that’s still true. Okay and then I see, you can estimate a use case’s must-haves and I need to multiply it by three or two and a half actually or something. And so, bang, you have answer.
Now your job is to spend it wisely, by using a product owner to prioritize, rather than a plan to prioritize it.
Q: Yup.
Dr. Dan: And the beauty of it is, and you’ll like this one, I know you will, the last half of the S shaped curve, this part here, is an 80-50 curve, which is halfway between perfect 80-20 and totally random, which is 80-80. So, that would expect a product owner to be able to take you up an 80-50 curve. So the thing is, now you know the curve is the same, whether you use the perfect plan or just a random product owner. See, that’s a key thing. A random product owner is as good as the perfect plan, perfectly followed.
Q: Yup.
Dr. Dan: So you see, so that’s actually the reason you should be agile, because any old person can be better than a plan… as good or better than, a perfect plan. But, the budgeting is still the same. But you also have to know, that what you’ve actually budgeted for, for the must-haves, you also know, that you don’t know exactly what the must-haves are, so you just have to estimate how many of them will be in this use case.
So now, you have a small, medium, large use cases lead to a certain number of story points, blah blah blah blah blah and there’s your release planning. And it’s something that works. I mean, it’s amazing and people can understand it and project managers looking to understand it, more importantly. So, they’ll let you do it and you can get nice CPI and SPI graphs out of it. And so, all the things that they want to see are there, but you still get to be totally agile, under the covers.
Q: [laughs] To me, it sounds like there are far too much mathematics. . .
Dr. Dan: Yeah, right, none of it affects the team. The only thing that affects the team is, ‘What’s next on the product backlog?’
Q: Yeah, absolutely. And so, you let the project managers do all that?
Dr. Dan: You let the project managers and the team leaders together, manage that many to many relationship between each of the project backlogs and the team backlogs.
Q: Yup.
Dr. Dan: And so, and all of a sudden, bang, you have a program management, actually, because that’s many… many projects. You have a program management team, whose job it is, to keep the backlogs, the team backlogs and the project plans, in sync. And that’s that team’s job, that’s it’s product. And you know, when you come at it that way, and use a pattern, the program management team would be a pattern, the development team, would be another pattern. You stick them together like Lego blocks and you get a big ugly organization… right… which, watching flows of priorities coming in and getting sorted out and then, coming in and getting sorted out. And then, at the bottom, people are actually doing work and then rolling it back up.
It makes as much sense, I’m not saying it’s the right thing to do, it does make sense, you can actually do it as well, but, it makes as much sense, as all the crap we learned with work breakdown structures and waterfalls and everything else, it’s just as beautiful a model.
Q: Yeah.
Dr. Dan: But, you can actually do it and it’s agile. But it requires a lot of people willing to be product owners and make decisions, and that’s the tough point because you don’t have a plan to fall back on — it was your call. And so, we changed the fact we’re following a plan blindly, with we’re following a leader blindly, who’s making decisions and you have a hierarchy of leadership and like I said, you wind up re-inventing an army division or something equivalent, which we already know, is the largest successful agile animal made out of people. You know, that we’ve seen many times so, you know, the pattern works, we already know it works, works in a very complex domain called warfare, it will work in a very complex domain called software.

, ,

Comments are closed.