2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- April 27, 2011
- Rants
Compromises are part of life. We must make tradeoffs if we are going to ship product but we want to make the right tradeoffs and that can only happen when we have information to back our decisions. Understanding good design principles and practices help us make informed technical decisions. The principles give us guidance in the large to help us keep sight of what we are striving for. The practices give us guidance in the small to help us form good work habits. Together the principles and practices we follow help us make the right tradeoffs so we can build the best system within the constraints we must work in.
Scrum and XP is not prescriptive, like waterfall. Their purpose is not to propose a process for developing software. Instead, they have distilled down a handful of principles and practices that allow us rapidly build high quality software that is more resilient to change.
The development practices that most developers have been taught are obsolete. They lead us to build code that cannot be changed as easily as our clients often need. The challenge is that Agile development is very different than traditional development and without changing the way we write code to accommodate developing in short sprints we can end up with poor code that is hard to change.
Traditional development shops tend to have several impediments to fully realizing the promise of agility. Changing the business to be more Agile and helping the stakeholders see how they can use the process to get what they need is something that doesn’t happen overnight.
We not only need to understand what the principles of Agile are but why they are there in the first place if we are to make the best use of them. You don’t have to do all the practices if you understand and can mitigate what the practices offer.
Far too often someone will read a book and try to transition their organization to Agile, unaware of the common pitfalls that transitioning to Agile can bring. They lose a lot of money and time trying to figure out best practices and how to approach their problem effectively.
More and more companies are saying what they do is Agile but many are not really doing any more than mini-waterfall, which is not Agile. Short iterations and stand up meetings alone are helpful but that not doing Agile, not by a long shot. To really take advantage of an agile development methodology the whole team must be well versed in Scrum and XP development practices. They must understand the “why” as well as the “how”. This helps assure building changeable code whose quality is so high that we do not need all the checks and balances of a traditional waterfall process.
Good software development is about making the right tradeoffs. To do this we must know tools and techniques in Agile for mitigating risk. When we do we can make the best choices for almost any situation.
Previous Post: « The Enemy of the Great
Next Post: Do You Mentor? »