Agile
  • Agile is closely related to modifiability (non-functional requirement)
  • Agile tackles complexity by reducing the irreversibility in the process (Enrico Zaninotto)
  • Making change in big organisations is difficult and takes time so the feedback cycle is slow and consequently Agile implementation is hard.
  • Scrum is a better template for Agile than XP. It is good though to use XP technical practices in Scrum.
  • Iterative development means deliver early and often
  • Agile is a middle way between anarchy and heavy processes.

Good Agile Practices

  • Continuous integration and working on one code base (no branching)
  • Having lots of automated tests
  • Continuous delivery for more feedbacks

Team

  • Setup teams based on features not (architectural) components or subsystems.
  • Team distribution is not usually recommend specially inside one team. Maybe cross team distribution is more acceptable. Although distributed agile teams is feasible.
  • Let this be an agile motto: Let the team figure it out.
  • Do not define a lot of roles such as architect! Although architectural specialisation is good but in smaller teams such roles are not helpful. If the architect role is needed in the organisation then they can be dedicated to one team for one iteration and move to another in another iteration. Matrix organisations are not well suited for Agile. In a big organisation we can have informal community of architects.

Estimation

  • The only thing that can almost be estimated is the complexity of a story compared to other stories! Things that cannot be estimated are: time, external factors, knowledge, unexpected surprises !
  • It is a good idea to re-estimate the user stories periodically.

Continuous Delivery

  • Continuous delivery != Continuous integration != Continuous deployment

They are not equal in their exact meaning but very closely related.

No Branching

Martin Fowler is an advocate of everyone working on the trunk instead of creating branches for every feature because of merge issues, etc. Even when the feature is taking longer than your release circles then you can have configurations to take on/off the feature using flags/toggles or show/hide in UI or ….

Another way of avoiding branching (and merge hell) is "Branch By Abstraction". There is a good article here: Make Large Scale Changes Incrementally with Branch By Abstraction

It is basically saying that you can not have continuous delivery if you have branches. It does not mean not having branches at all but it suggests not to have branches for adding every features or refactoring and changes. We still can have some temporary branches i.e for production fixes, etc.

It urges to create a layer of abstraction on the part of the system that we want to change and refactor the code to use this abstract layer. This abstract layer can delegate to old or new implementation. When the new implementation is finished and tested the old implementation can be removed together with the abstract layer.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License