On Monday night some colleagues and I attended a thought provoking presentation entitled The Future of Agile (If Any). I believe that agile patterns and practices are fundamental to the continued successful growth of an IT company, so hence the questions I left with felt weighty enough to share more widely:
The link between these questions is a third:
3. What does the future hold for Agile Development Practices? Is it rosy or is bleak?
Uncle Bob, one of the founders of the Agile Manifesto, explored these questions for about an hour.
After his usual diversion into natural phenomena (this time it was interference patterns), Bob explored Agile's history, from it's humble beginnings to present day.
Kent Beck, at the creation of the Agile Manifesto, said: "We want to heal the divide between business and development". The group that met and formed the Manifesto recognised that this divide could be bridged by building trust, which in turn, is built by transparency. The original practices sought to provide this transparency.
One of my colleagues provided the definition of software as being soft "because you can squidge it about." TDD, Pairing, Refactoring and Simple Design help keep software soft. Bob stated that these practices could be replaced by others, but only if some core values (from Extreme Programming) could still be met:
In his opinion, TDD, for example, is the best way of getting feedback when developing code, but he welcomed any suggestions of alternative practices that still gave the same amount of feedback as TDD.
Bob recognised that Scrum has helped Agile move from the margin to mainstream, but questioned whether Scrum has allowed team autonomy and self-organisation to overrule minimum standards, practices and principles that give improve a software team's maturity (such as pairing and TDD). This was a particular concern for Agile's future, as, in his opinion, the community is very immature. This opinion was based on a rough and ready estimation that the number of developers world-wide is doubling every five years, and so hence the vast majority of developers in the world have less than 5 years experience.
He then looked to the future and posed the question: What major catastrophe will be caused by software? When it happens, how will Development defend itself against the accusation of "how did you let this happen?"?
On a positive note (in response to a question I asked) Bob stated that the disciplines encompassed by Agile Software Development are a positive step towards maturity (providing their adoption continues to spread and become the norm).
The main question I left with, was back to the original purpose of the manifesto: how do we increase the level of trust and transparency between Development and the rest of the business?
- What physical actions can you take today to increase the level of trust between your Development Team and the rest of your business?
- When (not if) a major catastrophe is caused by software, how will we, in the IT Industry, answer the question: "how did you let this happen?"?
The link between these questions is a third:
3. What does the future hold for Agile Development Practices? Is it rosy or is bleak?
Uncle Bob, one of the founders of the Agile Manifesto, explored these questions for about an hour.
After his usual diversion into natural phenomena (this time it was interference patterns), Bob explored Agile's history, from it's humble beginnings to present day.
Kent Beck, at the creation of the Agile Manifesto, said: "We want to heal the divide between business and development". The group that met and formed the Manifesto recognised that this divide could be bridged by building trust, which in turn, is built by transparency. The original practices sought to provide this transparency.
One of my colleagues provided the definition of software as being soft "because you can squidge it about." TDD, Pairing, Refactoring and Simple Design help keep software soft. Bob stated that these practices could be replaced by others, but only if some core values (from Extreme Programming) could still be met:
- Simplicity
- Feedback
- Communication
- Courage
- Respect
In his opinion, TDD, for example, is the best way of getting feedback when developing code, but he welcomed any suggestions of alternative practices that still gave the same amount of feedback as TDD.
Bob recognised that Scrum has helped Agile move from the margin to mainstream, but questioned whether Scrum has allowed team autonomy and self-organisation to overrule minimum standards, practices and principles that give improve a software team's maturity (such as pairing and TDD). This was a particular concern for Agile's future, as, in his opinion, the community is very immature. This opinion was based on a rough and ready estimation that the number of developers world-wide is doubling every five years, and so hence the vast majority of developers in the world have less than 5 years experience.
He then looked to the future and posed the question: What major catastrophe will be caused by software? When it happens, how will Development defend itself against the accusation of "how did you let this happen?"?
On a positive note (in response to a question I asked) Bob stated that the disciplines encompassed by Agile Software Development are a positive step towards maturity (providing their adoption continues to spread and become the norm).
The main question I left with, was back to the original purpose of the manifesto: how do we increase the level of trust and transparency between Development and the rest of the business?
