AYE Conference Next Week!

The AYE Conference is next week and I’m very, very excited about it! I will be there, doing several sessions. Dave Smith and I are doing a session on Renegotiating where participants will be playing the “Renegotiate” game – a game that Dave and I created. I will also be running my WordCount simulation in my session titled Reflect and Adapt. And I’ll be running a fun session on using our worst nightmares to improve our testing, titled “What Could Possibly Go Wrong?”

And I’m really excited to participate in the sessions that other presenters are doing. Dale Emery will be doing sessions on Resistance as a Resource and Putting Your Power to Work. Diana Larsen (co-author with Esther Derby, of Agile Retrospectives) will be doing a session on Cultivating Trust in Teams.

The hosts for the conference are all doing sessions as well. And that includes Esther Derby, Johanna Rothman (co-author, also with Esther, of Behind Closed Doors: Secrets of Great Management), and also Jerry Weinberg, industry icon and early pioneer, and author of many books including The Psychology of Computer Programming, Becoming a Technical Leader, and Secrets of Consulting.

It’s designed to be a small conference, and the organizers cap participation at 99 people. That’s why I was surprised to learn that they still have spaces left. If you aren’t doing anything next week, and you feel like coming to Phoenix, AZ, you should come join us. It’s a tremendous opportunity to spend 3 days of intense interaction with some amazingly cool people.

From the Mailbox: TDD and Automated Testing

A reader asked: “I am hoping that you can answer my question to clarify something for me and another co-worker. Could you tell me the difference between TDD and Automated Testing? He says that TDD is for unit testing and Automated Testing is for System test. He also says Scrum doesn’t include anything about TDD so we don’t have to do it.”

Let’s start with definitions.

TDD stands for Test Driven Development, a specific technique introduced with Extreme Programming (XP). TDD tests are unit and sometimes code-level integration tests. But TDD itself is a development approach rather than a testing approach. However, a key result of doing TDD is that you end up with a fully automated set of code-facing tests. The Wikipedia article on TDD provides a good overview.

So the characterization of TDD being about unit testing is partly correct, but it is a misleading oversimplification.

Now, about automated testing. An automated test is one that can be executed by the computer rather than by a human. The term applies to any kind of automated test, and is not limited to system tests.

However, the distinction between developer tests and acceptance or system tests is useful. Developer tests are code-facing, and a result of TDD. Acceptance tests are business-facing, and on Agile projects, their automation is the result of a collaboration between the business stakeholders and the developers. Both are important. One of the mistakes that Agile teams tend to make is attempting to substitute unit tests for acceptance tests, or vice versa.

Now back to the assertion that “Scrum doesn’t include anything about TDD so we don’t have to do it.” It’s true that in Agile Software Development with Scrum, Ken Schwaber and Mike Beedle say: “During a Scrum, only the team can define its work.”

But that doesn’t mean it’s responsible to say: “Scrum doesn’t say we have to do it. So we don’t have to if we don’t wanna. Neener neener neener thbbbbpppt.”

Scrum also says that “Although a team has the authority to decide how to do its work, the team is responsible for using and conforming to any existing charters, standards, conventions, architectures, and technology. These ensure that the products of the project and the Scrum Team fit in with other organizational products and can be understood by others.” (See Agile Development with Scrum, pages 38 – 39)

Furthermore, as the Agile Project Leadership Network’s Declaration of Interdependence states, being Agile means delivering a continuous flow of value. To achieve that continuous flow of value, we have to use development practices that provide the visibility and feedback needed to make frequent, incremental changes.

Put another way, Mary Poppendieck says that speed requires discipline. I extend that to agility in general: if you want your team to be Agile, it must also be disciplined. Agile doesn’t mean “do whatever feels good.”

That need for disciplined development practices is why many teams have found that embedding XP-like practices (TDD, continuous integration, collective code ownership, pairing and/or frequent code walkthroughs, etc.) within Scrum is an incredibly powerful combination.

The bottom line: automated testing at all levels can be difficult, but the alternatives are worse. Without automated testing, both code-facing and business-facing, the manual testing burden becomes too large, the team begins incurring technical debt, and velocity slows.

So I don’t buy the argument that “Scrum doesn’t say we have to…” I think the real question is not what Scrum says or doesn’t say, but rather what practices are needed to ensure continued Agility.

Oh, the irony…

So I’m working on course materials for a class I’ll be teaching next week on Acceptance Test Driven Development.

I decided to try using Keynote on my trusty no-longer-all-that-new Mac instead of PowerPoint. I find PowerPoint on the Mac incredibly annoying. Whenever I want to edit a presentation on the Mac that I created on the PC (like, all of the presentations I have), I get Converting Metadata messages all over the place. When editing a 300 slide file, making even the smallest change can take forever. So, Keynote seemed like a better alternative.

Now I should explain that although most of my slide decks look reasonably simple, I tend to use a lot of animations for certain types of things – like bringing a workflow to life.

And I also use the presenter notes area as a place to put the meat of the materials for participants so that when I print books with both the slide and the presenter notes, there’s a good amount of text. The result are course notes that read kind of like a book with a whole lot of illustrations.So in other words, I am not your typical lightweight presentation software user. And I’ve crashed PowerPoint a lot as a result.

But I had high hopes for Keynote. For starters, it’s Mac software. Built for Macs. None of this ported over from Windows crap.

Alas, I was doomed to disappointment.

First, when I attempted to do some fiddly edits on the text under a page with a ton of animations, Keynote died a horrible death. It didn’t exactly freeze entirely, but I could no longer edit the content. I could attempt to save/export my file, but every time I did – no matter what format – it told me that the file was corrupt. Sadly, I’ve gotten out of the habit of saving every 30 seconds, so I lost a fair amount of work.

When I finally recovered everything an hour later, I vowed not to make the same mistake again. I not only started saving rabidly every 30 seconds, but I also checked everything into my subversion repository. However, when a subsequent commit failed with the message “Directory …/.svn containing working copy admin area is missing” I learned that there’s an interaction bug between Keynote and Subversion. I used the workaround kindly published by Daniel Sadilek (bless you, dude). And I was back in business. Annoyed, but back in business.

But here’s the thing. I’m already annoyed, and now I’m looking at my .key file for a 27 slide file, and it’s 3.8Mb. What??? I know I’m abusive to presentation software. I understand that my usage is a tad on the abnormal side. But 3.8Mb for 27 slides? Slides with graphic drawings and text, no photos, no movies, no sounds? That’s nuts. With a little experimentation I discovered that more than half that is due to two slides that make extensive use of animations. And I’m betting that those same animations had something to do with Keynote dying a horrible death when I tweaked the text underneath. Someday when I have more time I’ll see if I can reproduce the bug.

Let’s just say I’m re-evaluating my decision to use Keynote. PowerPoint is looking pretty good right now. Sigh.

And this is also a lesson re-learned about software testing: there’s nothing like a real user to find real problems. For Agile projects, that means automated unit and acceptance tests are necessary but not sufficient. Make sure real humans try the software under real world conditions. Given the topic of the course materials I was working on, this was a timely reminder…though a far more painful one than I really wanted.

AA-FTT: the Agile Alliance Functional Testing Tools program

I’m back from the first event sponsored by the Agile Alliance Functional Testing Tools program. We held a visioning workshop in Portland, OR on Thursday and Friday of last week. While we generated a lot of great ideas and began hammering out a direction for the future, I think the real results of the workshop will be visible in the weeks or months to come.

In the meantime, if you’d like to participate in the online discussion list that we created for the conference, I invite you to subscribe. Workshop participants are already posting tool links and blog links and conference photos there. And at some point in the not-too-distant future videos of the tool demos and lightning talks will be available too. So it’s the best place to find out what happened at the workshop.

In other news, the Agile Open California (AOCA) conference still has a few open spots. It’s in San Francisco next Monday/Tuesday, October 22/23. (See http://www.agileopencalifornia.com/). I highly recommend it.

RubyFIT and Fitnesse

At the moment, I’m creating a little Acceptance Test Driven Development (ATDD) demo. I’m keen on Ruby these days, so I wanted to do it all in Ruby. And I wanted to use Fitnesse. And as it happens, Fitnesse supports RubyFIT. Or RubyFIT supports Fitnesse. Something like that. So I figured this would be a slam dunk.

I was wrong. It’s taken me the better part of a day. Now it could be because I can’t read directions terribly well. And that may also explain the odd assortment of leftover hardware I have from various Ikea purchases. But I did discover at least one gotcha I didn’t find documented anywhere else, so I thought I’d share.

First, major thanks to Cory Foy for his fabulous little tutorial. And thanks to maosd, whoever you are, for blogging some update notes. They helped a lot. And finally thanks to Ron and Chet for blogging about their RubyFIT/Fitnesse adventures.

Now, for the gotchas I ran into that made a 1 hour project into something more like 6 hours.

  1. Beware hiding the right side of your browser off-screen. The “Errors Occurred” icon in Fitnesse appears on the right hand side of the browser. And if it’s off screen, all you’ll see is a friendly “Assertions: 0 right, 0 wrong, 0 ignored, 0 exceptions” when something goes drastically wrong. Time wasted: 1 hour. Yes, I am an idiot.
  2. By default, mac host names are like host.local. So my iMac, “eshmac”, has a host name of “eshmac.local”. The first problem I ran into was that Fitnesse wanted to refer to the machine as “eshmac,” and my machine maintained “there’s nobody here by that name.” I tried to figure out how to get Fitnesse to let me customize the host name, but to no avail. So I decided to make “eshmac” a legitimate name instead. Now, I’m sure there are better ways to do this, but since I didn’t want to change the host name on the network, I just added a record for “eshmac” and pointed it to “127.0.0.1” in the /etc/hosts file. Time wasted: 0.5 hours.
  3. As maosd indicates, you need to call the FitServer.rb file from the gem location. Conveniently enough, the path is documented in the README.txt file that comes with the RubyFIT gem. Inconveniently, that file is placed in the very folder I was looking for. The answer is that on Macs, gems get installed to /usr/lib/ruby/gems, and you can find the RubyFIT gem at /usr/lib/ruby/gems/1.8/gems/fit-1.1/. Time wasted: 1 hour.
  4. In Cory Foy’s tutorial, where it says, “You want to go one directory below the directory your class is in,” it really means one directory below. I had my !path variable set incorrectly, and could not figure out for the life of me why RubyFIT couldn’t find the fixture. Silly me. Time wasted: 2 hours – and waaayyy too many “puts” statements.

So, as a service to those who happen to be as documentationally challenged as I am, allow me to be excruciatingly precise about the naming thing with RubyFIT and Fitnesse. It’s enough of a gotcha that lots of people have already written about it. But here’s my attempt at explaining things.

Let’s say you want to call your test page FooTest. And you want to create a Division fixture. And you want to create a directory hierarchy under “/mine” to hold your fixture files.

Your Fitnesse page will contain:

...other stuff...

!path /mine/
|Footest.Division|

...other stuff...

Your fixture code will look like:

...
module Footest
	class Division < Fit::ColumnFixture
		# code goes here
	end
end
...

And that code will live in the file /mine/footest/division.rb

Once again, note that the !path setting in Fitnesse is “/mine/”. For the record, the mistake I made was setting “!path /mine/footest/”. As I said, I’m documentationally challenged.

Matching capitalization does not seem to be important, but the names of the directories, files, modules, and classes sure are. And they all have to match up. So, your test page name must match your module name and that must match the directory name in which the file lives, and does not match the !path variable.

I’m sure I’ll run into more gotchas, but I figured I should document these while I’m thinking about them.

From the Mailbox: How Much Visibility is Too Much?

A long time reader wrote to me asking what I thought of the idea of letting management have full access to an internal bug tracking system. He said that the idea made him nervous, but that others were pushing for it.

This person works in a traditional, non-Agile environment, one that has historically practiced information hiding.

But I think visibility is important even in non-Agile environments. After all, most attempts to impose control are a reaction to lack of visibility. Think about it: quality gates and heavyweight processes with reporting requirements are usually given labels relating to bringing projects under “control,” but they’re really about visibility. Such practices are a managerial response to the feeling “I don’t know what’s going on!”

Management is responsible for the success of the project, and must make decisions about projects every day. Ship or delay? Staff up or ramp down? Authorize additional resources or make do with what we have? It’s really difficult to make good decisions about a project in the absence of concrete information – like what kinds of bugs remain in the code. So my first reaction was, “Why wouldn’t you give management visibility into bugs? What could you possibly gain by hiding that information?”

But my correspondent (who shall remain anonymous here) pointed out the curses of full visibility:

  • The managers don’t understand the details and need a lot of help interpreting it. And even then they still don’t really understand the technical implications of any given decision.
  • In this particular culture, these managers tend to use such information to play rounds of pin-the-blame-on-the-techie.
  • The managers also tend to use such visibility as an opportunity to override decisions, decisions that they would be perfectly happy with otherwise.

Ah yes. The problem with visibility is that it’s so visible.

Even in Agile teams, visibility can be a double-edged sword. I’ve witnessed some managers behave a little irrationally when the visibility afforded by Agile development made it quite clear that the real problems in the organization lay within the corner offices and not within the programming bullpen. When an organization is built on information hiding, visibility is guaranteed to upset the current power structure.

But I can’t help but notice that last concern my correspondent had about managers overriding decisions, and I think that is the crux of his problem.

Here’s an area where even traditional phased projects can take a page from the Agile book and separate decisions into two categories: business and technical. Agile processes are quite clear about who gets to make what decisions. If it’s a question of what we’re building or how important it is (requirements/enhancements/fixes and priorities), it’s a business decision. If it’s a question of how, or how long it will take to do the work, it’s a technical decision. The business stakeholders (“management” in this case) make the business decisions. The implementation team makes the technical decisions. Neither side attempts to do the other side’s job.

Once everyone agrees on who gets to make what decisions, it becomes safe to reveal any and all information without fear that the information will be misused. And if a manager tries to override a technical decision, perhaps telling the technical team to fix the floobitz bug by renormalizing the object array and subclassing the relational database to a singleton, the technical team gets to say, “Thanks for your input; we’ll take it from here.”

In fact, I think lack of visibility is far more dangerous than an excess of visibility.

Keeping internal stakeholders in the dark about things like bugs creates an imbalance of information. That imbalance that leads to all kinds of odd political games and maneuvers in which information is power. Such political maneuvering creates unhealthy work environments. So while visibility might be scary, the alternatives are worse. Icky things fester in the dark.

If visibility causes pain, the solution isn’t to hide the details. Rather, the solution involves understanding why visibility is causing pain. Chances are it’s because the organization lacks clarity on who gets to decide what. And that’s the real problem that needs to be addressed.

Agile Open California

This year, I’ve attended two small Open Space conferences, AONW and CITCON in Dallas. Both were incredibly valuable events. I learned a lot, I got to participate in some great conversations, and I met a variety of people with whom I’ve continued to connect.

(And some of those reconnections have been pleasantly serendipitous. While in Finland, I arrived about an hour early for one of my meetings. The only other person there was a fellow American. We started chatting and realized that we’d actually met before. In Dallas at CITCON. It’s a very, very small world, and getting smaller every day. But I digress.)

So anyway: there’s another, similar conference coming up October 22 – 23 here in the San Francisco Bay Area: the Agile Open California conference. Modeled after Agile Open Northwest, AOCA is another all-Open-Space-all-the-time-conference.

If you’ve experienced Open Space before, you know how cool it is. If you haven’t, you may not know how it works. In Open Space, the content is developed by the participants in the moment. It’s not your typical simultaneous-tracks-with-droning-speakers-and-death-by-PowerPoint conference. Instead, the content reflects what the participants want to talk about, now.

In traditional conferences, participant feedback inevitably includes comments like “The coffee breaks were the best part!” and “I found it incredibly valuable to be able to exchange ideas and experiences with my peers!” Open Space is like all-coffee-breaks-all-the-time, but with a lightweight organizing mechanism to make it easier to find the most relevant discussions for your current situation. The result is magic.

AOCA has an impressive participants list, and I’m sure the sessions and the conversations will be fascinating.

My friend Ainsley who has had a big hand in organizing AOCA tells me they still have places left. Frankly, I’m stunned that they aren’t sold out. I highly recommend you grab a space if you plan to be anywhere near SF at the end of October. Given my experiences at AONW and CITCON, I predict it will be among the best 2 days and $250 you’ve spent on conferences, ever.

(And in case you’re wondering – the only reason I’m not going is because I had a previous commitment that’s taking me out of the country – again. I’m really disappointed that I’m going to miss AOCA, but I can’t move my commitment. But because I think conferences like this are important, my company is a sponsor even though I can’t be there.)