Most software development organizations will at some stage see one or more of these issues (there are many more and if you ask your developers and testers they should be able to add to this list).
- Extent and correctness of the developer testing
- Stability of the code base which contains features to be released
- Resource limitations
- Lack of automated tests and mock objects at the class/method level
- Lack of understanding of requirements, design and technologies leading to delays and issues
- Lack of effective code reviews or code reviewers becoming bottlenecks to completing work
- Unmanaged complexity and coupling of the code base
So how do you encourage change within Kanban or Scrum?
The best way to do this is to start measuring what you value and would like to see improved. Identify your top impacts and break those problems down into feasible solutions. Make sure that you differentiate the symptoms from the root cause. By taking this approach you will help identify the metrics that will help you evolve change in your organization.
For example, if your release validation process is finding too many bugs that should have been picked up by your developers then this will impact the release validation cycle time. The knock-on effect will be less time for your QA team to do more varied testing and write automated acceptance tests. You will also start to see work build up if you have a 'Ready for QA' queue. To help encourage the developers to change their way of working you could implement a metrics program and certain other best practices.
- Measure the average cycle time for release validation
- Measure the number of bugs found by QA per KLOC
- Measure the number of unit tests written, executed and pass rate
- Measure the number of automated tests that are run as part of the daily build
- Measure the effectiveness of your continuous build integration
- Measure the effectiveness of build automated tests
Ken Schwaber said the following "The Scrum Master only has the authority to ensure that the Scrum Team follows the rules of Scrum .... The Scrum Master can coach, teach, establish learning situations, enter Socratic dialogue, and parent. However, they weren’t given the authority to manage the other members of the Scrum Team."
Should Scrum be tailored to such an extent so that the values are lost? We don't think so but that's a topic for another post.
To achieve organizational agility you not only have to focus on communication (the aim of the Agile manifesto) but you also need to deal with the impacts on the Software Development teams productivity. The best way to evolve change is to start a metrics program and publish the results. Even better set-up an employee incentive scheme as a result of the metrics so that new behaviours are rewarded and encouraged.
Don't forget to leave your comments!