
Modern Tooling and Scrum
Without using modern tools and practices, Scrum may not be delivering what it promised
– increased transparency
Boards not showing the progress that is being achieved (people don’t know how to split tasks so that they move in 1 day) which also makes burndown charts become useless.
– increased velocity
Test activities might need freezes(!)
Big crunches on test effort in the last days of the sprint with multiple or even all the user stories being delivered to testing together
Operational overhead increases due to release activities taking too much effort they are performed as few times as possible….
All these problems are solved using modern techniques.
Ken knows this, here he is talking about it
[embedyt] http://www.youtube.com/watch?v=WMgch8BxSWw[/embedyt]
In his words, the biggest challenge to scrum is learning the tooling and practices that you NEED to use to get the most out of scrum. He was surprised that most developers could not use these tools he has endorsed courses and training is now offered as part of his scrum organisation.
Practices Mentioned by Ken
The fundamental skills
— refactoring
— test driven development
— acceptance test driven development
— code coverage tools;
Refactoring
Refactoring increases agility because it makes code much easier to read. In a first coding pass through our solution we are focused primarily on achieving the solution, not readability – reviewing this code a week later might lead you to complain about the developer who wrote it only to painstakingly realize that it was you the wrote it. It contains oddly named variables, duplicated code, bad practices, and the time it takes to re-understand your code is much larger than necessary.
This is why we perform a second refactoring pass of the code, to focus on readability.
It removes code smell, increases readability and removes bugs. Do it shortly after the first pass.
Refactoring with unit testing is a match made in heaven, think twice before attempting 1 without the other.
Test Driven Development (TDD)
TDD creates clarity on the board and maximizes the number of developer working on the same story, allowing it to be done within a few days instead of having 5 or 6 user stories open for the entire sprint, performed by different developers, leading to a huge crunch on test capacity since they must all be tested at the same time.
User stories are more easily planned and burn downs are more meaningful! (A symptom of a meaningless burndowns are other types of burndown charts that burn time instead of tasks).
Acceptance Test Driven Development
Personally my favorite, simply get the tester to give a NAME/TITLE what they believe the acceptance test is DURING refinement.
Is of particular use if the user stories are malformed somehow. Eg:
“As a project manager i would like a service that loads street addresses so that we maximize the locations where we sell our products”
Acceptance criteria:
1. attached file is loaded
Doesn’t really mention the user does it?
insert test name(s) during refinement and we quickly draw attention that we need a newly worded user story…
“As a project manager i would like a service that loads street addresses so that we maximise the locations where we sell our products”
Acceptance criteria:
1. attached file is loaded
Acceptance tests:
1. products xxx, yyy are orderable for postal codes xxxxx – yyyyy
2. business and wholesale departments see different products
3. bulk ordering continues to work.
Practices Not Mentioned by Ken
Continuous delivery and Release Automation
You must log in to post a comment.