Three bloody roles, Scrum has, and only three. If you can’t get that right, don’t call it Scrum, OK?
- Ron Jeffries
When we are blind to systemic causes of problems, all the solutions we try will likely make matters worse.
- Esther Derby
The first few steps in an agile transformation are critical to success. Lay a good foundation and what follows will be simplified.
So what is a good way to start an agile transformation?
The following are some common Scrum myths.
Velocity is a measure of performance
Isn't a higher velocity a sign of a more productive team?
The Scrum guide is very clear that velocity is purely about establishing the likely capacity of a team for future sprints. The actual value is irrelevant, it is the predictability that is important.
1. Mike Cohn - Mountain Goat Software
One of the founders of agile, Mike speaks with authority on a number of agile subjects. His focus is slightly more towards the product/project side with less focus on engineering practices.
1. Use the same deployment mechanism for all environments
When you do something often, you get good at it. So deploy to all environments using the same mechanism. That way, when you deploy to production things less likely to go wrong.
Agile emphasises the importance of communication. This is not just about the formal communication at stand-ups and meetings, it is also about everyday communication within the team.
Consider the following example.
A team member tries something new with some automated tests. They hope the change could be an improvement and that it could provide significant benefits.
It has long been a tradition in waterfall style projects to associate long hours with increased productivity. A recurring pattern is up-front planning, followed by realisation that a deadline is not going to be achieved and then finally a push to increase working hours.
Performance testing is often difficult and expensive to do. When you need to get real-World performance figures you need to test on real-World hardware and this is not always possible. Even when it can be achieved it is difficult to do frequently without a dedciated (and hence expensive) performance environment.
Jenkins is an excellent choice for continuous integration as it has numerous plugins available, is well supported and is open source.
The following is a list of some of the most useful plugins and how they can be used.
A word of caution for anyone switching to Java 8 (which is now officially released by Sun).
Issues I have found so far:
Eclipse
The previous version of Kepler Eclipse runs with Java 8, but it only understands compliance levels up to Java 7.