2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – 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
- February 24, 2010 ( 1 comments )
- Rants
Why do some teams adopt an agile methodology and become wildly successful while other teams adopt agile and fail miserably? What is the difference?
In order for software development to be successful we must “build the right thing” and “build the thing right”. Agile strives for both but without understanding the goals and how agile aims to achieve them some teams misapply agile and end up getting little value from it.
Agile supports building the right thing by keeping the customer in the room with the development team all the time to answer questions and provide guidance. Some companies say that it is too expensive to give developers access to the customer but how expensive is it to keep developers waiting to get an answer or to end up building the wrong thing? I’d say it is a lot cheaper to have direct access to the customer.
Sometimes management feels that agility usurps their control because they cannot say they will be finished with X features by Y date. Of course, in waterfall you can say it but it often ends up not being true. Isn’t it better to have certainty around one of theses; features or date? For example, with agility you can guarantee that you will deliver working software by Y date but perhaps with a subset of X features. However, this subset will be the most important features to the customer and maybe ones the customer thinks of mid-stream; isn’t that better?
Of course, you can’t build inflexible software incrementally; you have to know how to write code that can easily change. Not following programming standards while building software iteratively will result in an un-maintainable mess. This is where I see a lot of organizations fail with agile and it is easily solved with some essential training for developers.
Agile projects can also fail because of culture. Some corporate cultures require everyone to commit to specific deliverables up front. This does not always work on an agile project. Some cultures see a lack of commitment to long term deliverables as being wishy-washy.
Agility is not just a buzzword. To truly be successful with agile takes understanding and internalizing the agile principles at all levels of an organization. It’s not about reading a book and following the “agile recipe”. Each organization must figure out how to make it work for them.
Building software is non-trivial. Each situation is different and whenever you find yourself in uncharted territory it is good to have a guide. This is why we agile coaches and trainers are in such demand. We have seen how organizations have successfully adopted agile and can help you apply that knowledge to your specific situation. This can make a big difference in how successful you are with agile.
{1 Comments }
Previous Post: « Why Agile Works
Next Post: The Habit of Quality »
links on page broken