Values and Practices

 Author: Joshua Kerievsky, Industrial Logic, Inc.
Started: June 30, 2003
Updated: July 1, 2003

This page contains short descriptions of the values and practices in Industrial XP. If you'd like to discuss the ideas on this page, please consider joining our email list.

• An integration machine can go down
• Your coach can get sick
• A virus can destroy data
• Overtime can lead to major defects
• A jerk can tear apart a Project Community

One of the greatest risks in software development is building software that isn't needed or that has no chance of succeeding with its users. The Planning Game, Evolutionary Design and Continuous Learning aid in managing this risk.

Books that address the subject of Continuous Risk Management include Tom DeMarco and Tim Lister's Waltzing with Bears : Managing Risk on Software Projects and Rob Thomsett's Radical Project Management

Project Chartering

• Is the idea for the project worthwhile?
• How does the project further the organization's vision/mission?
• How would we know if the project is a success?
• Who is part of the project's Project Community?

• Vision and mission
• Project Community
• Values
• Committed resources
• Measures of success
• Boundaries and limits
• Committed resources
• Working agreements

Write your Project Charter on posters in big letters and place these posters in highly visible places.

Project Community

This population is often bigger than you think.

For example, some projects I've coached have not adequately involved building maintenance. And yet, establishing a comfortable working environment by configuring and re-configuring furniture and computers has been an important part of our project work. Without building maintenance membership in our Project Community, we've had to wait for changes or make unauthorized changes that upset people in the organization. What's the problem here? Building maintenance can help us do better project work so they must be members of our Project Community.

Human resources folks participate in our projects in unseen ways: for example, they assess project worker performance. Such assessments may influence the actions of project workers and managers. And yet, such assessments may be out of alignment with the nature and actions of the Project Community. One way to help improve the way we assess people's performance within the organization is to have human resources members in our Project Community.

Our hyper-efficient software development process is aimed at producing only what people value and need. To produce such software, we need members of our Project Community to include those who will use our software and thoroughly influence what we create for them.

If sales and marketing people have influence on what our software does and how it sells in the marketplace, they must be members of our Project Community.

If our competitors can influence our project work with press releases or product releases, how do we include them in our Project Community?

If people in the organization do not decide to participate in a pilot XP project, are they not part of the pilot's Project Community? I've found that by including them in the Project Community - by talking with them, giving them guided tours of the pilot project, listening to their concerns - I can more effectively help an organization grow XP over time.

Your Project Community is bigger than you think.

David Schmaltz, author of The Blind Men And The Elephant : Mastering Project Work, wrote:

How does a Project Community learn whether its project work is successful? The same way programmers learn whether their code works: tests.

Apple Computer had the following management test for their iTunes project:

1 million song downloads = $1 million for Apple. After 1 week in production, the new service passed Apple's management test. Project green bar!

Test-driven management directs the specification of management tests. A management test is a statement that indicates a measurable, time-limited goal, framed in a binary manner: We either achieve the management test or we fail. Good management tests are SMART: Specific, Measurable, Achievable, Relevant and Time-Based.

Management tests are statements about the world external to the project, treating the project as a boundary of responsibility and authority. They avoid specifying ways in which external effects (that is, things that occur outside the boundary of the project and the software) should be achieved. In other words, good management tests set a destination, but don’t specify how to get there.

Management tests are specified using spoken language, not software, and must be measurable and undebatable. The measure can be a hard number (50 organizations will have signed up to use our software by December 31st) or a perception number (by project end, survey of customers’ happiness shows a 20 percent increase on a scale of 1 to 10).

Management tests provide an excellent way for a Project Community to understand what unites them. This echoes Tom DeMarco and Timothy Lister’s observation that “The purpose of a team is not goal attainment, but goal alignment.” (Peopleware, Dorset House, 1999, second ed.). Management tests create goal alignment by delineating how and when success will be measured, enabling individuals to understand the effects of their own actions.

Management tests complement an XP project’s unit tests and storytests by adding a test layer around the project itself. While unit tests assert that small units of code meet programmer expectations, and storytests assert that system features meet customer expectations, management tests assert that organizational returns on investment meet management expectations.

Management tests should never state what system features must be completed by a given date, for that’s the job of Release Planning. The tests should also not create an environment in which people live in fear of their tests. Management tests are meant to form connective tissue within a Project Community, which implies that people must be comfortable in their willingness to commit to the achievement of the tests. It’s therefore best for a Project Community to formalize management tests with business managers prior to embarking upon Release Planning.

Management tests are part of a Project Charter. The tests are assessed at regular intervals, such as the end of each iteration. Tests may be updated or deleted as a Project Community learns whether its tests are helping drive it towards important organizational objectives. Management tests come in two flavors: external and internal.

External management tests are focused on the success of the host organization, measurable outside the project and software boundary, and critical to the organization’s Gold Owners.

Internal management tests are focused on the success of the development organization, measured at or within the project boundary, and critical only to development managers.

For more on Test-Driven Management, including sample management tests, please see Joshua and III's Software Developmemnt Magazine cover story, Right Game, Wrong Team.

Sustainable Pace

If I get accustomed to consistently working at an unsustainable pace, I spend a few non-productive hours per day getting little done. My attention drifts to a web page, a chat window, the phone, an email, a magazine. Yet such time isn't what Tom DeMarco would call Slack. Slack is healthy; it's a good thing. When I work too many hours, the time I spend drifting away from my work is my body and mind rebelling against an unsustainable pace.

In his keynote speech at the first Agile Software Development conference, Jerry Weinberg made one thing crystal clear: to be a professional, you must take care of yourself. "Taking care of yourself," Jerry went on to say, "means taking care of your whole self - body and mind."

Maybe that takes courage. If your organization values people who most definitely do not work at a sustainable pace, you'll probably need courage to work at a sustainable pace. You might loose your job. Or, you might be so productive that no one could question your dedication or your accomplishments.

When I work at a sustainable pace, I have energy to work efficiently and effectively, I have time to spend with my family and friends, time to work out, time to even reflect on my work and a genuine satisfaction with my productivity.

When I commit to working at a sustainable pace, I know that I must not dilly-dally during work hours, as I won't have evening hours to make up for lost time. Committing to this practice means focusing during work hours and for me, and many others, the easiest way to focus is to pair with other individuals on tasks. After numerous hours of pairing, I'm usually happy with my productivity and content to go home on time.

Sustainable Pace takes practice and experimentation to master. Give yourself time to learn this practice. Observe yourself as you experiment with it. You may just find that you're a better professional when your pace is sustainable.

Planning Game