I had a great batch of interesting items lined up and then laptop had an odd shutdown (driver issue) and Firefox couldn’t reopen my state from that day. So much great stuff has been lost. So sad.

This week I lead off with Ilja Preuss’s “The Aha-Experience Exercise” – this an exercise helps attendees highlight continuously review their training and share with each other what is working. The best part I saw Ilja mention this on twitter. I asked for details and week later I have this blog post. Ilja thanks.

Being late to the party I missed Dale Emery’s “Writing Maintainable Automated Acceptance Tests” last year when it first came out (examples in Robot Framework). Uncle Bob replied with a version for FitNesse.

Finally George Dinwiddie reminds us that you really can’t get “100% utilization” (or even close) out of your software developers.

Next week I intend to write a short piece on acceptance testing.

Be Sociable, Share!

• 

Offshoring is frequently promoted as a way to produce great products for far less money. So many software development companies boast about sending large amounts of their work to India or China to reduce costs. Unfortunately, in doing so they’re often reluctant to pay the price to create and maintain high-performance distributed teams.

Agile works on the basis of a few simple principles:

• Short Feedback Loops—which leads to iterations, TDD, …
• Radical Transparency—which leads to daily standup, demo/review, …
• Face-to-Face Communications—which leads to high trust, group problem solving, …
• Value—which leads to eliminating waste
• Continuous Improvement—which leads to retrospective, adoption of engineering practices

Thinking back on every project that I’ve ever worked on (Agile or not), the quality of communications was a good predictor of success. So when we run distributed teams, there has to be a focus on making communications work.

At best, the typical approach to this problem is to buy web cams, fancy video- conferencing software, and conduct our meetings sitting in front of them. But that misses the point—these devices improve the quality of communications but not enough. They don’t build trust. To really build trust, you have to meet face to face for at least a week. Unfortunately, trust is weakened through the course of a year, so it has to be renewed. At a minimum, team members should visit each other twice a year.

So, if you really want to get a high-performing team—don’t underestimate the real costs. Be sure to budget for travel—a minimum of twice a year to build and maintain trust. Don’t shortchange your distributed teams.

Be Sociable, Share!

• 

Almost exactly three years ago, I was trying to use David Allen’s "Getting Things Done" (GTD) system, and I wasn’t seeing the benefits he promised. In the end, I found that it just helped me thrash. I suspect the problem was more my focus than his system—but at end of the day, his approach just didn’t resonate with me.

Today, my system is a little closer to a hybrid of Mark Forester’s AutoFocus and Francesco Cirillo’s Pomodoro Technique. I still use MLO as my task manager but on a more granular level than I used to. Instead of slaving over MLO constantly, now I use it to help generate my list for the day. I use MLO to keep track of a large list of tasks. Mostly, I just use the outline to remind me of things I want to tackle. Every day I glance at the TODO view to make sure that there isn’t anything that is date sensitive that I’ve lost track of. Once it comes to committing to tasks for a particular day, I often use index cards using MLO, email, and anything else as inputs. At the end of a day (sometimes two), I take anything that remains in the card and put into MLO. Then I tear up the card, which is probably the most fun part.

Other habits:

• I sweep my tabs in Firefox every few days and move stuff to reading lists in MLO.
• Once/Twice a week I go offline and go through my email.
• Once a week I take some time to reflect—what is going well, what needs improvement, what do I  have the energy to improve, and what one thing can I do next week to improve it. Aka a retrospective. This is the hardest one to maintain—because you’re tempted to skip it and get more "work" done. Yet, it’s the most important because it drives real improvement.

I use the Pomodoro Technique for the following:

• a reminder to stay on task
• a way of doing a rough estimation every morning

Also, on a two-monitor setup under Win7, I dock MLO on the far left and leave it in outline mode, where I can always see other things I want to do.

Other tools I use include ClipMate Clipboard Extender because it allows me handle more than one item in the clipboard and to clean (i.e., remove html, etc.).

Be Sociable, Share!

• 

Last week I challenged Agile Tool Vendors, and the post got a little bit of attention. I received replies from Rally: How Agile is Rally?, Danube: How Agile is Danube?, and MicroTool: How We Use Agile to Develop Our Tools?.

In addition there were several comments with replies: Robert Dempsey:

CEO and Founder of Atlantic Dominion Solutions. We developed Scrum’d: http://www.scrumd.com. A great post and an excellent challenge. To answer your questions:

# Your Definition of Done

We define done for each user story. Acceptance criteria includes the behavior a user can expect from the app when using it, the workflow for the feature, that it needs to be tested (and how it will be tested), any validations that occur, and if there is documentation for the feature that it is updated.

# Whether you use TDD? Or at least Unit Testing?

We do full TDD for all our stories. We didn’t start out that way, but now that we have a full test suite, we keep it that way. Also, if a bug is found, then a test needs to be written for that and the code fixed.

# What do you do for Acceptance Testing?

We have staging servers set up for internal testing. We also have a few select customers that we let into our staging servers, and I show (in person) some of our current and potential clients the features to get their feedback as well. In addition, we use Get Satisfaction for our support site and ask that commentators who suggested features that we implement to check out the release and see if it’s what they wanted.

# How often do you release?

This depends. We try to do monthly releases. Sometimes it’s longer, but typically it’s less. The release schedule really depends on the importance of features to our user community.

# What did you learn in your last retrospective?

You don’t always get it right the first time, but anything you do release needs to work correctly. Also, continuous integration is a huge help as your product gets bigger, and of course, testing is an absolute necessity. We would rather delay a release to ensure quality than release stuff that won’t work.

Marcin Niebudek (creator of TinyPM)

I like challenges, so…

Our DoD for stories:

• code meeting minimal requirements committed
• unit tests passing
• feature is working under FF, Chrome, and Opera
• feature is working without any significant failures under IE
• feature is tested and accepted by at least one team member that was not implementing the story

Our DoD for release:

• WAR and .exe distros built successfully
• all unit test passing
• all functional bugs fixed
• all UI bugs fixed or small UI bugs (mostly for IE) at least scheduled to be fixed
• installation and upgrade documentation updated
• installation tested on Windows and Linux
• new features list updates at product web site

Do we use TDD? Well, I would not say that because our coverage is not 100%, which means some of our code is not unit tested (glue code), but, yes, we do unit testing with "test first" style for all domain and business logic code, and we tend to shift into BDD style right now.

As our Product Owner is also an active developer, for acceptance testing, we tend to verify features within a team, as we have strong and common vision of a product within the team (see also acceptance in our DoD for stories). It’s a low ceremony process (as are all our processes in the team).

How often do we release? Every 2–3 months.

What have we learned from our last retrospective? That we need to shift into feature branches to be able to release small stories more often while the big ones are still in progress.

Do you see any flaws or warning signs in what I’ve posted here? Go on, say it… we’re always happy to improve…

It would be fun to hear from Target Process, ThoughtWorks Mingle team, VersionOne, AgileBuddy, and anyone else I might have missed.

Be Sociable, Share!

• 

An idea shamelessly stolen from O’Reilly Radar. Every week I will publish a short article with 4-6 relevant Agile links. I’m open to feedback on the frequency etc.

Given last weeks announcement from Jerry Weinberg, it seemed appropriate to kick of with a couple of items related to him:

• Jerry as “freaking people Ninja” – Eric Nehrlich (the Unrepentant Generalist) reflects on a session at AYE with Jerry.
• “The View from Jerry’s Shoulders” looks over his writing and comments on his many books. While I like alot of Jerry’s books I will admit that I’ve found “An Introduction to General Systems Thinking” a tough slog. I gather that The Fifth Discipline: The Art & Practice of The Learning Organization (Peter Senge), maybe more to reading abilities. YMMV.

The Scrum Alliance twittered about a new list: Scrum Alliance community discussion group: “All healthy discussion is welcome. Differences in opinion and thought are encouraged. Spam, abusive language and direct advertisements/attacks aimed at splintering the community’s energy are prohibited and violators will be warned/banned. Heated debate, differences of opinion, methods other than Scrum or desire for a different SA community group are all open topics. Please be respectful of each other and be mindful that email is often toneless and can therefore be easily taken wrong.” My take – this is a good place to discuss issues that would get you kicked off ScrumDev.

Given/When/Then And Example Tables Using the Robot Framework – Shows how to BDD/ATDD style grammar’s in RobotFramework.

The Airplane Factory game: “The Airplane Factory Game is a simple game to introduce people to Agile and SCRUM. And also, it could be easily adapted to Lean, XP, etc. This article will explain briefly the game, showing the rules, some tips and results. Also, you will be able to download it” I’ve not had a chance to try this game yet – but the premise does seem interesting.

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Be Sociable, Share!

• 

I keep on seeing announcements for the next great Agile Task Tracking tool. I just saw one posted to Scrum Development where it’s author said: “I haven’t done much testing, so if you find a bug and want me to fix it let me know :-)”.

My reply: Congrats I’m sure you have an excellent application. I’m wondering if you see the irony – you’re posting to an Agile group and say that your app has hardly been tested? What is your definition of Done? Do you use TDD? At least Unit Testing? What was your approach to acceptance testing?

My Promise

Here is my promise to all of my future clients, I won’t show you an agile tool that wasn’t developed using Agile methods. From future tool suppliers I need to know:

• Your Definition of Done
• Whether you use TDD? Or at least Unit Testing?
• What do you do for Acceptance Testing?
• How often do you release?
• What did you learn in your last retrospective?
• ….

If you can’t answer these questions I’m not interested in your tool.

Update I mis-understood the author’s intent. He’s not releasing a tool, so much as testing the waters to see if there is any interest. For these purposes I think he did the right thing. I still stand behind the statement I would show a client a tool where the vendor couldn’t answer the above questions.

Be Sociable, Share!

• 

Two weeks ago I gave an introductory tutorial on “From Code Smells to Unit Tests” (pdf) at Agile Tour Toronto (thanks to the organizers for a great conference). The slides presented an introduction to Technical Debt, SOLID Principles, The Sea of Complexity, Basic Code Smells, Refactoring and Unit Testing Basics, and Good Practices, Bad Practices. As usual, the slides were only taste of what was said. In the session, two elements didn’t work: First, I wasn’t expecting to have to explain SOLID Principles—I was caught off guard and was ill prepared. Second, the pair Refactoring Demo tanked. The plan was to invite audience members up to refactor Martin Fowler’s Movie Example (git hub browseable, zip file) and then they would make small improvements five minutes at a time.The goal was to help people integrate what we had already covered in the seminar by doing it live. There has to be another way of providing an integration event. Basically, I would need to give the audience a way for experiencing refactoring for themselves.

Please try the Movie Example (git hub browseable, zip file) and see how far you can get with some simple refactorings.

References:

• The Art of Unit Testing: with Examples in .NET (Amazon.ca) – Roy Osherove (.NET and soon a Java version)
• Refactoring: Improving the Design of Existing Code (Amazon.ca) – Martin Fowler
• Refactoring to Patterns (Amazon.ca) – Joshua Kerievsky
• xUnit Test Patterns: Refactoring Test Code (Amazon.ca) – Gerard Meszaros
• Pragmatic Unit Testing in C# with NUnit(Amazon.ca) – Andy Hunt and Dave Thomas
• Pragmatic Unit Testing in Java with JUnit (Amazon.ca) – Andy Hunt and Dave Thomas

BTW David Koontz did the hard work of typing in Martin Fowler’s Movie sample – I just modernized it (Java 1.2 –> 1.6).

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Be Sociable, Share!

• 

Last year just before Agile2008 I wrote a series of posts about my the sessions I planned to attend. Last year was used to help coordinate a diverse group of IBMers. This year the audience is smaller: me.

Monday Morning

9:00–11:00:  will likely be open jam time for me. Come find me there and let’s talk.

11:00–12:30

Kanban adoption at Software Engineering Professionals (SEP) Chris Shinkle (45 minutes) – “In 2004, SEP tried adopting Agile practices. However, Agile failed to have the desired lasting impact across the entire organization. Things changed in 2007, when SEP implemented Kanban for the first time.”

The Agile Playground Tobias Mayer (90 minutes) – “Agility in Action… This session will introduce five interactive games that a facilitator can add to their toolkit for team and management training. The games all illustrate the principles and dynamics that support Agility. The rationale for this session is that people learn best by embodying the learning, rather than just receiving knowledge at a head level. All participants will be immersed in the games; there are no observers. At the end of the session the participants will have a set of games they can introduce into their own organization to enhance their own Agile adoption process.” From my own recent experience: Learning: the Best Approaches for Your Brain, I can say that games are a very useful way to integrate knowledge.

Using the Agile Testing Quadrants to Plan Your Testing Efforts Janet Gregory (90 minutes) – “Different testing approaches are needed because quality has many aspects besides functional requirements, such as making sure the code is reliable and secure. How do you know you’ve done the kinds of testing and quality processes are necessary for your product, especially on an agile project?”

My choice: Tobias “Agile Playground” Caveat: Tobias said he wants at least 16–24 for this workshop, so please don’t overwhelm him based on my recommendation.

Monday Afternoon

14:00–15:30

Help! Already too many amazing options. First a bunch of experience reports:

Enterprise Agile Transformation: The Two Year Wall Chuck Maples; Weaponized Scrum Michael Marchi; Accidental Adoption – The Story of Scrum at Amazon.com Alan Atlas; The Amazing Team Race – A Team-Based Agile Adoption Gabino Roche, Jr., Belkis Vasquez; The Covert Agilist Ken Howard; Descending from the Architect’s Ivory Tower Andrew Rendell. I’m interested in all of these, but they have some stiff competition:

In the end, it’s coming down to three options:

When it just *has* to work: Agile Development in Safety-Critical Environments Brian Shoemaker, Nancy Van Schooenderwoert

What Does an Agile Coach Do? Liz Sedley, Rachel Davies – They’ve just written the book on the subject.

Creating Agile Simulations and Games for Coaches and Consultants Elisabeth Hendrickson, Chris Sims (3 hours). This one is on the Manifesting Stage, for which I was a reviewer, and I championed the presentation. I love the idea of learning how to create games. I’m really hoping that Elisabeth and Chris distill their knowledge into an InfoQ article.

My choice: I’m torn between Rachel and Liz—What Does an Agile Coach Do? I’ve got to work on this a bit myself and Creating Agile Simulations and Games.

16:00–17:30 I may be meeting with Linda in this time slot, so I will play this one by ear.

Team Start-up: one of the first Agile Adoption activities Lyssa Adkins (90 minutes): “Starting up an Agile team is one of the first things you might be asked to do when a company wants to “go Agile.” What do you need to know before starting up a team? In the start-up, how much do teams need to know about Agile before they “go”? What do they need to know about each other…what the project is all about…who they will become as a team? These and other questions are answered as we walk through good ways to start-up Agile teams.”

Giving and receiving effective feedback Elizabeth Keogh (45 minutes) – “Find out why we give personal feedback, how to provide effective feedback, what makes feedback ineffective and how to deal with poorly phrased feedback. Learning what makes feedback effective helps you to seek your own feedback and improve, whilst being able to support the people around you.”—echoes of “Giving an Taking Design Criticism with Rebecca Wirfs-Brock”

10 Temptations of an Agile Coach (new or experienced) Stevie Borne (45 minutes): “Regardless of your coaching experience, there are a wide variety of temptations you can fall into that affect the quality of your coaching”

Effective code reviews in agile teams Wojciech Seliga, Slawomir Ginter – I was tempted by this one, but as I read the description it feels a bit like a vendor talk. “The session includes a demo on how Atlassian Crucible integrated with leading IDEs via Atlassian IDE Connector facilitates the whole process”  Not interested. To be clear I like Atlassian and their tools, but it feels like the talk has less value without their tools $$$. See the exchange in the comments below.

My Choice: Team Start-up: one of the first Agile Adoption activities—Lyssa Adkins

Be Sociable, Share!

• 

Recently, I needed to capture the output of a program in a PDF. A few minutes of googling led me to PDF Creator (hosted at SourceForge). The application itself is great, but when you install it, a toolbar is bundled with it—pdfforge. You don’t get an option. It’s simply installed on your behalf—as a “benefit.” The worst parts of the license agreement are shown below:

Read More…

Be Sociable, Share!

• 

I used to be rich client guy, but my current client is building web apps, and suddenly I’m a web app guy. I wish now that I’d paid more attention in the past. For my penance, I promise to document whatever I learn on the forthcoming Agile Tools Functional Test Wiki (i.e., the wiki that we discussed last year at the AA-FTT meeting before A2008).

My client is building an ASP.NET application, and we’re trying to decide how to test it. The issues I have to deal with include the following:

• The two QA people have no coding experience, so any tool that requires significant coding will require more development support.
• The application will be run in IE on the IIS webserver. No other combinations need be tested.
• The application is really a document creation and management system. Once the documents have been created and approved they’re submitted to an outside system.

Read More…

Be Sociable, Share!

•