During a flurry of tweets and blog posts about whether or not ATDD is a good thing, I posted a blog on Stickyminds with my opinion. I’ve gotten some great comments, please add yours!

Previous posts in this series:

• A Primer
• Aggregate Construction

One of the common themes throughout the DDD book is that much of the nuts and bolts of structural domain-driven design is just plain good use of object-oriented programming.  This is certainly true, but DDD adds some direction to OOP, along with roles, stereotypes and patterns.  Much of the direction for building entities at the class level can, and should, come from test-driven development.  TDD is a great tool for building OO systems, as we incrementally build our design with only the behavior that is needed to pass the test.  Our big challenge then is to write good tests.

To fully harness TDD, we need to be highly attuned to the design that comes out of our tests.  For example, suppose we have our traditional Customer and Order objects.  In our world, an Order has a Customer, and a Customer can have many Orders.  We have this directionality because we can navigate this relationship from both directions in our application.  In the last post, we worked to satisfy invariants to prevent an unsupported and nonsensical state for our objects.

We can start with a fairly simple test:

[Test]
public void Should_add_the_order_to_the_customers_order_lists_when_an_order_is_created()
{
    var customer = new Customer();
    var order = new Order(customer);

    customer.Orders.ShouldContain(order);
}

At first, this test does not compile, as Customer does not yet contain an Orders member.  To make this test compile (and subsequently fail), we add an Orders list to Customer:

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Province { get; set; }
    public List<Order> Orders { get; set; }

    public string GetFullName()
    {
        return LastName + ", " + FirstName;
    }
}

With the Orders now exposed on Customer, we can make our test pass from the Order constructor:

public class Order
{
    public Order(Customer customer)
    {
        Customer = customer;
        customer.Orders.Add(this);
    }

And all is well in our development world, right?  Not quite.  This design exposes quite a bit of functionality that I don’t think our domain experts need, or want.  The design above allows some very interesting and very wrong scenarios:

[Test]
public void Not_supported_situations()
{
    // Removing orders?
    var customer1 = new Customer();
    var order1 = new Order(customer1);

    customer1.Orders.Remove(order1);

    // Clearing orders?
    var customer2 = new Customer();
    var order2 = new Order(customer1);

    customer2.Orders.Clear();

    // Duplicate orders?
    var customer3 = new Customer();
    var customer4 = new Customer();
    var order3 = new Order(customer3);

    customer4.Orders.Add(order3);
}

With the API I just created, I allow a number of rather bizarre scenarios, most of which make absolutely no sense to the domain experts:

• Clearing orders
• Removing orders
• Adding an order from one customer to another
• Inserting orders
• Re-arranging orders
• Adding an order without the Order’s Customer property being correct

This is where we have to be a little more judicious in the API we expose for our system.  All of these scenarios are possible in the API we created, but now we have some confusion on whether we should support these scenarios or not.  If I’m working in a similar area of the system, and I see that I can do a Customer.Orders.Remove operation, it’s not immediately clear that this is a scenario not actually coded for.  Worse, I don’t have the ability to correctly handle these situations if the collection is exposed directly.

Suppose I want to clear a Customer’s Orders.  It logically follows that each Order’s Customer property would be null at that point.  But I can’t hook in easily to the List<T> methods to handle these operations.  Instead of exposing the collection directly, I will expose only those operations which I support through my domain.

Moving towards intention-revealing interfaces

Let’s fix the Customer object first.  It exposes a List<T> directly, and allows wholesale replacement of that collection.  This is the complete antithesis of intention-revealing interfaces.  I will now only expose the sequence of Orders on Customer:

public class Customer
{
    private readonly IList<Order> _orders = new List<Order>();

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Province { get; set; }
    public IEnumerable<Order> Orders { get { return _orders; } }

    public string GetFullName()
    {
        return LastName + ", " + FirstName;
    }
}

This interface explicitly tells users of Customer two things:

• Orders are readonly, and cannot be modified through this aggregate
• Adding orders are done somewhere else

I now have the issue of the Order constructor needing to add itself to the Customer’s Order collection.  I want to do this:

public class Order
{
    public Order(Customer customer)
    {
        Customer = customer;
        customer.AddOrder(this);
    }

Instead of exposing the Orders collection directly, I work through a specific method to add an order.  But, I don’t want that AddOrder available everywhere, I want to only support the enforcement of the Order-Customer relationship through this explicitly defined interface.  I’ll do this by exposing an AddOrder method, but exposing it as internal:

public class Customer
{
    private readonly IList<Order> _orders = new List<Order>();

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Province { get; set; }
    public IEnumerable<Order> Orders { get { return _orders; } }

    internal void AddOrder(Order order)
    {
        _orders.Add(order);
    }

There are many different ways I could enforce this relationship, from exposing an AddOrder method publicly on Customer or through the approach above.  But either way, I’m moving towards an intention-revealing interface, and only exposing the operations I intend to support through my application.  Additionally, I’m ensuring that all invariants of my aggregates are satisfied at the completion of the Create Order operation.  When I create an Order, the domain model takes care of the relationship between Customer and Order without any additional manipulation.

If I publicly expose a collection class, I’m opening the doors for confusion and future bugs as I’ve now allowed my system to tinker with the implementation details of the relationship.  It’s my belief that the API of my domain model should explicitly support the operations needed to fulfill the needs of the application and interaction of the UI, but nothing more.

Authors: Langr & Ottinger
Font: Burst My Bubble

Programming pundits often decry the dismal state of code in the world. We hear speakers demand professionalism or a more craftsmanlike value system, rigorous certification, etc. In response to these very demands we find contradiction of these very concepts. The argument is frequently made that whether code is "good" or "bad" is subjective and situational. We beg to differ.

To promote a shared set of programming values, we propose these seven virtues of code:

• Working, as opposed to incomplete
  A program that works is simply superior to one that doesn't work. We contend that a working program now is of higher value than one that might work some day. To this end, incremental and iterative methods (such as agile methods) push us to complete minimal features as soon as possible, with improvements and expansions to follow.
  We ensure code is working by writing tests before and after writing code as we consider more success and failure modes. We can tell code is working by running the tests and by using the software.
  
• Unique, as opposed to duplicated
  The worst thing we can do to working code is to duplicate it. Copies and near-copies scattered willy-nilly across the code base makes code difficult to maintain. We struggle to eliminate duplication each time we refactor in our red, green, refactor cycle.
  A dirty software industry secret: Many "stepback" or "regression" errors are not really re-broken code, but are instead examples of fixes to duplicated code.
  We can tell that code is duplicated visually (common paragraph structures) or by the use of duplicate detecting tools like Simian.
  
• Simple, as opposed to complex
  Simplicity here refers to the number of entities, operations, and relationships present in any particular routine/function, and not to the readability of that module (which we call "clarity").
  The first way to increase simplicity is to use simpler structures and algorithms. Reducing complexity in this way often translates to improved runtimes, smaller code size, and easier optimization.
  We can often improve simplicity by extracting methods so that a series of manipulations becomes a single step as far as all of its callers are concerned. While the code still takes the same steps, those steps are evident in far fewer places in the code. Such simplicity is at the heart of object-oriented design.
  
• Clear, as opposed to puzzling
  The meaning and intent of code must be obvious to the reader. Code misunderstandings generate errors. Confusion over code creates delays. Clarity is the quality that is improved by improved naming of variables, classes, and methods. Clarity effects the ease with which one might find the places in code where changes are necessary. Detecting clarity in code is an inherently human activity, such as detecting beauty or poetry.
  
• Easy, as opposed to difficult
  Adding and modifying code should not be an arduous process. Ease is largely a matter of how much code must be typed in how many places, and how much configuration must change. In an ugly code base, the easiest way to get code working is to implement a hack. In a truly clean and simple code base, putting a correct design into place is often as easy as a hack. Uncle Bob Martin has stated that design has degraded when the doing "the right thing" is significantly harder than making "an ugly hack."
  
• Developed, as opposed to primitive
  A primitive system is not necessarily simpler (fewer parts), nor easier (less thinking and typing), nor more clear than a developed system. Primitive code tends to be characterized by Duplication, Feature Envy, and Primitive Obsession code smells. These make a primitive solution more complex, more difficult, and less clear than one built with a well-developed type system.
  In an object-oriented system, the developed type system of an application provides well-thought-out classes whose methods make continued development easy.
  A system is well-developed when functionality appears to be just where one might expect it. String methods on strings, account methods on accounts, and button activations and the like merely make calls on "business objects."
  
• Brief, as opposed to chatty
  It is valuable for code to be as brief as possible without sacrificing other virtues. This is part of the reason that language tools like LINQ and list comprehensions and closures have become so popular of late. All programmers, including the one who writes it, benefit from writing and reading less code (as long as this smaller amount of code is otherwise clean).
  Code that is long and chatty is much more likely to contain hidden errors. An overly cryptic method is likely to be misunderstood. Either one is hard to take in at a glance and understand.
  Playing "programming golf" is actually a meaningful activity. If one can make the solution to a problem smaller without sacrificing clarity (or indeed may improve clarity by reducing the solution to a smaller form), then one is reaching a more brief form. The distance from an ideally brief, clear form is unwanted verbosity (chattiness).

Leadership is a mysterious art. Whether you're leading an agile development team or not, some of the important qualities of an inspirational leader are obviously the same.

My latest blog post on the subject is now live on Jurgen Appelo's new site, "Management 3.0". Take a look by clicking on the link below!

How To Be An Agile Leader

Kelly.

Photo by BrianForbes37

Dear Mr Bowley,

Thank you for your email regarding the NPfIT. I certainly agree with your point that drawing up contracts for IT systems that have yet to be developed has proved costly for the taxpayer and for Government. Nowhere is this more true than the National Programme for IT where only one hospital has received a full implementation of Lorenzo due to the fact that it had not yet been designed when the Department of Health let the contract with CSC, and only 12 hospitals have received Cerner Millennium – a U.S. system that has had to be adapted extensively for application in NHS Trusts by BT.

Whilst I have not come across the Agile approach before, I will certainly bear it in mind as we seek to develop our policy of giving local NHS Trusts a choice of IT system through a central catalogue of open standards/accredited systems. I will keep on record any further information you are able to provide in writing about the Agile methodology and would welcome any such information in response to this email. Once again, thank you for getting in touch.

Yours sincerely,

Stephen O’Brien

Shadow Health Minister

Pickle adds many convenient Cucumber steps for generating models. Also learn about table diffs in this episode. Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format. Pickle gives [...]

The Maven team has gone to the ends of the earth to ensure backward compatibility, improve usability, increase performance, allow safe embedding, and pave the way for implement many highly demanded features. This talk will briefly cover the process and tooling changes that have occurred in the Maven project in order to accomplish what we [...]

Tamara Sulaiman presents experiences in implementing Agile in teams across different time zones in large companies. She shares the pleasure and the pain, ideas that worked as well as ideas that didn’t. She also shares the critical success factors in making program level implementations successful and sustaining. http://www.infoq.com/presentations/distributed-team-tips

I was skimming twitter this morning when I saw a link to an article/blog post in HS site about how they plan to "revolutionize" the way people interact/work with HS today.

First let me get this out of my chest: whoever was tasked with creating this project is either a complete noob in this thing we call the internet or their task was to create a good video for a concept that has no chance in hell to succeed! What a large #FAIL!

Now for the actual content. HS misses the whole internet thing completely.

1. First, they created this video which is about creating a platform that transfers their "paper" product to your screen. Really? Don't you have a little bit of imagination? Or at least look around to see what is happening! People don't want the "old" media in a new format. They want and need a new media, that is a more integral part of their life, not another format to learn!
   


2. Second, they completely ignore that in the age of the internet when the competition is just a click away the media business model has to be about producing good content first and only later about the medium to deliver it. The medium will evolve forever! (remeber sites from 1999? not so successful if launched today!) Having a concept that revolves around the way that media is organized *on the screen* is like trying to build a car by 1800's standards: you know with a 1000 bhp engine on a model T. Totally clueless if you ask me
   


3. Third, the video seems to show that they want to use all kinds of media formats in their content: videos, more photos, more ads, etc. Well, I don't see how a decreasing revenue ecosystem (print media) can really work with a future model that will exponentially increase their production costs (more video report teams, more photographers and photo editors, more expensive content handling and management systems, etc.) I mean, look at Huffingtonpost.com. They are competing for attention with the big guys with a much smaller work-force!
   


4. Fourth (and last - although I could continue for ever), they completely forget that in the age of the Internet, access to content is the commodity, what they should be focusing on is either a content-niche (opinion, creating social dialogue, etc. -- where they have no competition) or then try to create a dialogue with their customers that cannot be replicated elsewhere (like user engagement through social media, etc.). Trying to just create another "way" to access their content, which is closed, limited and will be out-dated 6 months after they spend millions implementing it is not just dumb, it should be considered neglect by WSOY board!
   

Helsingin Sanomat: please wise up and truly innovate! Look around, there's lots of people in Finland with great ideas. Take a risk, listen to them. After all Finland is one of the most advanced countries in online/mobile services. Surely we must have people in this country who can give you great ideas!

Here's the sad, sad video. Well produced, but with the wrong content...




Photo credit: fireflythegreat @ flickr

Recently I've had some time to spare, so I decided to refactor my Backlog Manager into a new version.

Here it is: Backlog Manager v10.1

It is more robust than the previous versions, and has better support for Release Planning.

By Kevin Meyer

Over the past several weeks we've penned many posts about manufacturers that have woken up to the hidden costs of offshore manufacturing or outsourcing and have decided to return to America.  By focusing on improving internal efficiencies and recognizing the extra tangible and intangible costs of global supply chains, cash floating on the high seas, communication problems, and long problem recognition and resolution chains they realize they can offset the supposedly "lower cost" of China and elsewhere.  But just when we begin to get a warmer feeling in our heart we get jolted back to the reality that many, if not most, manufacturers just don't get it. 

The latest Manufacturing News has today's jolt of dolt.

If you can't beat China and can't get the U.S. government to understand what you're up against, then you may as well join them. That is what Evergreen Solar has decided to do, shifting production of solar fabrication and assembly from its factory in Devens, Mass., to Wuhan, China. Evergreen Solar CEO Rick Feldt went to Washington, D.C., and met with Energy Secretary Steven Chu and Commerce Secretary Gary Locke. He told them Chinese government policies made U.S. production uncompetitive.

Without an adequate response from the U.S. government to counter competitive forces working against domestic production, "we are going to China as quickly as we can," Feldt told the analysts. "The issue for us is just how long does it take to get there. We've got the China operations underway as we speak." The company expects to spend $50 million this year on its Wuhan, China, facility.

Better call the waaahmulance...  waah waah...

Evergreen Solar's Massachusetts plant is producing panels at $2.05 per watt, down from $2.24 per watt in the third quarter of 2009. But the 100-megawatt Chinese facility will produce panels for $1.25 per watt, going down to $1.00 per watt by the end of 2012.

Yes a tough challenge.  But look at what they've already done.

The company expects to produce 20 to 25 megawatts of solar cells per quarter in China by early 2011. During that time, the company expects to reduce costs at its Devens [Massachusetts USA] facility to about $1.50 per watt "as we transition panel assembly to China," said Feldt.

Not too shabby, although still quite a ways to go.  But what do these guys decide to do?

In response to the Chinese competitive challenge, Evergreen Solar has two options. It can try to counter China's advantage by reducing its costs in Massachusetts as low as possible, or "get to China as fast as we can," said El-Hillow. "We've tossed internally about becoming more aggressive in Washington, trying to get them to understand the situation that we face as a solar manufacturer and leveraging our wafer technology. There's no silver bullet here. It's an incredibly tough situation." Added CEO Feldt: "The issue for us is just how long does it take to get [to China]."

Waaah.... unbelievable.  The magical government solution.  Of course they've tasted the milk already.

In 2007, the company received $23 million in grants from the State of Massachusetts to build its facility on state-owned property in Devens. It also received $17.5 million in low-interest loans along with a 30-year lease on the property.

And then they found a new use for those taxpayer funds.

Evergreen spent $8.5 million in its fourth quarter on the transition of panel assembly operations from Devens, Mass., to China.

I wonder if those taxpayers realize what their investment is doing. 

I also wonder where they'd be if they put half as much time working on internal improvements instead of whining and lobbying our representatives.  And they should wonder why their high tech operation isn't as efficient as the likes of American Apparel, who beats the socks off (literally) of overseas sweatshops while paying 4,000+ people above minimum wage plus health benefits in the low cost nation of Los Angeles.  One of my favorite examples of a company that simply focuses internally, which happens to have just been called a small cap long-term winner by Motley Fool.

Waaaah... waaaah...

Hey Dov, wanna run a solar panel operation?

It’s only been a few days since the Mockito 1.8.3 release and I have to say that for a minor release there’s a lot I like about it!

What I like about the new annotations is the ability to have test cases that are completely free of @Before. Observe this example of a class that takes a text input string, translates it to an AuctionEvent, and fires it off to an AuctionEventListener:

@RunWith(MockitoJUnitRunner.class)
public class AuctionMessageTranslatorTest {
	@Mock AuctionEventListener listener;
	@InjectMocks AuctionMessageTranslator translator = new AuctionMessageTranslator();

	@Test
	public void shouldSendAnEventToTheListener(){
		translator.sendMessage("SOL Version: 1.1; Event: PRICE;");

		verify(listener).handleEvent(any(AuctionEvent.class));
	}
}

This is a first step, to just verify an event is passed to the listener (we don’t care about it’s contents yet). @Mock creates a mock on each test method run, and @InjectMocks will pass mocks to any matching setters or constructors.

Now I’ll implement a little code to make the example pass.

public class AuctionMessageTranslator {
	private AuctionEventListener listener;
	public void setListener(AuctionEventListener listener) {
		this.listener = listener;
	}

	public void sendMessage(String message) {
		listener.handleEvent(new AuctionEvent());
	}
}

Doesn’t do much… so let’s add a new example that verifies the contents of the message sent to the listener. Since this object is created by the translator (translating a string to an object) we’ll use an argument captor to capture and verify it’s value.

@RunWith(MockitoJUnitRunner.class)
public class AuctionMessageTranslatorTest {
	@Mock AuctionEventListener listener;
	@Captor ArgumentCaptor<AuctionEvent> arg;
	@InjectMocks AuctionMessageTranslator translator = new AuctionMessageTranslator();

	@Test
	public void shouldSendAnEventToTheListener(){
		translator.sendMessage("SOL Version: 1.1; Event: PRICE;");

		verify(listener).handleEvent(any(AuctionEvent.class));
	}

	@Test
	public void shouldSendAnEventWithNamePrice(){
		translator.sendMessage("SOL Version: 1.1; Event: PRICE;");

		verify(listener).handleEvent(arg.capture());

		assertThat(arg.getValue().getName(), equalTo("PRICE"));
	}
}

It fails, so we implement the code to make it pass:

	public void sendMessage(String message) {
		listener.handleEvent(parseEvent(message));
	}

	private AuctionEvent parseEvent(String message) {
		AuctionEvent auctionEvent = new AuctionEvent();
		auctionEvent.setName(message.split(";")[1].split(":")[1].trim());
		return auctionEvent;
	}

This passes as the argument passed to the listener does indeed contain the event name. This is a little ugly, so let’s refactor it a little bit with our test providing a nice safety net:

	public void sendMessage(String message) {
		listener.handleEvent(parseEvent(message));
	}

	private AuctionEvent parseEvent(String message) {
		AuctionEvent auctionEvent = new AuctionEvent();
		auctionEvent.setName(unpackMessage(message).get("Event"));
		return auctionEvent;
	}

	private Map<String, String> unpackMessage(String message) {
		Map<String, String> pairs = new HashMap<String, String>();
		for(String pairString : message.split(";")){
			String[] pair = pairString.split(":");
			pairs.put(pair[0].trim(), pair[1].trim());
		}
		return pairs;
	}

Looks good, and the test case for it is pretty clean although it has a lot of annotations. We could change the injection strategy to use constructor injection since we don’t really want the object to even exist without a listener:

@RunWith(MockitoJUnitRunner.class)
public class AuctionMessageTranslatorTest {
	@Mock AuctionEventListener listener;
	@Captor ArgumentCaptor<AuctionEvent> arg;
	@InjectMocks AuctionMessageTranslator translator = new AuctionMessageTranslator(listener);
...
}

As long as the @InjectMocks annotation is present, the MockitoJunitRunner will initialize the mocks do they’re available for injection. Drop the @InjectMocks annotation off, and it fails with a null pointer exception.

One interesting thing of note when using @InjectMocks with setter injection is if you do something silly like the following:

@RunWith(MockitoJUnitRunner.class)
public class AuctionMessageTranslatorTest {
	@Mock AuctionEventListener listener;
	@Mock AuctionEventListener listener2;
	@Captor ArgumentCaptor>AuctionEvent> arg;
	@InjectMocks AuctionMessageTranslator translator = new AuctionMessageTranslator();
	...
}

It will inject the first @Mock, not the second. Verifications against listener will work, while verifications against listener2 will fail as it was never injected.

Tomorrow I’ll include some examples of using the @Spy annotation as well as the different answer types you can configure @Mock annotated mocks with as of 1.8.3.

Have you heard this one yet, "We're not ready to talk to Technology yet, we're still in strategic planning on the product and priorities. We'll talk soon when we have requirements ready".

Ba humbug. Here's my answer to this issue. The key Business / IT engagement question is:

What are some of the biggest issues or opportunities that need to be addressed for some of your core customers in the relatively near future?

Let's not try to answer this question holistically - stay with some of the more important things we should try to find solutions for over the next few months. Also, watch for the red herrings - cost concerns, organizational needs (most common: getting more people into the discussion), resource contentions, etc.

I'm not saying product strategy isn't important - it is very much so. I'm also not saying that you should avoid dealing with issues of cost, people, process, and change - you must. However, I'm specifically saying that none of these should prevent having the dialogue on short and medium term priorities.

With these questions answered - and even if there isn't complete alignment on priorities or vision - a technical team can start mapping out solutions. They will focus on the items that have the highest priority and cleanly articulated vision. They may also suggest some technology oriented activities either to prove out a technical approach (R&D) or address a specific operational issue (defect management or technical debt). They can then go back to the Business Managers and say, "Well, what if we delivered the following items over the next few weeks to start, followed by these other things afterward? We'll demo what we finished and we can reset priorities then based on what you see."

This is how agile planning and delivery starts - and the first steps to developing a healthier Business / IT relationship. 

Mark Wilden pointed me to a post he's written about his experience pair programming at Pivotal Labs where he makes some interesting although not uncommon observations.

When you pair program, you're effectively joined at the hip with your pair. You can't pair if only one of you is there.

I've previously written wondering what we should do if our pair isn't around where I was leaning more towards the opinion that we should try to continue along the same path that we were on when working with our pair if they're gone for a short amount of time and to find a new pair or work alone if they're gone for longer.

On the projects I've worked on we'll still have times working alone when there's an odd number of people around or if someone just feels like working on their own and I think that's fine as well. I don't think we need to pair 100% of the time.

You have to be able to think out loud – 8 hours a day. Then you have to type in code while someone is watching you. They'll catch your typos (hopefully after giving you a chance to spot them yourself) and they'll see when you're floundering for how to do something.

I find that this is quite a useful practice for explaining things to yourself although I can see how it would initially exhausting.

Even now there are times when I just want to write some code instead of having to explain what I want to do to someone else. Sadly almost every time I explain something it turns out that my pair has a better idea of how to do it than me so I'm always glad pairing encourages this conversation.

Pair programming doesn't encourage quiet reflection and exploration. You can't just sit back and read some code. You can't just sit and think. I mean, you can, but then your pair is just sitting there.

This is a bit of a double edged sword – pair programming does encourage us to get things done but it's also true that sometimes we need to get the whiteboard out.

Often just sketching out the problem on a piece of paper to check your understanding is enough to trigger a conversation which might result in a better solution.

It does tend to need one person to drive this process though. I haven't seen it just happen organically.

We rarely pair 100% of the time so there are often times when you get a bit of time to play around a bit with the code and see whether specific approaches would work out and I often use this time for reflection and exploration.

One thing which a couple of the commenters on the original blog suggested is that perhaps more rotation was needed to help overcome some of the problems and from my experience it's vital that we do rotate otherwise the pair will end up hating each other!

I recently worked on a story with 3 other people across its life and each person pointed out something that I hadn't previously considered and which led to an eventual output that was much better than it would have been otherwise.

I think rotating different people onto a story can help lead to more innovative design as long as we have people working together who are relatively flexible and open to trying out new ideas.

Mark's post is certainly interesting though and helps identify some of the things we need to be aware of when pair programming – we don't just want to follow the practice blindly.

Almost no spare time this week, so just the links:

Virtual Team Member Dolly – from Lisa Crispin. Lisa talks about giving a remote Developer based in India a presence on her team. This is cool. Now if only we could erase the time difference

Testing Small Stories – another from Lisa Crispin. I so often hear from clients that it will impossible to slice their stories any smaller than 6-8 weeks for two developers. Its always possible and Lisa provides another tool to help.

You’re Just Going to Fail, So Don’t Bother – from Scott Downey. Ignore the awful myspace ads and read the content. He nails the difficultly of really doing Scrum/Agile – you will have to change your organization.

Simon Baker takes an interesting crack at measuring Effectiveness: “is used as a measure of the product stream’s ability to improve throughput and minimize failure demand, which allows capacity to focus on meeting value demand. It was inspired by the First-Time-Through (FTT) measurement used in Lean manufacturing to measure the effectiveness of a cell’s standardized work as a percentage of product made without any need for rework or scrap.”

Bob Hartman writes: “New to agile? Keep it very simple”

In the next few weeks I look forward to having some time to breathe and do some more writing.

Steve Berczuk has a lovely discussion of Manage Your Project Portfolio. You can see his review here.

Tweet This Post

In about 5 minutes I’m going to play the role of being a “doctor” at the Scrum Clinic which is part of the Orlando Scrum Gathering.  It’s an interesting concept.  A doctor and a patient meet to discuss a topic important to the patient.  In my case the patient wants to talk about the Scrum Alliance Certified Scrum Coach (CSC) program.  Since I am a CSC and all of my CSC brethren wimped out I’ll be the one acting as doctor.  I’m looking forward to it so I’m only kidding about the rest of them wimping out!

More on the Scrum Gathering later this week.  It’s bee great so far!

Related posts:

1. I’m a Certified Scrum Coach (CSC) – so what? I’ve asked myself that question more than once in the 5 or...
2. New to agile? Watch an Intro to Scrum video in about 8 minutes My friend, Arif Gangji, and I created this video to help his...
3. Agile antipattern: Waiting for all the requirements before starting Time for a short blog entry (I tend to be way too...

You can now download the presentation (PDF) I gave at the Scrum Gathering today. This is a presentation that has gone through multiple revisions but I’m very happy with how it turned out. I got really good feedback on the session as being extremely valuable to Product Owners to help them connect Product Backlogs with Business Goals.

I believe now, after refining the presentation and the core message (thanks in part to the From-To Think-Do concept), I have the wrong title for the presentation. The primary focus isn’t on Evo + Scrum. The primary focus is that of Value over Features and Ends over Means. Evo and Scrum are techniques, but in fact not the core message (this was validated by an attendee). I’ll see if I can find a better title before Agile 2010 where I’ve submitted this talk.

Many thanks to Tom and Kai for their feedback (and edits on their train ride to Orlando).

It is perhaps a myth, but an enduring one, that people and their pets resemble one another. The same has been said of products and the teams that build them. If it is true that a product reflects the structure of the team that built it, then an important decision for any Scrum project is how to organize individuals into teams. This paper presents a set of guidelines to consider in designing an appropriate team structure. Each guideline is presented in the form of a question to be asked of a current or proposed team. The questions are intended to be asked iteratively. Ask each question of a current or proposed team, changing the structure as appropriate based on the answer. As the structure changes, re-ask the questions until you can answer “yes” to each.

1. Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members? People don’t enjoy being on a team where they are not able to make use of their strengths or are constantly required to do things they are bad at. Good team members are willing to do whatever is necessary for the success of the project, but that doesn’t relieve us from the goal of trying to find a team structure that accentuates the strengths of as many team members as possible.
2. Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)? A well-conceived team structure for an organization that is not attempting to do too many concurrent projects will reduce multitasking to a tolerable level. If more than 20% of all team members belong to more than one team, consider an alternative team design or deferring some projects.
3. Does the structure maximize the amount of time that teams will remain together?
   If other factors are equal, you should favor a design that allows team membership to persist over a longer period. It takes time for individuals to learn to work well together. Amortize the cost of that learning over a longer period by trying to leave teams together as long as possible.
4. Are component teams used only in limited and easily justifiable cases? Most teams should be created around the end-to-end delivery of working features. In some cases, it is acceptable to have a component team developing reusable user interface components, providing access to a database, or similar functionality. But these should be exceptions.
5. Will you be able to feed most teams with two pizzas? Given the compelling productivity and quality advantages of small teams, the majority of teams in a good design should have five to nine members.
6. Does the structure minimize the number of communication paths between teams? A poor team structure design will result in a seemingly infinite number of communication paths between teams. Teams will find themselves unable to complete any work without coordinating first with too many other teams. Some inter-team coordination will always be required. But, if a team that wants to add a new field on a form is required to coordinate that effort with three other teams, as I’ve seen, then the communication overhead is too high.
7. Does the structure encourage teams to communicate who wouldn’t otherwise do so? Some teams will just naturally communicate with each other. An effective team design encourages communication among teams or individuals who should communicate but may not do so on their own accord. In fact, one valid reason to put someone on two teams is that doing so will increase the communication between those teams. If lack of communication between two teams is a concern, splitting a person’s time between those two teams is easily justified.
8. Does the design support a clear understanding of accountability? A well-designed team structure will reinforce the concept of a shared, all-teams accountability for the overall success of the project while providing each team with clear indicators of their unique accountabilities.
9. Did team members have input into the design of the team? During the early stages of your transition to Scrum, this may not be possible. Individuals may not yet have enough experience delivering working, tested, ready-to-use products by the end of each sprint. Similarly, some individuals may be initially too resistant to Scrum to contribute to team structure discussions in constructive ways. In these cases, it is acceptable for managers outside the team to design an initial team structure.

An effective team structure is one of the most critical factors in the success of any agile endeavor. Poorly structured teams will lead to inefficient teamwork, excessive integration challenges, multitasking, low morale and other problems. By using these nine questions to carefully consider how teams are organized you can avoid these problems.

Du hast Lust zu Reisen, ständig neue Teams kennen zu lernen, in einer weltweit bekannten Scrum Consulting Organisation State-of-the-Art-Scrum zu praktizieren und damit die Teams unserer Kunden erfolgreich zu machen?

Wir suchen dich, wenn du

• einen Hochschulabschluss in den Geisteswissenschaften oder Informatik hast,
• bis zwei Jahre Berufserfahrung hast, oder einen Doktor mitbringst,
• sehr gu Read more ...