The 2018 InfoQ Editors’ Recommended Reading List: Part Two

As part of our core values of sharing knowledge, the InfoQ editors were keen to capture and share our book and article recommendations for 2018, so that others can benefit from this too. In this second part we are sharing the final batch of recommendations

Source: The 2018 InfoQ Editors’ Recommended Reading List: Part Two

Episode 123: Some Principles of Lean and Product Development Flow with Don Reinertsen

The Agile Revolution Podcast

8265695783_995186c1ce_hCraig and Tony are at YOW! Conference and are privileged to spend some time with Don Reinertsen, who is considered one of the leading thinkers in the field of lean product development and author of numerous books including “Principles of Product Development Flow”

  • Principles of Product Development Flow” book and why there is a waterfall on the front
  • Japanese Manufacturing Techniques was the name before it was rebranded as Lean Manufacturing
  • Taiichi Ohno, the father of the Toyota Production System, hated math and thus preferred to sit on the factory floor and tweak processes, hence it was not a theory driven approach but rather empirically driven
  • Need to understand why things work so you can transfer it to other domains, a big shortcoming in lean manufacturing is that they don’t have much of a mathematical view on what they are doing
  • You can use magic in manufacturing…

View original post 264 more words

Lean Metrics & Time Tracking

Lean MetricsAt this month’s Agile Brisbane meetup, Ben Starr presented on Lean Metrics. His talk was based on metrics that they tracked at his previous company on an operational support team. A couple of points from the talk:

  • used Kanban – work item types to allocate capacity and 3 levels of service (standard, coordinated, expedite)
  • JIRA was the tool but was not the most ideal choice and not really up to the task
  • reported by type on backlog, work in progress, throughput (number of work items not size), velocity (throughput and velocity were similar which showed average size), cycle time, class of service mix, due date performance, estimation accuracy, cancelled WIP (started and then cancelled work) and demand balancing (clearing out the backlog)
  • flow efficiency – percentage of time you work on an item versus in progress, also referred to as touch time – using time tracking in JIRA to do this
  • time allocation – value add, failure load (defects), transaction cost (overheads of planning and releasing), coordination cost (management), used percentage of time spent rather than actual hours

The one things that got me thinking during this presentation was the flow efficiency report.

Early on my journey of being an Iteration Manager, my teams used to track times per card. We used to use XPlanner which had some reasoanbly easy functionality for tracking time (one of the good features was as the Iteration Manager I could enter time for my team if needed, tools like JIRA require the developer to record that data if you want it assigned to that developer). We used to use thee metrics for comparing estimates to actuals but over time I came to the conclusion that we would be much better off just making sure that the cards were completing on time (an average of 3 times) and splitting cards out if they appeared to big.

Lately, a number of people in my Agile classes have been arguing that time track is beneficial. My usual response to this (like for all metrics) that it is OK if it adds value, but my recommendation is not to waste your time. Even more so, this opens up the estimation debate that I also believe that a lot of time should not be wasted on (#noestimates), but that is a discussion for another post. My main reasoning is often we need to track for other sources (like timesheets) in different systems, and the overhead does not justify the effort. If teams need time metrics (often to see if time is being wasted away from the core work of the team, say on production support or corporate meetings), I suggest they are done at a team level and rounded to the nearest hour, and collected as time not spent not on project work.

In the graph above, flow efficiency is a good way for showing waste in the system (in this example, the team could potentially be way more effcient), but it relied on the team tracking time (in this case using the time tracking feature in JIRA against each card). I really like it as a graph, I am just not sure the effort to produce it is justified.

Some discussion in the Q&A revolved around recording time tracking (or similar metrics) is OK if the team understands it is an incentive for better metrics, and I can’t disagree with that thought. Just in my experience as an Iteration Manager, getting reliable and timely time and effort metrics ha been painful and the reward outweighed the effort.

Agile Encore 2013: Visual Management: Leading With What You Can See

AgileEncore2013My presentation from the Agile Encore 2013 conference called “Visual Management: Leading With What You Can See” is available on Slideshare.

Renee Troughton was unfortunately unable to join me to present this reprise of the talk we presented together at Agile Australia 2013.

Using task boards or story walls is a key Agile practice, but are you making the most of it? Visual Management is more than just putting cards on a wall, it is a growing style of management that focuses on managing work only by what you can see rather than reports or paper being shuffled around. Visual Management allows you to understand the constraints in the system, mitigate risks before they become issues, report on progress from the micro to the macro. Visual Management can also be used to demonstrate to customers and clients where the work they care about is at. This presentation is all about taking the management of your work to the next stage of transparency. Discover:

* How to identify when your story wall isn’t telling you everything and how to adjust it
* What the three different types of story walls are and which one is more suitable to certain circumstances
* Different ways to visualise your product backlogWhy queue columns and limiting work in progress is so important regardless of whether you are using Scrum or Kanban
* How symbols and tokens can be used to give more information
* What else can you use other than story walls to visualise information
* How to ingrain Visual Management into both the team and management structures of your organisation
* Visualising Your Quality, Testing and Team
* What is systemic flow mapping and why is it important

Unfortunately the talk was interrupted about three-quarters of the way through by a rogue video conference call into the auditorium. My attempt to try and answer questions why people were trying to fix the problem were interrupted by audio coming through the call. We soldiered on – but it interrupted the flow.

And here are some feedback from the feedback forms – much appreciated!

  • Lots of ideas
  • Very informative with real world examples
  • Delivered as per advertised. Was relevant and interesting to listen to. Some great take outs
  • More relevant to where we are as an organisation
  • Big wall
  • Most applicable as I am a newbie
  • Kept the audience engaged from start to finish
  • The task based techniques most relevant
  • Gave more understanding of how to do better Agile

 

Agile Australia 2013: Visual Management: Leading With What You Can See

Agile Australia 2013 Speaker ButtonMy presentation with Renee Troughton from the Agile Australia 2013 conference called “Visual Management: Leading With What You Can See” is available on Slideshare.

Using task boards or story walls is a key Agile practice, but are you making the most of it? Visual Management is more than just putting cards on a wall, it is a growing style of management that focuses on managing work only by what you can see rather than reports or paper being shuffled around. Visual Management allows you to understand the constraints in the system, mitigate risks before they become issues, report on progress from the micro to the macro. Visual Management can also be used to demonstrate to customers and clients where the work they care about is at. This presentation is all about taking the management of your work to the next stage of transparency. Discover:

* How to identify when your story wall isn’t telling you everything and how to adjust it
* What the three different types of story walls are and which one is more suitable to certain circumstances
* Different ways to visualise your product backlogWhy queue columns and limiting work in progress is so important regardless of whether you are using Scrum or Kanban
* How symbols and tokens can be used to give more information
* What else can you use other than story walls to visualise information
* How to ingrain Visual Management into both the team and management structures of your organisation
* Visualising Your Quality, Testing and Team
* What is systemic flow mapping and why is it important

Lynne Cazaly did an awesome visualisation of the talk!

We had some great feedback from people after the talk as well as via Twitter.

Renee also has a (slightly earler) version of the slidedeck online via her Slideshare, with one slide change and one omission…