XP Explained Cover

This week we tackle Chapter 14 and 15 in Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005).  Chapter 14 deals with design.  Software design is a transition point in the life cycle that begins with business requirements and ends in functional software. The design translates the need into a cohesive solution. Chapter 15 covers topics related to scaling.  Scaling concepts focus on using XP to solve larger, more complex problems in more complex organizations.   

Next week we have more what will follow Extreme Programing Explained, Second Edition (2005) ; a re-read or a new read?  Thoughts?  In this week’s we tackle two concepts central to XP; planning and testing, both done the XP way.

Chapter 14: Designing: The Value of Time

One of the most important features of XP is the delivery of functionality every week or two weeks (depending on iteration length). In order to facilitate that process, XP embraces the concept of incremental design.

The design is important to software.  The design allows software developers to share  and inherit elements and components or to copy and use pieces of a design in other instantiations or even other applications. While metaphors of physical design are often used in software, those metaphors don’t work for software design and often constrain the options that we consider in the long run.  For example, the design for a physical product such as a bridge is created and set in stone (ok, maybe you can add flag holders and flags, but that is not a significant design extension). Software designs are far more flexible and changeable, and most importantly software designs can be incrementally built.  Once built a suspension bridge can’t be easily modified into a cantilever bridge, on the other hand, an application running in three tier client server can be incrementally shifted to the cloud.

The incremental approach of delivering value (rather than a big bang approach) provides the basis for gathering feedback faster.  The faster users can interact with the functionality and then provide feedback, the faster the XP can adapt.  Beck suggests that the art of designing is to get feedback and then to use the feedback to do only as much design as needed to get the next feedback.  Beck is defining a continuous improvement loop that begins with just enough design upfront.

Recently I visited Italy and was fortunate enough to be able to spend time looking at Michelangelo’s David.  His design was inspiring but unlike the design of David, the team is continuously learning and the technical environment is evolving which means there are alway new and better ways to design the software. If learning, experience, and technical evolution can positively improve the design then delaying the completion of the design provides the greatest chance of increasing the value and quality of the product.  Timing when during a project, a design is needed requires considering the value learning and experience.

The chapter concludes with a set of criteria for evaluating whether a design is simple and useful enough:

  1. The design is appropriate for the intended audience. If those who are going to work on design and code don’t understand the design, then it isn’t appropriate. 
  2. Create a design that facilitates communication to the team and stakeholders.
  3. The design should not include duplication of logical structures which can make the design hard to understand.
  4. The design should have the fewest elements possible.  Designing fewer elements requires building and documenting few components.

 

Chapter 15: Scaling XP

Chapter 15 is a reminder that scaling has been a topic of conversation for a long time! Beck describes scaling XP along seven dimensions.

A number of people: One of the classic scaling mechanisms is to add people. Earlier in my career the organization I worked for told clients that it would “darken the skies with SEs” (software engineers) to deal with their projects.  Beck, influenced by the Mythical Man-Month, suggests a different path.

  1. Break the problem down into smaller parts. Breaking work into smaller parts allows better prioritization, supports getting started and getting feedback faster.  Prioritization also helps to highlight items in the backlog that might be gold plating.
  2. Use simple solutions whenever possible. Keeping things simple allows work to be done faster, gets feedback faster and in the longer run is easier to maintain.
  3. Apply a complex solution to any problem that’s left.

Investment: This not a scaling issue rather it is a reflection of how organizations account for work.  XP does not change the accounting rules for what can be expensed or capitalized in projects. Make sure you discuss how XP works with your financial group before you start to reduce the potential for surprising accounting!

Size of organization: An XP team can be an island in a larger organization by being transparent and maintaining communication. Maintaining communication in a larger organization will require understanding the information needs of those outside of the XP bubble and then finding a mutually agreed upon way to address those needs.  Beck suggests that the project manager role can provide the interface.

Time: XP supports long running projects (scaling using duration) by building a test base from TDD which prevents many of the common maintenance mistakes. TDD tests also act as a history of project or product development.

Problem complexity: Specialization is a common scaling approach used to great effect in manufacturing and by extension software development.  The assembly line is an example of using specialization to address problem complexity. XP uses pair programming as a tool to leverage the history of specialization in IT to generate closer close cooperation which improves a team’s ability to scale.  Pairing helps team members learn a bit about each other’s specialty which deepens cooperation and the ability to share work across the team.

Solution complexity: The XP dictum to break work down and then to build incrementally allows the team (or team-of-teams) to chip away at the solution, deliver and then get feedback.

Consequence of failure: XP practices are built to provide focus on work in a very transparent environment.  Stories or requirements with a high potential consequence of failure may closer verification and validation. For example, the software that controls x-ray machines.  XP practices that help address the consequence of failure include building in tests using TDD to prove that the work meets needs.  Other tools include pair programming, breaking working to smaller parts and continuous builds. That said, nowhere in XP does it say that you can’t add steps to the flow of work to address mission, safety or security critical requirements. 

XP asks us to simplify problems, apply the basic principles and values, leverage the core practices and then to interact and collaborate with teams outside in order to scale to meet the problem, technical and organizational complexity.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 – 3

Week 3, Chapters 4 – 5

Week 4, Chapters 6 – 7  

Week 5, Chapters 8 – 9

Week 6, Chapters 10 – 11

Week 7, Chapters 12 – 13