Blogtastic

If it really was all about business value my life would be so much easier

The principles behind the Agile Manifesto state Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. I've often heard this shortened into a frequently used battle-cry of Agile: It's all about business value!.

This is an incredibally liberating and empowering statement. It tells us that we have a concrete, measurable, fulcrum we can measure all our decisions upon. Should we implement feature A or feature B? Well think about how much each are worth! Should we write this support documentation? Well, is the company going to save money by having it? And so on.

But there's a problem. How many people in an organisation actually care about business value? Sure, the CEO probably does. He needs to justify the bottom line of the company accounts to the board. And so, by the chain of responsiblity, should everyone else in the organisation. But what if someone doesn't. How does an Agile project justify its existence and practices then?

An immediate counterpoint may be 'well, if there's an Agile project happening in a company, then obviously someone believes in business value, and they take the responsiblity for the justification'. Great, but there's more than one stakeholder a project has to deal with, and what happens when some of those people don't care about business value? What if they only care about process? What if, at the end of the day, they only care about doing work they can't get fired for? How does Agile prove itself here? And no, you can't just ignore those people. If you do, your project is doomed to fail.

In my experience Agile can be promoted as a worthwhile change in process without using the argument of business value, but it's hard work. It gets harder the bigger the project, the more visibility the project has within the organisation, and the more bureauocratic the organisation is. Arguments about quality, visibility, repeatiblity, etc can be used, but effectively what's needed is a knowledge about what motivates every individual within the stakeholder community. If that community conists of 50+ people, that's a lot of work, requires a lot of patience, and needs (at least) an experienced Agile project manager or Agile coach. Even then there's going to be a certain amount of extra work required within the team to satisfy the environment in which the project lives.

Of course, there's also a danger that not even the project sponsor really cares about business value. Maybe they had ulterior motives when they picked the methodology or supplier, or maybe they move on from the project. In this environment, Agile can still win, but until Agile becomes 'mainstream' any such project is in a dangerous place and such teams need to tread carefully.

Looking forwards optimistically though, what if the Agile Software movement changed not just the world of software development, but also helped to bring about a more 'agile oriented' business world in general; one where business value, respect, individuals and interactions, and the ability to change were valued more highly than process, sticking to the rules, or making decisions based on how they would impact 'me' rather than 'us'? In this business world, my life would indeed be easier.

Permalink

Classifying Tests

I'm not really a 'testing guy', but I am an 'agile guy' so I do write and use automated tests during development. I find that there's a lot of confusion about what a 'unit test' is, what an 'acceptance test' is, and that kind of thing. Most of the time people have their own feelings about what these different classifications of test are and when talking to others assume that they have the same idea. This is frequently not the case.

So just in case you ever talk to me about tests, and we forget to come to a common shared language about them, here's what I might mean by the various types of tests. Note that these are mostly 'development test' defintions, not 'QA test' definitions. I'm not saying they're right, they're just what I think they mean. (Bret and Brian - please forgive me. :) )

A unit test tests the smallest component in a system. In an object oriented system, this is a class. It might also be an individual stored procedure, javascript method, whatever. A unit test should not assert (or rely on) any behaviour in the system other than that of the component it is testing.

At completely the other end of the scale, an acceptance test is a behaviour that 'the customer' has defined the application should have with the environment around it. This may be a relationship between different parts of the application's domain, an expected output for a set of input in the UI, performance criteria, or interactions using a shared technological resource (such as a shared database or messaging infrastructure.) The important thing about an acceptance test is it should not assert anything about the implementation of the application.

Ideally, acceptance tests should be automated, but sometimes the cost of doing this is too high to justify the value.

I like any application I work on to have both of these types of test. Acceptance tests are about showing the application does what it should do, to the extent of what I (as a developer) have been told it should do. Unit tests are about helping develop new parts of the system.

Somewhere between these two I define functional and integration tests.

To me, a functional test is used to assert the behaviour of an individual component within the application. Typically this would be a pretty small component, consisting of smaller components that have each been unit tested. The point of functional tests is to group together some overall behaviour for a (developer defined) part of the system.

An integration test is like a functional test, but tests a complete sub-system of the application in its target environment as opposed to functional tests which would typically be tested in a test-specific environment (e.g. out of container.) If the application consists of several services (for example), an integration test in my speak would test each of these services in their deployed environment with a set of example scenarios.

To me, functional and integration tests as defined here are not strictly necessary for the successful development of an application, but can help development by showing problems in a more easily diagnosable form. That said, if you have a failing functional or integration test and no failing acceptance test you are either missing an acceptance test or are implementing functionality that is not required.

And I have no idea what a system test is. Maybe someone can tell me. :)

Permalink

Lessons from a Successful Agile Project Part 4

Anyone that knows me would have expected me to spout on about tools and build issues by this point, and I think its pertinent how important the previous points were to this project that build gets pushed into the fourth chapter, but here it is finally.

Technical Automation

Despite having 10 highly productive developers, and a fairly complex build process, we did not need a full-time 'Buildmaster'. I think there were a few reasons for this:

- A few of us on the team had had enough build experience over the years that we now had a good feeling of 'what worked' on an agile project
- The build environment was under the same common ownership as the source base
- Major build improvements would be driven by specific stories
- Minor build improvements would be treated as refactorings and done at any time

This was beneficial since no one person was 'stuck' with the tag of being in charge of the build, and everyone else on the team felt empowered to change anything that was causing them pain.

I should add at this point that if your build / deployment setup isn't sufficiently automated and easy to troubleshoot, then you probably will need a full time Buildmaster. One of their tasks should be to make themselves redundant by adding such behaviour.

Lesson 6 : Aim to not have a specific Buildmaster. Instead, treat the build system as part of the commonly owned source tree and make sure anyone can add value to its on-going development.

There were many things that worked really well in our build system but I'll just talk about 2 of them. The first covered the area of build configuration.

I've seen many 'difficult' build systems where there are a plethora of build config files, build launch scripts, environment variable dependencies, complicated build invocations, etc. All of this is (in my mind) totally unnecessary. On this particular project, there was one property of build configuration that changed between developer workstations and that was the database name to use. Apart from that, everything was the same. So the entire configuration for our development workstation environment of 15 (or so) machines fitted in one page of a properties file which itself was checked into source control.

Now of course we had some clever stuff going on to handle figuring out what specific machine you were using, how to override for Continuous Integration environments, etc., but most of the time developers didn't have to worry about it.

This setup saved us so many headaches and so much time that I would now always consider it a 'must-have' for any future project I work on. I hope to write an article on the exact details at a later date, so keep your eyes peeled.

Lesson 7 : Minimise the complexity of your build configuration system. Keep the entire development environment configuration in one file and store it in Source Control

The final thing I want to mention here is our database automation. We migrated the full database on every build. Go back and read that last sentence and think about it for a moment.... OK, I'll tell you why I think its great:

- We never hit a data migration problem on release: we migrated all the time, against real data and so any problems were caught early
- We didn't have an ostricised data team: data migration work formed part of any story that required it and all the developers did it.
- Since we wanted to 'do it all the time', the data migration process was highly automated. That meant our DB release process that we gave to the operational DBAs was really-simple, reducing likelihood of errors and getting us in the DBAs' good books. :)
- We could release at any time - we always had enough data migration code written to support the state of the code base.

Technically. we did this with a bunch of NAnt script and command line 'osql'. Again, it would be too big to document in a blog item but I hope to write it up later.

Lesson 8 : Make data migration part of your regular build. Make developers write data migration code as part of implementing a story that requires it.

Permalink

Agile Auckland starts next week

It seems I have timed my arrival in New Zealand, and specifically Auckland, perfectly. Agile Auckland is a new Agile User Group that has its first meeting next week (12th October). Check out the website for more details about the event and a mailing list.

Permalink

Lessons from a Successful Agile Project Part 3

Apologies for the delay since the last installment of this series - I've been pretty busy with work and moving country. :)

Daily Practices

Our daily practices worked out well, and were pretty simple, so I wanted to describe them.

The day would start at 9:30 with a team stand-up. People present would be the entire project team (the 10 devs, 1 PM, 2 BAs and tester), plus anyone we were also working with at the time (e.g. we would occasionally have iterations where a reporting specialist would work with us.) Also the department coach would drop in every now and then. The initial stand-up would last about 10 minutes, by going around the team one-by-one (we would stand in a circle) and people reporting what they did yesterday and any particular problems they hit. Deeply tech problems would be mentioned but not described heavily. Since we paired, often the first person in the circle would decribe the activity, and the second person would just say 'What Bob said', and that would be considered perfectly OK.

Lesson 4 : Keep your stand-up meetings short, and allow the whole team to talk about what they've been up to

After the main stand-up, the developers would remain for a brief 'tech stand-up'. About 1 in 3 times we would spend time quickly discussing any tech issues that arose from the main stand up. With that over, we would do pair-up and story-distribution. This basically worked as follows:
- If a pair from the previous day were near to completion and/or had only just started pairing they would often stay paired and stay on the same card.
- The remaining people would pair up normally with a different pair and often with someone that they hadn't paired with for a while.
- For any started, but incomplete, stories being worked on at least one member of the pair would always have worked on the story the previous day.
- If people remained after all started but incomplete cards had been distributed, new stories would be distributed according to priority set in the IPM.
- We would normally have one pair assigned to bugs.

If stories were completed in the middle of the day, we might iterate the above process with a few people on the team. For example, pair rotation could happen during the day, and new stories could be started during the day.

The important point that is not mentioned here is anything about 'story ownership'. I've often seen projects where each story is 'owned' by a particular developer for a particular iteration. I really don't understand the value in this and believe it to be the sign of either a micro-managing PM or a development team that doesn't have internal trust. The developers should be jointly responsible for all stories in an iteration. If the iteration is running slow, it is the team's, not an individual's, responsiblity to pick up the slack where required.

I actually think 'individual ownership' is damaging. Consider the following:

- If there are people on the team that have specific knowledge about an area that no-one else has, it is the team's responsiblity to spread that knowledge around - individual sign-up is not going to encourage the team to start picking up specialized tasks and so knowledge sharing is limited.
- What does individual responsiblity mean? I've heard of some projects where it means that if a story is running behind in an iteration it is that individual's responsiblity to pick up the slack, if necessary by working weekends. This is terrible for team morale.
- Individual sign-up hinders pair rotation. Consider a story that takes 3 days to implement. If one specific person has to work on that card every day, a maximum of 4 people will work on that card. If the ideas above are used instead, 5 people could work on that card. This means more rotation and more common knowledge in the team.
- It doesn't fit with prioritisation. The 2 most important cards in an iteration should be the 2 that are worked on first. If these 2 cards are both 'owned' by the same individual, one is likely to be pushed back in the iteration and therefore is less likely to be completed.

Lesson 5 : Don't do individual story sign-up. Instead allocate stories on at least a daily basis, keeping priority stories up the stack, and pair rotation a continual activty.

Permalink

Lessons from a Successful Agile Project Part 2

Lightweight Planning

It was not appropriate to deploy to the 'real' customer every iteration for a few reasons, so we bundled new functionality into several releases, each being 2 - 3 months long.

We would have release planning meeting at the beginning of every release, and normally also halfway through to keep track of how we were doing. Such meetings were typically between 1 and 2 hours long. The process would be:

- One of the BA's would read out the 'release level' stories one by one
- For each story each developer would write down an estimate in rough 'ideal days'
- Once all the stories were read out each developer would sum their estimates
- We would then go around the room and all the totals would be written on a whiteboard.
- From this, we would see a basic idea of how much work the team thought there was

This process was not at all in depth, but it was only meant to give a 'finger in the air' estimation. Keeping the meetings short also kept the developers from falling asleep. :)

Before each iteration planning meeting (IPM), the project manager, the 2 BA's and 2 of the developers would have a quick look through the upcoming stories to pick candidates to discuss at the IPM. This decision was not final - it was just an optimisation so that we'd have a first cut of stories to discuss in the IPM proper.

The IPM itself would normally be about an hour long. The sequence of activities would normally be:
- The Iteration Manager (one of the developers) would describe the results of the last iteration in terms of completed stories, total 'ideal days' completed, and stories remaining ('hangover').
- The team would estimate the remaining ideal days for each of the hangover stories.
- The Iteration Manager would give a rough amount of how many ideal days were left for new stories, based on velocity and how many pairs we had for the next iteration.
- One of the BAs would then describe a story. At this point a combination of 3 things would happen:
+ A discussion would spark up
+ The team would split the story (e.g. because of size)
+ The developers would estimate the story
- Once the story was estimated, another story would be played and the process repeated
- This story description / estimation process would continue until we were pretty happy we had the right amount of work for the iteration based on how many ideal days we thought we needed from the beginning of the meeting.

This process is very similar to what Martin Fowler describes here. Its not particularly precise, but we found it was good enough for our project to work, and at the same time meant that we weren't bogged down by process.

Related to our planning processes were our tracking processes. These were also kept simple, and were based solely on completed stories (i.e. completed and remaining stories per iteration).

Lesson number 3 is then:

Keep your planning processes lightweight, and adapt them to suit the team and the project

Permalink

Lessons from a Successful Agile Project Part 1

For the last 9 months I've been working as part of the best project I've experienced in my career so far. The project has successfully delivered into production 5 times in the space of a year, with only 2 production bugs (each of which were fixed and deployed in less than a day). The real customers are happy due to the successful delivery (and relatively low total cost), and so are the project team due to being able to deliver successfully while keeping a sustainable pace and good team spirit throughout.

So, what's been the secret of the team's success? As I roll off the project, I want to write down some of the reasons before I forget.

Great People

The core team is 14 people - 1 Project Manager (PM), 2 Business Analysts, 1 tester / admin and 10 developers (including 1 developer taking an iteration manager role). Everyone on the team has been top quality. The most important attributes throughout the team have been:

- Desire for team success over personal achievement
- Knowledge and acceptance of own abilities and limits
- Willingness to speak up
- Willingness to accept the team's decisions over personal choice

Individually, the PM is the best I've ever worked with. The way he has worked with the business (in areas such as expectation management) has been crucial to both the happiness of the business themselves, and the rest of the team.

Its interesting to note that even though there have been 10 developers thoughout, there has been considerable rotation of who the 10 people are. This has been possible due to the qualities above, and also because of practices like pair programming.

So lesson number 1 for a successful agile project:

Create a great team, and focus on getting an excellent project manager




Use Business Analysts as Customer Proxies

Having an on-team customer is a great idea since it means that developers can quickly get feedback for questions about how a story should be implemented, and also the customer can give early feedback for how a new feature is being developed. (Note I say 'on-team' rather than 'on-site' purposefully to show that the customer is part of the core team - a 'pig' rather than a 'chicken' in Scrum-speak.)

The problem with using a 'real' customer though is that 'real' customers also need to do 'real' work, and so there is a a conflict of interest between getting their 'real' work done and helping the team deliver the project. (This reminds me of the 'context switching' problems Tom DeMarco talks about in his book 'Slack'). There's other problems with using 'real' customers too, but this to me is the biggest.

So on our project we haven't had an on-team 'real' customer. Instead, we have 2 Business Analysts that act as 'customer proxies'. The BA's need to do (at least) the following:
- Talk with the customer groups to come up with a set of features
- Figure out how these features can be coalesced into a set of stories
- Communicate effectively with the developers to explain the problem domain, and the stories to be implemented
- Work with the customers to get early feedback (e.g. from UAT)

Having the BA's as part of our core team has allowed us to keep open and active channels of communication, enabling early and relevant feedback to issues.

Lesson number 2 then is:

Use a pair of on-team Business Analysts instead of on-site customers




These 2 areas have been about people, and team structure. I think they're the most important lessons I've learned from the project. In later entries I hope to talk about areas such as how planning worked, day-to-day team practices, and development practices.

Permalink

My XP 2004

A couple of weeks ago I was at XP 2004. Due to my goldfish-like memory I've already started forgetting what happened, but here's some things I do remember:

• It was good to meet new people, like Angela Martin, Rick Mugridge, Charlie Poole and the Exoftware folk


• It was good to catch up with people I've met before like Josh Kerievsky and hang out with my fellow Fowlbots Chris Stevenson, Chris Matts, Ivan Moore, Martin Fowler, Owen Rogers and Steve Freeman


• Hot Topic number 1 - the customer role (including a great panel.) Chris Matts has blogged a tonne about this so go read it!


• Hot Topic number 2 - acceptance tests. There's a still a huge amount of debate about what an acceptance test is, and how to implement them (e.g. Fit is not a panacea).


• Talked with Charlie (NUnit) and Owen (fellow CruiseControl.NET project lead) and others about .NET tools. We're going to work more on Mono compatibility if we get some time


• I presented my paper on Enterprise Continuous Integration. The demo I gave is available here, the paper is available here.

Permalink

Older entries can be found in the Entry Index