Scott Ambler gave a talk at JAVAPOLIS 07 about Evolving Agile. He started out by describing Moore’s Adoption Curve which is like a bell curve and starts out with innovators, then early adopters, peeks with early majority, start its decline with late majority and dies down with laggards. Most new technologies/processes do not manage to cross the chasm from early adopters to early majority and never make it. The innovators are always excited about new things and are ready to jump in. The early adopters believe they can get a competitive advantage so they try it. The early majority see others succeeding so they get in. The late majority need to see similar organizations doing the same thing before they step in, while the laggards need to see case studies and solid proof before committing. In most cases, the late majority and laggards come way too late to catch up to the competition.Next Scott provides some stats from surveys done on dr dobb (www.ddj.com).
The survey shows the about 70% have adopted agile in some way. Teams that are collocated have higher success rates than distributed teams. Smaller teams have better success rates than larger teams. The survey also shows that:
- Quality: 87% believe high quality is more important than on time and budget
- Scope: 87% believe meeting actual needs of stakeholders is more important than building to spec
- Money: 80% believe that providing the best ROI is more important than delivering under budget.
- Staff: 75% believe that having a healthy workplace is more important than delivering on time and on budget
- Schedule: 61% believe that delivering when the system is ready to be shipped is better than delivering on schedule
On any project there needs to be project initiation where the team and stakeholders are determined, funding is secured, a team room is setup. This also includes initial scope modeling.
Spend some time getting initial requirements, architecture modeling. You always need to answer
What are you going to build? How much will it cost? How long is it going to take? How are you going to build it?
Other issues include release into production, pilot, documentation, training, end of phase testing, sign-off, final testing environment, data conversion. Also one needs to understand production needs (operations and support)
Test driven development is not meant to scale. One should use the right tool for the right job. When working with small issue, one can do just in time specs by writing tests followed by code to make the tests pass. When dealing with big issues then we need to draw sketches, use index cards, etc. For validation, we can run tests to ensure code still works, but this is smoke testing or confirmation testing. It is good, but not enough. It validates to our understanding of the requirements. This makes the assumption that stakeholders understand what they want and can communicate that to us. We need investigative testing. TDD tests to spec. Investigative testing is testing outside the box (key strokes, integration, usability, break the system).
Reconsider on site customer and product owner. Huge assumptions: Can 1 person reflect stakeholder community. Wide range, different priorities, vision. Can possibly have 1 person to represent them all.
Need to understand who the stakeholders are. Need to understand the product owner won’t have all the answers. They are a communication conduit between team and stake holder. Must have good agile business analysis skills, give access to relevant stakeholder just in time. Negotiate, negotiate, negotiate.
What happens if PO the person leaves? Need multiple people in this role rotating.
Documentation:
User manuals, support manuals, operations manuals, interm docs, law (sarbayn-oakly)
Can be smart about it. Example use TDD instead of detailed spec to replace interm docs.
Database techniques:
Low data quality. Database refactoring, testing, regression testing, continuous integration, test driven database design. Developers need to learn database. Need to know that some things belong as a stored procedures or triggers. Developers also need to understand UI stuff.Next Scott cover some challenges that the community needs to address. These include global organizations with geographically distributed teams, large teams, compliance requirements, dealing with contractors, consultants and third parties, governace, application complexity of multi platforms and legacy systems, entrenched processes, people, and policy.
Scoot gives the following guidance in dealing with governance:
- Mission and principle: Pragmatic governance body, staged program delivery, business driven project pipeline, scenario driven development
- Organization: Align HR policy with IT values and align stakeholder values with IT values.
- Processes: iterative development, adapt the process, risk based testing, continuous improvements, embedded compliance
- Measures: Simple and relevant measures, continuous project monitoring
- Policies and standards: integrated life cycle environment, valued corporate assets, flexible architectures
- Roles and responsibility: Promote self organizing teams, align team structure with architecture
Finally Scott makes a call for action and asks that we talk about everything we do, and not just the cool stuff, look beyond development and into the business, bring agile concepts to other communities (UI, data), and invite outsiders to our community.
