Requirements, Customers and a new Dialogue Sheet

I’ve written many many times in this blog about Dialogue Sheets. On the whole I offer dialogue sheets as a retrospective technique. However they have other applications, for example:

• The Agile Discussion sheet serves to help teams decide what Agile practices they wish to adopt. I use this to close training sessions and I’ve seen teams move straight from training into using some of these practices. I credit this sheet with some of this success (Oh, and my brilliant training course of course, plug plug.)
• The Planning Meeting sheet helps guide teams new to Agile planning meeting through the planning process.

I’ve long believed Dialogue Sheets can help on the requirements side too but until recently I’ve not had a chance to try this. Now I have.

Last month the Victoria Wiggins and Rosie Curran at Nature.com offered one of their teams as guinea pigs to try a new sheet. The session went well, the team had about 2 hours of discussion and they even provided lunch. Thank you very much!

After observing the team discussion around this sheet I’ve made a number of modifications. Primarily I decided to focus the sheet on the customer question, i.e. who are you customers? and what are their problems?

I now offer this sheet for free download. The Customers sheet is available on the Dialogue Sheets pages.

Now the catch: I still consider this sheet to be in beta test. I really really really would appreciate some feedback on the sheet - please please please. If you try the sheet please let me know how it goes - for better or worse.

Until recently I had all the sheets behind a registration page. This allowed me to known who was downloading the sheets and in the past I occasionally e-mailed people to find out about their experiences. I got feedback.

But I also got feedback from people who said they didn’t like putting their e-mail address into a system. So I removed the registration process. Now I have no feedback.

I find it very ironic that despite all the talk of the importance of getting feedback (particularly in Agile circles) very few people offer feedback without prompting. Consider this your prompt.

Please, try the sheet, and please please, tell me what you think!

Common Agile objections

Last time (“Waterfall works when…”) I promised to discuss some of those common objections to “Agile.” (Actually, reading back this this post I’m struck by how like my “12 Myths of Agile Development” which was originally a blog post 2 years ago called “11 Agile Myths of 2 Truths”.)

(Apologies by the way, “Waterfall works when…” was misposted the first time, I’ve just fixed that.)

“Waterfall is most appropriate because our requirements are known and stable”

So what? Agile works brilliantly with stable requirements, it also works pretty well with changing requirements.

“Scope cannot be flexed”

See above.

If scope can’t be flexed than so be it, you will do it all. Scope is flexed all the time on traditional projects. No matter how much traditional projects say “scope is fixed” once they get near the end and no more money, people or time is available scope always flexes.

“We work on multiple projects at the same time”

And? Its all work to do. If you want a full discussion see Xanpan.

I think some of the Scrum texts talk about “dedicated” or “ring fenced” teams. I’ve never yet met a team that doesn’t have some baggage. As John Lennon might have said: “None project work is what happens to us while we are making plans."

“The thing that is being built cannot be decomposed into smaller pieces”

Well have you tried to decompose it? - many teams jump to this assumption without trying to decompose it. Decomposing work is a skill, just because you tried once and it didn’t magically happen doesn’t mean it can’t be decomposed.

If you couldn’t did you ask for help? Did you ask someone (like myself!) to help? - breaking things down isn’t always easy, it might help to have some help.

What if you can’t break it down but your competitor does?

I believe almost everything can be broken down if you approach it right. And if you can’t break it down then perhaps it isn’t something that can be implemented in software.

“Agile works on greenfield projects but we have a legacy system.”

and

“Agile works on legacy systems but we are building something new.”

(Now I really am repeating myself - see “11 Agile Myths of 2 Truths”)

They both can’t be right? I’ve seen Agile work on both new and legacy development and I’ve heard both sides say “It won’t work because…”.

The grass is always greener on the other side.

“Our project finance model does not allow Agile”

So what? There is plenty you can do which has not finance implications.

Stop pointing at other people who stop you, do what you can and take one problem at a time.

 

Waterfall works when....

I frequently find myself in situations where someone says something like: “Waterfall is appropriate when…”

Some people out there think there are occasions when an Agile (mainly iterative) approach is “best’ and other occasions when “Waterfall” is “best”. Most of the time I let this line of argument go because its boring, I can’t be bothered arguing. (I’ll look at some of these common objections next time). Right now lets get something out in the open:

• Before you make any decision on Waterfall or Agile define what you mean by “Agile” and “Waterfall”.
• The decision to work Agile or Waterfall should not be based on which is more appropriate.
• The decision on whether to work Agile or Waterfall should be a based on an examination of the business benefits.

Briefly, let me define “Agile” as working and delivering in short iterations and “Waterfall” as delivering in a single pre-planned event.

In cold hard cash the benefits to the business are:

1. Agile working produces a far higher return on investment because benefits are delivered sooner.
2. Agile reduces risk because risk is spread across many independent (consecutive) deliveries.
3. Agile further reduces risk because failure can be identified sooner thereby saving money and time (Fail fast, fail cheap).

Without any other changes I can prove those improvements: they are objective. Using just mathematics without reference to any subjective opinion I can prove those three claims.

There are some other business benefits which are I can show logically although this opens the possibility that some will see these are subjective:

1. Agile creates options for businesses and options have value (see Black-Scholes)
2. Agile creates opportunities to incorporate feedback and incorporating feedback leads to better products
3. Agile (when done properly) improves quality (fewer defects) and fewer software defects leads to short schedules (reduced time) in software development, shorter schedules leads to reduced costs

The question of “appropriateness” is an engineering concept based on the idea that one approach is better for the problem in hand than another. If instead we examine the problem from a business perspective it can be rephrased as:

“How can I maximise the return on investment from this work?”

Given that Agile delivers a greater return on investment than Waterfall surely Agile is the most appropriate method every-time?

Of course “which is better Agile or Waterfall?” has never been about cold rational arguments because as individuals, and as businesses, decisions are very rarely made in such rational terms, despite what one might hope or event claim.

Code and other reviews (a small piece of advice)

Many teams have some sort of very regular reviews. I’m not thinking personnel reviews or budget reviews, I’m thinking code reviews specifically but it could be test reviews, documentation reviews or some other. Reviews that need to happen every day but which frequently get delayed.

Lets stick with code reviews because they are the type I encounter most often.

Code reviews are good, by some accounts they the most effective means of removing bugs early - although I haven’t seen code reviews compared with TDD. But, code reviews loose their efficacy when they are not conducted promptly. The longer the period between the review being requested and the review being conducted (and by extension the review comments being acted on) the less effective the review.

The effect reduces because: a) the person who requested the review has moved onto something else, b) issues found in the review may be repeated until the review is conducted and c) the review will either inject a delay into the delivery process or the delivery will happen without the review in which case, what was the point?

So: if you are going to conduct reviews you want them to happen soon.

And it is not just the code and the developer who wrote it who have problems. The designated reviewer feels the pressure to “do reviews” when they have other - important! - work to do.

One team I know came up with a simple solution to this problem. I recently recommended the solution to another team who promptly adopted it and are delighted. One developer said: “I’ve never been so relaxed about reviews before.”

The solution is….

Make reviews the first item of work after the stand-up meeting in the morning. And let people do them before the stand-up too.

Thus, as soon as the stand-up is finished everyone undertakes any reviews which are needed before they start their day’s work. Review work is prioritised before new work: after all, yesterday the thing that now requires review was the priority, it is probably still the overall priority and the only thing standing between it and “done” is a review.

Reviews don’t typically take very long so today’s work isn’t delayed. And the recipient of the reviews comments can act on the comments before they get into today’s work.

Better still, knowing that reviews will happen right after the stand-up meeting means that it also makes sense to do the reviews BEFORE the stand-up meeting. This also addresses the question of “how do I usefully use the time before the stand-up meeting when I know I’ll have to stop doing whatever I start.”

So for example, imagine on Tuesday afternoon Bob asks Alice to review the code he has just finished. If Alice is available she might just do it there and then. But if she is busy she will wait. Now if she arrives at work at 9am and the stand-up is 9.30am she can get on with the review before the stand-up, if she finishes Bob will have his feedback and can act on it before 10am. If Alice doesn’t get to Bob’s code then she will do it at 9.45am when the meeting finishes.

Either way, Bob isn’t left waiting.

In part this works simply because it keeps the review queue short. If reviews are done soon, say within 24 hours, then the queue is never allowed to become too big and thus its easy to keep the queue short.

One of the teams actually put a column on their board where tasks awaiting review could rest. In the stand-up everyone could see what was waiting for review and arrange to do it.

Simple really.

While we are on the subject of code reviews let me comment on something else.

There is often a belief that only senior developers, or only “architects” should conduct reviews. I think this approach is mistaken for two reasons.

Firstly in this model it is normal that there are far fewer reviewers than there are review requesters. This frequently results in queues for reviews because the pool of reviewers - who also have other work to do - is small.

Second this model assumes that only “architects” can make useful comments on code. I believe most, say 80%, of the efficacy of a code review is the result not of having an expert review the code but simply the result of having another person review the code.

Indeed I even go as far as to say junior people should review senior people’s code. Code reviews are a two way learning process - one of the reasons I like to see them done face-to-face. If an experienced developer is writing code that a junior cannot understand (why do I think of C++ meta-templates?) then the experienced person should know that they are writing code other people cannot maintain.

Anyway, there you go, let me know if you try this idea and what the result is.

How much does your manager need to know?

In this social media age I am often surprised by the reaction to what I say online. Usually this is not by the reaction to what I say but rather the lack of reaction. I’ve lost track of the number of times I’ve written what I think is a killer-blog post, or a super meaningful tweet, pushed it out in great anticipation and…. well…. nothing.

Just goes to show: what you think is good and what your “customers” think is good can be two completely different things.

And once in a while the reverse happens. I push out a something I think curious, of minor interest, something unobjectionable and bang!

A week or two back I put out what I thought was a slightly humorous tweet which would be agreeable to many:

“If you manager doesn’t know what technology you are using then they probably shouldn’t be your manager.”

And bang! People - techies! - took exception and rushed to defend managers - usually that is my job!

In a way I was delighted that so many people rushed to defend managers - and to say how managing wasn’t about technology. Most of the IT community damn managers without a second thought. Thanks guys!

Well I feel the need to reply and explain myself more fully. First lets clarify what I mean, then I’ll explain why I think its important.

I friend of mine recently delivered an Agile Introduction course to a client. Before the course the team leader/manager couldn’t tell him what technology the team were using. That is: which language (C#? Java? PHP? Scala?), which operating system (Windows? Linux? MacOS?) or which database (SqlLiite, MySql, SQLServer, Oracle?). Sure we could guess because we knew it was a web development but beyond that…. Anyway, not critical.

This confusion continued at the course itself. Apart from the coder (and possibly the tester) none of the others involved with the work knew which technology was being used.

My interpretation of this situation is: those who didn’t code were disconnected with the work of the technical staff. A gap existed, if they were ignorant of the central technology then what else might they be ignorant of?

(I once heard of a UK Government/BigConsultancy project where when asked “Where are the coders?” a project manager replied “I don’t know, Bangalore I think”. It later transpired they were in Newcastle-upon-Tyne.)

I also take it as a sign that those people do not have a technical (specifically coding) background. I can’t imagine a former coder who doesn’t have some interest in what technology is being used.

The situation clear?

So why is it important?

Lets point out: I’m not for one minute claiming the manager, or requirements analysts etc., need to be able to use these technologies. An appreciation of the technology can be useful, and if they can code they might be able to help, but, too much knowledge can be dangerous. It can lead to the non-coder trying to second guess the coder and tell them in too much detail what they need to do.

I once managed a C# team: as a former C++ and Java coder I could understand and join in the conversations but if I ever felt the urge to reach for the keyboard or tell them how to do their job I knew I would make a fool of myself.

The first reason I think management types should know the technology is exactly as I’ve said above: it shows they understand what is going on. One of the big problems faced today is disconnected managers. This is the reverse of micro-managing, this is what Professor Henry Mintzberg calls macro-leading: ‘people in senior position who try to manage by remote control, disconnected from everything except “the big picture”.’ (Simply Managing, 2013)

That is what I was getting at in my original tweet. If managers don’t know what technology is being used they they are simply too disconnected to be able to manage it. But I will go further….

The second reason is I think management types absolutely do need to understand programming and technology if they are to manage such efforts. I’m fond of saying: “In software development work the devil is in the detail.”

If managers don’t understand the nature of the coding process I don’t think they can manage it. And if they have never coded I find it hard to understand how they will know the nature of coding work.

If managers don’t understand how software is developed - in the real world - then they will impose models of development and management which undermine the work.

If managers don’t appreciate the difficulties that can arise in software development then they will not be in a position to use their authority to help the technical staff. Indeed they may have problems even talking to their technical staff if they lack knowledge.

I don’t believe “if you can manage you can manage anything” - it is a lie. Such advice is a recipe for the kind of mis-management we see all too often in the IT world.

The fact is: if you are developing technology you need to get your hands dirty with technology.

I’ve long been guided by the words of Fred Brooks:

“In many ways, managing a large computer programming project is like managing any other large undertaking - in more ways than most programmers believe. But in many other ways it is different - in more ways than most professional managers expect.” (Brooks, 1975)

(Indeed I chose these words to open Xanpan 2: The Means of Production.)

When I studied management I found much of the advice and good practices were highly applicable to software development. Indeed my Masters dissertation is an examination of how some management ideas map directly into Agile software development. (And yes, that dissertation opens with the same words from Brooks, “Software Development as Organizational Learning” is available to download and formed the beginnings of “Changing Software Development: Learning to be Agile”.)

There is a lot of good management practice and advice out there that many people inside IT and software development would benefit from knowing. But asking a generalist manager to manage a software development effort (always a complex effort) is going to result in problems.

Let me quote again from Henry Mintzberg:

“Managers deal with the messy stuff - the intractable problems, the complicated problems. … put together a good deal of craft along with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context.” (Simply Managing, Henry Mintzberg, 2013)

If you are managing a software development team I do not see how you can have the requisite experience and context if you have not programmed yourself. Managing does not exist in a context of its own, all management is rooted in the thing being managed.