| (1) There has to be trust between management and people who do the work. You can get things done without trust but it is going to be expensive, late, broken, nerve-wracking, etc. You aren't going to paint process onto a low trust situation and see improvement unless the trust improves. I'm going to go out on a limb and say that close to 100% of the time when people are in agony over agile there is a lack of trust. (2) If you want to have good results you have to have a technical framework such that changes that management thinks are "a small change" are really a small change. Some people think agile means "not thinking ahead" -- you certainly shouldn't be borrowing trouble but you should be planning for sustained productivity which means that tomorrow's "small change" is not a 6 month project. This is not to advocate for some particular, language, framework, database, whatever but to say that, from a system level, you are designing on the expectation that you're going to be doing "sprints" on this thing for a long time and that you shouldn't need major re-engineering. (3) You've got to get realistic expectations about details, the "definition of done", etc. For instance does "finishing the sprint" mean that the developers throw a feature over the wall to testers? Or does that mean the testers say the feature is ready to go? If it's the latter, the testers will need to see the product long before the sprint is "over". Then what do the testers do before that? What do the coders do when the testers are testing? I'm not advocating for a particular right answer but that there has to be agreement on the team for something real. I have been on some teams where we often finish 2/3 of what is supposed to be on the sprint but we do a good job of not letting things get stuck so we solidly deliver features. There are other people who would blow a fuse if there were 15 items on the sprint and only 14 got done. (4) When it comes to very high velocity I think fixed length sprints are a problem instead of a solution. Sometimes there is a feature you could put in front of customers in two days but they have to wait two weeks because of the process. If there are multiple teams that have to line up with their own sprints a small delay can snowball into a big delay. In teams without trust people really stick to the sprint structure rigidly because it is all they have. The most effective teams will figure out how to to bend the sprint structure to overcome its limitations. |
There's one thing that I would like to challenge though, which is high velocity and sprints. I don't think those two things have much to do with each other. When you work in sprints you just promise that you will get those items you start out with by the end of the sprint. But as items get finished, they can also be rolled out to customers already if you have that capability. This capability depends on other things than the sprint boundary though.
I've been in places where we deployed once every sprint. Also where we deployed once every quarter. And where we deploy once something hits the main branch. The difference between these places regarding sprints? None, all three used 2 week sprints. But they differed in how automated and integrated testing and deployment procedures were. Deploying once a quarter was at a place where "QA" wasn't fully integrated into the sprints. So while we had automated tests and manual testing in each sprint, deployment could only happen after "regression testing", which was a "throw over the fence to another department" process and deployments were manual and required down time. Deploying once it hits the main branch? We have automated tests and manual testing w/ a fully integrated system for every branch. Deployments are fully automated and run on a schedule that picks up anything that was recently merged to the main branch multiple times a day. Nobody has to touch anything after hitting the "Merge" button on that PR. So if something's done two days into the sprint, it will go out. Have a bug that you fixed and got QA'd 4 hours into the sprint? Customers can have it in hand around hour 5 into the sprint.