Sunday, May 26, 2013

Agile Development with debt ridden code

Is your code base as messy as this kitchen?



If it is, I am sure it will be slowing you down. Working on technical debt ridden code is very hard to do in an agile way.

This is because the debt: 

  • Limits our ability to easily cut scope to meet our deadlines. (Caused by Coupling)
  • Makes it hard to split the work into small user stories. (Caused by Coupling)
  • Makes it hard to predict when we will be done. (Caused by lack of tests, coupling, defects, unexpected side effects)
  • Limits our ability to work fast, while maintaining high quality (Caused by all types of debt, especially debt with the tests)

Technical Debt that impacts our ability to delivery consistently:

  • Tight coupling
  • Design that limits extensibility
  • Inconsistent design
  • Inconsistent coding style
  • Existing defects, especially hidden/unknown defects.
  • Lack of automated tests
  • Unpredictable/ inconsistent test results 
  • Slow tests 

Recommendation One: Focus on Fast, Reliable Automated Test Results

The aims are to improving the quality & scope of our test suite, along with obtaining faster feedback. Fast, reliable feedback allows the team to work towards their sprint goals in small controlled steps and this improves reliability of delivery. 

Here are my specific tips to achieve these aims:

  • Run the test suite more often. Once a day is rarely fast enough, aim for at least three test suite runs during working hours, more is even better.
  • Increase granularity of reporting; ensure that all tests report their results separately. Watch out for 1 test failing that stops several other tests from running; this results in secondary defects being hidden until the defect causing the first test to fail is resolved.
  • Split up the test suite into separate tests or test groups; run them in parallel on separate environments. You may need to acquire more environments. This does a couple of things; it removes dependencies within the test suite which will likely identify some hidden defects. Secondly it will greatly reduce the overall duration of the test suite resulting in faster feedback.
  • Get faster hardware to run the tests on, resulting in faster feedback.
  • Add more environments, with at least one environment per team; giving flexibility of when/who runs the tests, resulting in faster feedback.
  • Set standards of how tests and test suites are structured. Ensure all new tests are developed to the standard and any exist tests that are ‘touched’ are updated to the new standard. Over time this will improve the quality of the entire test suite.
  • Improve the reliability of the test suite by identifying and removing intermittent tests. Refer to Martin Fowlers excellent article on Non Determinism in Tests for specific approaches to removing intermittent failures.  Also run the test suite on isolated hardware to remove outside influences. 
  • If your tests are running over night, identify regular IT maintenance work that could be impacting on your test results. For example database backups that greatly reduce the speed of the database.
  • Enforce that all new development work has automated tests that cover that work. This is not just for new features/components. Any work on existing code must have tests added, if there are no tests for that area of the code, they may have a substantial piece of work to do. However it does not take long for the extra effort to start paying dividends.

Recommendation Two: Incrementally attack the debt

Fast, reliable feedback allows the team to engage in effective refactoring.  This in time allows them to reduce coupling with their code and also reduce other types of technical debt, which further increases their reliability of delivery. 

With our Fast, Reliable Test Suite in place it is now time to start attacking the debt:
  • Revise the existing Coding standards with a focus on decoupling and consistency. Ensure all new code is developed to the standard and any exist code that is ‘touched’ is updated to the new standard.
  • With each new piece of work that the team is about to start, get them to think about technical debt that is related to this work. Investigate the debt, make it visible, do a cost benefit analysis for the reduction of that debt and involve the Product Owner.


Do you have any other tips for working in these difficult situations?

Photo Credit: independentman    

Monday, May 20, 2013

Transforming the Scrum of Scrums and Delegating Release Co-ordination


“The agile manager’s scariest move; handing over responsibility”

Once we* had our Delivery Teams regularly delivering increments of valuable working software; the management team made the tough call of pushing the responsibility for co-ordination of releases to the Delivery Teams. This blog post follows this decision through its successes and failures and explains how we adapted to the feedback we received and issues that we identified.

*The Royal we: Management Team, Transformation Team, and Coaching Staff.

Attempt 1 – Complete freedom

A meeting was arranged by the management team to announced to the Scrum Masters (and a few other stakeholders) that as part of the ongoing transition the Scrum Masters must step up and take ownership and responsible for co-ordinating our quarterly releases. After this meeting the management team deliberately sat back and let the Scrum Masters sort it out themselves.

The Scrum Masters held a brief meeting to decide how they would handle the situation. They quickly selected two Scrum Masters to lead the co-ordination effort. One of them took the lead and did a great job of co-ordinating the release, which went out on time and to the quality we had aimed for. There was plenty of room for improvement but no major disasters.  

While the Scrum Masters were comfortable with this change, the management team quickly lost visibility of any issues that were occurring and at the same time were getting feedback from many staff members about a lack of communication between the Delivery Teams.

Another couple of issues popped up, which told us another approach was needed for the next release: 
  1. The Scrum Master who lead the co-ordination of the previous release was promoted into the management team. 
  2. The other Scrum Master who had been involved was currently swamped with practice improvement work. We were not sure who would step up to the take the reins.


Attempt 2 – PMO established Scrum of Scrums

With issues around lack of visibility, low communication between teams and concerns about how repeatable our previous success was, the management team decided that they needed to act.

At this point in time the culture had moved from ‘responsibilities being assigned to individuals’ towards ‘responsibilities being assigned to teams’. Looking at our current issues the decision was made by the management team to rotate the responsibility for Release Co-ordination between Delivery Teams each release, along with establishing a Scrum of Scrums as a status reporting, cross team communication and impediment removal approach.

To get things moving quickly our PMO manager booked a weekly meeting with the Scrum Masters, during which they were asked what the status was of each release that was in progress (we have 1 or 2 maintenance releases and 1 feature release in progress at any one time). The Scrum Masters saw it as the PMO meeting and were fearful of raising issues at the meeting, as those issues would then be forwarded onto the management team. The Scrum Masters thought that any issues that were raised made them look bad, meanwhile the management team was hanging out to know the real status of the releases, so that they could help wherever was needed. This fear or lack of a ‘Safe to Fail’ environment was addresses separately (and is perhaps the topic of another blog).

With the PMO established Scrum of Scrum operating, the management team continued to receive feedback that there was not enough team to team communication, however we did start to get some issues raises and did get some feeling for how well the releases were going (and they were going well). We were still concerned that the level of ownership of Release Co-ordination was not as high as we needed it to be.

Attempt 3 – Scrum Master established Scrum of Scrums

With Attempt 2 still not providing the results we wanted, we decided to intervene by re-invigorating the ‘SOS’ (this unfortunately meeting name was one of the first things to go).
To kick off the change our two Engineering Managers (who have responsibilities around People and Practices) each talked one-on-one with the Scrum Masters that reported to them. 

They asked about the Scrum Masters view of the SOS meetings and set out some clear expectations around team to team communication, Scrum Master to team communication, the raising of issues, ownership of release co-ordination and running the Scrum of Scrums. Lastly they were told that a meeting would soon be organised with all of the Scrum Masters where they would have to work out how they would re-invigorate the Scrum of Scrums.

I facilitated the meeting with the Scrum Masters and the Engineering Managers in attendance. We started with one of the Engineering managers setting down the expectations regarding the Scrum of Scrums:
  • Raise team specific risks, so that the other teams are aware and can assist.
  • Explain what each team is doing, so that the other teams are aware and can assist.
  • As a group uncover big risks and either deal with them or escalate them.
  • As a group review and understand commitments especially those with specific dates.




Goals of the Scrum of Scrums


Once those expectations were clear we got down to the business of the Scrum Masters deciding what information they needed to be able to meet those expectations, how the meeting would be organised, when it would occur and who should attend.

Self selected actions for making the Scrum of Scrums effective


In summary they decided upon:
  • All Scrum Masters and the PMO manager would meet weekly on a Monday after all of the Stand Ups were completed. No other people had to attend, however back up Scrum Masters and the Lead Architect was optionally invited.
  • Using a large highly visible planning board, showing all teams, all key user stories, dates, etc.
  • A simple agenda: Each Scrum Master presents in the order shown on the board, and then any issues/news is discussed as a group.
  • Each Scrum Master was responsible for keeping their team’s row up to date.
  • One volunteer would create the first Scrum of Scrums board.


Multi-team release planning board


Continuation / Tuning

The first meeting went reasonable smoothly, a due date was clarified, a risk was discovered and they discovered two teams that needed to co-ordination on a user story. A few tweaks to the board where suggesting, including using a consistent colour coding scheme.

The next few meetings were tentative affairs as each Scrum Master was ‘feeling out’ how they should behave in this new situation.

The fifth meeting seemed like they were starting to get off track and just running through the motions of an ineffective status update meeting.

Multi-team release planning board


The sixth meeting had some minor cross team concerns discussed. A couple of teams had let their information get out of date, with only one user stories up for the current sprint. The major issue was that we were fast approaching a critical release date, and there was no communication around the status of features that had been committed in the release. It seems like the Scrum Masters were not considering the whole release as much as was hoped by the management team. This prompted a lot of one-on-one discussions and feedback sessions, which thankfully all hit the mark.

Seventh meeting: Great, they are really getting it, taking ownership, asking questions, self-organising. The teams that last week only had one card had added all of their planned user stories and provided more detail in their summaries; this triggered conversations and overall seemed successful.

The Eighth meeting was held part way through the first sprint of our new Release cycle. The board had the next 4 to 5 sprints filled in for most teams (only at a high level for sprints 2 to 5). As a group they spotted three key issues and quickly resolved them. It looks like the Scrum of Scrums is working and is here to stay.

Multi-team release planning board, after several evolutions

Monday, May 13, 2013

Coaching Scrum Masters


In my coaching work, I find that any effort I put into coaching Scrum Masters pays itself back many times over. The Scrum Master is able to take their improved knowledge and apply it to their team which has a compounding effect. With the Scrum Masters fulfilling their role well the teams can hit their stride earlier and I can focus on key individuals and organisational issues.


Growth in people


In this blog post I explained my approach of providing direct feedback to Scrum Masters based on the Scrum Activity that they just facilitated. That approach has served me well; however it was not always been smooth sailing. I have learnt a few lessons along the way. From my successes and lessons I present to you a list of ‘Trys’.

The basic approach is to observe the Scrum Activities (Planning, Review, Retrospectives, Stand ups) and provide feedback directly to the Scrum Masters. Focusing on the Scrum Activities helps the Scrum Masters to quickly come to terms with the most visible aspects of Scrum. With these visible aspects under control, they can move on to learning about the more ‘behind the scenes’ aspects.


Prior to the activity


  • Try asking for permission from the Scrum Master to attend the activity. This serves several purposes; it helps to bring the Scrum Master onside ready to receive your feedback, it gives you a chance to ask the Scrum Master to explain your presence to the attendees at the start of the activity, and it allows you to book in a time to provide the feedback promptly after the activity.



During the activity


  • Try having the Scrum Master explain to the attendees as part of setting the scene for the activity; that your presence is to provide feedback to the Scrum Master and help them improve; it is not to grade the team. This goes a little way towards the attendees being more open in your presence.
  • Try taking plenty of notes during the activity. Making sure to record specific examples of the incident that relates to the feedback you want to provide. i.e. During a Retrospective ‘Need to drill into symptoms to find root cause’, would be better recorded as ‘John said the tests where taking too long; you should have asked why are they taking so long, before getting the team to come up with a Try.”

After the activity


  • Try to meet with the recipient promptly after the event. The same day is ideal, the next day is ok. With the event fresh in your minds you will both be better placed to discuss specific examples.
  • Try keeping your feedback to around five key points or less. Any more then that will be hard for the recipient to take in during the feedback meeting. I often look at my page of notes and mark a couple of good points and a couple of the areas for improvement, making sure to only mark five points or less.
  • Try meeting in private, this encourages the recipient to be more open and frank with you, especially when talking about their interactions with other people.
  • Try starting the feedback meeting by asking them what they thought of the event; their answer is often enlightening. Some times they may already have internalised the feedback that you intended to give them, they may have seen the activity completely different to you, they may have had some insight into why people did what they did, they may offer up some issues that gives you a great opportunity to drill into.
  • Try to discuss all criticisms in a constructive way. They should be presented as areas for improvement. E.g. ‘You did not stop the ongoing discussion about how to design the widget, that discussion was wasting the team’s time.’ would be better phrased as ‘The ongoing discussion about how to design the widget, could have been cut short and taken offline. This would have saved several minutes for the team. Perhaps next time a discussion is occurring that only involves a couple of people goes for over a minute of two, you could politely ask them to take it offline? Would you be comfortable doing that?’
  • Try using the Feedback Sandwich:  

  1. Start with positive feedback (Praise).     
  2. Discuss areas for improvement (Constructive Criticism)     
  3. Wrap up with more good stuff or general encouragement (Praise).

  • Try to discuss all praise and criticisms based on recent and specific examples. E.g. ‘It would be good to see you support the voice of the quiet people in the team’ would be better as ‘When Ronald started to talk about his issues with the documentation being out of date; it would have been a great opportunity to support a quiet voice in the team by agreeing with him and asking the team to discuss it further’.


Good luck giving out your feedback and seeing your Scrum Masters grow. Let me know if any of these try's worked for you. I am also keen to hear about any that backfire for you.

Photo by: Kris Anderson