It's hard. Certainly much easier to say than to do, right? We keep failing at this. Actually, "failing" is maybe a bit harsh so let me rephrase; we're not as good as I think we should be.
The problem is in how we look at the code we write and the work we do; and what values and expectations we lay in the term "Done" (or "Releaseable"). We want to finish what we start. Even the Definition of Done (DoD) tells us that it should be "finished". Our Definition of Done says "Releaseable" (more or less). This should be your DoD too, by the way. So the team sits there with a bunch of stories to produce and knows that the DoD says that it should be "releasable". A natural reaction, given every developer's pride in work, is to focus on delivering something that is really fully "releasble", meaning "great". Or often "perfect". When all the DoD really (read it again if you don't believe me :-)) says is "releasable".
But here's the problem: "Finished" doesn't mean "Complete".
What we fail to do is to remember that the Definition of Done only requires us to deliver something that is possible to release. No more and no less. It doesnt say anything about the code being in super shape, future proof or completed-once-and-for-all-for-all-eternity-never-to-return-to-again. On the contrary; Scrum and Agile development is all about iterative, incremental work. It is about continous refactoring. It is OK, it is even expected - even required - for us to go back to code and add new stuff and kill off or change things done in previous sprints.
Forget about trying to do everything right from the start. Try and look only as far as the sprint length is - as far as your current sprint goal. That is what we need to focus on. We do what we need to now, in order to make what we're currently committed to - then we come back next sprint and add to and refactor what we previously did. It's ok - it is not something to avoid: it is something to strive for!
Another thing to consider is the following: isn't it great to be able to refactor your code, continuously? I know since my programming days, I really loved it when I got a chance to refactor my own code. This, I think, because I learned stuff when I originally wrote it - so I know how to make it better when I rewrite it. And I think most people love the feeling of making something better.
Finally, I also want to mention something I picked up when speaking to a scrum coach the other day: refactoring a few years ago really could be a pain, due to the poor development environments. But today most major IDE's and code-writing tools have great support for refactoring; in a matter of minutes you can make changes to tens or even hundreds of files. This is something that I will definately look into in our organization; what support for refactoring do we have in our development environment(s), and what better tools are out there?
Scaling Agile @ LEGO and Spotify – my talk at EA träff - Here are my slides from today’s talk “Scaling Agile @ LEGO and Spotify” at EA träff in Stockholm (EA = enterprise architecture). Fun to hang out with enter...
1 week ago