NOTE: (30 Dec 08)

This set of pages will take me a while to create. I am going to attempt to post my agile process tips and techniques.

Process Introduction

Over the years, I have worked with many people and learned from masters and novices alike. Here you will read about a single, simple, slightly variable process with a handful of tenets that seem to routinely work at both getting the project off on the right foot, and providing checks and balances to catch us before/when we inevitably stumble.

Each situation is unique -- from the whole business/company culture/dev team culture/problem domain perspective. However, the overall approach to meeting the project head-on is very consistent -- just the details vary.

To some readers, this process may seem like "a lot of upfront work." All I can offer you is my advice against blindly applying some process (agile or not) without using your brain and without collaborating at a mental distance greater than just the coding aspects. There is a lot more to software development than software!

Software development of the the kind I have been involved with (and continue to enjoy doing) is always "knowledge work" and never "factory work." The projects tend to be 6 months to over a year, developing business-critical products and the team/process/culture to go with them. The more you understand about the company's business drivers (often a "level up" from your immediate project's needs), the more that you can provide innovative and explosive solutions to provide business value.

The process described herein is for just such type of projects.

Background

A conundrum of Agile Development to many laypeople is that we trade in seemingly precise process (sequential steps, roles, Gantt charts, lots of non-software-based evidence of activity) in the name of getting to production faster with higher quality -- yet mysteriously with seemingly less process.

The reaction of naive development teams is to "run wild" and do a poor job of delivering a professional solution and claim it is "agile." This gives agile a bad name -- at least to those who do not understand that software development is mostly about the quality and experience of the people and not the name of the process they followed.

Agile requires a keen understanding of sometimes subtle relationships between cause and effect in software development. This is true in many facets of software development:

• people's interactions
• frequent, tangible, working results
• involving the customer more often
• being able to embrace change
  

While some agile techniques -- if blindly adhered to by a newbie team -- can help provide clear feedback, there is still a challenge in our industry to identify the shades of quality. For example, there may be three shades of an architecture used to solve the same problem.

• All three approaches work.
  
• On the surface, the user would not be able to see any difference.
  
• All three approaches require about the same time to arrive at.
  

A newbie developer came up with the lowest ranking architecture. A newbie might not be able to decipher the differences between the three in terms of the near- or long-term benefit. Or, they may tacitly understand what you might point out to them, but not really deeply embrace the reasoning because they just haven't got the amount of experience to appreciate the differences. A developer with more experience might recognize why the middle architecture is better than the worst, but may not be able to come up with the best architecture due to lack of experience (or skill). However, a skilled senior architect will understand the ramifications -- both near- and long-term -- behind choosing the best architecture. You just can't deny the value of working with as highly-skilled people as you can find for every aspect of the team. Ten highly skilled people with good discipline and process can do the work of 100 mediocre developers and do a better quality job on top of it. Sounds controversial? Hardly -- if you have good experience in our industry for any length of time.

Success Factors

Some mantras that we choose to work by:

• Always be visible
  • We work in a completely transparent way
  • We are one, open team, from developer to stakeholder to gold owner
    
  • Knowledge transfer is on an as-frequent basis as needed
  • We tend to document in a natural, cost-effective manner
    
• Business vision is critical & necessary driver
  • Development is to support marketing vision and business needs
  • The closer we work with actual clients, the better the results
  • Technology and business works together in a give and take
  • We work our magic to make the business dreams a reality
    
• Close the "gaps" to reduce risks:
  • ...of building the wrong thing by demonstrating working software in a matter of weeks, not months or years
  • ...of being non-performant by testing early and continuously
  • ...of being brittle by ensuring our code has appropriate level of tests
    
  • ...of deployment by duplicating or simulating the environment(s)

General Philosophy

Our job is to do the best we can at shepherding the company's assets and resources, and the folks being assigned to the software product development.

The basic process:

• Building features in an iterative manner
• Having a range of tools to ensure efficiency of development and testing
• Evaluation by users after each iteration
• Take the reviews/critiques back to the product development team
• Be prepared to throw some things away and redesign/rebuild
• Repeat as needed

This will lead to a quality product.

Some typical rules of thumb:

• Do not do any one aspect to excess, keep things reasonably in sync.
• The only truth: running (quality) software demonstrating feature completion.
• Client specifies features, dev team dictates cost and schedule.
• It is far better to collaborate than to engage in antagonistic "detailed contracts"
• Strive to be in a state where the software can be built and running at a moment's notice (best to have multiple environments)
  
• Tons of detailed documentation and requirements can be wasteful; keeping everything at the conversation level can be short-sighted
  
• Lots of fine-grained project plans for 5 years out is also wasteful

Do Not Get Blocked You must not allow yourself to be blocked. That is, "stuck" from achieving success due to external forces. Bring this to the team's attention immediately as part of an email to the project list, or in the daily meeting or on IRC.