Evolving with Extreme Programming

• Communication must be continuous between customers, developers, management, and anyone else who will influence project success.
• Simplicity is a goal (or directive, if goal is not strong enough) that influences not only program design and code, but also work processes, planning decisions and team interaction.
• Feedback is probably most embodied by testing. Test your assumptions, automate your test, test often, and most importantly, create your automated test first (before creating the code).
• Courage refers to having the guts to make a change. Some might also add, the courage to accept criticism; or to jump-in and be a true team member.

This 1-3 week time limit is not unlike an old estimating technique I’ve used; where the assumption is that an average skilled person should be able to predict all or most of the tasks necessary in a one to two week work element. I once led an engineering team where a certain project manager had a lot of trouble meeting his schedule commitments. After about the 5th excuse, all I wanted to do was to scream, “What about the word ‘done(!)’ don’t you understand?” He simply could not foresee all of the variables in any given situation. That experience illustrated for me a small weakness in the planning process, if estimates are based on the guess work of the team members.

I do not mean to say that the XP technique is bad, it may be fine for an in-house development team. However, there are situations when a more accurate estimate is necessary; for example, when an software engineering outsourcing firm estimates a fixed price proposal. One successful firm, combines the ideas of short storied definitions with some of the structure in use cases, coupled with a powerful Use Case Point (UCP) parametric analysis model to obtain very accurate estimates. This automated process considers factors such as actual delivered history on thousands of projects; use case complexity; engineer skill; object re-use; and other factors to quickly calculate a highly accurate project cost. This firm consistently produces estimates that are greater than 91% accurate, 95% of the time, on projects that average 60 man-months each. Compare that figure to any industry study on project estimation accuracy; which typically run around 30-50% accurate.

Read more!

I cannot tell you how many times I have been told by management (those guys with the pointy hair) to release the prototype into production. My guess is that the XP gurus just admitted to themselves, there was no point in calling it a prototype; it will be released, so we might as well plan on it from the start.

Seriously though, the concept of frequent small (full) releases, makes good sense. Customers often have the expectation that they can throw their requirements at the engineers; and then magic happens and the engineers throw a completed application back. Frequent small releases, requires frequent iterated involvement by the customer. Frequent iterations are very effective in keeping a customer engaged in a project; which is all important when trying to give the customer what they want.

Read more!

XP encourages collaborative ownership through concepts like pair programming (pair analysis, pair design), and moving people around. I like to go one step further, and add peer reviews and structured code walk-through. I cannot think of a better tool to train inexperienced engineers on code standards, or to get engineers out of their fear (or arrogance) of having others see their code, than with true peer reviews (meaning, without management).

Read more!

For some reason, there are others who need to be told to do these things over and over. I once led a very large project, where I was forced to lay-off several members of the project team before their planned roll-off. It was interesting, and painful, to see how poorly some of these under-achievers wrote code; discovered when the remaining project members picked up the left behind work. Needless to say, we paid a lot more attention to each others code after that experience.

Ward Cunningham, one of the XP collaborators, gave me a great example of how XP tries to solve this problem. He said:

“A lot of programmers are afraid to make schema changes. What if they were to start a project with the simplest schema. Then as the project evolves, they would be forced to change the schema many times. By the end of the project, they would no longer be afraid to change schema.”

The XP rules of moving people around and collaborative ownership of code are integral to effective pairing. In hind-sight, I can see that engineers are the most energized about solving a problem when they are working with another person, a partner. This is true whether the partner is a business end-user, systems analyst, junior programmer or senior architect. Perhaps, even engineers are social animals.

Read more!

Contact Ed Carroll