Giles Bowkett invited me to discuss another article he wrote. For some reason I’m willing to do that.

Here’s the article in question. Please read it, then come back. I’ll wait.

Welcome back! Let’s look at some of what’s being said in that article. I’ll pull out some topics. It’s probably fair to assume that I agree with anything I don’t comment on. And as you’ll see, I also agree in large part with some of the things I pull out.

First Things First

Let me emphasize that I don’t care at all what “process” people use. I don’t get paid any more or less if they use Scrum, XP, Waterfall, or the Amazing Panda Process. I don’t get paid anything, either way, as it turns out. My mission, as I see it, is to explain what I understand these methods to be, and in so doing, to help interested parties to find ways to do better and to have more fun in so doing.

When an article like the earlier Scrum Should Just Die in a Fire comes along, I may well respond with something like this, or like this. My purpose in such responses is primarily to help people distinguish between the not-so-good things they may be doing and the things that are recommended by so-called experts.

Anyway, I’m not here to judge people. I am here to point out the things that I find work, and to explain why I believe that they work. I am here to point out when something a team is doing does not seem to me to be Scrum. And I’m here to point out when a team seems to be doing something unproductive – especially when the team members themselves say it’s unproductive – and to suggest that they might want to stop doing things that they find to be unproductive.

Wait, what, isn’t he contradicting himself right here in the same paragraph?

In doing all that, I try never to say “you”, and never to say “should”. I’m not perfect at that, nor at anything else. Nonetheless, it’s not about “you”, and you should remember that as you read my work.

Remote Work and Distributed Companies

Mr Bowkett[1] goes on at some length supporting written communication, in support of distributed teams. He says that when the Manifesto says

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,

that implies that “open source projects are less efficient and effective at developing software than commercial projects.”

This is not the case: the Manifesto neither says nor implies that. The Manifesto specifically says “efficient and effective method of conveying information”, not “method of developing software.” The Manifesto does not compare open source to commercial, and it’s not talking about the best way of describing code, as Mr Bowkett suggests in what follows:

There’s a reason we write code onto screens, rather than transmitting it as oral history like an epic poem from before the invention of the written word. Face-to-face communication has a lot of virtues, and there are certainly times when it’s necessary, but it’s not designed to facilitate extremely detailed changes in extremely large code bases, and tools which are designed for that purpose are often superior for the task.

Is Everything in Agile Done by Oral Tradition?

As Mr Bowkett’s article points out, many of today’s tools were not very much in the picture at the time the Manifesto was written. Do they change things? Certainly. That leads to some interesting questions such as these:

  • When, if ever, should a company prefer distributed work to co-located?
    • How does this model affect ability to hire good people?
    • What is the impact on managing individuals and teams?
    • What does Conway’s law tell us about the likely design of a product built by a distributed team?
  • What aspects of the work, if any, are best done face to face?
    • When is joint design stronger than distributed design?
    • What is the impact of distribution on team cohesion?
    • When, if ever, does brainstorming or other joint work, provide better results?
  • In short: when is face-to-face better, and when is it not?

What we had in mind …

My recollection from those days was that we had in mind customers and business-side people talking with the developers rather than communicating with them via written requirements documents created by third party “Analysts”. As Mr Bowkett points, out, “Waterfall” was on our mind at that time. Nonetheless, I’m quite sure we did not have in mind treating software as something that should be expressed in the form of Vogon Poetry.

So instead of saying something that’s just not so: “Agile is against open source”, would it be possible to offer a reasoned discussion of when we do best to write something down and when to talk face to face? I think it might be possible and I think it might lead to more useful communications.

It would be particularly useful to see articles that point out the things that work well, and the things that do not work so well. For example, Mr Bowkett is fond of communicating about code using pull requests and the like. He says:

But when you’re reviewing a pull request, a GitHub diff usually beats face-to-face conversation. And this is not a fluke. Remote work requires a ton of writing, and that’s one of the best things about it.

That may be true, but my guess is that it is, at best, true only sometimes. Here’s a bit of current experience:

RonJeffries.com project

Let me tell a story of what has been happening with me and Mr Tozier[2] as we work on the ronjeffries.com stories. We work together two or three hours a day, two or three hours a week. WHen we separate, sometimes we work on things germane to the site. I wrote some RSpec tests and did a spike on something. Mr Tozier built a little sample Javascript thing that displays a random article.

When we do those things, we push them, as a branch or not, to GitHub, and invite the other to take a look. And we do take a look, communicating with and around the code.

As I’ve mentioned in the rj.com articles, Mr Tozier and I do not always approach code from the same angle. He likes to use Ruby idioms more than I do. I often try different things from what he would try, because we have very different internal models of what is obvious and what is not. The result of these difference is that we can always understand the other person’s code, but we often cannot understand why it is that way or how it came to be that way.

When we try to sort that out via email and GitHub issues, we mostly get nowhere. When we try to sort it via Twitter DM, we mostly irritate ourselves with the incessant beeping and the limitations of 140 characters.

When we sit down across the table and talk, we quickly sort things out, reaching understanding and agreement quickly.

Similarly when we plan. We do lots of blue-sky planning, as we mix together our technical inclinations, our views of what the site should be, and the “business requirements” to get something done. Doing this via any remote medium we’ve found to be far less effective than sitting down, writing things on cards, and chatting about them.

Does depth of sharing come into this?

Mr Tozier and I are working jointly on almost 100% of the code. We have not divided up the project so that he’s working on scraping and I’m working on rendering. We are working together: we pair program when we’re together. Each of us has contributed to most every line of code in the system.

Does a distributed team share code at this level? Or are they more likely to share at the object or module level? If so, what happens on the interfaces? What happens to a design where half was done by one bright person, and half by another, compared to a design where it was all done by two bright people who have learned to work together. I think the latter design is better, and freely grant that if Mr Tozier and I were always at each others’ throats, that would not be the case.

Point is, these are questions. They have individual answers, and I believe there are probably trends as well. I think it’s context dependent, but I also think that a good pair will beat two good developers working separately most of the time. I could be wrong. I could be right.

It is, in my strong opinion, overreaching to conclude that Agile is (or has) a bad idea because our team have a distributed project that’s really great, or that face-to-face is inferior because we don’t communicate code via voice. What’s more appropriate, I suggest, is to look deeply at specific cases and try to conclude useful things about what’s going on.

Individuals and Interactions

From Mr Bowkett’s article:

But in either case, evolving tools change our interpretation of the Manifesto. So what about the Manifesto’s core idea?

“Individuals and interactions over processes and tools”

It’s good to prioritize “individuals and interactions over processes and tools” when the only tools that exist are terrible. But on the one hand, the Agile culture often seems like nothing more than a marketplace for processes – including Scrum – and on the other hand, you won’t be a productive developer if you’re not fluent with modern tools. It doesn’t matter how good you are with individuals and interactions if everybody’s texting and you’re still leaving voice mails. Even companies that claim not to do remote work, or asynchronous communication, will still expect their employees to answer work emails on their phones from almost anywhere. If you change the tools, you change the interactions.

Mr Bowkett then goes on to argue that Marshall McLuhan’s work (ca. 1964) is really very important, that Wired Magazine declared McLuhan to be their patron saint (in 1993), and that the Manifesto authors should, somehow, have factored McLuhan’s work into our own. I confess that I do not see just how to have done that to good effect.

While there is value in the items on the right, we value the items on the left more.

More to the point, for me, at least, the phrase individuals and interactions over processes and tools stands, absolutely, as something I believe in. Note, as always, that it doesn’t say “instead of” or “to the exclusion of” or “don’t never have no”. It says “over”. I really don’t care whether people communicate using GitHub, with cell phones, or with mental telepathy: what’s going to matter is the people and their interactions.

People trump everything. That’s the point of that line, and as far as I’m concerned, that one stands the test of time as well as anything we said.

I don’t know that Mr Bowkett disagrees with that. Perhaps his point is “yes, but now we can interact differently”, and with that I certainly agree. The point remains, the people and their interactions are more important than the particular tools and processes they use to do it.

We’ll agree to agree, or to disagree, on that one, as the case may be. To me, people are more important than processes and tools and I hope that they will remain that way forever.

Business Interaction

Mr Bowkett points to another “destructive flaw” in the Manifesto. We said “Business people and developers must work together daily throughout the project.” Mr Bowkett replies:

First, this assumes that “business people” and “developers” are distinct and separate. There’s a weird and condescending implication that developers are not in business, which they typically are, in Scrum environments. I’ve never heard of anyone doing Scrum for fun in their free time.

Second, the “daily” part is silly. There’s lots of technical work where “I’ll see you in a few days” is the only sensible thing to tell your colleagues in marketing, UX, QA, product, or what have you.

Yes, well. The phrases “business people” and “developers” are meant to refer to the people who want the product and are paying for it, and the people who are building it. If those are the same people – and perhaps in some cases they are – then yes, we think they should work together daily. And if they are separate people, as they often are, we still think they should work together.

Are there times when it’s a good idea to say “I’ll see you in a few days”? I suppose so. Does that mean that none of the business people should talk with any of the developers over those few days? I think that’s less likely.

In any case, I’d suggest that little harm is done if every day the business folks and the technical folks touch base with “Hey, how’s it goin’, got anything for me?” And I’ve found that having the team’s main business-side stakeholders present in the room is quite valuable.

So, no, with all due respect, I’m not buying it. If there’s something destructive going on between the business side and technical side that makes being separated a good idea, I think I’d treat that as a problem and try to solve it by improving the interactions, not by reducing them.

We may have to agree to disagree on that one as well.

Mandatory [Unproductive] Daily Meeting

Mr Bowkett continues with this concern:

Scrum takes this “daily” thing much too literally, making a daily meeting between developers and “business people” mandatory, whether there’s any need for it or not. If you’re required to say “that thing I said would take a couple days is taking a couple days,” it’s hard to do so without sounding apologetic, defiant, or mindless. It’s just a silly thing to require a professional to say to other professionals on a daily basis.

I’m sorry, that’s just a mistake: Scrum does not say that. The only daily meeting is the fifteen minute “Daily Scrum”, which is a meeting where the Development Team touches base to coordinate. Historically, only the Scrum Team members even speak at that meeting, which specifically means that managers or other stakeholders do not speak. Some particularly strict individuals even object to the Product Owner speaking at this meeting, though personally I would rank that idea with the one above and fix the unproductive conversation rather than outlaw it.

If a team is having an unproductive meeting where people are required to say “that thing I said would take a couple days is taking a couple days”, they should[3] stop. And, frankly, after I’ve worked for a day on something where I’ve planned for a couple of days, I would expect to have something interesting to say about it. Perhaps I learned something interesting about the system, or discovered a useful library, or pushed some interesting tests and code to the repository. Worst case I can say “it’s looking good, I feel on track”. This doesn’t offend me and I don’t see how it’s a problem to tell the team I’m OK. The point of the Daily Scrum is for the team to ensure that they’re on track to deliver, and I’m perfectly happy to spend 15 minutes[4] doing that.

So maybe we disagree on that. Me, I see little harm in a productive team check-in, and if the meeting is unproductive, I’d suggest fixing it rather than dropping it.

Agile is Dead (What, Again?)

Mr Bowkett quotes a statement from Dave Thomas (who just published my new book, The Nature of Software Development, thanks Dave)[5], saying that he feels that Agile events, the Alliance, and such are not in the spirit of the Manifesto. Among the other books Dave’s company has published are Agile Web Development with Rails, Agile in a Flash, Agile Coaching, Agile Retrospective and some of the best books out there on what Agile people do. Check them out, they’re really good.

Now I would argue differently. First of all, the kind of abusive “Scrum” that Mr Bowkett spoke of in the initial article I responded to is absolutely not what we were talking about on those days in Snowbird. While I am not as disillusioned as Dave appears to be in the statement Mr Bowkett quotes, I am very unsatisfied that that sort of so-called Scrum goes on. And it certainly does go on.

That said, I believe that most teams who undertake to do “Agile” gain some benefit. The benefit comes, in my opinion, from two main sources. First of all, the Agile approach likely puts directing what’s done in the hands of someone close to the business side, which is a great leap forward from most IT projects. Second, because Agile methods all ask for real working software to be delivered every couple of weeks or more often, such projects tend to engender trust between business and tech, and because what they’ve built is visible, they tend to get better decisions made.

Is it enough? Hell, no, it’s not enough. Let me enter a personal note.

My Work

My work appears to consist mostly of publishing my every thought on how software development ought to be done. I don’t put anything behind a pay wall, although you will have to pay a few bucks to get my book. Sorry.

When I’m not writing this stuff, I teach a few CSM courses (one or two last year). In those courses, I do my best to emphasize the essentials of the Scrum idea, and I assure you that I do not recommend two-hour Daily Scrums, nor the use of suggested acts of sexual congress to silence people. (I have found that such suggestions often do silence people, however.)

I also teach Certified Scrum Developer courses, with Mr Hendrickson[6]. In these courses, we show the participants what happens when they pair program, when they do TDD and ATDD, and give them experience producing software that makes sense to a business person in ninety minutes or less. We do our best to let them experience these technical practices – which you’ll perhaps recognize as the technical practices of Extreme Programming – so that they can decide how those practices might fit in to their work.

Finally, unlike Dave, I do attend conferences. When I speak at those conferences, I either offer advice about whatever people want to ask about, or, especially at Scrum conferences, I talk about the necessity for Scrum to go deep, not just wide, so that people will get more benefit. As such, I am proud to say that I’m one of the primary forces behind the Certified Scrum Developer program, which is a damn good course if I do say so, and behind the Certified Scrum Professional program, which focuses on continued learning relating to Scrum and Agile ideas, and behind the latest thinking on continuous education, the upcoming notion of the “Additional Qualification”, which is a bit of recognition when someone demonstrates some in-depth understanding in some specific area.

Do I get business from that? Sure, sometimes I do. And when I get called out to visit a company, I give them the best I’ve got and they are generally happy that I was there.

I do that because in my view, “Agile” is here to stay for quite a while, and it’s not being done well enough. Dave Thomas has advanced the state of Agile, whether he’d say so or not, by publishing great material that is of value to people trying to do software in the Agile fashion. I try to advance the state of Agile by helping people understand what we did and didn’t say, what has been found to work and why. I try to make it better.

Personally, I do not find value in saying “Agile is dead” or “Scrum should die in a fire”, because those ships have sailed. People are trying to gain the benefits that Agile and Scrum purport to offer, and if people will do the right things, and work to improve, they will prosper.

I don’t care whether they wind up doing something that looks like Agile or Scrum. I care whether they prosper. I find that as long as I offer the best I’ve got, enough folks will call me up and invite me to help them. And I find that they are generally glad that they did.

But it’s not enough! Every good idea gets watered down. Every good idea gets screwed up. Religion, politics, Agile, Scrum. All watered down, all screwed up. What works, I choose to believe, is working to make the good ideas clear and to push out the bad.

Some men just want to watch the world burn.
– Alfred Pennyworth

I’m pretty sure that Mr Bowkett has been trying to do the same thing. To my taste, I’d prefer to see more “We tried this and we tried that and that was better”, and less auto-da-fé.[7] But that’s just me. And, I’m sure, in his inimitable style, that’s Mr Bowkett as well.

A Bit More …

I’ll keep this short:

  • Mr Bowkett objects to some of the words. As I said before, yes, well, so do I. This is another ship that has sailed. That said, I’d be remiss if I didn’t point out that the word “commitment” in the Scrum Guide has been replaced with “forecast”, owing to the difficulty people have interpreting the word as meaning “promise” instead of “dedication”.
  • Mr Bowkett takes a swipe at Agile Fluency but doesn’t carry through with any particular argument. I think that’s probably for the best, because the Agile Fluency model, new though it is, is based on looking at real Agile projects and observing the stages they go through. I don’t know if it’ll catch on, but I think it’s something worth watching.
  • Mr Bowkett objects to measuring velocity, as do I. The idea came from Extreme Programming, and has my fingerprints on it among others. Used as intended, to help decide how much work to take on, it’s fine although probably unnecessary. Used to measure teams and push on them to go faster, it’s pernicious. Here again, I think we’re stuck with it but with ideas like #NoEstimates out there, we’re seeing some progress.
  • “If a client’s using Scrum, we’ll go along with it.” This tells me, if the Die in a Fire article had not, that Mr Bowkett and his colleagues know the difference between Sensible Scrum and Stupid Scrum and probably did all along. Stupid Scrum should in fact die in a fire. I’m good with that.

XP

We’ll close with something I’m pretty sure we’ll mostly agree on. Mr Bowkett closes thusly:

We were into Agile before it was cool, and we’re still fans of Agile’s early work. So if you’re dead set on using an Agile development process, we recommend you look into Extreme Programming instead.)

Yeah, me too. It’s worth noting that if you squint your eyes just a tiny bit, XP’s outer cycle looks almost exactly like Scrum. XP left out the Retrospective (which was a mistake in the original formulation IMO) and recommends a coach instead of a ScrumMaster. Other than that, pretty much the same out there.

Inside, of course, XP has all those cool technical practices for actually developing software. If you’re going to build software iteratively, they’re just about absolutely necessary. And if you do build software iteratively, your Scrum project is a lot more likely to work.

Anyway, there you are. Let me know what you think.

  1. By request …
  2. In for a penny ..
  3. Sorry …
  4. But not two hours, see previous wire.
  5. Blatant plug, but it is my web site after all.
  6. For consistency …
  7. No one expects the Spanish Inquisition.