The purpose of this category is to ensure that people are working on what is of greatest value to the company, and have time to focus and make progress on that work.
The top corporate key initiatives are prioritized & visibly posted for each two-week production cycle. They are allocated to individual people so that each person knows their top two or three personal priority items for the cycle.
Work is broken into what can be completed and tested in the two week cycles, further broken down into things that can get accomplished in 1-3 work days. Each person working on more than one initiative is guaranteed at least two consecutive days to work on any one initiative without being pulled onto another assignment.
The developers post on the whiteboards outside their office the current status of the work they plan to complete this week. Every morning, the developers meet with the business owner of their current work initiative, in a short meeting to determine the current state of the work, the top work priorities and to discuss any questions. The business owner is not permitted to ask for status again the rest of the day. The period 10:00 - 12:00 each day is declared "focus time," in which no meetings take place, and everyone in the company is encouraged to turn off their phone.
4. Maximally defect-free
The purpose of this category is to construct a culture of "kill bugs here!"
Every server and servlet class will have a set of automated regression unit tests, written by programmer for his/her own code, using JUnit and HttpUnit, or equivalent. Programmers only release code to integration test when the tests have passed the scrutiny of a peer developer. the integration tester therefore get the code, the test cases, and a note from another programmer saying she/he will vouch for the quality of the tests.
The server contains a loopback mechanism so that the integration testers can maintain their own, controlled test database (which other people can use).
There will be a small, pidgin language that can be used by business people to construct sample business transactions and name an expected response. This little language allows integration testers, business owners, and the servlet writers to construct a test scenario and add it to the test database.
Screen-click statistics from the call center are posted in a visible place so that everyone can see where the public is having difficulties, whether navigation difficulties or programming defects
5. A community, aligned in conversation
The purpose of this catgory is to indicate the long-term target toward which the company is aiming.
Eventually, the programmers, user interface designers, testers, business owners, marketers, and so on, should sit in cross-functional teams to maximize the effect of conversation around delivering initiatives across specialty boundaries, and to minimize the effect of rumoring about others specialties. This will have to be balanced with staffing levels and growing space needs.
Reflection on Crystal Orange / Web
Two things strike me about about this methodology.
The first is the reduced role of process and work products in expressing the methodology. They are present, but occupy only a fragment of the space usually devoted to them.
The second is the general absence of concurrent development, which is one of my favorite development speed-up techniques. Concurrent development is missing because of the bottlenecks in the system.
The programmers had an enormous work backlog, no spare capacity, and were being constantly interrupted. The people were quite inexperienced in both developing software and in the business domain. These two points together meant that the programmers were not able to do overlapped development and hold the requirements in an oral culture. They needed stickiness in the information, which meant having specs written down for them.
With time, this should change, and as it does, I hope they will reduce the paperwork and increase the conversation. In the meantime, they need the paper.
Six Months Later
I present this methodology as it was constructed as the starter methodology. We would expect to see some drift over time, both as people thought up new ways of working, and as they drifted away from the high-discipline practices.
Michael Jordaan, CEO of eBucks.com, made these comments about the group's work habits six months later: "Obviously, when you left some disciplines survived while others did not stand the test. The survivors include the forthighly heartbeat with carefully planned cutoff times, which allows for developers and business owners to plan, testers to test rigorously and customers to be informed upfront of scheduled upgrades.
We discussed a three week heartbeat, but this was considered too long. More complex issues than can be solved in two weeks are run at twice the heartbeat (four weeks), but we still encourage incremental rollouts. The post-heartbeat meeting is strictly enforced and it has become one of the few times that I get to speak to the entire team. I have made quite a point of paying tribute to those involved in succesful upgrades. Hopefully this public recognition is motivating.
Whether you use Crystal or not, increase morale and communication on your project so that the people trade information a little bit better. This applies for any base methodology.
Mistakes are discussed and suggestions for improvements have been made at every meeting, supporting the learning culture we are creating. The quality of code going live has improved greatly as the testing team has a veto power, to prevent bad code from going live (and this can be embarrasing). The SWAT team, dedicated to eliminating live bugs have also made great strides in responding to customer and call centre queries.
Focus time is still adhered to (and we still ring a bell every morning at ten). If I go a single day without these two hours I now start panicking, so useful has it proven to be.
Some things that did not survive was the habit of posting current priorities/ work progress on a board. Maybe interruptions are less of an issue now, as people work from home or maybe relationships between business owners and developers have stabilised. Maybe people are just lazy.
Most developers have a maximum of three tasks at any given time, except for the two key people working on the back end, who may easily have a list of 15 each. Moreover they are still interrupted by live issues, which interfere with their completion of tasks and lead to much frustration by other developers and business. The issue here is lack of skilled resources. It is the age-old problem that training employees to assist, while undoubtedly the right medium term solution, takes longer than simply doing it yourself."
In those comments, what I notice with some satisfaction is that the team still uses the core elements of the process: heartbeat with learning, and have found ways to modify even that heartbeat to fit their needs.
I notice the discussion of talent and skills as being critical to the project, and I notice the drifting away from what probably was embellishment in the methodology.
Get your experienced developers at Level 2 in methodology design. If your project doesn't have anyone at that level, do two things: Study your base methodology.
Start holding reflection workshops so that someone Compare what your team is doing with the three gets up to Level 2 soon. methodology samples given in this chapter. Choose a few ideas to apply on your own project.
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more."
Seventeen advocates of lightweight development processes gathered in Utah in early 2001 to discuss what they might have in common, or if they would just agree to disagree. I was one of them.
We agreed that the word "lightweight" too much of a reaction against something, and not enough of a belief in something. Agreeing on the importance of being able to respond to changing requirements within the project timeframe, we chose the word agile. We agreed on the above four values and on a dozen principles to support those values. We agreed that we were not interested in agreeing beyond that. We nicknamed the group the Agile Alliance. This appendix discusses that meeting, the values and the principles.
The meeting happened at Snowbird, Utah, in February, 2001.
The 17 people were Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, and Dave "Pragmatic" Thomas. (If Dave A. Thomas from Object Technology International had been able to make it that week, we might have had two Dave Thomasses as signatories!)
Each person there saw their own version of the meeting. What follows in this appendix is mine (but I did pass this text in front of the others).
The reason we met was to see whether there was anything in common between the various light methodologies: Adaptive Software Development, XP, Scrum, Crystal, Feature Driven Development, Dynamic System Development Method (DSDM), and "pragmatic programming."
Kent Beck, Ward Cunningham, Ron Jeffries, James Grenning and Robert Martin brought their views of XP, along with their considerable other experiences and their own personal wishes.
Martin Fowler brought long experience in both XP and methodology evaluation in general.
Jim Highsmith represented Adaptive Software Development and ideas around the emergent properties of complex, adaptive systems.
I was there, protecting my interests in methodology-per-project and just-in-time methodology construction.
Jeff Sutherland, Ken Schwaber and Michael Beedle represented Scrum (Schwaber 2001).