"Commitment to the fixed scope."
Those three statements have made my flesh creep, did you get the same sensation? They are definitive, they are scrict, there are about formal responsibility & discipline. And they are the essence of traditional, waterfall approach.
Agile seems far more relaxed about that:
- story points are not exchangeable for any currency, they don't translate to MDs or MHs
- velocity varies from sprint to sprint & everyone's cool with that (by default)
- no big deal if something from sprint backlog doesn't fit in sprint in the end
But it's a false impression. It may look like there's no discipline, just unrestricted flexibility - and that's unfortunately what MANY people think. Surprisingly many. But TBH - to truly succeed Agile requires ...
Seriously, you can't just pick up the elements of Agile you like & discard whatever you don't (because self-managing team said so). Let's get through some examples:
There may not be any guarantee the whole iteration backlog will be delivered during the iteration, but it doesn't mean you should not plan your iteration. Planning is crucial not only in understanding what you'll have to do, making sure it adds value & giving your business partners something they can rely on, but also in setting yourself a baseline you can measure yourself against. No fixed scope doeasn't mean no commitment.
Freezing Iteration Scope
Requirements do change as does the business reality around. But developers need minimal comfort zone, bounded by the timespan of current iteration (or sprint - you may call it whatever you like). They need a stable foundation to build upon, as short-term planning is necessary to organize work & create maintainable solutions. Constant hop-in scope injections WILL UNDOUBTFULLY kill any iteration.
There's no Agile without CI. Because there's no agile without reliable, repeatable build, test & deployment automation. That's the FIRST thing you should set up, even before you write the 1st line of code. No CI means no short feedback loop, repeated breaking of sustained quality state & increased effort for troubleshooting & bug fixing (waste, Waste, WASTE).
Clear Definition of Done
DONE has to mean DONE. Not "done, but still to be tested", not "done, but end-user hasn't seen it yet", not "done, but well - development-wise done". Breaking this rule doesn't just kill the transparency, it causes constant re-work. The same task appears again & again ("Wasn't it done already FFS?!"), killing any team's credibility that was left.
Cadence & Timeboxing Discipline
If you've set the timebox once, don't change it - build up the flow, the rhytm, the ritual of delivery. The biggest advantage IMHO is avoiding requests like "add that one feature in exchange of extending iteration by one day". Such requests have a tendency to herd, wrecking havoc & causing utter chaos by adding unecessary (and unjustifiable) tension & uncertainty.
One of the key things in Agile is not losing the quality level once you have it established - keeping it on the shipping-ready level is possible only if you have the means to detect any regression pretty much immediately after the change. Otherwise the flow of changes will overwhelm you - potential regression scope will creep, overlap & get out of control instantly. That's why there's no Agile without automated regression testing, amigo.
'Stop & Fix' Mindset
My favourite point, mainly because it has a dual meaning. The first one is quite obvious & it's abouot short feedback loop: red tests - stop whatever you're doing & fix it ASAP; broken compilation / deployment - stop whatever you're doing & fix it ASAP. No-brainer. The second one is about problems / impediments that can be worked around - we tend to do dirty fixes, just to proceed & then they remain for ages - each time they costs us minutes, but in total they result in major long term efficiency / development agility drop. Stop. And Fix. Procrastination is for the weak.
Continuous Improvement & Validated Learning
No Measured Improvement --> No Improvement At All
No Improvement --> Gradual Decay & Increasing Tech Debt
Increasing Tech Debt --> Reduced Agility & Multiplying Waste
All Above Together --> Efficiency Falling Head Over Heels
Agile going rogue
Agile without all this discipline is just careless, "I-don't-give-a-f@#$" amateur codework. Non-transparent, bereft of any chance for valuable feedback, not credible at all. Unpredictable (as Agile can be), and not giving anything in exchange. It doesn't just cut the benefits usually brought by Agile off, it also quickly exhausts the credit of trust in Enterprise.