thinking-out-loud

Kai-Zen Conference

Kai = Change

Zen = Good

KaiZen = Change is good. 

KaiZenConf = An open spaces conference on continuous improvement. 

I'm here in Los Angeles, CA at the Microsoft PDC listening to the Agile Perspectives session presented by Grigori Melnik and Mary Poppendieck.  Mary and Her husband Tom wrote a couple of great books called Lean Software Development and Implementing Lean Software Development. 

The Mary and Tom as well as Improving's Jef Newsom are attending the Kaizen Conference in Austin next week.  I wish I cold be there, but I guess you can't spend all your time going to conferences, right?  At least I got to see Jef's presentation at Improving last week. It was hilarious. 

This is a post for my class

on c# agile dev using visual studio.net 2008. Nothing to see here. Move along.

TFS 2008 Feature List

Caleb and I have been working with VSTS and TFS quite a bit lately.  I have much to post about problems and solutions we've encountered (soon).  But until then, here's list from Brian Harry, a VSTS Product Group Manager at MS, about the list of features in TFS 2008.  I'm especially intersted in the continuous integration feature since most of our customers are using Agile processes and interested in CI.  I also like the idea of halting check-ins until the CI build is fixed. 

Free Scrum Process Guidance for VSTS

Ken Schwaber and Conchango have released SCRUM Process Guidance for VSTS. I am including his entire posting from the scrumdevelopment yahoo group. It is a very active group, and you can find some really insightful commentary there. Definitely consider subscribing.

Ken said:

I have worked closely over the last eighteen months with ConChango, a UK based consultancy, to prepare guidance for managing projects using Scrum. This work was prompted by our mutual concern over the quality and misdirection of Microsoft's initial contents, which badly represented Agile. I feared that, without adequate alternative, many Agile and Scrum "newbies" would think that the MS work actually had some resemblance to the real stuff.

I was and still am delighted with Conchango's help in this initiative.

They have not only invested strongly, but they have become potent Scrum advocates in the UK and throughout Europe. Even better, they did so without any direct belief in product sales or direct payback. Colin Bird, Howard vanRooijen, Ian Shimmings, and Steve Garnett all went way above and beyond their normal work to make this happen. As a result, the VSTS Scrum for Team Systems is now available, after an extensive Beta, as free downloads for use with VSTS, or as a standalone guidance system.

I am delighted to recommend that everyone take a look at this work.

See below for more details,

Ken

"Over the weekend we launched the microsite with the new process and multimedia guidance that we filmed when you were last over (I know I worked you hard - but I think the finished version was worth it). you can find it at: http://scrumforteamsystem.com/ProcessGuidance/ - we have also made the guidance available as a separate download, so that people can get access to the content even if they don't live in a Microsoft / Team System world – you can get access to the downloads from http://scrumforteamsystem.com/cs/forums/2/ShowPost.aspx

- I thought it might be a useful resource for your Certification Courses or people who are interested in getting started.

So far we've had 70 downloads in the first 12 hours and the first blog post I've found has been very flattering:

"I've been testing their Scrum for Team System product for awhile now and now they've released it as freeware...The add-in is pretty slick and covers all the major aspects of Scrum and is a much better implementation (IMHO) over something like MSF for Agile (that comes OOTB with TFS)"

MSF for Agile Software Development

It looks like Granville "Randy" Miller has a book coming out about MSF for Agile Software Development.  It should be available in the UK on February 28th, but I see no sign of it in the US. 

Info:

Publisher: Addison Wesley

Language: English

ISBN: 0321336445

Top Ten Reasons to use Mock Objects in your Unit Tests

Top 10 reasons

1. Complete Unit Test Isolation
2. Top Down Development
3. (Almost) Automatic Dependency Inversion
4. Makes 100% code coverage approachable
5. They make your unit tests run really freakin fast.
6. They make your unit tests run really freakin fast.
7. They make your unit tests run really freakin fast.
8. They make your unit tests run really freakin fast.
9. They make your unit tests run really freakin fast.
10. They make your unit tests run really freakin fast.

That last one is huge. In my experience, a slow test suite is seldom run manually. A fast test suite is run much more often. Running the suite more often means you introduce less errors. If you haven't tried using mockobjects in your unit testing, you need to give it a good go-round. And by good go-round, I don't mean spending an hour or a day trying them out. You need to spend at least a couple of weeks working with them before you can start to grok it. Fowler chats about them a bit here, and as usual, it's well worth the read. As Fowler points out, the big downer is the implementation coupling. You are designing a unit to work in isolation, though, and white box testing is a vaild approach. You just need to understand the tradeoffs. Fowler highlights most of the top 10 list in his discussion, but fails to talk about the psychological impact of a truly fast test suite.

These days, I tend to break my tests into pure unit tests using mock objects when it makes sense, functional tests that are, in fowler's terminology, basically state-based and end-to-end, and integration endpoint tests that test [my system's abstraction of] interfaces to external systems. I run the unit and integration tests frequently, and the functional less so, e.g. before check-in. If I have been a good boy and implemented continuous integration, then everything is, of course, run in the context of that.

Then of course, there are acceptance tests, but that is a different story and a different day.

TestDriven.net and VS 2005

I wrote a while back about the Visual Studio-integrated test-first development tool, TestDriven.net.  Unfortunately, the main site still leads you to the v1.0 download.  But, if you're using VisualStudio 2005, you'll need this improved 1.1 version.

Evolving Scrum

Jeff Sutherland has set free a copy of a paper on evolving scrum that is a really good read. In the interest of full disclosure, I haven't even read the whole thing yet, but the first few pages were so good, and so I just had to mention it. Enjoy!

Top-down vs. Bottom-up Development

In some of our courseware, Jef mentions that there are pros and cons to both top-down and bottom-up development. To my astonishment, he then proceded to pursue a bottom-up approach to sovling the problem. But, it was completely appropriate given that the course teaches C# and .Net fundamentals to Java programmers. When learning a new language it's usually easier to work bottom-up. Recently, though, I watched a client present a system under development to the project sponsors. He presented it in a bottom-up approach, starting with the components he'd been working on lately. I thought the sponsors had seen the system before and maybe didn't need the overview that I so desired to understand where these components fit into the big picture. But after a few minutes of conversation it was evident that they hadn't seen the top-level flow - you know, a use-case approach how things work. I later talked with my client and discovered that even though I had written a complete set of use cases for the system, he was using a bottom-up approach to development. Moreover, he always uses a bottom-up approach because he's drawn to the technical challenges and focuses on them until they are addressed and he can move on to the next thing. So, I had the opportunity to explain why I feel top-down is almost always the way to go. Reasons for top-down agile development:

• Provide context: By outlining the top-level structure of the system, you provide context to subcomponents - whether subsystems, classes, or just functions - increasing the likelihood that they are properly abstracted.
• Identify risks: Building out the system breadth-first creates opportunities to identify risks. Even stubbing out subsystems and classes can make you realize the complexity of those elements and bring risks to light.
• Manage time: Once you've built out the top level and have a feel for the effort and risks in building the entire system, you'll likely avoid spending too much time diving deeply into one aspect of the system while ignoring other risk areas. Conversely, if you start bottom-up, you can get caught up in building out the perfect solution of a small piece and ignore the rest of the system that must be built.
• Parallelize activity: Individual developers often shy away from adding resources and delegating parts of the system under development because it takes too much effort to define the area to be delegated. Afterall, if they are working bottom-up, they haven't thought through how components interrelate and would have to do that high-level thinking before delegating. Practicing a top-down approach, development always starts with defining the context for subsystems and components and the team lead is more likely to sense when a project is under-staffed and can easily add a person to take on a stubbed-out component.
• Self managed teams: As the end result after establishing a context and developing a scoffolding for building the system, team members can dive deeply into high risk areas, knock them out, and return to the top to pick up the next tasks. You'll find that star developers choose the most challanging parts with the most learning opportunity, while others choose the components they are most comfortable developing. I find this to be a good, natural allocation of responsibility that optimizes the time spent and quality produced by the team. The team lead just has to watch for team members spending too much time on something - either because they are hung up on problems or are caught up in gold-plating their subsystems. And, daily scrum meetings can easily bring either problem to light.

TestDriven.net

For developers using Microsoft Visual Studio .Net (ver's 2002, 2003, 2005): If you haven't seen it yet, check out TestDriven.net. It installs as a plug-in to Visual Studio, making test-driven-development easier by launching NUnit tests from a the context menu. Works with MbUnit and MS Team System, too. And it's free! There's a blog for news on it, too.