I would argue that the difference between a group of individuals and a team is the ability of the group to adapt to maintain its interests. For example, an amateur football team needs to adapt to the opposition’s tactics to try and win games and stay competitive. If they couldn’t do this effectively they’d probably lose all their games, get relegated and eventually get so fed up they’d disband and spend their weekends playing golf instead.

As we know from my last article, that ability to adapt is when self-organisation occurs and therefore we can say self-organisation is a key component of effective team dynamics.

Too big?

A significant factor in being able to self-organise is for the people who make up a group to be able to communicate & collaborate effectively and form the shared identity and shared goals which determine the group’s boundaries. This is one reason why agile proponents favour co-located teams and open plan offices, but there’s only so much that will help – 100 people working in the same office on the same project are going to struggle to maintain the types of quite intimate relationships which are required for self-organisation to emerge.

Too small?

Most attention seems to be focused on how large a group can become be before it starts to lose its ability to self-organise and work as a team, but I think it’s just as important to consider how small an effective team can be. If we look to sport we very rarely (if ever) see teams of less than 5 people and when we do it’s in sports such as rowing, where the complexity of the interactions between team members is low. When you only have 3 or 4 people in a team (as opposed to 10) the flexibility of the group to adapt to situations is limited by the  number of ways the group can organise itself.

For example, in a game of 3-a-side football (soccer) someone is invariably going to have to be responsible for guarding the goal to prevent the opposition just shooting from long range or provide some defence if one of the opposition breaks away whilst your team is attacking. This leaves the other two players little option but to pass it back and forth between each other, making it rather predictable for the opposition and frankly, not much of a spectator sport.

Adding one more person doubles the number of possible connections between the group. Adding two more almost quadruples it. As this is exponential the possible connections increases greatly with each new addition to the group, but this then comes back to how many people you can realistically maintain a relationship with within the boundaries of the group and the context of its environment, so clearly there’s a balance between the two.

Software teams

From what I can see the main objective of working in teams is for the whole to be greater than the sum of its parts. I’m not saying a “team” of 3 people won’t do a good job, but it will find it hard to behave like a team as it will struggle to reach and maintain the behaviours it needs to self-organise well – the limitations of the group become more acute. For example, when someone is on holiday or off sick it’s much harder to adapt to this and if you have junior or inexperienced people in the team you are very limited about how you can share work, as neither of them can work very well on their own or together.

Scrum proponents suggests the most effective size for software teams is between 5-9 people. Jeff Bezos introduced the concept of Two Pizza Teams – team’s are at the best size when comfortably fed by two large pizzas. In fact, doing a general search for optimum or effective team sizes finds that many people have come to a similar conclusion on the effectiveness of team sizes (see here and here)  - that the team only really becomes a team with around 5 members, but starts to degrade when you reach 9.

If a small team (e.g. 2-3 people) is your only option then it’s certainly no disaster, but if your decision was how to best organise a larger number of people into contextual groups then it may be better to aim for somewhere a bit higher as the overhead of managing all the small teams combined with the increased complexity of the communication networks between the teams and the risk of knowledge silos may well outweigh any perceived benefits.

- Principles Behind the Agile Manifesto

I’ve often had people say to me that we’re not really self-organising because we’re not all taking part in all the decisions made at our organisations, such as how the company is run or what products we should be making. This is a misunderstanding of how self-organisation occurs. The fact is we’re constantly self-organising, it’s just most of the time we’re completely oblivious to the fact it’s happening.

For example, within a group of people (such as a workplace) there are many social sub-groups, such as the early morning runners, the ones that go to lunch together and the after work drinkers. They all naturally self-organise around shared goals & desires. Even within a team where a highly autocratic management approach is in place, members of the team will self-organise around anything they can (such as making the tea or going out to buy some biscuits). The thing with self-organisation is it’s actually harder not to be doing it!

If you define self-organisation as when everyone in a team is able to control everything that affects it where do you stop? Your team? Your department? Organisation? City? Country? See where I’m going?

Self-organisation always occurs within boundaries defined by it’s context. For example, a football team might be a football pitch for 90 minutes, a group of friends on holiday the holiday villa they’re staying in or your department at work by the responsibilities it has.  Something or someone always sets these boundaries. If they did not exist self-organisation couldn’t occur.

What causes self-organisation?

A complex system* will always be vulnerable to external events which are outside of it’s control, such as the opposite team, the weather or your customers or stakeholders. Self-organisation emerges when it becomes important to respond to these uncontrollable events in a manner which benefits the system. The ability to do so results in the system being adaptive. We know that software development is complex so we can determine we’re in a complex adaptive system. It’s a huge subject and not the particular focus of this article so I won’t try to go into any more detail, but if it’s a new concept to you I strongly encourage you to investigate further.

How to take advantage of the fact that it occurs

When self-organisation is on your side it can be extremely valuable. If you’re working in a complex adaptive system it’s shown that by far the most effective way to allow that system to operate is to allow it to self-organise, because that’s what it will naturally try to do.

The problem is it’s not always on your side (if you’re an oppressive Arab dictator, for example) and will often work against your goals and objectives. I’ve often seen self-organisation criticised because this happens. I’ve also seen it criticised because a team is unable to self-organise effectively when allowed to do so. In both cases you may be tempted to blame the individuals in the team. This would be unjust because in reality it is the system to blame (and probably you as the controller of the system).

To enable self-organisation to work in your favour you need to understand and ideally define the system – set it’s boundaries and try to organise it in a manner which will encourage self-organisation to occur in a way which supports your objectives. This is often called Systems Thinking. Again this is a large and well documented subject so there’s no need for me to elaborate further (if you’re looking for a good place to start though I thoroughly recommend Jurgen Appelo‘s excellent book, Management 3.0).

*It’s widely held that software development in general exhibits the properties of being complex (as described in the Cynefin Model).

The Online Catalogue (OLC) project

Shortly after I started at Worldwide I was moved into a team doing a re-write of the Online Catalogue (now renamed BBC Wordwide Sales - essentially a sales device so broadcasters can find and view details on shows produced by the BBC they could purchase and broadcast on their own channels). It was the company’s first foray into Agile and both a great success and complete disaster.

It was a success because we were a great group of people being given the opportunity to determine how we wanted to work. We made many, many mistakes (inc. classics such as “done” being development complete i.e. not tested or released), but crucially we were learning and improving all the time.² It was an extremely empowering and motivating experience and created an incredible bond between the people in the team (although I don’t see them often I still consider many of them great friends today). The highly collaborative nature of the way we worked meant I learnt more in the first year than all of my career up to that point. The wonders of TDD, refactoring and pair programming were truly opened up to me. It wasn’t so much a jump as a giant leap. The news of our successes spread quickly and it wasn’t long before Agile software development was the de-facto approach.

No doubt you’re probably far more interested in why it was not a success and you’d be right to be (I learnt far more from what went wrong that what went well).

Crucially before development started a year had already been spent on analysis resulting in a use-case requirements document a good inch thick so we weren’t iterating on functionality, only incrementing in two weeks sprints (and knowing the audience I don’t think I need to explain further). Also the expectations on the project’s delivery were very optimistic. The combination of these two and the political and bureaucratic culture of the organisation meant failure was baked in from the start.

Shortly after development began it was evident it was going to take a lot longer than expected, but by that time the project had gathered too much momentum and too much money had been spent. At each management review the estimated completion date got longer and longer but each time no one was prepared to cut the scope or do the honourable thing and kill it. As is typical with death marches failure isn’t an option until it’s the only one left. The initial estimate was 3 months and the project was eventually completed 18 months (and well over a million pounds) later. The product itself? To it’s credit it was a much better engineered application than it’s predecessor and was a good foundation for future development, but in many ways it had less functionality than the product it was replacing.

The subsequent witch hunt was extremely unpleasant with the blame eventually being laid at the foot of the Lead Developer and Project Manager. Their estimates weren’t good enough. Fortunately our PM (who was actually excellent and by far the best I’ve ever worked with) had already left, which unfortunately meant the Lead Developer bore the brunt of it and his contract wasn’t renewed, which was undoubtedly a political gesture to higher management. There was no interest or barely any investigation into the root causes. When we did eventually do a project review the findings were filed away. It didn’t matter any more as blame had already been assigned and everyone had moved on.

I wouldn’t say we were completely without fault, there were many things within our power we would have done differently if in the same situation again, but I could say that about all the projects I’ve worked on since.

The community

Pete Camfield and Jason Gorman built a brilliant community, among other things introducing lunchtime sessions where they managed to get in many well known faces to do talks, but also encouraged us to do our own. I did my first ever presentation on “Test Smells” inspired by the xUnit book and have since presented at numerous conferences and events, something I can’t imagine I’d ever have had the courage to do without this opportunity. We also started a design patterns study group and a library (which I proudly curated).

Additionally the lead developers, coaches and some others (like myself) who were motivated to change things got together regularly to discuss how to do so (during the time I wrote an article which I think sums up the mood quite well).

Of course it’s no community without brilliant people, of which there were many (I daren’t name check for risking excluding or offending anyone).

Why I left

I think I’ve already alluded enough to the fact there were significant systemic issues with the organisation. I guess it’s somewhat inevitable (and not exclusive to BBCWW) that larger companies suffer somewhat from bureaucracy and the political environment that generates.

Most people I worked with were decent and just trying to do a good job, but the nature of the environment brought out the worst in people (in the same way buying a house in the UK seems turns everyone into cold-hearted monsters)³ and this went all the way up the chain. We were able to optimise the way we worked within teams but efforts to change things beyond this were exhausting and mostly futile. It was ultimately an environment which suited politically minded career types rather than people who wanted to make a difference. I eventually got too frustrated with banging my head against the ceiling.⁴

How it changed me

The combination of my experiences on the OLC project and the environment created by Pete and Jason changed me unrecognisably. I learnt that in an agile environment being a super brain developer (which I’ll never be) is really not that important. It matters far more if you give a shit and want to make things better. As my confidence in my abilities grew I became more vocal about what was wrong, at the beginning within our team, but soon (as most agile teams quickly realise) about what was wrong with the organisation which was causing many of our problems. Among other subjects my experiences on the OLC project inspired countless articles and conference sessions about (and a fascination with) estimation and predictability.

Most of all it showed me that, unlike my previous belief, most organisations are not ran very well, in fact they’re being run very badly, which means billions upon billions of pounds are increasingly and needlessly being wasted on software projects and thousands upon thousands of people are being stressed, frustrated and depressed by being involved in them. It showed me that there is a better way and that I get huge satisfaction from being involved in trying to improve that situation (well, at least not making it any worse).

Conclusion

Agile environments make people care. It means you’re much more exposed to your customers and stakeholders and spend a lot more time (than most people in your organisation) engaged in retrospecting and discussing problems. I’ve also noticed recently that people are much more critical on agile teams – something I thought was a bad sign but I’ve now realised the opposite is true⁵

It has it’s downsides of course. More emotional engagement means more emotional attachment. I ride the peaks and troughs a lot and find it difficult to switch off.

It’s not as much the project or organisation it makes me care about as much as the people I work with, it just makes it all more human.

Footnotes

¹ BBC Worldwide is the commercial arm of the BBC, a wholly owned subsidiary and quite separate from the publicly funded corporation (although all it’s profits go back to fund the BBC).

² Matt Wynne and I presented our experiences of evolving from Scrum to Lean at XPDay 2008. Here’s a write up and here’s the slides.

³ This kind of behaviour is well documented by complexity sciences but most famously by the Stanford Prison Experiment.

⁴ I’d like to think this doesn’t have to be the case. I think at least part of the problem at BBC Worldwide was it suffered from having too many long termers (10 years was quite normal) meaning people were quite protective of their positions or not keen to make any noise/get off their comfy chairs with the consequence the status quo was very difficult to change. Also, within the development team the ratio was weighted too far towards contractors than permanent staff (I was perm) with the result that people either didn’t care or weren’t around long enough to make it stick. I understand the IT department has recently been through a major overhall with many people having left via redundancy and new management at the top, so I doubt my experiences are still relevant, however I’ve not heard anything to say it’s improved either.

⁵ A recent experience report published by Benjamin Mitchell found that a team involved in a System’s Thinking based approach were the most motivated but also more critical (than other areas of the business) of how well they were satisfying customers.

In the short time I’ve been involved with the community I’ve seen almost no discussion or articles which involve any contribution from people outside of the IT department and none of the methodologies/name clouds I can think of appear to have been developed or evolved with any collaboration from the people driving the work.

I don’t mean to disparage all the hard work and enthusiasm people (I include myself) have put in to trying to make things better, I just think the fact that we’ve left out the most important people from our discussions has caused us a lot unecessary of pain.  Agile adoption is never a smooth affair, especially the process of “convincing” people outside of the development department. If we involved our customers more in the process of forming our principles, tools and methodologies we would surely get where we all want to be a lot more quickly. Remember, people don’t resist change, they resist being changed.

Here are some examples of what I mean:

• Speaking to my CEO in the pub the other day he said he often finds it “patronising” when we try and impress on him the importance of the the things we’re trying to do.
• When I first started with Scrum I countlessly came up against resistance and cynicism when trying to encourage customers to participate in traditional Scrum meetings such as retrospectives, planning and stand ups. Nothing Scrum teaches prepares you for this (I’ve done both CSM and Estimating and Planning courses and read a lot otherwise).
• The terminology we use (e.g. Scrum, Sprints, Stories, Kanban, eXtreme Programming) is totally immature in some people’s eyes.  One useful takeaway from the session was to stop using inappropriate terminology in front of customers.

I have an enormous amount of respect for our CEO and others within our organisation for putting the trust they do in us even though they (understandably) find so much of what we do beguiling and irritating. In my experience you would be very lucky to be able to work with someone who is prepared to take that kind of risk – in most places I’ve worked you just don’t stand a chance.

For me, the flaw lies deep within Agile. It was never designed to address the needs of customers. XP and Scrum were designed for fixing dysfunctional environments. The terminology was designed to appeal to developers. When most of the Agile principles and methodologies were developed the need was different and they don’t appear to have evolved. New methodologies suffer the same – why does there have to be an introductory guide to Kanban for Managers? If we’re having to try and sell this stuff to people I think we’ve already lost most of the battle.

In the last 15 years or so most of the “microeconomic” problems with software development have been solved. The majority of people writing software may still not be doing it well, but the answers are there if you care to look. The big problems are still out there though and as a community we need to start addressing them and I think the only way we can do this is by getting our customers more involved in the debate.

This post is really a rallying call to all those that feel the same as I do. I’m keen to start doing something about this, but where do we start?

*I use the term customer here to mean anyone who is a customer of a development team.

Experience often counts for little in software development. If you’ve spent your whole career in the same shop with little exposure to other languages or people outside your organisation it’s quite possible that some 21 year old upstart with a copy of Clean Code under his or her arm will wipe the floor with you when it comes to effectively writing and maintaining software.

Granted, working with good or even great developers will mean a lot will rub off on you. I’ve learnt countless lessons from the people I’ve worked with, but if I look around me people are no older than 30 at most with an average of around 5 years developing software in probably no more than 3 different organisations.

People like Martin Fowler, Eric Gamma, Kent Beck, Robert C Martin, Craig Larman and Michael Feathers have been at it for 25 years or more and in that time have slowly built up the kind of reputation you only get from regularly being right.

Also granted, blogs are are an invaluable resource, but are rarely little more then a meme in someone’s head and give you nothing like the deep contextual insight you can get from a well written book. There is also little to assure you that the author is anymore likely to have a better idea than yourself. Believe me when I say there are many people blogging who rarely live up to the practices they preach and are no more or less likely than you to know the right or wrong way of doing something.

I have learnt a lot from both colleagues and blogs, but both pale to what I’ve learnt from the books I’ve read. I can comfortably say there is no way I would be where I am today without them and I strongly believe it will earn you more money. When you think of all the things you could do to try and put more folding stuff in you’re back pocket it’s a relatively simple win!

I’ve been inspired to write this after reading Eric Evans Domain Driven Design which has gone right into my top 5 books of all time. Why is it so good? It’s not because Eric has necessarily been born with some supernatural instinct for writing great software or that Domain Driven Design is going to save the planet. It’s because it’s full of the lessons that Eric has learnt in his long and illustrious career, carefully woven into a highly readable narrative. There’s nothing particularly new here. Like all the great books I’ve read it is no more than a distillation of the practices in the industry which through time have proven to be the most effective. I remember Martin Fowler once saying that people often asked him what would be the future of software development. His answer was that to see the future you only have to look to the past.

Below is a list of the books which significantly changed the way I think and work more than any other’s I’ve read. No doubt you’ve heard of them all already and are on a list of books to read in the back of your mind somewhere and I’m sure there are plenty of others that had as significant an impact on people as these have on me. However I think few will argue that any of these books do not deserve their place on this list. All I can say is get on and read them if you haven’t already.

Refactoring: Improving the Design of Existing Code by Martin Fowler
Domain Driven Design: Tackling Conplexity in the Heart of Software by Eric Evans
Working Effectively with Legacy Code by Micheal Feathers
Agile Software Development: Principles, Patterns and Practices by Robert C Martin
Clean Code: A Handbook of Agile Software Crafstmanship by Robert C Martin
xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros
Lean Software Development by Mary and Tom Poppendieck
The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer by Jeffry LIker

*I am in no way professing to be a top class developer :)

Certainly not enough to be able to draw a clear line between the two and start comparing the benefits of one against the other. Daniel Jones, the author of The Machine That Changed the World did a keynote at XPDay2008 and said from what he saw there wasn’t really much difference, apart from the name. In fact, when they were looking for a name for Lean they thought about using Agile.

Agile came from Lean, the related processes came from people studying Demming, The Toyota Production System or through convergent evolution. The two guys who invented Scrum are Japanese and that’s no coincidence.  When I started reading about Toyota and Demming it all simply made sense to me and explained where Agile came from.

Then I found an article written by Craig Larman on the history of iterative development and that wrapped it up: http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf

There is no point spending any time discussing and trying to find differences between what is essentially the same thing just written in a different way.

It reminds me of how the Jews and Christians went their separate ways and then came the Muslims and then they split up into the Sunni and Shia’s. They’ve all been fighting bitterly for the last 2000 years but all worship the same god. Go figure!

Recently there’s been a lot of (and subsequently criticism of) debate on message boards and blogs about the relative benefits of one paradigm versus the other.  Personally I don’t care much for subscribing to any particular paradigm and am much more interested in what works and what doesn’t (and in which circumstances) so my response is to publish what my team and company is actually doing right now. This is a snapshot of our current practices. Ask me again in 6 months and hopefully I’ll show you something very different.

The inspiration and influences for the way we work mostly come from Agile, Scrum, Extreme Programming, Software Craftsmanship, Lean, Lean Software Development, Kanban Software Development and The Toyota Way. It is all and none of these things.

Context

We are a small to medium size “start up” organisation working in the new media industry. The company employs around 60 people mainly based in the UK. The development department numbers around 20 co-located people. Agile practices are a relatively new introduction and the previous approach was of the typically chaotic type familiar to young businesses.  We mainly work in .Net using C# but also dabble in Ruby, Javascript and UI languages. The rest of the article mostly relates specifically to one of the teams working within the department but also addresses some of the practices of the department as a whole.

Team

The team is made up of 4-5 developers and a tester. There is no project manager at the team level – in the spirit of self-organisation (principle 11) the duties traditionally the responsibility of a PM are shared between the team members. The Product Owner role is shared between the stakeholders within the organisation for the products the team is responsible for.

Iterations

We currently work in 1 week Iterations. It’s a new team who are also new to many of the agile concepts and doing this enables us to control the amount of work in progress, focus on delivery, improve our discipline and most importantly have short feedback cycles so improvements can be discussed and applied frequently. The downside is the overhead created by the amount of meetings. Once we’re comfortable the team is working well together we will have the opportunity to change this if desired (e.g. Continuous Flow, changing the iteration length, changing the frequency of meetings).

Meetings

Each iteration we have the following meetings:

Work Prioritisation – occurs iteration minus one. Stakeholders come together to raise and prioritise work not yet commited to.
Requirements Gathering – occurs ad hoc when necessary. All the team is required to attend along with the customer/s to bash out requirements for work prioritised in the prioritisation meeting.
Planning – occurs at the beggining of the iteration. Prioritised features (MMFs) which have been analysed are broken down into stories, discussed, estimated and commited to based on our current velocity (avg. over last 6 weeks)
Stand Up – occurs daily at 10am at the task board. Anyone outside the team is welcome to watch
Retrospective – occurs at the end of the iteration. Any actions from the meeting are to be completed by the end of the next iteration.

Requirements

Features are requested at the prioritisation session and use the User Story format.

More detailed requirements are gathered during the requirements meetings mentioned above, with the customer/s and all team members present. We use whiteboards to bash out the requirements and convert them into acceptance criteria using the “Given, When, Then” format. We have a rule that no work can be commited to unless we’re happy we have a clear understanding of the requirements.

Task Board

The task board is essentially a Kanban board with each stage of the delivery process separated into columns. We have an implicit limit of 2 stories in active, but otherwise have not applied limits to any other columns. Features (MMF) are blue, the stories which make up the MMFs are yellow, bugs are pink and quick support tasks white. When a story is commited to, the feature card is moved into “commited”, above the titles of the columns and tracks the last related story.

Measurement & Metrics

We use an Excel spreadsheet to hold the product backlog and track the data from the Kanban/Task board. Whenever an MMF moves to another column the date this occured is recorded. You can download a copy of the spreadsheet here (you may want to check the calcs on the CFD, not sure they’re right). Among other things it calculates average cycle time, average velocity and projections based on velocity. I’ve tried a few bespoke tracking tools (such as Mingle) and found nothing is as powerful and flexible as Excel.

We have a manual Cumulative Flow Diagram (CFD) which each team member takes turns to update daily so everyone shares the responsibility (it is also their job to update the Excel spreadsheet each day). The CFD diagram only tracks the value delivered to the business (one unit = one MMF. Measure the output, not the input) and is also represented in the Excel spreadsheet. Why have both you may ask? Visibility.

We have some rudamentry code metrics set up through our continuous integration framework such as NDepend output and test coverage but are working towards something more visible and useful.

Estimation

Still very much a necessary evil.

For comitting to work for an iteration we use Story Points using the fibonacci (1, 2, 3, 5, 8…) sequence and achieve them by playing Planning Poker with everyone who may be involved in the work required to take part. We will only estimate (and commit to) work we have already analysed and gathered requirements for.

For longer term planning, as we don’t yet have enough information to be able to use cycle time for projecting work completion, using the velocity based on points completed per iteration has proven a very powerful toool to be able to give the rest of the business a better idea of our capacity and timescales (previously they had none). However this has well known drawbacks and we must be careful it does not get abused, as I have seen before (such as gaming of estimates, whether intentionally on subconsciously). Also, as we need to understand and have gathered the requirements to be able estimate this way it means there is very limited scope to how far into the future we can do this with any degree of confidence (as requirements will change). Once we have a reasonable amount of data in the system we will be able to use average cycle time, which will be much more powerful.

Coding Practices

Apart from the rules we’ve commited to as a team, Pair Programming, Unit Testing, Refactoring and the best working principles and practices of the software industry are encouraged from the top of the department and applied rigorously but pragmatically.

At the request of the department members (as a result of a disucssion on collective responsibility) we created a development standards document which includes topics such as naming conventions and testing. As much as possible the document is vague on implementation details to prevent it from holding us back when better working practices come along. We use shared Resharper and Visual Studio settings to help us keep to these standards.

As mentioned below we also frequently hold sessions to improve our skills.

Automated Testing

All new or modified code is covered by unit tests, integration tests (such as database interaction) and automated acceptance tests which test against the acceptance criteria (this last one is quite new territory).

Continuous Integration and Deployment

All projects are under continuous integration (we use TeamCity) and we are working towards having all deployments doing the same. We have monitors on the wall which show all the currently failing builds. Do I need to mention we use source control?

Roles and Responsibilities

Every role in the department is covered by a document explaining their roles and responsibilities. They are written in a way which encourages self-organisation and collective responsiblity. You can download them here. I will be talking about these descriptions more in a future article.

Learning Culture

Each week two hours are set aside for learning sessions such as coding dojos and presentations (we’re currently running a design patterns study group). Outside of these developers are actively encouraged to take the time to learn new practices during working hours (within reason). We have a library of books available on a range of subjects which are at the disposal of everyone. More often than not if there’s a book that someone would like to read the company will purchase it and add it to the library (books are pretty cheap in the grand scheme of things).

Continuous Improvement

Outside of retrospectives we have a monthly departmental session where the most pressing problems are discussed and actions taken away. However there is no limit or retriction to when improvements can be made and everyone is encouraged to take the initiative when they see a problem that needs addressing.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

The Five Principles of Lean

1. Value – specify what creates value from the customer’s perspective.
2. The value stream – identify all the steps along the process chain.
3. Flow – make the value process flow.
4. Pull – make only what is needed by the customer (short term response to the customer’s rate of demand).
5. Perfection – strive for perfection by continually attempting to produce exactly what the customer wants.

The Seven Principles of Lean Software Development

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

I. Having a long-term philosophy that drives a long-term approach to building a learning organization

1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals

II. The right process will produce the right results

2. Create a continuous process flow to bring problems to the surface

3. Use “pull” systems to avoid overproduction

4. Level out the workload (heijunka). (Work like the tortoise, not the hare)

5. Build a culture of stopping to fix problems, to get quality right the first time

6. Standardized tasks and processes are the foundation for continuous improvement and employee empowerment

7. Use visual control so no problems are hidden

8. Use only reliable, thoroughly tested technology that serves your people and processes

III. Add value to the organization by developing its people and partners

9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others

10. Develop exceptional people and teams who follow your company’s philosophy

11. Respect your extended network of partners and suppliers by challenging them and helping them improve

IV. Continuously solving root problems to drive organizational learning

12. Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu).

13. Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly (Nemawashi).

14. Become a learning organization through relentless reflection (hansei) and continuous improvement (Кaizen).

• No multi-tasking
• All new or changed code must be thoroughly unit tested
• No more than 2 pieces of work in “Active Work” at any time (our team is 3 developers)
• We always work on the highest priority task
• Our definition of done is “In UAT”
• Leave it in a better condition than you found it
• No hidden work
• No overtime
• No disruptions
• Don’t SysTest your own work (we don’t have a tester yet)

Firstly, if you haven’t read it, I’d highly recommend Agile Retrospectives: Making Good Teams Great by Darby, Larsen & Schwaber. A great introduction to retrospectives with a lot of plans and ideas to help you out (although I have to say I find many of them too long for my liking).

However, beyond that book there really isn’t much else available so I’ve started a wiki to collect retrospective resources. Without further ado I’m delighted to announce:

The Agile Retrospective Resource Wiki or http://retrospectivewiki.org

A plea for contributors

Everything else you need to know is on the wiki, but I would like to take this opportunity make a plea for contributors. The content is currently a bit limited as I’m the only contributor so far so if you’ve got any cool retrospective plans, tips, tricks or anything else please add them.

Along with Matt Wynne I’ll be running the Retrospective Surgery session mentioned on the wiki at SPA2009 next week so I expect we’ll be getting some juicy new content imminently.