Tim Ottinger and Ruud Wijnands gave a talk at QCon London 2015 on how to take back the agility of the initial times of XP and why part of it has been lost in the way.
During their talk “Taking Back Agile”, they started to explore the topic “If this is agile, take it back” by identifying the opposite, things that agile implementations brought to the organizations with few or null benefits. The message sent to audience was: “If this is not agile, get rid of it”. Many causes to the loss of agility were pointed out, below is a summary of them:
- Endless meetings, excessive bureaucracy.
- Developers not doing development, focused on following the processes.
- Teams more focused on management than on practicing engineering.
- Estimation burden.
- Velocity overloaded means crushing technical debt.
In the second part of the talk, “I’d like my agile back, please”, they provide the audience a recipe to start getting back the good things from agile and to get rid from the evil ones. The first idea suggested is to “stop having hope” because hope prevents people from acting and trying to solve questions by their own. Strongly connected with this idea is the duality “seeming vs becoming” - a person should become a good professional from the bottom, asking stupid questions, making stupid errors, learning and becoming someone. They explained that when a person is worried about seeming something is preventing himself from learning.
Acting was the next key point of the presentation. They talked about the first known XP project and the two questions that drove it:
- What has worked well for us in the past?
- How can we do these things more intensely?
People who worked on that project thought about how to proceed (act) to have both questions answered. They turned casuistic tasks on systematic ones executed as many times as possible. Examples of those were:
- Code integration and testing.
- Communication with the co-workers.
- Know customer expectations.
A key idea here is, as Martin Fowler says on its blog, “if it hurts, do it more often”.
To put in practice an action plan like that, they suggested that teams must have rights and permissions. Rights inherited from agile’s first days like providing own estimates, having freedom to decide, having ability to complete the job, knowing what customer wants. Regarding permissions, they remembered that no one needs permission to do a good job so, “do not ask for permissions! Find your own!”
All of the described above assumes that you should “Take responsibility of your work!”. Do you do it?