More Agile Options

G.B. Shah

When you think about Agile Software development, one thinks only about Extreme Programming (XP). It is natural because Extreme Programming is by far the most favorite of all Agile methodologies. It is popular because the methodology is very well documented and many articulate practitioners prescribe it. However, Agile is not only about XP, it goes much beyond that.

Some developers get confused when they talk about Agile. Agile Software development per se, can be used to describe any methodologies that adhere to standards set by the Agile Manifesto. In short, Agile Manifesto prescribes the following:

  • Individuals and interactions over processes and tools;
  • Working software over comprehensive documentation;
  • Customer collaboration over contract negotiation; and
  • Responding to change over following a plan.

To be Agile, hence, derives a larger meaning than merely following certain processes and practices. Simple steps taken to improve productivity can make a lot of difference. “Doing away with cubicles at our offices has done a world of good,” says Martin Fowler in an interview with S Ramdas, executive publisher of this magazine. “Cubicles prevent developers working in the team from interacting with each other, and at the same time does nothing much to stop noise distracting developers (unless they are in sound-proofed cubicles). And an open environment where developers sit across tables and do work improves interaction among developers,” he adds.

Essentially, the above thought subscribes to the first point in the Agile Manifesto.

In this article we will check out other Agile practices that are equally important and worth your attention.

Scrum

Scrum was founded by Jeff Sutherland and Ken Schwaber invented it at Easel Corporation in 1993. Scrum is a variation of Sashimi, an "all-at-once" approach to software engineering. Scrum originates from Sashimi, a Japanese methodology to solve process driven problems. Sashimi originated with the Japanese and their experiences with the Waterfall model. They had the same problems with the Waterfall model as everybody else, so they adapted it to suit their own style. Both Scrum and Sashimi are suited best to new product development.

Scrum refers to the mechanism used in rugby for getting an out-of-play ball back into play. Scrum generates productivity improvements by implementing a framework that empowers teams and thrives on change. A set of rules and corresponding terminology are used to reinforce such common sense techniques as small teams, daily status meetings, not interrupting people who are working and a single source of work prioritization. Scrum's two pillars are team empowerment and adaptability.

For each Waterfall phase there are a pool of experienced people available, form a team by selecting one person from each pool. Call a team meeting and tell them that they have been selected to do an important project. Describe the project, include how long it's estimated to take, how much it is estimated to cost, how it is expected to perform, etc. Now tell them that their job is to do it in half the time, with half the cost, twice the performance, etc. Tell them how it's done is up to them and explain that your job is to support them with resources.

Standby, give advice if it's requested and wait. Don't be surprised if a team member thinks the whole thing is insane and leaves. You'll get regular reports, but mostly you'll have to just wait. At somewhere around the expected time, the team will produce the system with the expected performance and cost.

This is exactly the way a rugby football captain leads the team during a scrum situation. The first thing that happens is the initial leader will become primarily a reporter. The leadership role will bounce around within the team based on the task at hand. Soon, QA developers will be learning how requirements are achieved and will be actively contributing, and requirements people will be seeing things from a QA point of view. As work is done in each of the phases, all the team learns and contributes, no work is done alone, the team is behind everything! From the initial meeting, the finished product is being developed. Someone can be writing code, working on functional specifications and designing during the same day, i.e. "all-at-once". Don't be surprised if the team cleans the slate numerous times, many new ways will be picked up and many old ways discarded. The team will become autonomous and will tend to transcend the initial goals, striving for excellence. The team members will become more committed to accomplish the goal and some members may experience emotional pain when the project is completed.

The basic premise is that if you are committed to the team and the project, and if your boss really trusts you, then you can spend time being productive instead of justifying your work. This reduces the need for meetings, reporting and authorization. There is control, but it is subtle and mostly indirect. It is exercised by selecting the right people, creating an open work environment, encouraging feedback, establishing an evaluation and reward program based on group performance, managing the tendency to go off in different directions early on, and tolerating mistakes. Every person on the team starts with an understanding of the problem, associates it with a range of solutions experienced and studied, then using skill, intelligence and experience, will narrow the range to one or a few options.

Unlike XP, which gets into code reviews and code changes, Scrum is all about effective people management.

DSDM

DSDM stands for Dynamic Systems Development Method but it is strictly not a method in the accepted sense. Rather, it is a framework focused on delivering a quality solution, quickly.

Like all other Agile methodologies, DSDM also believes in development being a team effort and development process can be iterative. It also believes that resources must be spent to the maximum to create that part of the software that needs the biggest attention.

There are certain principles on which DSDM is based, including:

  1. Active user involvement is imperative.
  2. The team must be empowered to make decisions.
  3. The focus is on frequent delivery of products.
  4. Fitness for business purpose is the essential criterion for acceptance of deliverables.
  5. Iterative and incremental development is necessary to converge on an accurate business solution.
  6. All changes during development are reversible.
  7. Requirements are base-lined at a high level.
  8. Testing is integrated throughout the life cycle.
  9. Collaboration and cooperation between all stakeholders is essential. 

The DSDM Consortium is a not-for-profit organization that owns the DSDM Framework. The Consortium oversees licensing for use of the DSDM Framework with only Licensed Users entitled to use the DSDM Framework in projects.

In DSDM, time is fixed for the life of a project and resources are fixed as far as possible. This means that the requirements that will be satisfied can change as the business needs them to.

It also prescribes a 'no-blame' culture and defines a philosophy for collaborative working that reaches far beyond the parochial concerns of an individual project team.

In many ways, DSDM is similar to Extreme Programming and even shares some of the latter’s philosophy, but it is different too.

Crystal

Alistair Cockburn, an Agile Thought Leader, is widely acknowledged as the founder of the Crytsal family of software development methodology. Crystal is a methodology series that is described for teams of different sizes. Crystal is seen as a family because the founder believes that different approaches are required as teams vary in size and the criticality of errors changes. The author claims that Crystal Clear is a methodology that summarizes 10 years of research into successful software teams.

The real essence of Crystal can be understood from Crystal Clear, which is a methodology recommended for teams of the size of 2-8. Team size is important, because if you have a small team it's easiest to adopt a methodology that already fits. It is more difficult to start with a larger one and prune it back.
                                                          
It is easy to understand Crystal from some of these Thought Processes – “Different projects have different needs. As the number of people involved grows, so does the need to coordinate communications. As the potential for damage increases, so increases the need for public scrutiny, and so decreases the tolerance for personal stylistic variations.”

In essence, Crystal family of methods describes decisions you need to take as the project sizes differ.

Lean Development

Lean Development is based on the principles used by Japanese manufacturing majors like Toyota in producing automobiles. Lean movement in manufacturing, which gave rise to the term ‘zero inventory’ among others, is the inspiration. Mary and Tom Poppendieck have promoted Lean Development. Here are some excerpts from their book by the same name.

“80% of the value of most systems is delivered by 20% of the features and up to two-thirds of the features of most systems are rarely, if ever, used. The easiest way to develop better software faster is to Write Less Code.  If we would stop spending time specifying, designing, developing, testing, documenting and maintaining features that are not going to prove particularly useful to our customers, we could focus on providing them with a significant competitive advantage.”

“The maturity of an organization is measured by the speed with which it can repeatedly and reliably execute its core processes. Rapid response is a primary driver of competitive advantage, as FedEx. How rapidly does your organization routinely respond to a customer’s needs? Are your competitors faster?”

“The fundamental discipline of lean software development is testing. Tests define the requirements, drive the design and document the system. Software should be built, integrated and checked out with a test harness every day. Best-in-class organizations write the tests first and deliver the test harness as a part of the code base.”

“80% of the code in any system is developed after the first release to production.  Some of the best software products have been evolving for a decade. Robust, responsive software that stands the test of time is created by developers who have a deep understanding of the domain.”

Lean development is based on a four point agenda. These are:

  • Customer Focus: Waste is anything that does not provide timely customer value. Have you identified who your customers are? Do you know what these customers really want? Do you know how long it takes to deliver that value? To find out how well your organization delivers customer value, start by analyzing the value stream.
  • Process Flow: An agile software development team can add features in any order and can release a working version of the software at the end of any iteration. When manufacturing plants learned how to make any product in any order, Just-in-Time manufacturing became practical. Now that software developers have learned to add any feature in any order and deliver working software in two-weeks or thereabouts, Just-in-Time software development is possible.
  • Local Responsibility: In really efficient organizations, the job of management is to organize things so that people can figure out what to do without being told. Effective workflow, visual controls and regular training build expertise in the workforce, allowing responsibility to be moved to the point where wisdom lies:  the place where work is being done.
  • Data-based Decisions: When the goal is to hit a moving target, learning-based software development is the approach to use. Experienced development teams can implement individual features in any order and deliver deployable code in less than a month. 

Adaptive Software Development

Adaptive software development (ASD) is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.

ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission-focused, feature-based, iterative, time-boxed, risk driven and change tolerant.

Today, there are a number of variants being suggested. However, these are some of the most popular non-XP based Agile methods.

Sources:

Agile Management with Scrum, Ken Schwaber
Lean Development, Tom/Mary Poppendieck
Scrum, Jeff Sutherland
Adaptive Software Development, Jim HighSmith








}