Am I Doing Scrum? - Nokia's Benchmark for Scrum Adoption

Dr. Jeff Sutherland, and Agile Manifesto signatory, has posted an excellent interview, "Scrum and Not-Scrum". As part of this interview, he advocates eight questions that Nokia uses to determine if their teams have adopted Scrum. Jeff presents this as a boolean test. If the team can answer "yes" to all eight of these questions, they are doing Scrum. If any question gets a "no," then they have not fully adopted Scrum. Here are the questions:

First Tier:

• Are you doing iterative development?
  
• Do you have a fixed iterations lasting less than six weeks?
• At the end of the iteration, do you have working software?
• Can the team effectively start work on an iteration without a detailed specification?
• Is testing part of the increment?

Second Tier:

• Do you have a product owner?
• Does the product owner have a prioritized, estimated product backlog?
• When the team is developing, do they have a burndown chart?
  
• Can you calculate the team's velocity?
• Is the team self-organizing?
  
• In other words, does the team choose, assign, and map the fastest possible way to deliver the work?
  
• The project manager cannot interfere with the team during an iteration.

I highly recommend watching this interview. It is only about 20 minutes long, and it is packed with good information including a summary of Google's boiled frog adoption of Scrum on the AdWords project.

Jeff also reminds us that Scrum will not solve your organizational problems, but it will make them painfully obvious.

Programmers Anonymous: Confessions of a Terrible Software Developer

Marc has posted his "Confessions of a Terrible Programmer." The overriding tone of the post can be summed up in the following pseudo-Zen quotes:

You will never become a Great Programmer until you acknowledge that you will always be a Terrible Programmer.

and,

You will remain a Great Programmer for only as long as you acknowledge that you are still a Terrible Programmer.

Marc does a very good job of stating how he overcomes his "terribleness" to provide working software. According to Marc, his solutions are doing a good job of hiding the fact that he is a terrible developer. However, I believe that agile practices present different solutions to these problems. In broad terms, Marc favors failing fast where I favor multiple levels of testing, Test-Driven Design, and the fast feedback loops provided by good test coverage coupled with Continuous Integration.

To address more specifics, I have provided a summary of Marc's solutions along with where I think agile solves these in a different way.

1. Marc says he favors strong typing to prevent problems. Having done most of my work in static languages (Java, C#), and some in dynamic language (Groovy), at this point I prefer solid unit test coverage (100% with excuses). Test-first design helps with this too. Once I have good test coverage, those tests are unearthing the same problems that the compiler would. With the dynamic languages, I find the same errors a bit later, but I get the benefit of code that I find to be much easier to read.


2. Marc favors programming assertions. Marc is a paranoid programmer. He will assert that something is not null even when he controls both sides of the interface - just in case he might change something later. I personally find that assertions and paranoid programming in general fall under the related headings of YAGNI and nosiy code. Instead, I prefer solid unit testing and a tester that knows how to unearth the edge cases. Write unit tests that assert that the service in question does not return null to box in the behavior.


3. Marc says he will, "ruthlessly try to break [his] own code." It appears that Marc is trying to accomplish through developer testing what should be done by an actual tester. While I agree that developers should be generating tests that give great code coverage, it is a waste of time to make them switch hats and become a tester for their own code. Hire a tester. They think differently from developers. Their concerns are different.


4. Marc favors code reviews. I favor pair programming. Both provide feedback, but I want my feedback while I'm "in the zone." I want my feedback immediately. I don't want you to sit back and wait for me to find my own bugs. If you see something, tell me. Tell me as soon as it looks like I've finished typing or as soon as it looks like I'm looking for the bug. This way, I can fix the problem without having to make the context switch to come back to it later. Plus, the quality of the review is better since the other developer should be equally engaged in the generation of the code while it is being generated.

To be honest, our team is not able to follow all of these guidelines at the moment. Our biggest problem is not having a dedicated software tester embedded with the team. We ARE having to generate the types of tests that a dedicated tester should be doing. And, we are missing some things that a tester would catch much earlier in the development process. I feel that this missing component of our team IS hurting our velocity.

Am I a terrible programmer? Yes. If you find me stating otherwise, please redirect me to some of my own code - something that I wrote yesterday should do just fine.

What are you doing to hide the fact that you're a terrible developer? I would love to hear.

How To Pass Command Arguments With a File Type

UPDATE: This issue appears to be fixed with the Groovy 1.5 Windows install package. However, this is still good general information to know about passing command arguments with file associations in Windows.

I just upgraded my groovy install to the latest RC for 1.1, and it quit recognizing command arguments. I tried debugging all kinds of older scripts that I knew worked, and none of them were working anymore. That's when Steve reminded me that the Groovy install messes up the Windows file extension association. So, it installed the .groovy file association like this:

"C:\groovy\bin\groovy.exe" "%1"

And it needed to be changed to this:

"C:\groovy\bin\groovy.exe" "%1" %*

This will allow the other command arguments to be passed when the groovy script is kicked off.

To change the file association (in XP),

* Open My Computer
* Tools -> Folder Options...
* Click the "File Types" tab
* Find the file type you want to change, ".groovy" in this case, and click it
* Click the "Advanced" button
* Click the "open" action
* Click the "Edit..." button
* Edit the content of the text box under, "Application used to perform action:"
* OK / Close your way out of the dialogs.


Obviously, this will work for other file associations. This method, while it forces you through a few windows, allows you to avoid mucking with the registry directly.

Don't Get Fooled

Junk is junk. Whether it comes in your (snail) mailbox or your Inbox, it's junk.

Scott has a post asking how to teach common sense when here. Some will learn, some won't.

People that fall for scams fall for them whether they come by snail mail, telephone, or email Email is the easiest to perpetrate. Therefore, more people are falling for email scams these days.

The unfortunate thing is that I haven't found a way to foist pain back onto those that are populating my Inbox with crap. Actually, my filters are pretty good these days, so I don't see most of it.

With telephone scams, my game is (when I have the spare time) to keep them on the phone for as long as possible. I once kept a scammer on the phone for two hours while he kept trying different ways to get me to tell him my bank account and routing number. At least for those two hours, I knew that THAT guy was not scamming someone's grandmother.

Why Are You Asking Me This Question?

Any developer that's been around this industry for any length of time has found himself in a conversation like this one:

Manager: Hey, Mr. Developer, TheBusiness has decided that we need to develop a product to do XYZ. How long will that take?
Developer: Hrm... I'm not sure. What are the details of XYZ?
Mgr: The details aren't important. I just need an estimate
Dev: Well... something like 8 weeks.
Mgr: Okay, well how much longer until you finish the thing you're working on?
Dev: Around 4 weeks
Mgr: Okay. Thanks.

[10 weeks later]

Mgr: So, Dev, I'm looking forward to having this XYZ product. We've already sold it to 50 customers and they're excited to be getting it in two weeks.
Dev: WHAT?!?!?!

This is not a fun series of conversations. The breakdowns in communication should be obvious. The manager (unknowingly) expected way too much precision from the developer's estimate, and the developer gave it without nearly enough qualifying statements pointing out that it's a WAG.

So, how can this be fixed? Many developers that I know say, just don't provide the estimate. While most of us could get away with that, it doesn't necessarily help the conversation. I prefer to answer with, "Why are you asking me this question?" This is a question that I learned to ask by watching a former team lead, Glenn Burnside. Whenever a salesperson or manager would ask the team a question like, "How difficult would it be to...," Glenn's response was always the same - he would ask this question. This always resulted in a conversation that fleshed out a more detailed question (or questions) and much better, more precise answers.

The hardest part of software development is interacting with those objects that have a pulse - not those that have a system clock.

altnetconf - Cool Tools Don't Make Cool Software

I'm pretty sure that Jimmy Hendrix could make awesome music with a cheap guitar. Likewise, I could drop $5000 on a beautiful vintage guitar and I still won't be going on tour with anyone. The artist makes the tool work. While good tools make the artist's life a bit easier, they don't make the artist.

Likewise, it is perfectly possible to write clear, maintainable software without the use of things like inversion-of-control containers and mock frameworks. This weekend at the Alt.Net conference, I spoke with some very smart developers that don't use these tools that I take for granted. Tools that I even view as a necessary item. One developer that I spoke with stated that he has yet to find a need to use a mocking framework. Instead, he prefers the Testable Object pattern. I was completely taken aback until I grokked what his explanation. While I'm not going to drop my use of easymock, I see that this is certainly a valid way to do things.

I had the opportunity to speak with another developer this weekend - a brilliant developer and the second person ever added to my feed list. When the table at lunch started talking about IoC containers, he said that he's never seen the need for one. I found this to be very surprising. Once a couple of us explained why we like and use tools like StructureMap and Guice, he quickly grokked what was going on, and I think he could see why some find them to be useful tools to have. However, it also became clear that he had found other ways around the pain of supplying dependencies when using Dependency Injection.

All of this is to say that I was reminded that I don't have to pull in every tool under the sun. It's good to keep my head up and take a look at what others are doing to alleviate problems. However, there are also other ways around problems that may not involve pulling in yet one more tool.

It's not the tools that make the software good. It's the developers that apply sound judgement and experience - regardless of what tools they have.

altnetconf - Random Thoughts on Fishbowl

Some of the sessions are using the fishbowl format. This is a really fun format that lets just about anyone that wants it the opportunity to contribute content to the conversation. However, this did not work very well during the BDD Discussion most likely because code samples were being periodically presented on the projector. This was proof positive that if your turn on a video source, the entire audience will focus on it. In this case, chairs were setup for the fishbowl, but the fishbowl rules were not followed by the audience. Because the group was focused on the screen rather than the chairs and the people in them, the conversation was not controlled.

Either present video or do the fishbowl, but it seems you cannot do both at the same time

altnetconf - Behavior Driven Design

This post is separated into summary and thoughts.

Summary

This thing called "Behavior Driven Design" (BDD) doesn't seem to have a formalized definition. Not everyone in attendance could agree on what "it" is. However, the most clear definition presented involves several components. Scott Bellware asserted that BDD = UserStories + TDD + UbiquitousLanguage + Solubility.

Some constraints on the above components should be explained. User stories must be well-formed. So, the idea is that during a conversation that the business analyst and the developer would work together to produce a story of the form "As a... I want to... So that..." The assumption is made that the TDD being used is driving design at a granular level with only one assertion per test. To extend Scott's definition of Solubility linked to above, another term "grokability" was proposed by Scott Hanselman.

The Behavior Driven Design (BDD) session began with many questions, asked many more, and perhaps answered a few things. Bellware started by saying that BDD is not about testing. He later stated that BDD provides better tests. So, to summarize, BDD is not about testing... except when it is. So, that make that about as clear as mud.

Much of the discussion centered on improving the conversation. More specifically, the conversation between the developer and the business analyst was discussed.

One criticism presented is that BDD is using programming languages to discuss things with the business analyst. The concern was that we would be asking business analysts to write specifications including the markup. This bred a great deal of consternation.

This critique was perhaps diffused later when the suggestion was made that the business analyst would sit down with the programmer, and the two would discuss the user story and the specifications. During that discussion, the developer would transcribe the conversation into the story markup used by the spec tool (RSpec, NBehave...). Another possibility presented was that the conversation could be initially captured onto a story card and then transcribed to the tool by the developer at a later time.

There was the assertion made that BDD provides or formalizes context for conversations with the business analyst and context for the developer to write the implementation.

Scott Hanselman says, "This is like NUnit that generates prose." There seems to be a bit of buy-in for this. Perhaps C# doesn't lend itself to the readability of the spec implementation. The business owner writes this through the ears of the developer that is sitting next to him.

Part of BDD is generating a specification document directly from the tests. This allows the tests and the information being passed back to the business analyst to stay in sync better. This is NOT to replace verbal communication, but again to provide a talking point to augment the conversation.

Thoughts

It seemed as though the thoughts around BDD have application in many parts of the development life-cycle. BDD practices are useful for clarifying the discussions that should be taking place during the entire process. The initial definition of user stories is helped by these practices. During development, BDD practices help developers see the bigger picture. Finally, and importantly, the executable specifications serve as a note to the future self. In other words, when you come back to the code, it is easier to understand why the test was written in the first place.

Much of the confusion came about because these thoughts are useful in so many different places. It seemed that participants saw the potential to have certain pains alleviated, then latched onto that particular portion of usefulness. BDD is aspect-oriented. It is a cross-cutting concern and does not simply fit into a single portion of the development process. Wherever there is conversation in the development process, formalizing that conversation helps to remove ambiguity.

Perhaps this is more useful when you MUST generate documentation. Not everyone needs to have everything generated in paper form. For some business, people, they feel better seeing the specifications generated as either a sheet of paper or a web site. Even in situations where this documentation must be generated, this documentation is not set in stone.

I'm pretty convinced that we don't need a separate tool to do effective Behavior Driven Design. We need to get much better at language - both natural language and expressing natural language with programming languages. As if the natural language wasn't ambiguous enough, we are forced to complicate it by writing something that the parser can understand.

The conversation about this is still in process. I'm sure that I don't know everything about this. I hope to continue to look in this area and find ways to write better software with less pain.

altnetconf - Alt.Net First Impressions

I'm not sure how much I will find myself around the computer this weekend, but I thought I would post my impressions of the ALT.Net conference as we go along. The comments during the opening remarks and fishbowl seemed to center around a few core concepts:

• Though perceptions might be otherwise, nobody expressed total contempt or hatred of Microsoft.


• Everyone wants to write better software.


• Writing better software probably means using tools that weren't developed in Redmond.


• The overriding of "better software" seems to be maintainability.


• Drag-and-drop is still the whipping boy of this crowd.


• Alt.Net IS alternative because most .Net developers seem to use whatever tools Microsoft puts out (and MSDN talks about). Conference attendees are much more likely to use tools that are alternatives to simply the set put out by Microsoft.

I'm looking forward to hearing more opinions and thoughts as we go along. I'm not sure how much will be decided. Many seem to want to come to a consensus, but everyone in attendance is so passionate that it may not happen. We'll see. At least we're trying to figure out what is going on and how we can deliver better software for all involved.

Don't Use Mocks...

...when you aren't really interested in testing the interactions. This is related to my previous post regarding mocks and stubs. If leaving off the verification of mocks wouldn't change the nature of what you are testing, then you aren't writing an interaction-based test. Therefore, the mock dependency probably creates more noise than simply using a simple stub. If your dependency is not behind an interface, you can in most cases still create a stub using subclass and override.

While writing:


Dependency dependency = createMock(Dependency.class);
expect((Foo)dependency.bar(anyObject())).andReturn(somethingValid);
ThingToTest target = new ThingToTest(dependency);


isn't too bad. It still causes more noise than:


ThingToTest target = new ThingToTest(new DependencyStub());


Most of the time, I see that stub and grok the fact that in the context of this test, I really don't care what the Class under test does with that dependency.