Espresso Fueled Agile Development : Agile

If you missed the patterns & practices summit....

mpuleio — Thu, 04 Dec 2008 12:37:00 GMT

Ajoy has posted that three of the sessions have been made available online at pnp Summit videos online. Since one of the three sessions is one that Grigori and I did about the Acceptance Testing Guide, Driving Development with Acceptance Testing, I figured I'd share the information. The other two sessions are Ade talking about distributed agile development, and a discussion with Ajoy on the new SharePoint guidance from p&p that I have mentioned before (Guidance on SharePoint, Unit testing SharePoint). If you missed the Summit and want to attend next year in Redmond (or elsewhere), keep an eye on http://www.pnpsummit.com/, which will eventually be updated with information on the next conference.

Back from vacation... and a lot has happened in the last week

mpuleio — Mon, 03 Nov 2008 22:48:30 GMT

I took a week off, which was good. I visited family and spent time relaxing and playing video games. (Fallout3 rocks so far!!). I got back this morning to hundreds of emails to go through. After reading almost all of it, there were a few things that happened recently I wanted to share... Here are the highlights:

Grigori and I have been working (with Gerard and Jon) on the Acceptance Testing Guide...and we released a beta. (Grigori talks about it here: News: Acceptance Test Engineering Guidance BETA1, and the guide is under Releases here: http://codeplex.com/TestingGuidance). We would appreciate feedback.

Unity 1.2 and Enterprise Library 4.1 were both released. Way to go Chris, Grigori, and the rest of the team. (Just Released: Microsoft Enterprise Library 4.1 and Unity 1.2 and And we're live! Entlib 4.1 and Unity 1.2 are released.) Unity had some very neat (and hard to implement) stuff added to it in this release. I know since I paired with Chris on a small part of re-work that allowed the Policy Injection Block functionality to be added. This is a good, solid release of both projects.

p&p opened up the patterns & practices Agile Development Showcase, starting with a paper Ade wrote on Distributed Agile Development at Microsoft patterns & practices. I reviewed the paper and bounced ideas around with Ade. The paper has a LOT of information and helpful hints. (Ade's blog post about it is here: patterns & practices Agile Showcase)

The Redmond patterns & practices Summit is this week (http://www.pnpsummit.com/). I've got to prep for a talk tomorrow after being out for a week (fun). Here are a few other random posts on the topic: patterns & practices Summit in Redmond, Crazy Times Ahead - PDC, P&P Summit, Tech Ed EMEA). The Summit is always fun, and I am looking forward to it.

After the Summit, I'll be ramping down on the Acceptance Testing project now that the Beta is out. I will continue to work on it, just not as my primary focus, as it gets cleaned up, reviewed, re-worked, edited, etc. I'll blog soon about my next challenge.

Acceptance Testing Guide Community Preview 2 Available!

mpuleio — Mon, 04 Aug 2008 20:16:38 GMT

As I have mentioned before in a few posts (Acceptance Test Engineering Guidance, Acceptance Testing Guidance Survey, and Acceptance Testing Guide Update), I am working with a team on guidance around acceptance testing. We still have a lot of work to do our the guide, but we have made available a second community preview to show you how things are shaping up and to give you a chance to provide feedback.

Check these out:

The Acceptance Test Engineering Guidance community site on CodePlex (so you can follow the project)
An announcement about the guide (which is being handed out at the Agile 2008 conference this week)
The second community preview of the guide (it is a bit rough, but you should be able to see where we are headed with it)
Provide Feedback on Community Preview Aug 4, 2008 (so we can make changes, add topics we missed, etc).

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 Test Engineering Guidance

mpuleio — Sat, 19 Apr 2008 00:48:23 GMT

As I mentioned before (Acceptance Testing Guidance, Grigori's Take on the Acceptance Testing Project), I am working on guidance around acceptance testing with Grigori.

We now have alive CodePlex site that we can work from: patterns & practices: Acceptance Test Engineering Guidance

We will be posting more as we really get ramped up. We have a LOT of ideas that we will post and talk about. We will also post bi-weekly (or close) drops, probably in the form of Word documents, showing what we have so far, and asking for input.

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.

Data-mining for Code Quality Metrics

mpuleio — Thu, 03 Apr 2008 02:30:48 GMT

I spent two weeks between full time projects (still working on the 2 part time projects I am on) looking back at the build logs from the past 6 months (or so) trying to figure out what metrics we have, what we should track going forward, and what goals we should have for these metrics. I came up with some interesting findings.

First, overall unit test code coverage was OK, but not as high as I would like on my projects. Of course, these numbers included generated code, view code, and other things that I usually filter out. Also coverage was fairly flat. For the most part, as we added code, we added tests. This, I think is much better than one of the alternatives, having coverage drop over the course of the project.

Here is coverage for the Application Blocks in WCSF, without axis labels. The Y axis starts at 76% (not zero).

You will see that there was a noticeable drop in coverage part way through the project. That was when we added a new library of AJAX controls. Before the change was made we knew this would happen and accepted the risk. I also worked with the testers on my team to mitigate the risk via more acceptance tests and careful code reviews. And after the change, we trended up, slowly, over time.

In addition to watching coverage over time, I was able to come up with a few indices to watch going forward. Thanks to NDepend, a little bit of work parsing build logs, and Linq, I was able to create seven indices, three of which I will be watching closely on future projects:

Cyclomatic Complexity
Afferent Coupling
Efferent Coupling

If you want a definition for any of these, check out the NDepend site. The index for each of these is the average of the top 10 worst values by type.

Here is a graph of these indices over time for another, un-named project (without the axis labels)

You can see that the first few builds did not have NDepend hooked up properly. Then everything tracks along, relatively stable until about 40% through the project. The Dev Lead on the project was able to tell me what happened on the day that the Cyclomatic Complexity dropped drastically. It was a big change to simplify things.

Do these graphs, numbers, and indices (and all the others that I pulled from the data, but did not share yet) tell me the whole story as far as code quality? Of course not. However, these can all be used as indicators. If complexity trends sharply up over time, there may be a problem we need to investigate. If it stays low, there can still be other problems hidden. However, a little information is better than none.

Now, on to the next project...

"I need a new co-worker", or "p&p is Hiring"

mpuleio — Sat, 22 Mar 2008 20:48:00 GMT

Peter Provost left p&p a month or two ago*, and Ade Miller is now our Dev Lead. However, this leaves a gap in the dev team here at p&p, and leaves us with more work than people.

If you are a strong developer and love doing agile development, apply for the postion as a Software Development Engineer

Ade has also posted about this job openening at Come work for Microsoft patterns & practices!

[*] Here is Peter's post about leaving p&p:Changes for me.

Front Page of the Seattle Times!

mpuleio — Mon, 12 Nov 2007 04:50:00 GMT

This morning, I was sitting in a local coffee shop, drinking a latte, and I checked my email on my phone since I was expecting a response from someone. In my inbox was an email from Keith Pleas (the organizer of the p&p Summit) that the Seattle Times online had an article that highlighted p&p. I walked over to the newsstand, grabbed a copy, and was surprised to see my face on the front page. :-) Needless to say, I ended up buying a few copies to share with my folks, inlaws, and a few others.

The online article is here:Microsoft campus expands, transforms, inside and out. It does not talk about the team, or patterns & practices, but rather, the ongoing campus expansion. The front page photo was of the Client team room in the p&p Agile Development Center. I was standing behind Blaine, helping him as he put together a web site with the Web Client Software Factory. It was a reminder of why he is a Program Manager, and why we do not let him code much anymore. (Don't worry, Blaine has said as much himself, on stage at the p&p Summit).

[Update] I got an email with an A/V article at the Times site, Microsoft's New Look which talks a bit about the space, has a few pics, and quotes Peter Provost.

Enjoy.

CNN Series on the Future of the Office

mpuleio — Fri, 01 Jun 2007 20:38:00 GMT

A few weeks ago, a film crew from CNN International visited Microsoft to do a segment on how Microsoft is looking at the workplace of the future (Alan talked about it at the time). They talked to the Workplace Advantage group, the team that helped patterns & practices put together our "Agile Development Center." I have mentioned the Workplace Advantage and our space a few times in the past (p&p Team Space, p&p Team Space Update, p&p Team Space Update - Revisited, Team Rooms Increase Productivity). The CNN film crew ended up over in the patterns & practices space after they discovered that our team had already moved into one of these "future" environments.

The segment is interesting, and highlights a number of things that the Workplace Advantage team is doing on campus and as they look ahead. This segment is part of a series that also looked at a few other companies as well. Check out the entire series:

Thoughts on Code Coverage

mpuleio — Tue, 27 Feb 2007 02:44:00 GMT

Jim Newkirk and Brad Wilson have an interesting blog post on code coverage and what it means.

They have some interesting ideas to think about.

On my last project, I ran covereage numbers at fairly regular intervals. At one point, the trend sharpy dropped, and I had a conversation with the dev team, resulting in us fixing the problem. I guess I did what they are advocating, not with intent, but on accident.

On my current project, I want this reporting to become automatic, and not need to worry about communicating the problems with the team, but have them see the problem and take responsibility without intervention... We'll see how it turns out, if I can get the automation and reporting to work.

[Note: I know that TDD is not testing, and a better description is Example Driven Design. I threw the Testing tag in anyway, because this can apply to acceptance test code coverage as well as unit test coverage.]

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.

"We are doing Scrum, BUT..."

mpuleio — Fri, 13 Oct 2006 20:14:00 GMT

Eric Gunnerson has a great post on ScrumBut. As a ScrumMaster (certified, certifiable, whatever) I agree with what he says completely. I've said it before when talking about Brad's ScrummerFall post, but Eric sums it up very well. ScrumBut is NOT Scrum. 12 week iterations are not short and completely miss the point. And teams that do Scrum without even reading the books and literature (and by not brining in a coach for a while) are just hurting themselves.

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.