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


Burn down or burn up – which is best?

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.


Dealing with the Change Curve

ChangeCurveWhen you implement a new technology platform some people will be on board and excited at the prospect of a new and usable product, other will be worried that their knowledge and skills will become redundant and the new product will cause problems, slow things down and make their life more difficult.

It is normal to find more of the latter than the former in any business. So how do you deal with the problems caused by the change curve?

It is important first to understand the reasons people are resistant to change:

  • The change will reduce my power base!
  • I will not let the center tell  me how to run my business!
  • What does this mean for me/my career path?
  • How will this affect my ability to influence?
  • Who will win from this?
  • I do not believe the change will actually improve performance!
  • How will this work?
  • I can not see how the savings will be made!
  • Is this “doable”?
  • How does this affect the people/things I care about?
  • Will we still be true to our values?
  • I’m not supporting anything developed by them which I haven’t contributed to!

How do you combat these?

Talk to your stakeholders find out who is most likely to be a naysayer and get them involved early. Rumors and bad opinions spread fast so getting those that are most likely to complain to feed into the project early is good.

Find out what peoples worries are, perhaps using a social platform like Yammer and give good quality reasons to dispel them.

Once you have the worries set up discussion groups with other more engaged end users on your social platform, bringing the two groups together in open discussion can be useful to win over those who are no quite as engaged as others.

Open conversation is key to show those who are most concerned by the change the inherent benefits.  Remember you can’t please all of the people all of the time, but if you can please most of them you are more likely to succeed.

Critical Success Factors in CRM

CRM2013I came across an article on Critical Success Factors in CRM:  Original article

I thought it might be useful to look at how one of my recent clients  CRM implementation compared against this critical success criteria.

The article stated that to achieve CRM technology deployment success requires a balanced approach. Focus on all four fundamental success factors:

Process. Nearly half (44%) agreed their CRM projects faced problems grounded in: poor or insufficient definition of business requirements; inadequate business process designs; and, the need to customise solutions to fit unique organisational requirements.

In my recent CRM implementation, well defined business requirements and early engagement of key users and stakeholders gave Shelter a good understanding of processes and user needs. The agile inspect and adapt development cycle gave my client the opportunity to tailor the solution early and drive the platform to deliver the key benefits.

Where a bespoke solution to a unique organisational requirement is required, concentration on the benefits and outcomes guided the initial development. Early end user involvement ensured that the bespoke solution met end user and business needs.

People. More than two-fifths (42%) agreed that their problems were “people” issues: such as slow user adoption; inadequate attention paid to change management and training; and, difficulties in aligning the organisational culture with new ways of working.

Again, early engagement of key users and the agile inspect and adapt cycle allowed my client to “listen and learn” from this issues of both the existing platform and the new CRM solution.

A communications plan for each of the Phased delivery User Group and the availability of the Project Team to answer questions and perform show and tell drove interest in the new CRM solution meaning users were quick to adopt the new way of working.

A Train the trainer approach to deployment and end user knowledge transfer meant that end user teams had a ‘SuperUser’ to turn to when getting to grips with the new platform. Regular feedback to the wider business from new users through the intranet is raising awareness in a positive light.

Strategy. Two-fifths (40%) agreed they had the challenges related to CRM strategy, such as: a lack of clearly defined objectives; poor solution deployment practices; and insufficient solution governance practices.

The phased approach to the CRM roll allowed the progamme team learned from each phase of the delivery and could therefore adapt the process to best serve its requirements and end users.

My client’s existing ‘benefits map’ give the programme delivery team clearly defined objectives to work towards for each of the end user groups. Regular update meetings with the Stakeholders, Project Team and Strategic Programme Board ensured that benefit targets and key milestones were met.

An Agile approach to development and rollout allowed my client to deal quickly and effectively with change management and prioritisation.

Technology. Only about one-third (35%) agreed they had technology deficiencies such as: data problems; functional shortfalls in vendor solutions; lack of the required skill sets needed to implement the solution; system performance shortfalls; and, poor usability.

My client used a recommended third party supplier and brought in the necessary skillsets that were missing from the core project team to implement the solution. The vendor and my client took time to work together to create an understanding of the business, its goals and the benefits required from the CRM solution, this helped define the criteria for the development of functionality.

I helped my client consider the technical infrastructure early in the project. One of the early goals was to define and deploy a hardware solution that would adequately support the CRM platform and improve the day to day experience for end users.

Early end user involvement in the development process has ensured good quality usability feedback could be incorporated into the development process.

Succeeding with Yammer

yammerImplementing a business collaboration network is all very well, but you have to give it direction otherwise after an initial burst of usage people will leave and return to more familiar surroundings.

As a stakeholder you can reduce the likelihood of this happening by considering how the business can best use the platform and what the driving force is behind the roll out.

At the outset of the Yammer journey each customer should define their “Yammer Vision” by answering the the following 6 questions:

  1. Why is the organization deploying Yammer at this time?
  2. How does Yammer support the organization’s Mission / Values / Strategy?
  3. How will Yammer change the organization?
  4. How will the organization know if Yammer is successful?
  5. How will Yammer benefit the overall organization?
  6. How will Yammer benefit every employee personally?

The “Yammer Vision” will help gain the support of the business and the Yammer champions can return to the Vision for ongoing direction after the initial usage has started to wane.

Shelter – Realising The Benefits

BenefitsFor the implementation of the MS Dynamics CRM system at Shelter we focused heavily on the benefits.

The key Helpline benefit benefit being a reduction in wrap time of 3 minutes per call. By Saving three minutes per call Shelter would then be able to help more people with the same volume of Helpline Staff.

We used this benefit as the focus for inspect and adapt workshops with the end users, prioritising those changes that would take us closer to the three minute goal.

The benefit has almost been realized on launch, with a wrap time reduction of 2:47 per call with the initial user testing against the same call on the existing system.