Measuring Code Quality

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.

Code Quality Metrics

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).

Maturity Grid

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%.

Advertisements

Shelter – MS Dynamics CRM Integration

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.

AAT – Strategy and guidance

aat logo

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.

AAT – Project rescue

To rescue an existing business systems/business change project.  To scope, define and deliver a new e-learning programme and revenue stream.

Reporting to:  AAT Directorate, Steering Group Committee.  Budget:  £3.5M. Development Teams: UK.   Team Members include: Drupal, .Net, and Java Developers, User Interface Developer, Testers, Designers, Business Analysts, and  Information Architects.  Suppliers:  30+.

Project status:  Success – Project Rescue delivered the business systems/business change project on time and to budget.  The AAT e-learning programme delivered 150+ products and platforms on time and to budget.

Scrum Guide 2011

The new 2011 Scrum Guide has been released!

Ken Schwaber and Jeff Sutherland, the co-founders of Scrum, have been working together and with the Scrum community on updating the official Scrum Body of Knowledge, the Scrum Guide. They have released this update through Scrum.org, the home of Scrum, and your source for Scrum training, assessment, and certification.

Check out the news here and the guide here

Project Documentation – How much is enough?

With Project documentation it is prudent to remember that less is often more. Consider who the documentation is for, why they need it and what they are going to use it for.

With those three pieces of information you can deliver good quality required reports that are useful to the individual.

Think about the type of document that you will use for your report. Word docs aren’t always the best. A graph or chart could show the required information more clearly and be more useful to the end-user.

The best way to achieve this is to scope the documentation that the project requires in the initial phase of the project. For each requested document ask for a user case. It is worth remembering that you may receive the answer:

“…because I said so…”

No matter who says this, dig deeper there must be a reason for each of the project documents.

You can always try defining and justifying project documentation using the ROI approach.  As a consultant they are paying for your time.  By having a user case for each of the project documents you can prove the value and the benefits in each case, this will ensure that the client is not paying for wasted time.

Results Focused Delivery – Keeping an eye on ROI

How do you deliver a whole list of product features?  There are two question that you should ask of the project:

What does the stakeholder think are the most important features?
What features benefit the business the most?

You will often find that the two sets of answers that you receive will not match up.  In many situations the key features for the stakeholders are those most important to them as an individual, not the most important to the business.  There may be certain things that they will have been tasked to deliver within the product that are linked to their yearly performance metrics and goals, so it is a fairly sure thing that they will push these heavily in order to reach their targets.

You on the other hand will have a scope that dictates the product backlog of business benefits that are required from the system and will need to deliver a mix of business benefits and stakeholder features.

How do you do this effectively?

Start to look at business benefits in terms of return on Investment (ROI) in order to create leverage,  you can do this through evidence based delivery.

Take an example of a software platform where a stakeholder requires a mobile application as an additional feature.  You have a target audience, your number of prospective downloads and the cost of developing the app.  If you discover the true cost of each download the ROI may not be at the level required by the business.  It therefore ceases to be an asset that adds benefit to the product.

If this principle of calculating fiscal value or business benefit is applied to the whole of the product backlog you can assign those items with the greatest ROI to the top of the list and give clear reasons for each in terms of value to the business.