Agile is much more about reducing lead time, defects, and all kinds of wastes by empiricism (feedback; transparency, inspection, adaptation) on all various scales of time (from seconds to months) than any particular method or framework.
Your practices, methods, and frameworks should be aligned with this: Check where you are, decide where you want to be, go a small step in that direction, look at how that worked, and repeat. Establish that cycle on various time scales.
On the cycle of seconds, we can use editor-based static code analysis, pair programming, and ensemble programming, to get instant feedback on code while code is written.
On the cycle of minutes, we can use test-driven development to get quick feedback on behavior on a fine-grained level and on certain aspects of structure like how testable (synonym for decoupled) is.
On the cycle of hours, we can run acceptance tests and rotate people between pairs and ensembles.
On the cycle of days, we can run a DSM to see where we are and where we want to go as a team in our daily work.
On the cycle of weeks, we can have a review and a planning meeting to make transparent, inspect, and adapt about if we're delivering the value needed by the business, and retrospect if we're doing that in the right way.
On the cycle of months, we can have a check with marketing to have feature release plans on a bigger scale and empower our business to make more informed strategic decisions.
The described cycles are, by the way, called "Extreme Programming" (there's a bit more to XP as well, of course). But that doesn't matter. This is just an example, and there are other ways.
XP may not fit everyone, you may have to tweak it for your situation. Startups often need a much more direct connection with the market, for example. The key is to integrate empiricism in your process on various levels of scale.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
