Saturday, October 19, 2002

Agile Development: XP Scales to Large Projects


Scaling Agile Methods: Can eXtreme programming work for large projects?
By Sanjay Murthi, New Architect, October 2002

From literate programming to evolutionary delivery, veteran project managers have seen a variety of shifting development methodologies. Most recently, a family of new methods has emerged united under the umbrella of "agile development." These include eXtreme programming (XP), Scrum, Feature Driven Development, and a few others.

Agile methods have introduced new practices, such as pair programming, while discarding some old ones. Agile development favors delivering working code over complete documentation, for example. Recently, top proponents of these techniques have laid out twelve principles for agile development in the form of the Agile Manifesto (www.agilemanifesto.org).

Trial By Fire
Recently, I had the opportunity to use eXtreme programming (XP) on a large software product release. The team consisted of more than fifty people located in two different development centers. At first, I was skeptical that XP could work for us. I knew that, historically, XP has been most successful with small and very committed teams, and while our team was enthusiastic and committed, we certainly weren't small.

Fortunately, the results of the experiment came as a pleasant surprise. Using XP methods, project teams were more enthusiastic and eager. People enjoyed XP's concept of pair programming and it allowed any member of the team to fix anyone else's bugs. As a manager, this reduced my stress levels when a team member was out sick or on vacation...

Wednesday, October 16, 2002

Mountain Goat Software on SCRUM


Mike Kohn has a nice description and presentation of the SCRUM development process on his web site. Check it out.

"Scrum works because it is a highly-empowering process that allows requirements and self-organizing teams to emerge. In their book, Schwaber and Beedle describe Scrum as an empirical process that uses frequent inspection (daily meetings), collaboration and adaptive responses. They contrast this to defined processes in which every task and outcome is defined. Defined processes work only when the inputs to the process can be perfectly defined and there is very little noise, ambiguity or change. If that doesn't sound like the software projects you work on, look into Scrum."

Agile Project Management with SCRUM


Ambler, Scott. Managers Manage. Software Development, Oct 2002, p. 43.
Scott provides a brief review of SCRUM project management. It's enough to get you started.

Also the Software Development Conference is in Boston this year, 18-22 November. Check out:

21 Nov 7:30-9pm - Agile Project Management with SCRUM - Ken Schwaber

Tuesday, October 08, 2002

How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering

Pouring new wine into old wineskins has caused problems for thousands of years. When you take an agile development process and pour it into minds and marketing machines that reproduce the same old waterfall approach complete with GANT charts, failure should not be surprising.

Three RUP experts have identified patterns of failure when using RUP and written an excellent paper that elucidates them in depth:

Larman, Craig, Kruchten, Philippe el al. How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering. Valtech Technologies and Rational Software, 2001.

In order to ensure absolute misunderstanding and failure in RUP adoption, we provide the following checklist or score sheet. Of course, the more points scored, the more successful the RUP failure.

You know you didn’t understand the RUP when …
o You think that inception = requirements; elaboration = design; and construction = implementation.
o You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.
o You think that only prototypes are created in elaboration. In reality, the production-quality core of the risky architectural elements should be programmed in elaboration.
o You try to define most of the requirements before starting design or implementation.
o You try to define most of the design before starting implementation.
o A “long time” is spent doing requirements or design work before programming starts.
o An organization considers that a suitable iteration length is measured in months, rather than weeks.
o You think that the pre-programming phase of UML diagramming and design activities is a time to fully and accurately define designs and models in great detail, and of programming as a simple mechanical translation of these into code.
o You try to plan a project in detail from start to finish, allocating the work to each iteration; you try to speculatively predict all the iterations, and what will happen in each one.
o An organization wants believable plans and estimates for projects before they have entered the elaboration phase.
o An organization thinks that adopting the RUP means to do many of the possible activities and create many documents, and thinks of or experiences the RUP as a formal process with many steps to be followed.

We are confident that by ... applying the checklist of misunderstandings, your adoption of the RUP and iterative development will be a spectacular mess.
-----
More Rational whitepapers on RUP can be found on the Rational website. You won't find this paper there, however, and it may be the most important one for success. Please contact Craig Larman at www.craiglarman.com for a copy.

Monday, October 07, 2002

Agile Development: Reforming Project Management


Hal Malcomber has an interesting blog on "Reforming Project Management" that focuses on lean project delivery. If you run projects you might want to be reading this. Here is an interesting recent comment that explains why SCRUM avoids GANT charts. They are guaranteed to make agile projects late!

"Experienced project managers will tell you the critical path moves on a project. Why? Tasks don’t start and finish as represented in the project schedule. This would be fine if all the performers for critical path tasks were always available to perform on the project, but this is not the case. In most organizations people are working on more than one project at a time or project work is in addition to their normal work responsibilities. This creates the situation where they must manage priorities – “Do I spend my time on this or on that?”

"We don’t know all of what must be done. Oftentimes ad hoc work (those tasks that seem to arise in the course of doing the other work) encompasses as much time as the planned work of the project. To the extent that this ad hoc work requires the same resources as the work on the plan we see projects get behind. Performing this work often shifts the critical path.

"Task durations therefore are probabilistic. They will range from times that are as short as the actual time applied performing the task to as long as multiples of the task times depending on how much waiting time and distraction time is incurred. Projects by their nature make it difficult to gauge those probability distributions because each project is unique. Our only avenue is to manage the project to minimize the variability."