Agile Software Development

Pair Programming

noreply@blogger.com (Simon) — Tue, 7 Aug 2007 07:06:00 +0100

In PairProgrammingMisconceptions Martin Fowler makes some very good points and I agree with everything that he writes. However, I think that there is an important point that he has not mentioned: what are the alternatives?

In traditional software engineering projects, there has been widespread use of peer review (design reviews, code inspections, code walkthroughs etc.) as a means of improving code quality. Pair Programming provides a more efficient means of reviewing both design decisions and code.

Over the last few years I've noticed a tendency in many organisations to dispense with code reviews without replacing them with anything, let alone pair programming. If developers don't think that anyone else will have to read their code, code quality in terms of defect density and ease of maintenance will suffer.

Is the Toyota Production System Responsible for Toyota's Success?

noreply@blogger.com (Simon) — Sat, 9 Jun 2007 13:28:00 +0100

In April of this year it was announced that Toyota had overtaken General Motors as the largest manufacturer of automobiles in the world in terms of vehicles sold. It seems that they will maintain this lead for some time to come. Interesting, a Toyota representative played down the achievement stating that they were focussed on meeting customer needs rather than winning a race.

The Toyota Production System and the Toyota Development System, initially developed in the 1940s and 1950s and publicized in the west in the 70s and 80s, were primary inspirations for the Lean and Agile movements. So is "The Toyota Way" responsible for Toyota's success? According to a report that I overheard on BBC World Service Radio, yes, at least partially. They mentioned the Toyota Production System and stated that it is now used by most automobile manufacturers. Maybe the superficial details of the production system itself are even used by GM, but the Toyota Production System is based on much more which, according to anecdotes that I have heard, has not been adopted by GM.

The Toyota way is based on respect for their workers and embodies important principles such as self-organisation and adaptive processes that are so important when managing complex systems. It also applies the principle of eliminating waste, so if, for example, a machine needs to be moved to enable a team to do its job better, it will happen without jumping through hoops.

All of this does not sit comfortably with a prescriptive command and control approach, yet many Western organisations remain tied to such practices. In many cases, particularly when there is a crisis, the instinct of Western organisations (including governments) is to add additional controls to their processes (in the form of rules, laws etc.). This is often the opposite of what is required - give people the resources that they need, make them feel that they are truly valued and respected and they will deliver the results.

TDD Workshop

noreply@blogger.com (Simon) — Thu, 7 Jun 2007 09:42:00 +0100

I recently led a test-driven development (TDD) workshop for the team that I am currently coaching. We've been working together for several Sprints (every Sprint bar none has resulted in valuable functionality that has been put into production). We've previously looked at unit tests in detail and I had made a strong recommendation to try to write the tests before the code under test. Over the last couple of Sprints, the quantity and quality of unit tests in the product has increased dramatically.

One of the outcomes of our last retrospective was that the team requested that we revisit the area, this time focusing on TDD. So I scheduled a couple of hours for a workshop.

I kicked the workshop off with a few slides to explain the philosophy behind TDD, explaining that TDD is not just about testing (or even mainly about testing) but has a great deal to do with design and documenting what services the code provides. I found a quote from Bob Martin that I really like:

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function”.

The introduction led to an extensive discussion about the pros and cons of TDD. In this type of situation, I'm not looking to convince people that a particular technique is valuable (you can't make people believe in something) but to get them to try it out and then reflect on whether it works for them and the team.

I fired up Eclipse and went through some examples (based on material from Frank Westphal's excellent book Testgetriebene Entwicklung mit JUnit und FIT).

By the end of the workshop, everyone had agreed to give TDD a try in the current Sprint. As normal, we'll reflect on our experiences at our end of Sprint retrospective.

Second Talk on Agile at CDTM

noreply@blogger.com (Simon) — Thu, 7 Jun 2007 09:42:00 +0100

I was recently invited to do another talk on agile methods at the Center for Digital Technology and Management in Munich, Germany.

This time, the talk covered the following areas:

user stories
agile estimating and planning

After examining some of the characteristics of good user stories, the students practiced writing some (with "As a ..., I want ..., so that ..." clauses and acceptance tests on the back).

We then used the planning poker technique to estimate some user stories for the team's first Sprint.

Once gain, thanks very much to Ana Balevic for organising and hosting the talk and to the students for some interesting questions and discussion.

Talk on Scrum and SOA at the CDTM in Munich

noreply@blogger.com (Simon) — Sat, 26 May 2007 08:36:00 +0100

I was recently invited to talk about Scrum and SOA at the Center for Digital Technology and Management in Munich, Germany. The CDTM is a partnership between two Munich universities and cooperates closely with industry. It's aim is to "prepare the students for future leadership positions in their professional career."

The talk was provided as a part of a course that introduces students to an agile approach to SOA development. During the course, real functionality will be developed and demonstrated to industry partners.

The talk covered the following areas:

What is agile?
Why do we do agile software development (what are the issues with traditional methods and how does agile make it better in many cases)?
The agile manifesto, key values, principles and practices.
Key success factors and pitfalls for agile projects.
An introduction to Scrum.
The Dysfunctional Scrum exercise.
Case studies - different ways of approaching building an SOA-based system using Scrum, based on my experience coaching different projects and teams.

Thanks very much to Ana Balevic for organising and hosting the talk and to the students for some very interesting questions and discussion.

Scrum auf Deutsch

noreply@blogger.com (Simon) — Fri, 26 Jan 2007 18:39:00 GMT

We've translated Mike Cohn's re-distributable "Introduction to Scrum" into German. You can get it here. It's licensed using the Creative Commons Attribution-NonCommercial-ShareAlike License. Please let us know if you make improvements.

Planning Poker

noreply@blogger.com (Simon) — Thu, 25 Jan 2007 13:42:00 GMT

Planning Poker
Originally uploaded by sjroberts.

The estimates are starting to converge but there are still some significant differences. The participants are discussing the high and low estimates.

noreply@blogger.com (Simon) — Fri, 19 Jan 2007 16:32:00 GMT

It's the end of the first week with a new client in Munich. Despite the storm on Thursday (didn't impact Munich too much apart from the S-Bahn being suspended from 20:00 on Thursday night) we've made some great progress.

I've tried to do a lot of listening this week and have taken part in several meetings as an observer. Some of the other activities this week have included:

Team formation. The pilot project will be reasonably large with in excess of 10 active team members. My recommendation has been to split this team into 2 Scrum teams, each of which sits together and tackles vertical slices of functionality based initially on particular functional areas. This recommendation has been, in principle, taken on board. We're still sorting out some of the seating arrangements.
Training workshops. We've identified three days of training to which the team members will be invited. The first of these, focussing on agile values and principles took place on Thursday. Unfortunately, the exercise that I usually like new agile inductees to do on the first day (based on the well-known XP Game), had to be abandoned due to the storm warning. We captured lots of useful insight into some of the key issues that will be encountered as this client tries to introduce agile methods. I'll be maintaining a log of these issues and tracking how we address them. The next workshop will on Friday next week when we'll be taking a closer look at Scrum and User Stories and putting the theory into practice with a fun exercise.
Product backlog. We've started to create the product backlog. Today I facilitated a User Story writing workshop for one of the functional areas. This had real customer involvement and produced some really useful results. It went quite slowly but definitely a good start and subsequent workshops will get faster.

Other Munich observations:

I last worked in Munich in 1993. Either it's changed a lot or I have, or perhaps we both have. It seems much more open and more multi-cultural and a more comfortable place to be. I feel good here.
I've been staying in the Derag Max Emmanuel Hotel in the Munich area Haidhausen. My room is effectively a small apartment with its own mini-kitchen and even a small terrace. Very good value (80 Euro a night), clean and comfortable - recommended. I found the hotel through ratestogo.com. All other web sites that I tried when looking for accommodation had very limited availability due to the Bau 2007 trade fair that has been taking place this week. The web site was uncomplicated, they have a fair cancellation policy and they had accommodation available when others didn't - also recommended.

noreply@blogger.com (Simon) — Tue, 16 Jan 2007 09:29:00 GMT

Monday was the first full day with my new customer in Munich. I'm going to be here on and off for the next 5 to 6 months helping a part of a large organisation transition to agile methods. It's looking really interesting. Although this is going to be a challenging assignment (most agile transitions are!), there seems to be a genuine desire to give things a try. I have the feeling that we (that is the team including myself) are going to be able to make considerable improvements over their current process (by taking baby steps) and have a lot of fun at the same time.

Agile Day in Munich

noreply@blogger.com (Simon) — Wed, 13 Dec 2006 14:19:00 GMT

I'm in Munich again visiting my major new agile enablement client. Today we discussed the most likely candidate for a pilot project, the makeup of the team (4 developers, 1 tester, the customer, the ScrumMaster and myself as coach and mentor) and Sprint 0 activities. These will include training the team, establishing the development and test environment and preparation of the initial product backlog etc.

Over the next few months, we're going to have to solve some tough issues concerning how to integrate the agile team into the wider organisation. Today showed that key people are really committed to making this a success and I'm very much looking forward to working with this team. Sprint 0 will kick-off in January.

As part of this engagement, I'll be facilitating a Scrum quick start, something that I've facilitated for several teams recently. This combination of customised training and facilitation is a very effective means for helping a Scrum team go from zero to starting their first Sprint, and hence starting to deliver business value, within days. I'm combining the quick start with ongoing coaching and mentoring which means that I'm there to support the team and other stakeholders when needed. I have some capacity free - please contact me if interested.

Technorati Tags:
agile, scrum, Scrum quick start

New agile projects in the UK and Germany

noreply@blogger.com (Simon) — Mon, 4 Dec 2006 18:55:00 GMT

The demand for agile method consultancy seems to be growing. I've secured two new clients during the last two weeks: one in Stevenage, UK and the other one in Munich, Germany.

This week I'm with the UK client, doing a Scrum Quick Start. Last week I introduced agile to some of the key stakeholders. Today, I've taught Scrum to the project team (two sessions of about 15 people each, with a mixture of business and developers). Definitely a good bunch of people and I think that they have an excellent chance of making this a success.

Tomorrow, I'll be facilitating their first Sprint planning meetings and on Wednesday the teams will be starting their first Sprint. A Scrum of Scrums approach will be used to help coordinate the activities of the four Scrum teams. I'll be supporting the teams with regular visits over the next few weeks. It should be an interesting engagement.

I'm also gearing up for my Munich engagement. Over several months I'll be helping a household name select a pilot project and then transition to agile (again Scrum based).

The Dysfunctional Scrum: An Exercise in the Management of Scrum Smells

noreply@blogger.com (Simon) — Tue, 21 Nov 2006 18:41:00 GMT

The Dysfunctional Scrum exercise normally goes down very well as part of agile training. It's great fun but, more importantly, lets participants experience the World’s worst Daily Scrum. The exercise can lead to a useful discussion on how to deal with common Scrum smells.

Agile Mythology

noreply@blogger.com (Simon) — Mon, 25 Sep 2006 16:39:00 +0100

Overheard at an interview for a business analyst with agile experience:

"Yes I've got lots of experience using RUMP and the Agile Mythology"

RadRails 0.6 Released

noreply@blogger.com (Simon) — Fri, 17 Mar 2006 17:11:00 GMT

RadRails - A Ruby on Rails IDE

"Finally, RadRails 0.6 is out! This release includes a lot of refactoring and quality improvements under the covers as well as some nifty new features. The details can be found in the changelog."

I'm currently using RadRails instead of TextMate for most of my playing around with RubyOnRails. Well worth taking a look at IMHO. It's fast, free and fun!

0.6 has some useful convenience features such as easy switching between related controllers and views. I'm looking forward to 0.7 which is due to have debugger support.

technorati tags: ruby, rails, rubyonrails, radrails,

HP gets 3.4x productivity gain from Agile Management techniques

noreply@blogger.com (Simon) — Fri, 17 Mar 2006 10:42:00 GMT

HP gets 3.4x productivity gain from Agile Management techniques: "... - a reduction in lead (cycle) time from 9 months to only 2 months. Printer firmware development at HP was never this good. Imagine what this means for the people. They now go home early on Friday afternoons, they don't work overtime, they have rediscovered their social lives, their families and their passions."

(Via Robert Scoble.)

James Gosling on PHP, Ruby and C# vs. Java

noreply@blogger.com (Simon) — Sat, 11 Mar 2006 14:09:00 GMT

James Gosling: "Java Is Under No Serious Threat From PHP, Ruby or C#"

"There have been a number of language coming up lately,' noted James Gosling today at Sun's World Wide Education & Research Conference in New York City. 'PHP and Ruby are perfectly fine systems but they are scripting languages and get their power through specialization: they just generate web pages. But none of them attempt any serious breadth in the application domain and they both have really serious scaling and performance problems.' He then dismissed C# as having had potential, but no longer: 'We were afraid [Microsoft] were going to do something really creative - but they're hopelessly focused on one platform."

I've been a Java advocate for a long time but I really think that James has missed the point, particularly with Ruby. Ruby is actually a good general purpose language which potentially goes beyond the creation of the small to moderate scale web based systems that Rails is currently targetting. If James is referring to Ruby on Rails then I can agree with him to an extent. Rails is a framework applicable to a limited class of application areas right now, albeit in a particularly elegant way. In time, other Ruby based frameworks, possibly as extensions to Rails or as separate frameworks will address other classes of application.

technorati tags: ruby, C#, java, rubyonrails

Agile SOA?

noreply@blogger.com (Simon) — Fri, 10 Mar 2006 19:51:00 GMT

Benefits of SOA

It seems that everyone is talking about Service Oriented Architecture (SOA). All sorts of benefits are claimed for SOA, including:

Cost savings by increasing reuse. The idea is that common services can be created and then reused whenever this type of service is required within the enterprise. Typical examples include a common authentication service and a common payment service. Those who have been involved in software development for a while will recognise that this was one of the objectives of object oriented technology. Object technology has a good record for achieving reuse within projects or systems but a bad record for achieving inter-project reuse.
Cost savings by reducing the skill required to develop enterprise applications. If a palette of ready built common services is available, maybe they can be wired together by less highly skilled developers or even directly by business people?
An increasing number of vendors of commercial off-the-shelf (COTS) products already have SOA or have stated that they will have SOA in the future. Maybe it will be easier to integrate these products with each other and with custom developed services?

I would suggest that the jury is still out on whether or not these benefits are actually realised in practice.

Isn't agile software development supposed to deliver some of these benefits anyway?

Agile software development directly addresses reuse in an even stronger manner than a non-agile object oriented approach. Agile takes a rigorous approach to avoiding duplication in code. This typically applies not only to the version of a system that is currently under development but also to future systems, built on its basis.

Agilists tend to frown upon a large amount of architecture and design work being done up front, instead regarding design as something that is part of what software developers do every day and architecture as an emergent property of a system. At first sight, this might seem to preclude the development of an SOA based system, which surely requires considerable up-front and architecture and design work? Well, as we will see later, maybe the two are not as incompatible as they might first appear.

Agile doesn't directly address the remaining supposed benefits of SOA. Is it possible to combine agile and SOA to create a best of both worlds approach? Well, the answer is a qualified maybe. Here are some possible approaches:

Strategies for agile SOA

Design an initial service model up-front. Do a small amount of design up-front to define the service architecture (including means of communication between components) and an initial partitioning of the problem space into services. Build the software using an agile approach, in business scenario focussed vertical slices, adding code to the appropriate service as you go. When necessary, introduce new services or remove ones which didn't pan out. Use a "do the simplest possible thing that works" followed by aggressive refactoring approach, to keep the flow of business functionality coming whilst still preserving the integrity of the SOA.
Let a service model emerge. Do virtually no design up front, except to decide upon an outline architecture, including the the means of communication between components. Develop potential shippable system increments based on vertical slices of functionality. Periodically refactor the functionality that has been developed into services.

A case study

I was recently hired to agile enable a new strategic programme for a UK based company. The company concerned was insistent that a services based approach should be adopted. They provide a large range of services, most of which have overlapping functionality. They had previously expended a large amount of effort reinventing existing functionality, in some cases, several times. Business leaders in the company perceived that the development team was taking too long to respond to the market by releasing new systems. The development team was frustrated by continual drip-feed of requirements and by the apparent low esteem in which they were sometimes held by the business side of the company. All of this adds up to a classic case for agile. I was hired by the development manager who had been convinced by senior technical people to give agile a try. To add to the mix, the company wished to outsource the development of the service layer. The internal development team would handle an orchestration layer and the user interface. Strategy 1, identified above, was broadly adopted, as follows:

Pre-iterations. Four two-week iterations were used before the main software construction iterations, during which:

A service design was created, which identified the main common services that should be developed, the major system compoents and the means by which they should communicate.
Interface definitions for the major services were developed as Java interfaces.
An existing proof-of-concept system, originally conceived as a "spike" was brought up to production quality by judicious refactoring to fit in with the service model and the addition of appropriate automated acceptance and unit test cases. Agile purists may flinch at this, suggesting the PoC should have been scrapped but I usually find that a pragmatic approach to issues like this avoids alientating clients!

Release and iteration planning. During release and iteration planning, both the internal (presentation and orchestration layers) and external (services) teams were present. Since the external team was actually offshore, the majority of the team were present virtually using video conferencing. However, representatives of the external team were also present in person.
User story based vertical slices. When planning, the customer presented vertical slices of functionality using user stories - several weeks of coaching prior to the first planning meeting, included a number of dry runs during which the customers practiced writing stories, drawing heavily on Mike Cohn's story writing material. The internal and external teams then estimated the work necessary to implement their part of each story separately. This resulted in most stories needing to be split. Since delivery of the functionality described by the story required both teams to complete their part of the story, particular attention was placed on synchronising the outputs of the teams when release planning.

Observations

The approach taken has certainly worked and the organisation now has a number of well implemented services available and end user systems based on these services are online. However, progress has been slower than would be expected from a pure agile approach. Some of this can be put down to the initial inexperience of the teams involved but the majority of it is likely to be due to the contraints imposed by the service approach. The requirement for the two teams to coordinate their activites around the service interfaces is less efficient in creating business functionality than a purer agile approach would have resulted in.

An emergent approach to SOA

A pure agile approach implies an almost completely emergent approach to architecture and design and would make the development of SOA based systems practically impossible.

SOA as currently applied by many organisations includes a large amount of up-front architecture and design and is traditionally seen as a largely deliberate approach. As agile practitioners we know that this is best avoided, particularly because it limits our ability to respond to change.

A reasonable compromise is to do some up-front architecture and design by developing the service model and interfaces. This can be usually achieved as part of "iteration 0" activities. The result will perhaps not be the best of both worlds but will deliver the major benefits of both agile and SOA.

Just as it is now acccepted business wisdom that a combination of deliberate and emergent approaches to stragegy is most effective, a combined deliberate/emergent approach to agile SOA is likely to deliver effective results.

technorati tags: agile, soa

Personality preference and agile software development

noreply@blogger.com (Simon) — Mon, 20 Sep 2004 21:20:00 +0100

Over the last few years I've become increasingly interested in the relationship between various aspects of personality and how comfortable people are with an agile approach. For example, there seems to be quite good correlation between people's MBTI and how well they cope with agility.

In terms of the MBTI (Myers-Briggs Type Indicator), strong Js (judging) are, in my experience, likely to be very unhappy with the late closure and uncertainty that XP requires. Ps (perceiving) on the other hand, are much more comfortable with XP (they are comfortable moving into action without a plan and planning on-the-go). I used to be very sceptical about MBTI (and other psychometric tests) but it seems to fit so well in a lot of cases. Of course, there are exceptions (I have read that Kent is an ENTJ) and we all have coping strategies for operating in our non-preferred modes. A team composed of purely strong Ps would present its own problems - they would tend to avoid making any sort of commitment.