Espresso Fueled Agile Development : Extreme Programming

ScrumBut

mpuleio — Thu, 01 May 2008 00:55:20 GMT

I worked on my first XP project with John Boal. He recently did a post on ScrumBut. I have mentioned ScrumBut and Scrummerfall before, but this is a good, quick read with a few good tips. A lot of the concepts carry over to XP as well.

I'll add something though: Make sure your stories have acceptance criteria defined before you start working on them. This way you know when you are done. :)

Enjoy.

Acceptance Testing Guidance

mpuleio — Fri, 04 Apr 2008 00:52:25 GMT

On Monday, Grigori and I kicked off a new project: Acceptance Testing Guidance

Actually, we kicked off a pre-project planning project. In two to three weeks, we need to decide if there is enough demand for guidance on acceptance testing to warrant a real project, determine the scope of the project, generate a preliminary backlog for the project, and a rough release plan, and ensure we understand the space enough to move forward, and estimate a budget and timeframe.

We have some ideas, but we are open to input. I have a few questions for the world to help us get started:

What kind of guidance around testing, and particularly acceptance testing, would you like to see?
What questions do you want us to answer around testing and acceptance testing?
Do you think there is a need for guidance in this area?

Please use the Comments feature to reply, and I will consolidate responses. We will also have a survey (soon I hope) that I will post links to.

Creating a List of Examples (a.k.a. a Test List)

mpuleio — Tue, 27 Mar 2007 20:09:00 GMT

Brian has a great post on how to get an EDD (Example Driven Design) coding session started with a list of examples. Of course, Brian uses the terms "TDD" and "Creating a Test List", but the idea is the same.

[Author's Note: Because TDD (Test Driven Design) is such an overloaded term, and misleads people into thinking about TESTING rather than DESIGNING, I have stopped using the term. EDD is a much better description of the process and the mindset. Testing is just a great, beneficial side effect of the process.]

How are unit tests different from acceptance tests?

mpuleio — Sat, 27 Jan 2007 10:33:00 GMT

There was a question on one of the internal aliases today about the difference between unit tests and acceptance tests. I responded with my take on it. After some consideration, I decided to share this with the world as well. Of course, I have edited this a tiny bit to make sense by itself, and not in the context of a long email thread. Enjoy.

“How are unit tests different from acceptance tests?”

My unit tests each test one behavior of one class. There are lots and lots of them, grouped into fixtures by class. Acceptance tests, I prefer to have written by the customer or customer proxy, but it is often the testers who write them. My acceptance tests, when I write them (yes developers can help testers and customers by writing these too) are a lot higher level. Acceptance tests probably load up the whole application (or a big piece of it) and ensure that it works properly.

That is somewhat high level, so here are some examples:

I just finished up a project (<shameless plug>the Web Client Software Factory with a Codeplex community site </shameless plug>). This included guidance for developers on creating web applications for the enterprise, code generation, and a very simple sample web app. In the web application, there is a page that handles a customer entering an electronic funds transfer. There are unit tests for the presenter for this page, as well as the application controller that the presenter talks to. For example, a few unit tests for the presenter are

· AddIsEnabledAfterFithItemDeleted

· AddIsDisabledAfterFiveItemsAdded

· LookupAccountNameThrowsAnErrorIfAccountNumberNotFound

· GetAccountNameReturnsCorrectAccountName

Each of these test one specific behavior of the class. If one of them fails, you can figure out why pretty quickly, even if you have not seen the code before.

The whole EFT process had a number of functional tests, written with an internal web testing tool (That is as much as I can say about it, sorry). We tried to ensure that before dev work started on a feature, we had an automated acceptance test or at least the outline of the steps for the test and the expected outcome (so the dev and tester could work in parallel on the same feature). Here are a few test case names from the automated tests:

· CreateandSubmitOneTransferTest

· CreateandSubmitMultipleTransfersTest

· EmptyAccountNameTest

· EmptyAccountNumberTest

Each of these loaded a web browser, navigated to the site, logged in, hit the pages necessary for the test, filled in values, and determined success or failure. They looked at the whole system. For example, CreateandSubmitOneTransferTest would login, go to the eft page, enter an eft with valid information, submit it, and ensure that the eft went through. This was hashed out with a developer, a tester, and the customer (proxy) creating a set of steps to be done and checked on.

I hope this helps clear up the difference between acceptance tests and unit tests.

Ideal Days Aren't...

mpuleio — Thu, 02 Nov 2006 00:39:00 GMT

Mitch has an interesting post (http://blogs.msdn.com/mitchl/default.aspx) that talks about ideal developer days, and he hits the nail on the head... There are no ideal developer days.... Ever. Planning and estimating using them is kidding yourself, since there is always something that keeps folks from being 100% focused on their project. It could be that you stayed up too late getting caught up on episodes of "Battlestar Galactica" from your DVR, or you had too much Halloween candy with your kids, and don't feel well. You might even be just a little under the weather. Or you could be fighting with your source control system and losing (like me today). Whatever causes less than ideal days is not important. The important thing is to not use ideal days for estimating schedules, or you will regret it later.

Team Rooms Increase Productivity

mpuleio — Thu, 28 Sep 2006 08:49:00 GMT

Today, I saw two very interesting things. First, Peter pointed out that Channel 9 has a tour of the new p&p space. (I know that I have mentioned the space at least three times in the past, but I'm still excited about it. I'm excited not only by what I am doing and the people I work with, but also where I work.) Second, Mitch Lacey forwarded me an article that he found, entitled How does radical collocation help a team succeed?. This article describes some research looking into team dynamics and productivity in a team room. Here are a few interesting quotes from the article:

"Teams in these warrooms showed a doubling of productivity.”
“A distance of 30 meters is equivalent to being truly remote”
“Our study of six teams that experienced radical collocation showed that in this setting they produced remarkable productivity improvements. Although the teammates were not looking forward to working in close quarters, over time they realized the benefits of having people at hand, both for coordination, problem solving and learning. They adapted to the distractions of radical collocation, both by removing themselves to nearby hotelling areas when they needed privacy, and by zoning out, made possible because of the distance between people in the larger rooms.”

I thought this was great information.

Now, the Channel 9 post has a number of comments already. One of these comments (by DigitalDud) laments the loss of privacy for developers and says "Considering developers are going to be spending most of their time debugging, I'd say some privacy and the ability to shut off distractions is going to be pretty important." Very rarely do I spend time in the debugger. The way we work in the p&p team leads to very little time stepping though code. We practice test driven development and we work together (most of the time) by pairing. Today, I spent 30-40 minutes working with one of the other guys on my team, Matias, troubleshooting an ugly problem. We spent a total of about 2 minutes in the debugger validating a few assumptions, and the rest of the time making changes to our unit test fixture in a effort to isolate the problem to a simple, repeatable case. If we had relied soley on the debugger to solve this problem, we would still be working on it. But, to address the rest of DigitalDud's concern, if we need to tune out the rest of the team, we can use headphones, go grab one of the private "Focus" rooms that are available, or use someone's office. Also, once you've worked in a team space, you develop mental and auditory filters that help a lot too.

Sortable, Sticky Index Cards

mpuleio — Fri, 18 Aug 2006 17:16:00 GMT

My team (which is running a modified version of XP) is currently using sticky notes on the wall to track our work items and stories. We have a big area for all the project features. We use those giant (3 foot or so) sticky notes to hold a weekly iteration worth of work, and we archive the accomplishments of each iteration by stacking the current iteration on top of all the previous iterations. And all the sticky notes are color coded: blue for development, yellow for test, green for documentation, etc. This is a really simple system. (Of course, we are experimenting with a few changes to the system to see if we can improve on the amount of immediately available information, but more on that on another day.)

I was at one of the local office supply stores the other day, looking for a few more colors for a few more categories of work, and I saw these sortable, sticky index cards. These things are fantastic. The do not stick to each other, so you can stack them, sort them, handle them just like normal index cards, but they stick to the wall. Awesome. I'll be playing with them over the next couple of weeks to see how viable they are for use in our system.

They found a name for the TDD Pair Programming Game -- "Micro-Pairing"

mpuleio — Thu, 10 Aug 2006 00:32:00 GMT

I have mentioned Peter, Brad, and Mitch's talk on combining pairing and test driven design several times in the past. Well, Peter finally officially named the game.

Check it out.

Agile 2006 Follow-up

mpuleio — Mon, 31 Jul 2006 23:22:00 GMT

The conference was good. The weather was way too hot, but that is another issue entirely. I attended a number of good sessions and a few dull ones. There was not really anything in the middle. There was also not a lot in the middle as far as experience. Most things seemed to be aimed at the beginner level, or re-hashing talks from last year. As a result, those of us who have done some agile projects, some coaching, and are almost experts did not get a lot from the formal sessions. I actually got the most out of the experience reports and open space sessions I attended. I also had good talks with Ward, Jim, Brian, Randy, Paul, Jo, Lee, a few folks from SolutionsIQ (Lance and company), and many other folks whose names I can't remember (sorry, but I'm horrible with names). Other than the experience reports and open spaces, I think I got more out of the hallway and dinner conversations than the rest of the conference. In comparison to last year's conference, this aspect made it a bit of a let down.

My presentation went pretty well. I used some of the ideas from the book Beyond Bullet Points, which helped quite a bit. We also had a really good Q&A session after my "formal" presentation that was great. There were lots of good questions and a number of good points raised. Thanks again to the old team (Mitch, John, Bart, and Donavan) for helping out with the Q&A.

Mitch's experience report on promiscious pairing went well. He did a good job. I helped with the Q&A a bit (at Mitch's request), and the audience had a number of very good questions.

Brian Button mentions the conference as well in his blog. He seemed to enjoy the time. He mentions one of the experience reports I found interesting, and Brad and Peter's TDD/Pairing Game talk as well. They did a great job (and I'm not just saying that since Peter is my boss). I attended to see how they changed it from the internal talk (they didn't) and to help provide support and another Q&A resource (which worked well). I have used the TDD/Pairing Game in the real world on real code, exactly as they describe it, and it works very well. It is my preferred way of developing main-line code.

Robin, my wife, attended the conference as well (as a PM on the "intro" track even though she is a certified ScrumMaster with some experience working with agile teams). I'll let her speak for herself through the comments (if she wants to). She seemed to have a good time and learn a lot both from sessions and from informal chats.

Enjoy.

[Edit: Fixed company name of SolutionsIQ based on comment from PP. Sorry folks.]

Another Agile blog at Microsoft

mpuleio — Mon, 17 Jul 2006 19:21:00 GMT

I know that there a quite a few agilists at Microsoft. In my reading over the weekend, I saw this blog (Only Passionate People Win) by Young Joo, and I had to comment.

Here are a few of his posts on agile topics with my comments:

Abusing Agile
Amen.
You still do not get it!
I remember the thread on the internal mailing list that he mentions. Wow, that was a heated discussion.
Starting Agile? Learn basics first!
This is funny. I just moved into a new team collaboration space here at patterns & practices. We are spinning up a new project and I was trying to decide where on the wall to put a print-off of the Agile Manifesto and a few guidelines for how I want the development process to work. These are both for the non-agile folks (to teach) and for me (as a reminder).
Make sure your team is jelled before starting Agile
My first experiences with agile development and forming a high performance team was with a group of folks who had never worked together before. We had not jelled, but we were committed to trying out an idea. It worked for us, but I can imagine that a number of challenges we encountered would not of happened if we had been a well-formed team previous to the project.
Accountability in Scrum
Again, Amen. Scrum is not a silver bullet. XP is not a silver bullet. Agile is not a silver bullet. However, these approaches will expose the problems that your current model is hiding and make you deal with them. Young links to Doug Seven's post on Accountability in a Scrum World. I've got to comment on Doug's post as well. The whole team is accountable for the failure. There should never be a resource issue on a Scrum team. If there is too much work for the team, they should only commit to the amount of work they can actually get done, and the project plan revisited with the new estimated velocity. This sounds like a both a team (over-commiting) and a management (demanding features X, Y, and Z by this date) failure. The idea with most of the agile approaches is to fix quality (high), date (the iteration), and resources (the team), and vary scope. If you fix everything (like PMs and management often try to do) something will give and the team will fail.

As I find more blogs like this, I'll pass them on.

Bad Agile Definitions

mpuleio — Tue, 11 Jul 2006 01:15:00 GMT

A friend of mine (John Boal) has created a site (The Committee for UN-SCRUM Activities) where he has the ultimate bad definition for the term "Agile":

Agile
1. The ability to use popular buzzwords like "sprint" and "scrum" without having to really change our attitudes or the old-school way you [don't] deliver software.
2. Disconnected non-communicative everyone-for-themselves software & bug development

To this I'll add my own bad definition:

3. Any un-planned, un-documented, un-disciplined software development process.

Of course none of these are really the definitions of Agile, but (sadly) from some of the folks I have worked with and talked to (both inside and outside MS) these are apparently the definitions folks are using.

Brad Wilson has another term defined on his blog:

Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Brad goes on to make a couple of very good observations about agile and XP that I agree with.

Doing Scrum or XP or anything Agile is hard and requires discipline. It is also well worth it for a lot of projects (not all, but a wide variety).

If you are trying to adopt Scrum or XP or one of the other Agile methodologies out there, get a coach that has a good track record and listen to them to make sure you are actually doing things by the book for a while (3-6 months minimum). I was lucky enough to get coaching from folks like Ward Cunningham, Jim Newkirk, and others which kept my team in MSN on track. Without their help, we would have made a lot more mistakes and the project may not have been as successful.

[Edit: Updated the title of John's website.]

How do you keep your daily stand-up on track?

mpuleio — Mon, 26 Jun 2006 07:36:00 GMT

This question came up recently, "How do you keep your daily stand-up on track?" I answered by sharing what worked for me.

The way teams I have been on (and teams I have helped coach) kept things tracking was we agreed to the rules: Everyone must answer the three questions. (What did I do? What am I going to do? What is stopping me from getting things done?) No one may talk for more than two minutes. If there is an issue that needs to be discussed, they write it on the whiteboard. Anyone can tell someone they are taking too long, and the person speaking needs to finish quickly.

After everyone has answered the three questions, everyone is allowed to sit down (since the stand-up was over). Then the team runs down the list of things on the whiteboard. Decisions are made quickly. If a decision cannot be made quickly, the topic is moved offline. If something only requires part of the team to be resolved, the interested parties can take care of it immediately after the meeting breaks up.

Of course, I have heard of teams using egg timers or stopwatches.

Survey: Ideal Continuous Integration

mpuleio — Thu, 18 May 2006 18:30:00 GMT

One of the things we do here at p&p, in addition to providing guidance, tools, and reference implementations, is try to evolve the processes we use to write software. Last week, over lunch, the developers here at p&p had an interesting discussion about continuous integration. We were trying to decide what changes we should make to our CI process, if any. At som point I’ll report back on what we are doing internally, but at this point, I’d like to hear from the rest of the world on what you would do. Before I ask for input though, I want to make sure we are on the same page. Here is how I view CI. A basic CI process, started on every check-in, includes:

Get the latest source
Build the components
Build and running the unit tests
Report success or failure of the build and unit test run (If any unit test fail, the build fails)

Experience has shown me the need to inject a few more steps in the process, so it looks more like this:

Get the latest source
Build the components
Build the deployment mechanism (MSIs, usually)
Build and running the unit tests
Report success or failure of the build and unit test run (If any unit test fail, the build fails)

Then there is my view of an ideal scenario. I have yet to see this implemented in the real world on a full-scale project:

Get the latest source
Build the components
Build the deployment mechanism (MSIs, usually)
Build and running the unit tests
Deploy to a development environment
Run a build verification test suite against the system deployed in the development environment
Run a full regression test pass against the deployed system
Run a full acceptance test pass against the deployed system
Report success or failure of the build, unit test run, deployment, build verification, regression tests, and acceptance tests (If any step in the process fails, or any test fails, the build fails)

So, readers, I have a few questions:

What do you think about the ideal scenario?
How would your ideal scenario work?
What do you actually do in your CI process?

p&p Team Space Update

mpuleio — Wed, 10 May 2006 19:06:00 GMT

While we are still not moved in to the new space, a few folks are using their laptops to camp and it try out. I acquired a few candid pictures (thanks Steve Elston) to show off the new area.

The above picture shows one of the largest workrooms in the space and a few folks (Eugenio Pace, Alan Ridlehoover, Blaine Wastell, Wojtek Kozaczynski, and Brad Wilson). There are a number of workstations with flat-panel monitor stands and nifty chairs; plenty of wall space to hold our information about a project; light from the outdoors (through the glass-walled offices); and plenty of room to get the team together for an impromptu discussion. On the right side of the picture, you can see curtains closing off another workroom. One of the things you cannot see in this photo is the ceiling-mounted projector that projects onto the wall with all the sticky notes and hooks up to one of the desks.

This shows two workrooms, a lounge area, and a few guys (John Socha-Leialoha, Edward Jezierski, and Francis Cheung) preparing for a demo. The curtain from the last picture is just off-camera on the right side. You can also see one of the projectors at work. Since this area does not have a nice big wall to project on, there is a screen that drops from the ceiling on demand. You can even see a few of the flat-panels installed. The lounge area in the background is nice, and can be converted into another workarea by dragging a few desks over and moving the lounge furniture.

Now you can see why we cannot wait to get moved into our new space. We will get moved this week (folks started packing boxes Monday).

p&p Team Space

mpuleio — Fri, 05 May 2006 20:38:00 GMT

Today, I only have time for a short note. Rather than do anything technical, I figured I let people in on what is going on in p&p.

A while back, Darrell Snow mentioned the new team-oriented collaboration space that the patterns & practices team was building. Well, it is just about done, and we will be moving in within a week (if all goes according to plan). I'll see if I can either post or link to a few pictures in the near future.

We are all looking forward to using the new space, which has a few interesing features: 5 team areas that can be closed off or opened up to one another, floor to ceiling whiteboards and whiteboard glass walls, and small lounge areas for privatge conversations or phone calls. While the p&p developers are giving up offices and a bit of privacy (and I knew this when I joined the team) we believe that having a team of developers, testers, project managers, and other folks working in the same space on the same project can really help communication and productivity. A large part of the Agile community believes in this concept as well (lots of XP and Scrum practicioners recommend collocated teams whenever possible.) Personally, it took a bit for me to warm up to the idea, but now I would not want to do a project any other way.