Friday, May 18, 2007

Agile Styles: Crytsal

Agile Software Development: The Cooperative Game (2nd Edition)Alistair Cockburn introduces us to Crytsal in a presentation give at Agile 2006. He starts by discussing Japanese Ikido and the concepts of Shu, Ha, and Ri. He states that people learn things in 3 stages:

1. Shu or following: Show me one way that works. Once I know it, I’ll move on to others
2. Ha or breaking away: Learn limitations of technique A and look for others that complement it or competes with it
3. Ri or fluency: Improvise, slice, shift, or combine techniques in a moment

Alistair recommends getting the starter level kit for all the agile styles. He mentions that a methodology is a reflection of the methodology author and people pick a methodology because the style of the author resonates with them.

Alistair then introduces us to Crystal be stating that it aims to be the lightest, least intrusive set of rules that puts a project in the safety zone. Its purpose is to keep people informed and keep them from hurting each other. Its nature is enable people to follow a set of conventions that gets updated regularly. Its philosophy is that people differ in their working styles, projects differ in needs, and software development is communication-intensive, experiment-based, needs lots of feedback in all directions, less is generally better, techniques and technologies change over time, and people learn in class or on the job and not from methodology.

Crystal Clear: A Human-Powered Methodology for Small TeamsAlistair shares a study he conducted which concluded that people centric methodologies do better than process centric methodology. Methodology is nothing more than a set of conventions that people agree to follow. He recommends adjusting a methodology based on the team and project like having a meeting every month and tuning the methodology based on what was learnt. As the people on the team change, the conventions of the team change. As the project evolves from beginning, middle to end, the strategies and conventions also change.

Alistair then defines the Crystal family of methodologies Clear, Yellow, Orange, and Red. Each one is better suited depending on the project needs.

Crystal is a family with genetic code:
1. Mindset: Not modeling, but cooperative game where people help each other to succeed. There are 2 goals: The primary is to delivers software, and the secondary is to setup for the next game. These two goals conflicting with each other.
2. Design priorities: Project safety (first and foremost), then development efficiency process habitability (tolerance). Will people use the suggestions.
3. Principles:
  • a. interactive face to face communication is most efficient,
  • b. methodology weight is costly,
  • c. use heavier methodology for large groups,
  • d. use more ceremony for more criticality,
  • e. use more feedback and communication instead with fewer intermediate deliverables
  • f. Discipline, skills, understanding counter process, formality, documentation
  • g. Efficiency is expendable at non bottleneck activities

4. Crystal’s Project Properties
  • a. Part of genetic code: Frequent delivery, close communication, reflective improvement.
  • b. Good ideas: Personal safety (freedom to speak without fear of reprisal), focus (knowing what to develop and having time for it), easy access to expert users, technical environment with frequent integration, automated testing, configuration management.
5. Starter Techniques:
  • a. Methodology shaping
  • b. Reflection workshop (2 columns 1st: keep these, problem areas, 2nd :try these)
  • c. Blitz planning
6. Crystal sample methodology: Crystal clear, Crystal orange

To get started with crystal, Alistair recommends finding your place on the project chart, picking a frequency of delivery, focusing on the top 3 properties, starting work, and every month doing a reflection workshop and deciding what to change.

Alistair concludes by mentioning that to know if you are doing Crystal look for close communication, see users every week, deliver software every 1 to 3 months, monitor project by quality of communication and moral of community, actively reflect on team quality and working habit.
This presentation is available on InfoQ at

Agile Styles: Feature Driven Development

David Anderson gave a talk on Feature Driven Development at Agile 2006. FDD is highly effective and produces high quality in a faster time to market. It increases productivity and quality and enhances team work. In FDD there is no overtime, no time tracking, no GANTT charts, no task tracking, and no time on task estimates.

FDD methodology involves developing an overall model at a high level and then building a feature list. Planning then proceeds by feature where each feature is designed in detail and then built in small code batches.

David defines a feature as a tiny piece of client valued functionality which can be delivered in less than 2 man weeks, typically 2 days. There are 4 types of features: User Interface, Problem Domain or Business Logic, System Interface, and Data Management or Persistence. A feature is written using the following format:
action result [of|to|from|for] object
Example: Calculate the interest for the bank account. This directly maps to the method name, return value, and class name. David then explains relating a feature to the model. A feature is a method on the domain model.

David then explains relating a feature to the model. A feature is a method on the domain model. There is 1 UML sequence diagram per feature. A feature set is related to a moment-interval on the domain model. All features in a set touch the same pink class on the model. A subject area is related to a chain of moment-interval.

Next David covers the Law of Demeter which ensures loose coupling by stating that classes should only depend on their immediate neighbors. This allows for postponed component definition and making decision at the last responsible moment. This enables componentizations of service orientation which allows building one big code base and breaking into components later and not having to refactor because interfaces between components are defined as the method signature on the classes.

Components are color coded pink, yellow, green and blue. They are re-usable enterprise components. The pinks and yellows are re-usable across multiple greens (the core enterprise components). The greens and blues are re-usable across discrete Enterprise Applications modeled as sequence of pinks.

FDD includes the concept of class or code ownership. This ensures that a class is not doing something it is not supposed to do from a design perspective. Classes are consistent and the api is concise. It also fosters collaboration and team work because if a feature is messaging a class owned by someone else, you need to work with that person.

David then compares bananas to requirement documents. He stresses that they are both perishable and thus cycle time is very important. He introduces CPW( Chief programmer work package) which is a collection or batch of features which can logically be grouped for development simultaneously and can be delivered within 2 weeks or less (each feature must be less than 2 weeks, each CPW must be less than 2 weeks). There is no timebox iteration in FDD. It is however long it takes, but must be less than 2 weeks.

Next feature teams are defined as dynamically formed per feature under guidance of chief programmer. All owners of relevant code are part of the team. This emphasizes team work and ensures that multiple minds collaborate on design and development.

David then provides some productivity statistics of using FDD and briefly covers configuration management in FDD using promotions groups instead of branch and merge techniques. Finally David gives some examples of dashboards used on his projects.
This presentation is available on InfoQ at

Monday, May 7, 2007

Role of Testing and QA in Agile Software Development

Agile Modeling: Effective Practices for eXtreme Programming and the Unified ProcessScott Ambler gave a talk entitled “The Role of Testing and QA in the Agile Software Development” at TASSQ. The talk however covered many topics and was not necessarily geared to testing and QA.

Scott starts by giving an overview of agile software development. Agile development involves open communication, enhanced collaboration, and embraces change. It results in the creation of working systems that meet the changing needs of stakeholders and produces high quality software with the highest value possible for the stakeholder’s investment.

Agile values 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. There are 12 principles in Agile which Scott briefly goes over.

After that Scott dispels some misinformation about agile. These include:
  1. 1. Many people confuse agility with code and fix (hacking). Many hackers claim to be agile. These are not agilest. Do they have a test bed? Do they know the stakeholders?
  2. 2. Agilist don’t model. Agilist don’t document. Not true. Agile documentation and modeling is done just in time and avoids unnecessary documentations.
  3. 3. ISO/CMM/6sigma therefore we cannot be agile. These presents some challenges’ but it is still possible to be agile even in these types of organizations.
  4. 4. Agility does not scale. This has been proven to be false. Example is the Eclipse project.
  5. 5. Agilist ignore Enterprise concerns. This area is still not well addressed by the agile community.

Next Scott moves on to cover Agile techniques. These include:

    Agile Database Techniques: Effective Strategies for the Agile Software Developer (Wiley Application Development)
  1. 1. Regular deployment of working software: The only measure of success is delivering working software.
  2. 2. Pair programming: This is a hard sell to management, but the data shows that it increases productivity. People learn from each other quickly. Forces programmers to code. Reduces down time (facebook, email, browsing, etc…).
  3. 3. Active stakeholder participation: They provide information and make decisions in a timely manner.
  4. 4. Model with others – equivalent to pair programming. Collective ownership concept. More people understand what is going on. Leads to more collaboration and less documentation
  5. 5. Refactoring – Small changes to code that improves design and retains the behavioral semantics of code. Enables evolving development assets in a controlled manner, enabling design to remain high quality.
  6. 6. Database refactoring – simple change to database schema that preserves the behavioral semantics and the informational semantics.
  7. 7. Test driven development. Write test 1st, write code to pass test.
  8. 8. Continuous regression testing – Whenever someone checks code in.
  9. 9. Test as primary artifacts – acceptance tests are considered to be primary requirements artifacts and unit tests are considered to be detailed design artifacts.
  10. 10. Continuous Integration: Frequent builds
  11. 11. Follow Guidance – Coding practices and Modeling practices