Last call for this course. We have a good group; hope you or a friend can join us. Regards, Joe

Today is a good day. We got the kids up early... went out for a big country breakfast at Papa Jack's... and then drove up to South Carolina to pick up a mess of really awesome fireworks. You can't get really good fireworks here in Georgia... and since the South Carolina border is only about 90 miles North of Atlanta... we decided to make a trip. We've got about 20 lbs. of ribs basting in the oven... which should be ready in about an hour... so needless to say... but I'll say it again... it is a good day.

While we were driving this morning I got to thinking about my post from yesterday and why people fail to adopt agile in a meaningful way. We were talking about how often people fail to consider the human side of change. We tend to think in terms of process and practices... we don't think as much about the fears that are holding people back and preventing them from letting go. That said... and this was what was nagging me a bit... it's not fair to imply that fear, uncertainty and doubt are the ONLY reasons we struggle to adopt agile... often there are other factors at play
Our Trip to Disney World and Mike's Back Problem
I want to tell you guys a little story.
Up until last year... we used to take the kids to Disney World every October. Disney is great family fun and I highly recommend it. The only reason we didn't go last year was that the kids were getting older and decided they wanted to try something new. Last year we went on a cruise to Mexico.... but I digress. Back to the point... the last time we went to Disney for vacation... I threw my back out the day before we left. I had never experienced anything like it. I've always been pretty healthy and have never had a back problem. I didn't know what to do and it sucked... sucked bad!

My kids we ready to go to Disney... my wife was ready to go to Disney... so we went to Disney. I spent the first two days walking the park... riding rides... and trying my best to have fun... but in reality I was pretty miserable. It's kind of funny... when I look back at the pictures from those two days... I had a smile on my face... but I can see the pain coming through the smile. Back problems are no fun at all.
The morning of day three I finally had enough. We were at Disney's Animal Kingdom and my wife looked over at me and told me I had to go to a doctor. Not knowing what the heck a doctor was going to do to get me through my vacation... short of prescribing some pain killers which I did not want.. I decided to go to a chiropractor. To that point in my life I had never been to a chiropractor and I wasn't sure what to expect...
Long story short... the chiropractor told me that my spine and pelvis were not where they were supposed to be and it was putting pressure on a nerve in my lower back. He did a minor adjustment and I was functional and relatively pain free the rest of the week. Good news is that I haven't had a problem since... the chiropractor found and fixed the root cause... I was out of alignment.

I had the desire to go to Disney... I had a great attitude... I tried to keep a smile on my face... I wasn't afraid to ride the roller coasters... the problem was it just hurt. My body was not in proper alignment to take advantage of all the fun that Disney had to offer. A bunch of the companies I work with are kind of the same way. They want to do agile... they want the business benefit... they want to change... its just that their organizational structure is not in proper alignment to get the full benefits. It's like being at Disney with a back problem.
How do organizations get out of alignment?
Our organizational hierarchies provide the basic infrastructure in which we operate... in which we run our business... that is our foundation. On that foundation we have many forces that pull that structure in lots of different directions.

We have projects run by project managers with schedules, budget constraints, and performance objectives. We have managers that manage teams of specialists... the managers are incented to optimize individual performance and get maximum productivity from each team member. We have products that have their own set of managers... each responsible for managing their markets and trying to get as many revenue generating features in their products as possible.

We spin up teams to do projects... so we have a project team view. We have to mange the component architecture outside the context of any single project... so we have an archtiectural view. Projects might also be part of a program or a portfolio, team members are matrixed across multiple projects, products, and architectural sub-components... all of which put different pressures on the enterprise. Its amazing to me sometimes that we manage to get anything done.
Steven Covey in his book The 8th Habit talks about how so few people in a company feel they understand the objectives of the organization... that that they are working on the most important stuff... or that they are pulling in the same direction as their co-workers. Covey compares this to a soccer team where:

• 4 of the 11 players on the field would know which goal is theirs
• Only two of the 11 would care
• Only two of the 11 would know what position they play and know exactly what they are supposed to do
• 9 players are competing against their own team

Getting on the Same Page
So... while the people issues are really, really important... it is also important that the organization get in alignment if we are going to make a serious go at widespread agile adoption. That means putting some thought into how we create teams... what we have them work on... how we measure their performance... and how we have them work together. Its a matter of aligning the structures of our organization and then aligning team to support those structures. That is fundamentally what will make an agile organzation work.
Like most things... that kind of change doesn't happen overnight... but realizing this is a problem is more than half the battle.
BTW - Here is a picture of our fireworks stash we picked up today... pretty awesome!
Subscribe to Leading Agile


Mike http://www.leadingagile.com

Ken Schwaber und Jeff Sutherland called the result of a Sprint: „Potential Shippable Code.“ The idea was to present to customer and everybody else a piece of the product that worked. In their trainings both of them showed that a team needs to discuss with their Product Owner and with the management the „Level of [...]

I was talking to Erik yesterday and he was wary that I used the phrase "make the internal quality issues tangible" and said he preferred visible or explicit.

I suggested that explicit and visible aren't actually enough.  I truly mean "tangible" because the particular situation I'm targeting is the non-technical audience that doesn't understand what is happening with the long-term health of their systems due to short-term project trade-offs.

Explicit is a number which is too abstract.  Visible is better because then they can see.  But I actually want people to feel, emotionally, the danger which they are putting themselves in.

Our target is tangible with visible being along the way there.

Today is a good day. We got the kids up early... went out for a big country breakfast at Papa Jack's... and then drove up to South Carolina to pick up a mess of really awesome fireworks. You can't get really good fireworks here in Georgia... and since the South Carolina border is only about 90 miles North of Atlanta... we decided to make a trip. We've got about 20 lbs. of ribs basting in the oven... which should be ready in about an hour... so needless to say... but I'll say it again... it is a good day.

While we were driving this morning I got to thinking about my post from yesterday and why people fail to adopt agile in a meaningful way. We were talking about how often people fail to consider the human side of change. We tend to think in terms of process and practices... we don't think as much about the fears that are holding people back and preventing them from letting go. That said... and this was what was nagging me a bit... it's not fair to imply that fear, uncertainty and doubt are the ONLY reasons we struggle to adopt agile... often there are other factors at play

Our Trip to Disney World and Mike's Back Problem
I want to tell you guys a little story.
Up until last year... we used to take the kids to Disney World every October. Disney is great family fun and I highly recommend it. The only reason we didn't go last year was that the kids were getting older and decided they wanted to try something new. Last year we went on a cruise to Mexico.... but I digress. Back tot the point... the last time we went to Disney for vacation... I threw my back out the day before we left. I had never experienced anything like it. I've always been pretty healthy and have never had a back problem. I didn't know what to do and it sucked... sucked bad!

My kids we ready to go to Disney... my wife was ready to go to Disney... so we went to Disney. I spent the first two days walking the park... riding rides... and trying my best to have fun... but in reality I was pretty miserable. It's kind of funny... when I look back at the pictures from those two days... I had a smile on my face... but I can see the pain coming through the smile. Back problems are no fun at all.
The morning of day three I finally had enough. We were at Disney's Animal Kingdom and my wife looked over at me and told me I had to go to a doctor. Not knowing what the heck a doctor was going to do to get me through my vacation... short of prescribing some pain killers which I did not want.. I decided to go to a chiropractor. To that point in my life I had never been to a chiropractor and I wasn't sure what to expect...
Long story short... the chiropractor told me that my spine and pelvis were not where they were supposed to be and it was putting pressure on a nerve in my lower back. He did a minor adjustment and I was functional and relatively pain free the rest of the week. Good news is that I haven't had a problem since... the chiropractor found and fixed the root cause... I was out of alignment.

I had the desire to go to Disney... I had a great attitude... I tried to keep a smile on my face... I wasn't afraid to ride the roller coasters... the problem was it just hurt. My body was not in proper alignment to take advantage of all the fun that Disney had to offer. A bunch of the companies I work with are kind of the same way. They want to do agile... they want the business benefit... they want to change... its just that their organizational structure is not in proper alignment to get the full benefits. It's like being at Disney with a back problem.
How do organizations get out of alignment?
Our organizational hierarchies provide the basic infrastructure in which we operate... in which we run our business... that is our foundation. On that foundation we have many forces that pull that structure in lots of different directions.

We have projects run by project managers with schedules, budget constraints, and performance objectives. We have managers that manage teams of specialists... the managers are incented to optimize individual performance and get maximum productivity from each team member. We have products that have their own set of managers... each responsible for managing their markets and trying to get as many revenue generating features in their products as possible.

We spin up teams to do projects... so we have a project team view. We have to mange the component architecture outside the context of any single project... so we have an archtiectural view. Projects might also be part of a program or a portfolio, team members are matrixed across multiple projects, products, and architectural sub-components... all of which put different pressures on the enterprise. Its amazing to me sometimes that we manage to get anything done.
Steven Covey in his book The 8th Habit talks about how so few people in a company feel they understand the objectives of the organization... that that they are working on the most important stuff... or that they are pulling in the same direction as their co-workers. Covey compares this to a soccer team where:

• 4 of the 11 players on the field would know which goal is theirs
• Only two of the 11 would care
• Only two of the 11 would know what position they play and know exactly what they are supposed to do
• 9 players are competing against their own team

Getting on the Same Page
So... while the people issues are really, really important... it is also important that the organization get in alignment if we are going to make a serious go at widespread agile adoption. That means putting some thought into how we create teams... what we have them work on... how we measure their performance... and how we have them work together. Its a matter o aligning the structures of our organization and then aligning team to support those structures. That is fundamentally what will make an agile organzation work.
Like most things... that kind of change doesn't happen overnight... but realizing this is a problem is more than half the battle.

In the past, I’ve been a true believer that software development is not really possible to measure from a productivity perspective. I was ignorant, basically. I’m now a bit wiser and I understand that software development is no different than any other product development process. We can and should measure productivity of software developers by understanding that we are building business value via functionality that the end-user wants. So, we should essentially be measuring our progress toward the end user facing functionality (as an over-simplification).

A Paper On The Theory Of Constraints

Several months ago, I wrote up a paper for an internal company effort to help define productivity metrics for software developers. This paper is largely based on the work of David J. Anderson, in “Agile Management For Software Engineering”. It also includes some of my own interpretations and understandings of the Theory of Constraints.

The original intent of this paper was to facilitate the discussion of productivity and metrics in the Development Department at McLane Advanced Technologies, LLC., where I work. I decided to release it to the world, to hopefully help others understand how we can measure productivity as software developers. I did not intend this to be a comprehensive or exhaustive discussion of the points within, but am trying to spur additional research and conversations. I hope you enjoy reading it as much as I enjoyed writing it.

Download The Paper

You can download the PDF here:

The Theory of Constraints: Productivity Metrics In Software Development

Nice little article called Shark Swallows Woman from the Managing Agile blog.

'); //-->

Checking out the NerdDinner code the other day, I found a common Dependency Injection anti-pattern.  One of the core concepts of DI is that components are not responsible for locating their own dependencies.  The code went part of the way to full-on DI, but not quite far enough.  Here’s the offending code:

public class SearchController : Controller {

IDinnerRepository dinnerRepository;

//
// Dependency Injection enabled constructors

public SearchController()
    : this(new DinnerRepository()) {
}

public SearchController(IDinnerRepository repository) {
    dinnerRepository = repository;
}

The second constructor is correct – the SearchController’s dependencies are passed in through the constructor.  This is because the IDinnerRepository is a required, or primal dependency.  SearchController depends on IDinnerRepository to function properly, and won’t work without it.  But on the first constructor, we violate DI by having the SearchController create a concrete DinnerRepository!  We’re now back to concrete, opaque dependencies.  We have a small benefit of easier testability, but we still force our controller to locate its own dependencies.

So why is this a Bad Thing?

For one, it’s confusing to have two constructors.  Why go through all the trouble of creating the IDinnerRepository interface if I’m just going to depend directly on an implementer?  Now what if DinnerRepository now needs some dependency?  What if it now needs some ILogger, security or policy dependency?  Do I now need to go fix all of my calls to “new”?

And that’s the whole point of Dependency Injection, and the Dependency Inversion Principle.  I only know about my first level dependencies, and abstractions on top of that.  If we check out DinnerRepository, we see another issue:

public class DinnerRepository : NerdDinner.Models.IDinnerRepository {

    NerdDinnerDataContext db = new NerdDinnerDataContext();

A private, opaque dependency to NerdDinnerDataContext.  If we wanted to make that opaque dependency explicit, we’d have to fix our SearchController (and all the other controllers as well).  It’s these kinds of ripple effects that prevent refactoring and improvement.

Fixing it

But we can fix this, quite easily.  From MvcContrib, we can grab any one of the ControllerFactory implementations for the IoC container of our choice.  For me, that’s StructureMap.  First, we’ll need to configure StructureMap to wire up all of our dependencies.  The preferred way to do so is to create a Registry:

public class NerdDinnerRegistry : Registry
{
    public NerdDinnerRegistry()
    {
        Scan(scanner =>
        {
            scanner.TheCallingAssembly();
            scanner.WithDefaultConventions();
        });

        ForRequestedType<NerdDinnerDataContext>()
            .CacheBy(InstanceScope.HttpContext)
            .TheDefault.Is.ConstructedBy(() => new NerdDinnerDataContext());
    }
}

In the first part, we just tell StructureMap to scan the calling assembly with default conventions.  This will wire up IDinnerRepository to DinnerRepository.  Probably 99% of our dependencies will be taken care of in that one call.  Next, we need to wire up the NerdDinnerDataContext (for reasons we’ll see soon).  Since that class has multiple constructors, StructureMap likes to use the greediest dependency, with the most arguments.  I don’t want that, so I override it to use the no-arg constructor.  Finally, I cache it by HttpContext, though I could probably go Singleton if it’s expensive to instantiate.

Next, I need a wrapper class to initialize StructureMap:

public static class IoCContainer
{
    public static void Configure()
    {
        ObjectFactory.Initialize(init =>
        {
            init.AddRegistry<NerdDinnerRegistry>();
        });
    }
}

Initialize only needs to get called once per AppDomain, and all I need to do is add the NerdDinnerRegistry I created earlier.  I could wire up everything here, but again, the preferred configuration method is through registries.  The next piece is to wire up ASP.NET MVC to both call our configuration method and use the StructureMapControllerFactory:

void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);

    IoCContainer.Configure();
    ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory());

    ViewEngines.Engines.Clear();
    ViewEngines.Engines.Add(new MobileCapableWebFormViewEngine());
}

I put all this in with the other MVC configuration in the Global.asax Application_Start method.  One final piece is to remove the extra constructors on our controller:

public class DinnersController : Controller {

    IDinnerRepository dinnerRepository;

    //
    // Dependency Injection enabled constructors

    public DinnersController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }

And make our DinnerRepository expose its dependencies explicitly:

public class DinnerRepository : NerdDinner.Models.IDinnerRepository {
    
    private readonly NerdDinnerDataContext db;

    public DinnerRepository(NerdDinnerDataContext db)
    {
        this.db = db;
    }

Note that there are no no-arg constructors to be found!  When StructureMap creates a DinnersController, it will look to resolve the IDinnerRepository dependency.  That’s a DinnerRepository, which in turn needs the NerdDinnerDataContext.  But that’s all hidden from us, we never need to wire up an entire graph, as we would if we stuck to the “new” operator.  Just to make sure everything works, I can navigate to view upcoming dinners:

Wrapping it up

In the original NerdDinner code, dependency inversion was only partially implemented as the original controllers still contained a constructor that called a constructor of a concrete class.  To fix this, we added StructureMap to the mix, configuring ASP.NET MVC to use StructureMap to create controllers instead of the default controller factory.  Finally, we pushed the dependency inversion principle all the way down to our repository, removing the opaque dependencies where we found them.  When we finished, all of our classes exposed their dependencies explicitly through their constructor.  No one class knew more than one level of depth, and our controllers now properly depended exclusively on the IDinnerRepository abstraction.

In the future, we can add things like logging, policies and the like to custom IDinnerRepository implementations, without needing to change any of our controllers.  Once we introduce inversion of control to our application, we open a lot of doors for functionality and simplicity, but only going halfway won’t give us the full benefit.

I am particularly excited about the following courses or workshops.

One: Jeff Sutherland in Richmond, VA. Certified ScrumMaster (CSM) course. Dr. Sutherland (he has a PhD) is a great guy and of course the co-creator of Scrum. I always learn more when I do these courses with him. This a great advanced course for many people. Great for managers, too.

If you do not follow Dr. Sutherland's blog, you should.

Two: Poppendiecks in Chicago. New Leading Lean Software Development workshop. Mary & Tom Poppendieck are of course the thought-leaders in Lean Software Development. Again, I always learn when I help with their courses. This course is new, and will be based on their new book (coming out soon).

For an outline of their new book, see here.

Three: CSM for ScrumU at Notre Dame. ScrumU is a group of people who do SW dev (etc) for the universities...using Scrum (and other Lean-Agile stuff). This is a special course only for those kinds of people, at a "university" rate. And it is for professors who teach IT subjects. Kristine Gianelli, leader of ScrumU, is the mastermind behind this course.

 Subscribe in a reader

Scala has become more and more popular over the recent months/years. Its hybrid nature of being an imperative as well as functional language attracts a crowd from the Java world as well as functional fundamentalists coming from the world where statements like x=x+1 are looked at with the utter disbelief. It has been stated that Scala is 'Java as it should have been', but there are also numerous complaints about the language and its features (like not being side effect free, overly complex, too much of everything, too much abstraction, having a weird syntax, etc). The latter might actually be a proof of its popularity, since people seem to be actually using the language instead of just looking at it briefly and stopping, tired but happy, after having written hello world with it.
In this blog post, I'll give you some (hopefully) useful tips how to best start if you want to learn this language, which is one of the candidates become 'our next big language' and surpass Java in this respect.

Pick an IDE, or not
The first problem you might encounter is that the various Scala IDE plugins have not yet reached the maturity of the Java support that you might have been accustomed to. Lots of hard work is in progress on this, but you still might experience hickups and freezes (as I have) of your favorite IDE. At this moment, the Netbeans plugin seems to be the most stable (this is the IDE that David Pollak, creator of Lift, seems to use). If you're an eclipse user, you'll probably want the nightly build version of the Scala plugin, since that's the only one actively under development. This means that you need the Scala trunk to work with, however.

There's also plenty of support for non-IDE's, and recently I've tried switching back to emacs again. For some, this brings back memories to good old university days, others may find it the utmost horror. I must say, I found it to be a rather soothing experience after years of development using Eclipse. You'll need to do some setup work to get a good Scala experience. An excellent blog post describing how to setup your emacs environment for Scala using Yasnippet, exuberant ctags and maven can be found here.

Try out the trunk
The latest released version of Scala is 2.7.5. The next version will be 2.8.0, but its release date is still not known. However, the invaluable Paul Philips has done many bug fixes and improvements in the Scala compiler and the REPL, all hanging out in the trunk. To take full advantage of this, check out the sources and build them. Note that the Scala collections API has been redesigned in the trunk, and differs from the 2.7.5 release. To get a good understanding of the new design, and the API in general, you're encouraged to read the new collection SIP (Scala improvement proposal) available here.

Read a book
The standard work is Programming in Scala, co-authored by Martin Odersky (creator of Scala) himself. This book is lengthy but very thorough, providing plenty of examples. Another book that has seen the light is Beginning Scala by David Pollak (already mentioned). I have not read this, but reviews suggest this is also an excellent start. More books will hit the market this year.

Check out Lift
Eventually it is possible that you might start to really like Scala and want to use it in the enterprise. Lift is the first web framework written in Scala, created by David Pollak. Downloading and creating a simple web application to work is a no-brainer. The distribution comes with plenty of maven archetypes to get a basic web application ready in under than five minutes. Lift has its own database mapping framework, but there's JPA support as well, if you like this. JTA integration is also being worked on.

Read some articles
There are loads of (both academic and slightly less academic) articles about Scala. For example, if you want to know the rationale behind Scala's actor library design, read the scala actor papers.
Martin Odersky's homepage also contains a long list of his publications.
It provides lots of material to provide insight in the design of Scala and its libraries. If you're not that academically inclined and from a Java background, try The busy java developer's guide to Scala, by Ted Neward. Provides a nice introduction.

Read some blogs.
Plenty of blogs available, here are some I like:

• Daniel Spiewak Lots of useful Scala examples.
• Tony morris. He's the creator of functional java and of Scalaz. Beware however, if you check this out you might end up in deep functional waters where Monads reign.
• Jonas BonerHe has lots of experience of using Scala in the real world, some of which he has blogged extensively about. Well worth the read.
• Planet Scala Perhaps you don't even need more than this. This aggregates numerous blog posts (including the one mentioned above) about Scala.

Join IRC
Scala has an IRC channel, which can be found here. Whenever you're stuck at some problem you're working at, there's always the mailing lists, but many knowledgeable people hang out on a daily basis on the IRC channel. Use pocoo to show the code you're stuck with, and you'll get an answer in no time.

Start coding.
Lift might be the choice if you really want to write some useful, practical real world web applications. If you're totally impractical like me, pick a few problems from project euler, or the 99 problems projects (solutions in Scala can be found here. Many excellent programmers have taken this path, it's fun and an excellent way to play around with the core Scala API.

To put into practice what I preach here, a few lines of Scala code to either whet your appetite or make you run away screaming. Note that my Scala knowledge is still in the pre-kindergarten stage, I'm barely able to speak, so laugh at will when viewing this code.

First, a randomly picked Euler problem, number 48, just because I like onliners:

(1 to 1000).map(x => new java.math.BigDecimal(x).pow(x)).reduceLeft((a,b) => a.add(b)).remainder(new java.math.BigDecimal(10).pow(10))

This one liner is not nearly as concise and neat as the Haskell version, but it will do. If nothing else, it has at least has the tiny merit of showing Scala - Java interoperability.

Another randomly picked and slightly more complex one, problem number 21:

object Euler21 {
  def sumOfDivisors(number: Int): Int = {
    List.range(1, number).filter{i => (number % i) == 0}.foldLeft(0){(a,b) => a+b}
  }

  def solver(): Int  = {
      (for (i <- 0 until 10000; di = sumOfDivisors(i); if(di > i && sumOfDivisors(di)  == i) ) yield (i+di)).foldLeft(0){(a,b) => a+b};
  }
}

Enjoy.

Bookmark

Danilo writes about, “Done is not done” and I’m reminded of being careful about using the right metric. I remember being on a project where people had individual velocity. This is a really bad thing unless you want to prevent collaboration. I’d add it to Danilo’s list.

I just came across this fascinating article on how teams are organized at GE’s Durham plant. This plant is used to manufacture GE’s high powered jet engines for long haul commercial flights. The surprise? Teams at this plant are completely self-organized. There are 170 people here, with a single plant manager (more like a facilitator than a supervisor).

It’s a long article. Here are some quotes.

(more…)

I just started a LinkedIn group: Scrum Practitioners South of Sweden.

The idea is to collect a bunch of people in the south of Sweden who want to meet face to face regularly, in an informal manner and share experience of Scrum, Agile and related topics with the intent of helping each other out and improving how we work.

Not sure if such a network already exists but I certainly see a need for it personally.

Follow this link if you're interested in joining.

Recently I discovered an interesting blog thanks to Tim Ottinger’s comment on my TDD Anti-Patterns post, Agile in a Flash. It looks like they’re putting together a comprehensive book plus flash cards about Agile, and from the few posts I’ve read it looks very interesting. Check it out!

This 15 minute video shows how to implement a Kanban process using Silver Catalyst. In the process, we’ll see various practices of Kanban illustrated such as:

• How to customize the workflow to map to the value stream
• How to track custom data (like class of service) for each work item
• How to setup work in progress limits
• How to pull work items through the value stream
• How to block work items and stop the line
• How to use card colour to identify work item type
• How to track cycle time and lead time for each work item
• How to use the throughput and work item breakdown reports and link it with a continuous improvement process

You’ll also see how Silver Catalyst can help with the four basic Kanban principles:

• Pull value through the value stream
• Limit work in progress
• Make it visible
• Establish a cadence

(more…)

Swimlanes are used to track parallel work streams within a common resource.  The most typical use might be grouping composite work items with a parent.  Another typical use is an expedited lane for emergency work items that can skip queues and preempt other work.  Swimlanes generally indicate some kind of branching.  That can be either work item branching or workflow branching.

Kanban systems can be used when the work generally follows some kind of common workflow.  For many software development projects, this is an easy constraint.  Most software involves some kind of problem definition, some kind of design activity, and some kind of verification.  Most software development also involves the use of a limited set of technology applied to a limited set of systems within a limited problem domain, so that most of the work done falls into a few general types.

Most is not all, however, and sometimes work will appear that doesn’t fit neatly into any well-defined type.  Or maybe it does have a type that we haven’t defined yet.  If the work is non-value-added, we can chalk it up to overhead.  If the work is value-added, we will want to track it like all of the other value-added work.  A useful trick for managing that kind of work is to reserve a swimlane for ad-hoc workflow:

If you find yourself using the ad-hoc swimlane frequently, you might want to map the value stream of some of the work items to see if you can discover some latent or emerging workflow.

Dan North wrote an interesting post about the perils of estimation, questioning our approach to inceptions, release planning, and setting expectations about scope. This made me think about the implications of those factors once a project starts, and I came up with some anti-patterns on the usage of velocity to track progress. This is my first attempt at writing about them.

Before we start, it’s important to understand what velocity means. My simple definition of velocity is the total number of estimation units for the items delivered in an iteration. Estimation unit can be whatever the team chooses: ideal days, hours, pomodoros, or story points. The nature of items may vary as well: features, use cases, and user stories are common choices. Iteration is a fixed amount of time where the team will work on delivering those items. Sounds simple? Well… there’s one concept that is commonly overlooked and that’s the source of the first anti-pattern: what does delivered means?

One of the most common anti-patterns I’ve seen is not having a clear definition of done. Lean thinking tells us that nothing is really done until it’s delivering value, which in software means: code running in production and being used by real users. Although I know very few teams who can deploy code to production at the end of every iteration (some even do more than once per iteration), once a story is considered done, it could be potentially shipped, if the business decides so. There shouldn’t be a lot of extra work after that.

Another bad implication of this anti-pattern is that some teams decide to change the definition of done and count half-completed work to show progress. Some of the symptoms to help diagnose if your team is suffering from this anti-pattern are:

• The team starts tracking dev-complete stories
• “It’s done, but [we need to write the acceptance test/it's not integrated with the other system/...]“
• “It’s done, but not done-done”
  
• It takes a lot of extra work to get the story deployed to production
• After finished, the story goes into the next team’s backlog
• Hearing terms like “development team velocity” or “test team velocity”
• Counting half-points or percentages because “if we don’t count it will look like we haven’t worked”

The solution? Remember that velocity is just a number that provides information for the team to understand and improve it’s process. Forget that you’re tracking it and focus on the entire Value Stream and on what’s really value-added to get things into production. Anything else is just waste. If it’s not done, it’s not done. Accept it, move on, and don’t overcomplicate, because it will only add noise and mask what could have been important information to the team.

A few weeks ago at the local Ruby Users Group meeting there was a suggestion of actually writing some code at the meeting. The suggestion was to use a Ruby Quiz exercise. It was quiz #16, a Rock, Paper, Scissors simulation. We broke up into small groups of about three people, coded for maybe 45 minutes and turned in our solutions. My team came in last but it finally pushed me to actually take up a long neglected todo item to start doing coding katas on a regular basis.

I’ve done the classic Bob Martin TDD bowling kata for years as an intro to TDD. I’d also walked through a one day tutorial from a Dave Astels session on Rspec back in 2006 that was very much a game based kata. I’d read about Prag Dave’s coding kata ideas, but I’d never quite found the time to start the practice.

Last week I started utilizing two major resources:

• Prag Dave’s original CodeKata site.
• The KatCatalog from the Coding Dojo wiki.

I’m jumping back and forth between Java and Ruby in the katas to stretch my skills. I may even add in Groovy at some point, but Groovy and Ruby styles are pretty similar. I’m trying to take on one per day and when I wrap around I’ll try out different languages. As a committed TDD student I’ve started each kata with a test. I have to admit RSpec makes this a lot easier when using Ruby and autotest is a wonderful tool. At least I have annotations and JUnit 4+ when I’m doing the katas in Java. For IDE’s I’m bouncing between IntelliJ for Java and TextMate for Ruby. I’m even taking the opportunity to test out git and I setup a github account to store the katas so I can see how I evolve over time.

If you haven’t tried out the practice I might suggest giving it a go. One of the best things is I get to really focus on coding for about an hour a day and it blocks out the rest of the world. Mostly I’m doing them in the early morning to cut down on the interruptions. I’ll probably post again on my observations after a month or so.

Agile software development teams often use User Stories as a simple and concise way to express user requirements.

Ideally these User Stories are broken down as small as possible, whilst also trying to minimise dependencies.

Naturally, though, as you break User Stories down smaller, they become increasingly inter-dependent. Like most things in software development, it's a balancing act.

Break the User Stories down as small as possible. But stop breaking them down when it becomes onerous or pointless to do so. When a User Story can be delivered (done) in less than 1 day, I think there is little point breaking it down any further.

Use the concept of Themes to categorise these related User Stories under one label and keep them together.

You could physically keep the cards together by paper-clipping the cards together. Or you could put a card representing the Theme on the left side of your whiteboard, and keep all related User Stories on the same row as the Theme as they move across the board.

Equally important, try to make sure that any inter-dependency between User Stories is a soft dependency, rather than hard. By this, I mean that you might not want to ship any of the User Stories until the whole Theme is done. But try not to break them up in such a way that one User Story simply doesn't work without another.

For instance, a 'Login' Theme might include User Stories for Register, Log in, and Forgotten password. Although the stories are related, and somewhat dependent on each other, they can still be delivered in isolation, and can still work from a user perspective if you do them in the right order.

You can also use Themes to categorise loosely-related items on your Product Backlog. For example, on a web site, you might have a whole host of User Stories relating to SEO, performance, usability, a re-style, or sections that are made up of multiple User Stories.

Assigning Themes to the User Stories in your Product Backlog can help you to see emerging themes, which with a loose set of User Stories you may not have noticed. When you see emerging themes for your next Sprint or two, this can help to give extra clarity to the team and business about the Sprint Goals.

This is a useful thing to do. It gives you more of a message for the Sprint. It's actually *about* something, rather than a random collection of high value but unrelated stories. It could tell you that you're focusing a high percentage of your Sprint on features x and y, when at a macro level your priorities are really elsewhere, for example.

It also helps when priorities are set top-down. For example, let's say we make the commercial decision that for the next few sprints SEO will be a top priority. You can quickly grab all the User Stories with the SEO Theme and give them priority.

Of course it's fine for a sprint to include items that are not part of the overall Theme. The theme is simply the main area of focus, not necessarily the sole area of focus.

There is sometimes a danger with agile software development that everything is broken down so small and incremental that everything becomes a bit too tactical, and there is either no direction or at least the direction is not apparent.

It's important to keep a higher level Release Plan, or a Product Roadmap, so the Sprints do take the product in a certain direction, and so the team can see what that direction is. Because no Sprint is an island!

You can also use Themes as a simple way to sketch out broad priorities on the Product Roadmap, showing the key areas of focus over time.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by *phototristan

Agile software development teams often use low-tech, manual methods for tracking their work. Post-it notes or cards on a whiteboard. Charts drawn by hand. Sketches for architecture and design.

But why, for such a high-tech industry like software development, would agile teams do this, when there are plenty of project management tools available; even tools that are purpose-built for agile software development?

Personally I can see why. I think a whiteboard offers loads of advantages over electronic tools. They're mainly soft factors, I admit, but I think a whiteboard is hard to beat.

First of all, a whiteboard is visual. And it's BIG. You can see at a glance how things are going.

When you're part way through a Sprint, and most of the cards are still on the left of the board, you know it's not going so well. Or you're coming towards the end of a sprint, and the cards are mostly - reassuringly - on the right of the board, you know it's going fine. The Burndown Chart shows you instantly whether the team is on track. And, if not, by how much. All at a glance as you walk past the board. Whether you made a special effort to look or not. The visibility is unbeatable.

When you see something in print, somehow it seems more real. I guess because it's physical. A large number of post-it notes on a whiteboard looks like a lot of work. Probably because it *is* a lot of work! Its sheer physical presence reflects the amount of work the team is actually doing. It feels busy. It feels like a place where alot is happening, which feels good. A long list of tasks on a project plan, or a long list of rows in a spreadsheet, simple doesn't have the same impact.

A whiteboard is also flexible. Infinitely flexible. You can put literally anything you like on it. Wherever you like. In any position, any size, any shape. Unlike an electronic system, there are never any constraints. No-one ever says you can't do something because the whiteboard won't let you.

It's fast and efficient to change. You could completely reoarganise a set of cards in just a few moments. Or sketch something important in seconds.

It's also more tactile. For people that like tactile, it feels good to move a card to done. You feel a sense of ownership when you pick up a card. A business owner feels a greater sense of responsibility - real acknowledgement - when they add something to the board and take something else off the board to take it out of scope. It feels like something was actually, physically removed from scope.

It's also novel. When a team starts doing agile - and they create great visibility using the whiteboard - it's remarkable how many people want to come and look. Senior people have a sudden interest in what the team is doing. And even in the process itself. That would never happen with spreadsheets and tools! I can't ever remember a Director asking to come and walk through my project plan, or walk through my product backlog. In fact the very thought of it fills most people with dread! It just doesn't happen. But the whiteboard is interesting. It's interesting to look at. And interesting to talk about. When someone walks you through it, it's actually enjoyable.

Because a whiteboard has no set structure, it suits the way many people think (not all). Many people think visually. Not in lists, but in shapes, sizes, colours, etc. The whiteboard's lack of structure allows the information to be organised and presented however suits.

Important information can be highlighted easily by putting it on the whiteboard. Important information is not buried with loads of other documents and files in a project folder somewhere, which few people would browse and certainly wouldn't notice in passing.

Its visible nature can prompt people to remember things when they see them, rather than relying on their memory to go and look somewhere else that's out of sight.

But above all else, the whiteboard is a place for collaboration. It's a focal point. Like a campfire in days gone by. Or a fireplace in your lounge. Most team discussions happen round the whiteboard. Discussions about progress. Discussions about issues. Discussions about design. All sorts, sometimes even when the whiteboard isn't even needed. It becomes the hub of information for the team. The hub for communication and collaboration.

And last but not least, the unstructured nature of the whiteboard allows it to be be personalised by the team. The team can express itself through the things it puts on its whiteboard. It starts to show the character of the team, and therefore helps to create a visible sense of team spirit.

Tools can certainly help to organise information more efficiently. But I would challenge any tool to do all of that! I'm not against tools. Not at all. But I think they should supplement the whiteboard, not replace it. Tools should be used for things they can do that a whiteboard can't. For instance, keeping track of longer lasting information, doing calculations, searching, etc. But personally I don't think I'd ever use tools instead of a whiteboard. There's simply too much to lose.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by Fernando Meyer