#2782

Agile 2008 - Conway’s Law and Distributed Teams

During the distributed agile workshop at Agile 2008 there was some discussion of Conway’s Law (named after Melvin Conway). Conway’s law basically says

Any piece of software reflects the organizational structure that produced it.

So distributing your team not only effects its communication dynamics adds dysfunction, it also may impact the actual product that gets developed!

On the one hand you could plan for Conway’s law and distribute the work on your team based around architectural components. Do you really want the architecture of your application to reflect that fact that you decided to hire two great developers who work remotely in Kalamazoo? Users care about features and how they fit together to satisfy user stories. They want your architecture enable the features they care about in the current version of the product and subsequent versions.

Often teams think they can avoid Conway’s law by aligning by discipline. You frequently hear of off shore test or developer teams. While this seems to get us off the hook with Conway it presents more problems. Agile teams blur the lines between the traditional roles on a development team for good reason. Subdividing teams by function leads to throwing code over the wall between disciplines and them-and-us attitudes. The whole team is no longer on the hook for delivering a user feature.

This will also tend to lead to specialization as different geographical locations are aligned to architectural components and over time specialize in that component. Over time users stories will get harder to complete within an iteration as different parts of the team have to align on a critical path to complete a given cross-component user story.

In some ways this produces the same result as distribution by component or function results in the same thing. The team is misaligned around something that ultimately doesn’t matter to the user, architectural components or functional discipline. Agile teams align their efforts around user stories because that’s what users care about.

Alternatively you could fight Conway’s law at every turn. For small distributed teams this means behaving like a co-located team and removing as many of the communications barriers as possible so that the team aligns around user stories. Team members pick tasks off the iteration backlog and iterations are based on stories from the product backlog.

For larger scale projects a feature crew or feature team approach addresses Conway’s law head on in a similar fashion. Bas Vodde’s book also covers in great detail how a component based approach leads to waterfall and makes it harder to deliver complete functionality in a single iteration.

Tags: Agile, Distributed teams, Large teams, Scrum
No Comments »

I’m speaking at Agile Development Practices 2008

Now we’ve got Agile 2008 out of the way it’s time to think about the next thing. For me it’s Agile Development Practices 2008 in Florida, November 10-14. I’ll be speaking on Thursday afternoon on some of my expereinces at Microsoft with large and distributed teams.

Scaling Agile Up and Out: A Tale from the Trenches

It seems like everyone wants to scale their agile teams. As projects grow in scope, the agile approach to software development needs to scale up to larger team sizes. Agile also needs to scale out to handle geographically distributed teams as businesses expand into new markets and seek the best talent available globally. These are challenging propositions for many teams. Ade Miller talks about his experiences at Microsoft®—scaling agile up on the Visual Studio® Tools for Office team and scaling out on the radically distributed teams within the patterns & practices group. Ade covers the approaches used—some which worked well, some not so well—and shares that the important thing is what was learned and how this new knowledge can be applied successfully to other projects. Ade presents some successful practices when scaling agile projects as well as some key pitfalls to avoid on your projects.

Lots of the usual suspects will be there including some ex-Microsurfs; David Anderson and Mitch Lacey.

I’ll also be at the patterns & practices Summit 2008 in Redmond the week before (Nov 3-7) but I don’t have further details on that one yet - other than that there will be beer.

Tags: Microsoft, News & events, Orlando, p&p
No Comments »

C# String Assignment Optimization

I happened to come across the following code the other day.

  string cost = "FR" + "E" + "E"; // bad perf = true J

Which, after my performance investigation the other day, got me wondering again. Is there performance really going to be bad? Surely the compiler could figure this one out?

Read the rest of this entry »

Tags: C#, Coding, Performance
2 Comments »

Scrum Bestiary - The Rubber Duck

A final addition to the Scrum Bestiary. Yes, I know I promised that we were done but no sooner had I said that than Bob, one of the p&p developers, said “But what about…”. It’s the weekend so something a little off the wall is OK.

We all know about Scrum’s pigs and chickens and a while back I wrote about seagulls, cows and foxes. What about the rubber duck?

The first thing you’ll notice about the rubber duck is that it’s not a real animal and if you found one in a farmyard it would look a bit out of place. If the rubber duck could talk it would tell you that it wasn’t entirely happy with it’s new home in the agile farmyard. In fact its down right upset to be there. It sure didn’t volunteer for this whole agile team thing, inanimate objects have a hard time volunteering for things. Rubber duck probably got assigned to the team because it was in the wrong place at the wrong time - some manager decided that the duck’s skills were vital to the projects success. Next thing duck is being forced to attend team meetings. What next? Group hugs?

Read the rest of this entry »

Tags: Agile, Scrum
No Comments »

Slide Decks Available Online

I’ve added a page of slide decks for talks I’ve given over the past couple of years. I’ll be adding more when I get more time.

Tags: Best practices, News & events
No Comments »

C# Inline Methods and Optimization

Last night I was playing around with a vector class that’s part of a scientific computation code I’ve been working on. It’s a long story more on that later but it means I’ve found some of my own time to write code in. Anyway… The Vector class uses the automatically implemented properties feature of C# 3.0: 

  public class Vector
  {
    public double X { get; set; }
    public double Y { get; set; }
    public double Z { get; set; }

    // …
  }

I was concerned that the property getters and setters were adding overhead to my class. Normally this would be a non-issue but in this case the Vector class is being used inside a series of tight loops. According to the profiler over 90% of the application’s time is spent inside these loops and the property getters and setters get called hundreds of thousands of times as the loop works through some vector math. That’s a lot of method calls and I wanted to make sure that they were really getting inlined. As Eric Gunnerson points out there is no inline keyword in C#.

Read the rest of this entry »

Tags: C#, Coding, Performance
8 Comments »

Agile 2008 - Industrial Logic’s Agile eLearning

One of the things that really impressed me at the conference was Industrial Logic’s Agile eLearning product/project. I went to two good talks by Joshua Kerievsky (refactoring) and Brian Foote (patterns) both of which demo’ed their eLearning stuff. It’s arranged in albums and makes lots of use of videos.

They’ve put a lot of thought into this. I was very impressed by their choice of domains when talking about design patterns, for example the baby/stalk analogy when talking about factory patterns.

You can now buy these online. They’re not cheap, but neither is good development talent! Developers without opportunities to learn and grow are unhappy developers.

Note: Joshua gave me a T-shirt, nothing more. I have no affiliation with I.L, other than occasionally bumping into them at conferences and we make up defamatory songs about agile methodologies. I happen to think what they’re doing here is cool.

Tags: Agile, Coding, News & events, Patterns, TDD, Toronto
No Comments »

Agile 2008 - Something is wrong but why?

If you’ve been in software a while a lot of the time your gut starts to tell you that something feels wrong before you figure out exactly why. This year’s Agile 2008 conference gave me several insights into why some things I’ve had deep reservations about are wrong in a much more succinct way.

Distributing teams across time zones - Corey Ladas talk about “Scrum-ban” helped me figure out that one of the key issues with distributing teams across time zones is that it adds delays to your value stream. His blog post also points out how assigning all tasks at the beginning of an iteration adds a critical path to the work. This came up in the distributed agile workshop I attended but fitting it into the value stream mapping really sets it in context.

Scaling teams by decomposing using system components not product features - Bas Lodde’s talk on the pitfalls of component teams for large projects spent a lot of time explaining a theoretical model for how large teams distribute work. It provides a good framework for thinking about this issues. I’m still reading the Feature Teams chapter of his book which covers much of the same material as the talk.

The Singleton design pattern- Brian Foote’s design “Patterns Poster Children” session helped me figure out that the Singleton is often used like a global variable. Like a global variable it can effect application performance, scalability, threading and testability.

Really this was where I got most value from this year’s conference. It’s given me several frameworks for thinking about existing problems I knew I had. Now I have a better model of what’s going on it’ll be easier to articulate whyit’s wrong and help other improve things. Arguing for something based on the data is so much more convincing than “it just feels wrong”.

Tags: Agile, Distributed teams, Large teams, News & events, Toronto
No Comments »

Agile 2008 - Scrum and Kanban

Corey Ladas of Modus Cooperandi talked about “Starting a Kanban System for Software Engineering with Value Stream Maps and Theory of Constraints“

The section of this talk that was about applying Kanban to an existing Scrum process, “Scrum-ban“, can be found on Corey’s blog. What this does for you is allows you to evolve Scrum into something that involves less ceremony (planning) around each sprint/iteration or how to move towards a leaner planning approach:

The ideal work planning process should always provide the development team with best thing to work on next, no more and no less.

The end result is a team that implements a pull model for new work. It asks for new work very frequently rather than batching it up each iteration. Batching leads to waste as more incomplete work is effectively added to the system. It does require some uniformity in the size of the work items entering the system for this approach to work however.

Corey’s article shows how to evolve a batched Scrum process into something that used pull so you don’t have to disrupt the team with a big change. I’d definitely like to see us do more of this at p&p.

Corey also has a list of the other Lean/Kanban related sessions at Agile 2008.

Tags: Agile, News & events, Scrum, Toronto
2 Comments »

Scrum Bestiary - The Fox

Another addition to the Scrum Bestiary. So we all know about Scrum’s pigs and chickens and a while back I wrote about seagulls and cows. What about foxes?

Foxes are bad news, plain and simple. Foxes are usually part of the business but your team will only see them when they turn up and try and steal. They’ll steal people and even physical resources, like computers and office space, for other projects that they perceive to be more important. Often they’re doing this for the best of reasons. They really believe that the project they’re attempting to give resources to is more important and they’re actually helping the situation.

Unfortunately the fox isn’t helping the team who committed to delivering work and are now forced to complete it with with less. Not a happy situation.

Read the rest of this entry »

Tags: Agile, Scrum
No Comments »