Monday, 21 January 2013

Maximizing Flow - Lean Agile Team Productivity

Software Development Productivity
Do you know what impacts your teams productivity?  Whether you're passionate about Kanban or Scrum you will want to avoid bottlenecks and maximize the flow of work.  To do this it is vital that there is an understanding of the impacts to team productivity.  If you don't know what your impacts are then STOP and take a step back.

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

  1. Extent and correctness of the developer testing
  2. Stability of the code base which contains features to be released
  3. Resource limitations
  4. Lack of automated tests and mock objects at the class/method level
  5. Lack of understanding of requirements, design and technologies leading to delays and issues
  6. Lack of effective code reviews or code reviewers becoming bottlenecks to completing work
  7. Unmanaged complexity and coupling of the code base
Most of these issues are team problems that can be solved by the team. Be careful that these issues are not used as excuses or blockers to change!!!

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
In many corporates you will also come up against organizational issues that impact development teams such as dependencies on other departments.  In this situation many developers will want  a manager to deal with these issues as these issues can involve a degree of hassle. Within Lean/Kanban this is fine as more traditional roles, such as a Project Manager, are respected.  However, if you have implemented Scrum then you need to be careful not to break the values behind this project management method by using managers to deal with these issues from the start. 

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!

1 comment:

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


If you have any feedback that will add value to this blog then please go ahead and leave your comments!