Join members of the growing Selenium community for 3 jam-packed days of talks, workshops, lightning talks, and hack sessions. Hear speakers from around the world talk about the present and future of automated testing, share ideas with fellow Selenium developers, including Core Committers, and take part in shaping the future success of the Selenium project.

When: April 4-6, 2011
Where: Marines’ Memorial Club & Hotel, 609 Sutter St, San Francisco, CA 94102 USA
Register now to be a speaker or sponsor. More details: http://www.seleniumconf.com/

• Modular Agile: Loosely coupled, highly cohesive ceremonies
• Think You’re “Doing Kanban?” Think Again.
• On Gaelyks and Golden Hammers
• Automation for the People (because Everybody Doing It Manually Hurts)
• Build Scripts? We Don’t Need No Stinkin’ Build Scripts!
• Automated Browser Testing: What’s in Your Toolkit?
• To Selenese or not to Test? That Seems to be the Question.
• Is the Apple JVM an “Extra Feature?”

• The Seven Wastes of Software Development – Introduction
• Waste #1 – Partially Done Work
• Waste #2 – Extra Features
• Waste #3 – Relearning
• Waste #4 – Handoffs
• Waste #5 – Delays
• Waste #6 – Task Switching
• Waste #7 – Defects

Here’s a list of the complete set of articles for your convenience!

• The Agile Guerilla
• Show (Don’t Tell), Persuade (Don’t Preach)
• Going Guerilla: Where to Start
• The Guerilla’s Workflow
• Guerilla TDD
• Guerilla Continous Integration
• So What Are You Waiting For? GO BANANAS!

• Yes You Kanban!
• The Guerilla’s Workflow
• Feedback is the Key!
• Going Guerilla: Where to Start

In the near future you can look forward to a few more episodes of “The Agile Guerilla” series, as well as a brand new series I’ll be starting entitled “The Seven Wastes of Software Development.”

Got any topics you want to hear more about? Post up in the comments and I’ll see about covering them at Agile Zone in the coming weeks!

I recently accepted the role of Agile Zone Leader at DZone.com. For the past few weeks I’ve been publishing a couple of articles a week on various agile development topics. I’m very happy to get the extra exposure and I hope that folks are getting some value out of my posts. On the downside, I have virtually zero time to write anything here, but on the upside I’m definitely writing more regularly. Nothing like positive pressure to deliver!

Here are some links to my recent articles:

• You Are Your Software’s Immune System!
• Interview: Alan Shalloway on Lean Agile Software Development, Part One
• Interview: Alan Shalloway on Lean Agile Software Development, Part Two
• Show (Don’t Tell), Persuade (Don’t Preach)
• But the ScrumMaster said I had to!
• The Agile Guerilla
• Use Stories to Deliver Business Value

Enjoy!

What is too smart software? In our case, it was a system that attempted to encapsulate every single rule of “business” process that occurred within a given laboratory. Many times statements were flung around like “will it ALWAYS happen this way,” “what should we do if this happens?” etc., etc., etc. We tried to cover every single possibility, and we did an excellent job of preventing users from ever breaking their own rules. What we didn’t realize (and we’re not unique – this problem is RAMPANT) is that the rules CHANGE. Rules come, rules go. Sometimes the rule remains, but there are a few exceptional cases that must be dealt with. Our system simply couldn’t deal with a world that worked this way – and thus, our system was completely unfit for the real world.

We set out with a different mission this time. If there’s one overriding characteristic of SRM (Shared Resource Management) 2.0, it’s the explicit assumption that the world will change continually. We don’t attempt to tell you how you must use this system. We capture your data, we invoice for your services, we run your reports – but YOU, the user gets to decide how you’ll interact with it. If your workflow changes, we change with you. Now the devil is in the details. It’s taken roughly 20-30 man years worth of effort to build a system like this, and it hasn’t been easy. But in the end, we’re finding that those years were much better spent ENABLING our users rather than PREVENTING our users from getting things done.

I’m not sure that I’ve gotten my point across in this brief diatribe, so I’ll attempt to sum it up here. If you’re developing a system, figure out the 2 or 3 things that will make your users’ lives AWESOME, and do those 2 or 3 things extremely well. Don’t do the rest AT ALL. Don’t build a system that attempts to be smarter than the knowledge expert using it – it’s a means to your user’s end, not an end in itself.

I managed to complete two Pomodoros. Each of the Pomodoros was filled with internal interruptions of various kinds. One of the first things that I observed was something that I already knew from yesterday’s TADD post: I am definitely not used to focusing on one distinct task for any prolonged length of time. My mind was constantly bouncing around from idea to idea, almost as if my R-mode had a “memory leak.” My first Pomodoro was primarily a reading task – I used it for my daily Bible reading and meditation. This part of my day brings it’s focus challenges anyway, as I’m not doing anything tactile. I find its much easier to focus when I’m typing or writing something. The Pomodoro offered no relief from this, save a plan for dealing with the interruptions as they came up. First, note down that one happened with an apostrophe, and second, write the todo item or idea down on my inventory. This definitely helped to refocus my mind on the work at hand, but I still wish I could find a way to prevent those streamer thoughts from landing in the first place.

The second thing that I observed was that my workspace is not at all setup to encourage focus. In recent months I’ve stopped using task-focused desktops in OS X, something that Neil Ford recommends in The Productive Programmer. I was reminded of this later in the day today reading his latest blog entry. I think it would be a good idea to use my first Pomodoro of the day to setup task-based desktops for each of the tasks on my TODO list. I could fire up all of the programs necessary and drop them on to a space. Since a lot of my work is focused on web-based applications, I think I’ll probably use Fluid (http://fluidapp.com/) to create site specific browsers for the web applications that I need for each task. Another thing that I need to do is turn off the ringer on my phones and the new message notifications on Entourage. One tool that I did already have in my arsenal is Doodim, which blacks out everything except for the currently focused window on OS X. The only problem with Doodim (http://www.lachoseinteractive.net/en/products/doodim/) is that it doesn’t work with external screens, so only my MacBook Pro’s screen gets the benefits. I counteracted this by making sure that the window I was actively using was on the external screen and maximized, but this won’t work for some tasks during which I might have multiple small windows to interact with.

The final thing that I observed is that I still definitely live in an interruption-based work environment. My third attempt to complete a Pomodoro was repeated three times, and none of these times did I make it without having to stop and actively handle an external interruption. The difference? My office door was open. My first two Pomodoros were completed with the office door closed and my “Ssshhh…Genius at work!” sign on the door. This is going to be a tough one to handle. I don’t want to keep my office door closed all day, for more reasons than one. First, I don’t want to seem completely unapproachable. I’m a manager these days, and a huge part of my job is being available for people. For me, some interruptions will always be OK. But how can I sort those out prior to them happening? This is something I’ll be stewing on over the next couple of days. Second, my office turns into an absolute OVEN when the door is closed for too long. We have a really strange HVAC system that completely overreacts to small changes in the temperature. Unfortunately, it always seems to think I need to be slow cooked. ::SIGH::

So, there you have it. I’ve learned a lot – I observed quite a view things about my work patterns and my environment, and will be working over the next few days to make changes to both to support better focus. If you have any comments or suggestions, please feel free to comment. Thanks!

In early 2003, we were slowly dragging through development of the first version of our Shared Resource Management system. At the time our development model looked a little something like this:

1) Code until you run into an unimplemented dependency;
2) Repeat until one of the dependencies is checked in;
3) Big Bang Integration!
4) Debug, debug, debug…
5) Repeat until something pseudo-demoable is ready.

As you might imagine, this wasn’t a very productive way to work, but unfortunately it was all most of us knew. At the time I thought we really needed to improve on our testing so that we could eliminate a lot of the defects that at the time I didn’t realize were being caused by our development model. I asked my boss if I could start a QA effort and not too much later found the XP/Agile Universe conference that was held in August 2003. It was my hope that we could learn about how to properly test/QA our software there as there seemed to be a lot of talks about this “TDD” thing. I got approval to attend, and while down there I was immersed in this new culture of Extreme Programming (XP) and Agile.

At one point I ventured into a room that was setup like what many of us would call a SCRUM/Team room today, where a group of folks were all coding away on a system and making its “Fit” tests pass. I quickly paired up with a gentleman and we went to work. At some point Brian Marick came over and asked what we were working on. I fumbled through a description of the requirement and he then asked, “Well, where’s your test?” I said that we didn’t have one, and he then said something that at the time was very profound to me, “Well, you can’t write any code until you have a failing test!”

I spent most of my time waiting in the airport to return to Memphis reading Uncle Bob’s “Agile Software Development: Principles, Patterns, and Practices.” Needless to say, I was fired up.

When I returned to work in the following weeks, I essentially tried two different tactics in parallel to share what I learned with my team.

First, I practiced what Jared calls “2×4 Development,” or, beating your team in the shins with a 2×4 until they start doing TDD, pair programming, continuous integration, etc. I even delivered my own version of the agile manifesto to the entire department, and the most profound comments I got out of that were “I can’t ever imagine us paying two developers to sit at the same computer and work on the same code,” and “Well, who’s going to test the test code?!?!”

Needless to say, this didn’t work very well. My second tactic was much more guerrilla in nature. I told the guy that I was working with that I didn’t care what he did with the rest of his time, as long as he checked in his interfaces before he started to code. Now I had something to mock! I then proceeded to TDD all of my code. I advertised my productivity in terms of test cases passing with a little counter on my whiteboard. Development was fun again, as I could get instant feedback on how my code was working and I knew that it was interacting properly with its dependencies. Sure enough, when those big bang integrations happened, my code rarely seemed to be the source of the defects, and I quickly found myself getting pulled into other parts of the code to help develop since I had already gotten my typical assignment finished!

We delivered the section of the system that I developed using TDD much faster than any part that I had worked on up to that point (no hard numbers, but I have a pretty good memory of that time), and in addition, I wrote the CLEANEST code I had ever written up to that point.

So, while Jared wouldn’t recommend you try TDD if the rest of your team isn’t on board – you’re never going to get someone who doesn’t care about tests to fix one that they broke – this guerrilla tactic worked well for me and got me some recognition as a guy who could write good clean code fast! If I could go back to that point, I think I would have tried Defect Driven Testing first or in addition to my GTDD.

So, how are you getting your team test infected?

For the uninitiated, Toastmasters is an organization focused on helping individuals hone their communication and leadership skills in a safe environment. This is accomplished primarily through three different avenues:

• Serving in one of the meeting leadership roles, such as Toastmaster (the meeting facilitator);
• Giving a prepared speech/talk from the list of speech projects in the Toastmasters “coursework”;
• Speaking extemporaneously on one of several “table topics,” which are speaking prompts provided during the meeting.

Participation in any of these avenues is immediately followed up with feedback from one or more people playing various “evaluator” roles. I couldn’t help but see the parallels to agile software development!

I’ve now attended three meetings, and at the last meeting I decided to join up. The St. Jude club is an extremely friendly group, and several of its members are very accomplished public speakers. You can definitely tell that the Toastmasters experience has helped them enhance their communications skills. I’m looking forward to polishing my own.