Richard Lawrence

Exciting. Entertaining. Do these words describe your sprint demo meetings? Or are boring and unfocused more accurate?

I can’t believe how many times I’ve come in to coach a team and they’ve been surprised when I actually expected to see a software demo in the sprint demo meeting. As the agile principle says, “Working software is the primary measure of progress.” Let’s see some software!

Why are so many agile teams so hesitant to do demos? Why are demos so lifeless? Sometimes, the team’s not actually done. That makes a demo awkward. Other times, they can’t communicate what they did to the Product Owner; they don’t speak “business.” But most often, they simply don’t know how to give a good demo.

So, how do you give a good demo? Read on to find out »

I’ve written before about the amazing financial impact of releasing more often. And I know from personal experience the positive impact that frequent releases have on learning and on product quality and value. So, I enjoyed this post on one company’s experience with continuous releases. Yes, you read that right; they release, on average, 50 times per day.

We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.

Read the whole thing and consider what it would take in your organization to get to continuous deployment. How fast could you go? And what impediments would have to be resolved to make it happen?

One way to keep your WatiN tests maintainable is to keep them small and focused. WatiN Pattern #2, then, is a way to do just that.

Read the rest of this entry »

The main purpose of the Daily Scrum is for team members to make and follow-up on commitments to one another that work towards the team’s shared sprint commitment. If your Daily Scrum has become unfocused, too long, or otherwise ineffective, here are seven ways to get it back on track.

Read the rest of this entry »

In my previous posts on WatiN, I lamented the shortage of online documentation and resolved to do something about it by documenting the patterns I’ve found for good WatiN tests. This is the first in a series in which I’ll take an example of the typical beginner WatiN test I see and refactor it to use the patterns I recommend.

Consider this test:

63
64
65
66
67
68
69
70
71
72

        [TestMethod]
        public void SearchPageTest()
        {
            IE ie = new IE();
            ie.GoTo("http://www.google.com/");
            ie.TextField(Find.ByName("q")).TypeText("Richard Lawrence");
            ie.Button(Find.ByName("btnG")).Click();
            Assert.IsTrue(ie.ContainsText("www.richardlawrence.info"));
            ie.Close();
        }

It has a few problems, but I want to highlight one in this post: This test doesn’t properly clean up after itself. If the code on lines 66-70 throws an exception or if the assertion fails, line 71 will never be executed. When you’re testing on your own machine, this can be annoying—you have to close the IE window manually. But if the test runs unattended (e.g. as part of continuous integration) it can be much more than annoying.

Read the rest of this entry »

At my current client, we’ve decided to use WatiN, largely for the C# vs. Ruby reason I discussed earlier this week. After spending a week working with WatiN (following a year of rarely using it), I’m impressed. Ruby and the active Watir community still have their advantages. But WatiN has really come into its own with C# 3.0 features like lambdas. I’m pleased with the test code we’re producing in terms of readability, speed, flexibility, and maintainability. I’ve proposed an Agile 2009 tutorial session on the patterns I’m using to get those results, and I’ll post more on that topic here soon. (Which will hopefully help with one of WatiN’s shortcomings—documentation.)

Bob Hartman and I are offering an Agile Product Management Boot Camp course March 9-10 in Denver. If you’re a product manager, product owner, business analyst or in any other product facing role in an agile (or soon-to-be agile) environment, this intense, hands-on course is a great opportunity for you to ensure that you’re helping your team maximize the value it delivers.

Read on for more details and a special 2-for-1 offer »

I’ve noticed a pattern with several of my .NET clients who want to get into automated acceptance testing for web applications. They like the idea of WatiN because it would let them write tests in the same language as their production code. But then they notice that there’s much more documentation and apparently a much more active community around Watir. And that Ruby language looks interesting too. What to do?

I think there are good arguments for both. Here are the major pros and cons from my perspective…

Read the rest of this entry »

Denver’s new APLN chapter is having our first proper (i.e. non-planning) meeting next Tuesday.

Date: January 20, 2009
Time: 6:30pm
Location: Sigis Cabaret room in the Tivoli Student Center on the Auraria Campus

Our topic will be an open discussion on how to convince management that agile is the proper approach to be taken on projects.

Why Another Agile Group in Denver?

I participate in three agile groups here: the APLN chapter, Agile Denver, and the Boulder Agile Meetup. They all serve different niches in different ways. Read the rest of this entry »

I’ve decided to experiment with Twitter as a way to post more often than the once or twice a week I do here and to engage in conversations I’m otherwise missing. Follow me here: http://twitter.com/rslawrence.

Anyone else on Twitter? Have you found it useful?