Code quality is vital for true continuous delivery in an agile environment. Teams need to be sure that their code quality is at a standard that will not break the build in order to allow fast progression to live. Teams also need to ensure they have a good quality continuous integration / continuous delivery pipeline.
In order to assess code quality across the business you will need to set a baseline. From that baseline outline steps to show both the improvement of the team and of the business as a whole.
I used the grid below to work with my clients key service teams to create a code quality maturity baseline.
The example baseline table below gives clear indications of where effort was required for improvement 1. In each of the teams (Viewing vertically) and 2. where to focus effort across the business as a whole (Viewing horizontally).
Initially teams may be resistant, they may not want to discuss ‘code quality’ and have their service reviewed. Work with Senior Team members to make it clear that the purpose of the review is not for reprisal, but to see where the business is currently and how the collective could improve and deliver benefit to the customer. Combine this with a demonstration of the benefits of TDD (Test Driven Development), good Unit Test Coverage and the use of tools like stylecop and sonarqube through a working scrum team delivering shippable software on a two weekly sprint cycle to change attitudes.
In my experience, teams will began to look to the demonstration scrum team for ‘what good looks like’, joining the scrum ceremonies especially the retrospectives.
For my client, shippable code quality improved with the teams taking part in the programme. Commits did not progress if they broke the build and acceptable test coverage was set at 80%.
Well it kinda depends on what you want to show to your stakeholders:
Burn down charts are great for showing progress in a sprint. you can show Work in Progress (WIP), the actual burn and the ideal burn. These three will give stakeholders and team members a snapshot of where you are in your build. You can use it to give focus to certain areas to close the gap between ‘actual’ and ‘ideal’. Burn up charts show the amount of work remaining on a project and a projection of work completed based on the current velocity of the team.
Burn-down charts have the advantage that they’re simpler — they only show one line. However if you can stand a little complexity then I’d recommend burn-up charts as the more useful option for release management and stakeholder management.
Burn Down Charts
A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. The Scrum Master updates the values for WIP and actual burn after the daily standup.
Burn Up Charts
A burn-up chart tracks how much work remains on your project and whether you’ll hit your deadline. The vertical axis measures work remaining. The horizontal axis marks your iterations, and you should mark which iteration is your target end date for the project. After each iteration you mark your progress on the chart and you can project forward to see whether or not you’ll hit your target end date.
You can make burn up charts more sophisticated, showing several scope lines, one for each release milestone. This way the team and the stakeholders can see the effects of, say, moving scope from one release to another.
We are currently helping Shelter the housing and homelessness charity deliver one of their key principles, ‘helping more people’.
The implementation of an MS Dynamics CRM 2011 cloud service will reduce the current helpline administrators call processing time considerably allowing more advice to be given and easing the process of referring those who need help to the right internal or external service.
Agile Ninja is helping Shelter become more agile in their processes using the CRM implementation project as a launch pad for this change. A short delivery timeline with a non negotiable delivery date…lets get Agile.
What with all the recent news about the state of the economy it’s warming to know that the debt can be spread across so many areas.
Nigel Kneill of Indigo Blue poses this interesting slant on the buildup of debt on agile projects.
Debt on Agile projects is not just technical!.
I really like working with AAT. They are open to ideas, are keen to collaborate and eager to be on the cutting edge. That’s why I’m always ready to go back for more, recently I have been working with AAT delivering:
- Agile mentoring for internal Project Managers, problem solving and Senior Management/Directorate Team Guidance on new and existing agile projects. Including website rebuild and upgrade and CRM system upgrade. Working with Microsoft Dynamics, Drupal and .Net platforms.
- Strategic Planning for Professional, Education and Training and Marketing division business deliverables 2012/2013. Including recruitment, contract negotiation, process creation and implementation, escrow agreements and conflict of interest statements.
- Scope and creation of a new Product Development Team. Setting delivery roadmaps and centralising product development within the business.
- Scope and implementation of the Mobile Content strategy.
- Scope, definition and implementation of workstreams in a Drupal environment including Drupal commerce and Drupal scorm elements.
- Product development of CMS systems, e-commerce platforms, social forums, mobile applications and short courses.