Three separate teams are all working on pieces of the same project at the same time. They’re working with micro-services in individual containers so the teams can develop independently of each other except when there are true dependencies.
Why do I still hear people complaining that their stack of containers just broke? Each individual manages his or her stack, so why can’t they work with a stable set of containers except the one they’re developing on?
It seems the reason is we’re all in a hurry because we have to finish something every Sprint. We rush to accept un-proven containers so we won’t fall behind, and fall behind as a result.
I’m going to give you the punch to this post right up front. If you’re cutting corners on good practices to get things done, you’re doing it wrong.
It doesn’t matter what your particular issue is. For some it’s merging code directly into the release branch without testing. With others it’s not completing the unit tests. Still others don’t have time to document what they’ve built (to the level of documentation agreed by the team.) Too many of our people are convinced they don’t have time to finish the work. They can’t wait, the feature is too important, this is a small change, I have to get this bug fix to QA, the list of excuses is long. The list of problems caused by rushing is longer.
There’s a reason Scrum asks a team to define its Definition of Done. It’s so these issues don’t become questions. Unit testing completed, documentation written, code reviewed, these are all things a team can agree on up-front. Once agreed, team members should work on their Stories until they’re done, not cut corners to turn in their work quicker. If they don’t finish, it’s not finished and the bill will come due at a much more expensive time.
As much as it feels backward, if you really want to get a lot of work done in your Sprints slow down and make sure you finish everything you start according to your definition of done. There’s no better way to keep up at Sprint speed than to pick up a Story, finish it, and put it down. If you try to juggle Stories, writing code for several then writing unit tests for several, you’ll only slow yourself down. And if you talk your team into accepting the Stories because they’re functionally complete, you’ll pay a serious penalty later. You may have every intention of completing those unit tests, but you won’t. Once you start letting new functionality trump unit tests, you’ll never stop.
So, if you want to work at Sprint speed, pick up a Story, FINISH IT, and put it down. If you don’t, you’ll lose it later when you’re solving the problems you left behind.