Agile over RUP, My Preferred Development Approach

In this post I thought I would describe my delivery approach of choice, in a brief, and (hopefully) understandable format.

As anybody who knows me can attest, I'm a big fan of agile development. That being said, I don't believe that agile alone is typically sufficient for me to successfully run all software delivery engagements. Although I always tweak the delivery approach I take to suit the conditions of a particular project, I frequently have relied on a combination of agile delivery combined with elements of the rational unified process (RUP). In a nutshell, the delivery approach I typically recommend for myself and my clients can be described as agile over RUP.


What does agile mean to me?
I have seen number different descriptions of what agile software delivery is and what it means to different people. The one that resonates the most with me describes agile development as:

1) a set of software development principles that emphasize:

• individuals over process and tools
• working software over documentation
• collaboration over contracts
• responding to change over following the plan
  

2) a set of complementary best practices that support these principles and are

• collaborative
• lightweight
• simple

Note the "collection of complementary best practices" part of this definition, this is important (IMHO). In my experience agile is not something that is "done" or "not done". I've never understood the comment "we are doing agile delivery" or alternatively that team "isn't doing agile". Rather agile is something that can be applied to any development engagement on a graduated, practice by practice basis. When taken in isolation an individual agile best practice can still add value to a software development project. However, when an agile best practice is combined with and complemented with other agile best practices, there is a potential to provide an exponential amounts of value to the project.

These agile best practices come from a number of different but complementary agile "methodologies". Examples of these methodologies include SCRUM, XP, Crystal-Clear and the Agile Modeling Method. Increasingly, there is growing industry evidence that many organizations are selecting these best practices à la cart, rather than choosing a specific methodology and following it in its pure form. This is an approach that I follow, and it's one that I recommend...

Here is a brief list of the agile best practices that have provided value to delivery engagements I have been a part of in the past...

Test Driven Development

Test driven development is a development technique where test cases are written first, then the code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. "Refactoring" source code means modifying it without changing its behavior, and is sometimes informally referred to as "cleaning it up". Refactoring improves the understandability of the code and changes its internal structure and design, and removes dead code, to make it easier to comprehend, more maintainable and amenable to change. Many of the other tenets of agile development (like evolutionary design, responding to change, etc.) start to fall apart if application code is not supported by a robust and well thought out automated testing framework and periodic refactoring cycles.

Iterative Development

Another core best practice essential to effective agile delivery is the delivery of working software using a just-in-time assembly model where potentially shippable software is created at the end of each iteration. The first step in iterative development is to create a upfront but simple plan for the implementation effort as a whole, estimating and scheduling work into iterations of equal length ranging from one week to one month. At the beginning of each iteration a more detailed version of the plan is developed, scheduled work is completed, working code is presented to the business, progress is measured, and the plan is adjusted as necessary. For iterative development to truly work, software must be thought of as being potentially shippable at the end of each iteration. Work must also be focused on delivering real business value to the business, rather than developer "gold plating". Finally, estimates and planning needs to be done by the resources were actually going to do the work.

Daily Standup Meetings
Daily Standup Meetings is a core agile practice that requires a very little effort to run successfully. Communication among the entire team is the purpose of the daily standup meeting. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions. It is more efficient to have one short meeting that every one is required to attend than many meetings with a few developers each. Organization and involvement of all levels of team members is encouraged by requiring each member to specify what they plan to accomplish the day before, what they actually accomplish, what they plan to accomplish today, and what, if anything is preventing them from being successful. On large-scale projects, hold "super daily standups" once a day to coordinate work across different teams. This super daily standup should be attended by one representative from each separate team.

Continuous Integration

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including tests) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Common Coding Standards And Self Describing Code

Coding standards tells developers how they must write their code. Instead of each developer coding in their own preferred style, they will write all code to a common standards. This makes sure that a large project is coded in a consistent style -- parts are not written differently by different programmers. Not only does this solution make the code easier to understand, it also ensures that any developer who looks at the code will know what to expect throughout the entire application. A typical supplementary best practice is to employ Self Describing Code, a set of coding conventions with the intent of making code a self-documenting artifact. Specific implementation patterns can be followed to ensure that code is developed with readability as a primary consideration, in effect reducing the need for code comments, supporting documentation, and other artifacts which may not always be kept up to date with production code.

Collective Code Ownership

Encourages every developer to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, or refactor. Collective code ownership helps to mitigate the eventual transfer of resources from a particular project. This practice has been cited as being much more effective than conventional approaches such as code documentation, code walk-throughs and other knowledge transfer mechanisms.

Sustainable Pace

This best practice simply states that developers are much more effective at delivering high-quality code when they are put under the "right" amount of stress to perform. I.e. they are well rested, enthusiastic, and able to look at a problem with a fresh eye. This needs to be balanced with reasonably short term objectives, and a consistent and continual need to produce real results within a relatively short time. (I.e. a specific iteration)

Collaborative Modeling

Collaborative Modeling involves the use of simple and accessible tools to develop low fidelity, often throw away models of software that is to be built. The use of simple tools like index cards, whiteboards, and sticky notes allows for non-technical resources (i.e. the business) to actively partake in modeling HUP solution. Collaborative modeling calls for business users to actively engage and own any models that are developed to help guide the development.

An excellent example of collaborative modeling (one espoused by XP) are CRC cards (Class Responsibility Collaborator). CRC cards allow developers to create a low fidelity, object-oriented model. CRC models are created by laying out a set of index cards on a table or particle board, and labeling one or more of these cards with a major concept (a class) that needs to be represented in the software. Examples can include long-lived information such as a Student, an Account, or an Address. More temporary concepts can also be represented such as a ShoppingCart, or a RateCalculation. Using CRC modeling techniques facilitate a collaborative modeling atmosphere, one in which both business and technical resources can engage in.

Co-Located Teams

it is hard to overemphasize the amount of waste that is created by placing members of the same team in different locations. This should seem like a no-brainer, but the reality is many organizations really struggle with getting their team members into the same room for the duration of a project. Co-locating teams drastically reduces the need for official meetings, just go to the room where the work is being done, and resolve the issue. There is also a huge amount of information being simply from overhearing the conversation of others. On large-scale projects, organize teams to minimize the dependencies between teams and then make sure each team is in one room.

Retrospectives

While a set of best practices may look great on paper, the reality is that any best practice (even the ones described above) will require considerable refinement and adaption to the actual environment where the project is taking place. Retrospectives are short meetings held by the entire team at the end of every iteration. Retrospectives allow the team to add any best practices or processes that can help with the delivery of software, and remove one's that are getting in the way. Lessons learned are incorporated into the approach, and allow the team to continually improve over the duration of the project. Retrospectives are another essential agile best practice (IMHO) but one that is easy to implement.

Pair Programming

Pair Programming is a development technique involving the pairing of two developers to one computer, one mouse when keyboard. One developer enters in code (the driver) while the other developer (the observer) reviews, provide strategic direction, and refactoring suggestions. The two developers should switch roles for equally, a standard best practice is every 30 minutes. While seemingly simple, pair programming is (IMHO) probably one of the most difficult agile best practices to pull off, developers by their very nature like to work on their own computer on their own tasks. It is also counterintuitive to believe that their programming would not result in a drastic loss of productivity. There is actual empirical evidence that this is the case, with some studies showing overall effort reduced by 15% and code quality being increased by 50%. Pair programming also makes it incredibly easy to onboard and offboard resources, increases developer discipline (someone's always watching over somebody else) and lead to more effective problem-solving.

Active Business Stakeholder

Every form of agile methodology has some notion of this practice. XP calls the on-site customer, SCRUM calls it a product owner. In all instances, some form of user, or user proxy, plays an active part of the development team, providing advice, direction, and knowledge of what the product should do. The active business stakeholder is responsible for developing all requirements for the system, and has the final say on priority. The active business stakeholder is empowered to make decisions on the fly, and serves as a buffer between the development team and other business stakeholders.

Given the list above, the set of agile best practices could also be represented as:

Agile itself could be represented as a set of agile principles and agile best practices...

stay tuned for part 2 of this presentation where I described how RUP fit into the picture...