Thursday, July 27, 2006

Lie About Quality

Quality is the Constant

The controls you have over a project are scope, time, resource and quality. XP teaches us never to use quality as a control, it should always be 100%. However, I've recently noticed a strange phenomenon: the business is scared of quality. I try to say that we will deliver a high quality product, and the response is unexpected. That sounds expensive - can't you just throw something together quickly? At this point, I consider whether to talk about maintenance costs and total cost of ownership, but think better of it. Why do the business want a low quality solution? Its because they perceieve this to be cheaper and quicker to develop. But we know that with XP we can produce quality software very quickly. However, this is very difficult to communicate to the business sponsor. What to do?

A Novel Strategy

It seems a strange approach, but I can only see one way to overcome this problem. Lie. Pretend that you are throwing together a solution of questionable quality in order to meet the deadline. Sell it as Rapid Incremental Delivery of a prototype, RAD, JFDI, whatever. However, behind the scenes put in place all the elements of XP: Continuous Integration, TDD, Automated Acceptance Testing, Stories, Iterations, Release Planning, Pair Programming. Just don't tell anyone. They will get their solution rapidly and they will get incremental delivery of features. However, when they change their minds about the fact that this is a temporary solution, and leave it in live for 3 years, you will be confident of its quality and won't get bitten by a hidden maintenance cost. When you are asked to enhance the solution in a few months time, you will be able to do this in confidence, as you will have good test coverage.

Agile Architecture

Architecture doesn't have to suffer either. As long as you map out the architectural components of the system and assign them their responsibilities, data and interfaces, then you can implement them in the most minimal way possible - even to the extent of a manual process. As long as the system boundaries are well defined, you can fulfill the architectural component's responsibilities however you see fit. However, follow the same principle of lying to the business. If a quality system scares them, just wait for the reaction when you tell them you are going to build a system that adheres to architectural guidelines. That sounds very expensive. Can't you just throw something together - we could make it comply to architecture later...? Pretend you are breaking every architectural rule in the book in order to get the solution out quickly and cheaply, but quietly make sure that the architecture is well defined and adhered to. It doesn't take long to create a good architecture and build high quality systems, just don't tell anyone...

Monday, July 24, 2006

Conceptual Thinking


Over the past few months, I have noticed that people, and their approach to solving problems, can be broadly split into two groups. The first group adopt a Concept Driven approach, where they first visualise the logical solution to the problem, without constraints. The second group take what they have today as the starting point.

Two Different Approaches

People naturally fall into one of the following approaches when faced with a problem to solve:-

Concept Driven Approach

In response to a problem, this group initially form a high level, conceptual idea of how the solution should work. Then they look at the best way of implementing this model without making too many compromises. Once the logical structure, division of responsibilities, interfaces and patterns are defined, the next step is to see how much reuse can be achieved whilst adhering to this conceptual model.

Linear, Incremental Approach

In response to a problem, this second group look immediately to what they already have available. Once they find something that appears to do something similar, they try to extend or modify it to satisfy the requirements.


To illustrate these differing approaches, I will return to my favorite analogy: building a car. If a designer pens a beautiful concept car, and the car company decides that they need a car like this in their range, there are two approaches they could take. They could build the basics of the new concept, for example the bodyshell, and then use their parts bin to put in a standard, pre-existing drivetrain, engine and suspension. This approach would retain a purity of concept whilst achieving high reuse of proven components. The other approach would be to find the car in their range that looks the most like the concept car, and try and re-engineer it to fit this new concept. The likely outcome of this approach would be a dilution of the concept and a multitude of compromises.


I think that it is extremely important to work from a clear concept, and then deal with the specifics of implementation later. Taking what you have and changing it in a linear and incremental way in response to various different requirements will confuse the architecture of the system, involve complicated rework and result in a confused, complex solution.

Sunday, July 09, 2006

The Dyson Design Philosophy

The Dyson Design Philosophy

Design isn't just about how something looks, but how it works. I don't see a difference between a designer and an engineer. A designer should be both. They should be building, testing and using the product, making it work better. James Dyson

This philosophy, when applied to vacuum cleaners, created a fresh product that was technically better, had a more contemporary, fashionable design and was also more user friendly. These product features were totally integrated, they depended on each other for the overall package. You couldn't design how the product should look, and then throw it over the fence to the engineers. It was an integrated, iterative process that incorporated all the aspects of design and engineering to create a successful product. The fashionable look came from the engineering possibilities discovered by the engineers as much as it was created by the designers. This philosophy is directly applicable to the problem of web application design and development.

The Four Box Model

If you don't mind over-simplification, you can divide most people involved in the creation of a web application into four basic areas, or boxes.

  1. Creative

  2. Web Designers

  3. Internet Developers

  4. Back End Service Developers

People rarely fit neatly into one of these boxes, but you can usually position somebody primarily in one box with an appreciation of adjoining boxes. For example, a web designer, as well as being an expert in XHTML, CSS, JavaScript, cross browser compatibility and accessibility, will probably have a good grounding in User Interface Design, and have some artistic ability and PhotoShop skills.

The Creative Silo

I have found that the first stages of a project are usually dominated by the Creative box with no input from Box 2. Ideas people in Marketing get together with artists and interaction designers. Sample customers are given pictures or Flash demos of various page options to make decisions on how a page should look. Interaction designs and specs are produced, and the artwork commissioned. Only after this lengthy process is completed do the Box 2 Web Designers get involved. Even though they might have really valuable input into the design and the way that the whole application might work, it is already too late in the process for them to have an influence.

Thursday, July 06, 2006

Agile Case Study: Living the Dream...

Implementing Agile

Given my revelation about how Agile should be run without compromises and in a Lean and lightweight manner, I'm trying to run my current project in this way and seeing what gets in the way. I'm expecting the organisation, its culture or its people to put lots of blockers in the way, so I'm going to document how it goes in this article. But lets not start off with a negative attitude.


I'm kicking off the project with a Story-writing Workshop. I'm getting everyone who has a say in the project into one room and getting them to identify the customers of the system, and what their Role is. Then I'm going to get them to write all the stories they can think of from each Role's perspective. I'm not going to reject anything during the session, and I'm trying to keep the session quick and lightweight.

The Session

Got everyone to introduce themselves, and immediately I've got the advantage that everyone knows everyone involved in the project and their role. I got a load of pens and post-its and quickly introduced the concept of a Role as customers of the system. I asked everyone to write down the Roles they thought were relevant to this system.

I then introduced the concept of a Story as "As a [role] I want [a capability] to [deliver an outcome]. The Who, the What and the Why. I gave a couple of examples, then everyone got on with writing stories. After they had finished, I collected up all the post-its, said what the next stages were, and ended the meeting.

Processing the Information

During the session, I stuck all the Roles on a board and grouped them by role area. I included the duplicates to create hot spots that highlighted the most common roles. I noted them all down in Visio and binned the post-its.

I then took all the stories and put them in Word, and each time a Role was used, put a mark by that Role. This helped to identify the Roles that had the most relevance to the system. After consolidating the stories and organising them by Role, I colour coded the Roles Visio diagram with red for the most used Roles down through orange, yellow to blue for those roles that didn't have any stories put forward for them.

Clarifying Stories

I went through the stories, consolidated them and ordered them by role. This made it easier to identify the real roles that were important to the system, and I tweaked the roles in the stories so that they were consistent with each other. I put the roles at the top of my story document and described each role. We now have a fairly sensible set of stories, and we are fairly clear on the roles.

Release Plan

As part of the workshop, one interesting piece of information that I uncovered was that we need something in live in three weeks. This puts us under extreme pressure to deliver straight away, which is not really what is needed when you're trying to guide everyone through a process that is new to them.

We need to put high level estimates by each story to allow us to do the initial prioritisation and release planning. This is where things start to get tough. Various stories involve lots of existing products and processes that need to work together in new ways, or have the new system integrate with the current processes. To make a sensible estimate, even at a high level, we need to understand these other systems and processes. We need to talk to about three or four different technical areas within the organisation, but these people aren't available. We need to get our Truth, or Customer to clarify their stories, but they aren't available for a few days either. We need a Project Manager to pull things together, and a Dev Lead to arrange the technical meetings. None of them are available. We can't finalize the stories, we can't estimate or prioritise them and therefore we can't start work.

The Deadline

The business are extremely focused on getting something out by the end of the month, and will be annoyed if they can't have it because of the time-sensitive nature of the business case. We are losing days trying to get the information that we need to start the project. It is already July 7th. We will need a week to progress through the test environments and into live. Allowing a couple of days for system testing before we progress into the pre-live environments, this leaves us with 8 working days to develop the whole system.

Given the number of elements required just to fulfill the most basic system, we obviously can't hit this deadline. However, I find that promises were made to the business by various people in Development during the Propositions process, assuring them that something could be live by the end of the month. Various solutions had already been initiated prematurely without clear requirements or a release plan. I can feel that people are getting impatient, and the perception is that the process is delaying things.

The End

By the time I get in on Monday morning, the Business have demanded that Development keep their promise of hitting the end of the month deadline. Things go on over my head, and the conclusion is that the the project must continue using the JFDI methodology. I step aside, disappointed but not at all surprised. The company has rejected Agile and XP, and that's a real shame. However, its better to have this confirmed than labour under a misconception.