[NewBie] Inherit and old project and trying to use Scrum
I just attended an online course on scrum and agile. I am inheriting an old project and now trying to continue the development but with agile/scrum approach.
one of the things I notice is that the old code is of very poor quality and we need to make fixes to this code in order to improve its quality.
But my online course told me that items in the backlog are linked to user stories and something which end user could see and use.
So how do I fix the quality issues?
one approach I thought was that I should have a "cleanup sprint"... but then my team argues that this is waterfall in disguise.
your ideas?
[do not flame me. I have just attended a 3 hour course online on agile ... apart from that I know nothing other than coding and development]
Hi Abhishek,
Those "fixes to the code" should be integrated in the work done on a user story and you fix only the parts you're working on... don't touch anything in another part of the code base. Of course, before touching anything you should write tests. This is called "The Boy Scout Rule": "Always check a module in cleaner than when you checked it out.". This rule should be part of the Definition of Done. Also read about the "Broken Windows Theory".
Always try to improve things as you go, incrementally. This will slow you down a bit (at least initially), but at least it won't bring the project to a halt at some point. Explain this to your Product Owner so that he is aware of the situation (the "transparency" pillar of Scrum).
Here are some web resources:
1. Boy Scout Rule: http://www.informit.com/articles/article.aspx?p=1235624&seqNum=6
2. Boy Scout Rule: http://pragmaticcraftsman.com/2011/03/the-boy-scout-rule/
3. Opportunistic Refactoring: http://martinfowler.com/bliki/OpportunisticRefactoring.html
4. Broken Windows Theory: https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy
5. Broken Windows Theory: http://blog.codinghorror.com/the-broken-window-theory/
6. Refactor vs Rewrite: http://www.joelonsoftware.com/articles/fog0000000069.html
7. Refactor vs Rewrite: http://www.ben-morris.com/why-refactoring-code-is-almost-always-better-…
8. The Tiger Team: http://www.objectmentor.com/resources/articles/Clean_Code_Args.pdf
(search for "tiger" in the pdf and read that story)
And some books:
1. Clean Code (Robert C. Martin)
2. Working Effectively with Legacy Code (Michael Feathers)
3. Refactoring (Martin Fowler)
4. Pragmatic Programmers (Andrew Hunt)
Hopefully these links and books will give a starting point for your team.
Hi Abhishek,
you can write Product Backlog Items (PBI) for the quality issues. There is no rule against this.
Every sprint has to deliver at least some functionality which the end user can use, but this does not apply to each PBI.
A cleanup sprint probably won't help you, because you would need plenty of them, and wouldn't deliver anything for end users. But what you can do is
1. stop creating more technical debt (quality issues). Start to write clean code and find ways to measure quality (static code analysis).
2. bring your Product Backlog in shape, including the quality issues, and plan some of them next sprint planning.
3. repeat from 2.
Yes there is no exit condition. Quality is not a state but a process.
Good luck!