Listen Now

Subscribe on iTunes                   Check out the podcast on Google Play Music

Software Process and Measurement Cast 400 features our interview with Jim Benson. Jim and I talked about personal Kanban, micromanagement, work-in-process limits, pattern matching, pomodoro and more. A great interview to cap our first 400 episodes!

Jim’s career path has taken him through government agencies, Fortune 10 corporations, and start-ups. Through them all his passion has remained consistent – applying new technologies to work groups. In each case asking how they can be leveraged to collaborate and cooperate more effectively. Jim loves ideas, creation, and building opportunities. He loves working with teams who are passionate about the future, pushing boundaries, and inclusion. His goal with all technologies is to increase beneficial contact between people and reduce the bureaucratic noise which so often tends to increase costs and destroy creativity.

Jim is the author of the Shingo Research Award winning book Personal Kanban (use the link to support the podcast) . He is a noted expert in business process, personal work management, and the application of Lean to personal work and life. Jim believes that the best process is the least process necessary to achieve goals. He has zero tolerance for process waste.

All said, Jim enjoys helping people and teams work out sticky problems, an advocate of people actually seeing their work, and inventing new ways to work at the intersection of Lean thinking, brain science, and leadership. (more…)

Listen Now

Subscribe on iTunes                   Check out the podcast on Google Play Music

The Software Process and Measurement Cast 397 features our essay on cumulative flow diagrams.  A CFD can help everyone from team members to program managers to gain insight into issues, cycle time and likely completion dates. Cumulative flow diagrams are extremely versatile tools for managing work.

Download the figures that support this essay.

Our second column is a visit to the QA Corner. Jeremy Berriault weighs in on the thorny question of who signs off or approves the results of testing for projects. We discuss some strange behaviors that occur when responsibility and authority for the results of testing are ambiguous.

We also have the debut column from Jon M. Quigley. Jon inaugurates his column with a discussion of whether project risk, scope, and strategy are related.  The short answer is yes, and the longer answer suggests what happens when all of the options are not considered.  Jon is a principle at Value Transformation, LLC (www.valuetransform.com) along with being a teacher, coach, serial author and past guest on SPaMCAST 346. (more…)

Listen Now

Subscribe on iTunes                   Check out the podcast on Google Play Music

The Software Process and Measurement Cast 396 begins our run up to Episode 400 with our interview of with Mike Burrows.  Mike and I talked about his game changing idea of Agendashift.  Agendashift Identifies opportunities for positive change by exploring an organization’s alignment to the values of transparency, balance, collaboration, customer focus, flow, and leadership.  Along the way, we also revisited parts of our previous interview on the podcast covering Mike’s book, Kanban from the Inside (Kindle).

Mike’s Bio

Mike is the founder of Agendashift, author of the book Kanban from the Inside, consultant, coach, and trainer. In recent months, he has been the interim delivery manager for two UK government digital “exemplar” projects and consultant to public and private sector organisations at home and abroad. Prior to his consulting career, he was global development manager and Executive Director at a top tier investment bank, and IT Director for an energy risk management startup.

Agendashift Blog: https://www.agendashift.com/
Twitter: @asplake and  @KanbanInside (more…)

1


The simple cumulative flow diagram (CFD) used in Metrics: Cumulative Flow Diagrams – Basics  and in more complex versions provide a basis for interpreting the flow of work through a process. A CFD can help everyone from team members to program managers to gain insight into issues, cycle time and likely completion dates. Learning to read a CFD will provide a powerful tool to spot issues that a team, teams or program may be facing. But to get the most value a practitioner needs to decide on granularity, a unit of measure, and time frame needed to make decisions.
(more…)

Picture of the book cover

Commitment

This week we are back to our read of Commitment – Novel about Managing Project Risk by Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016) .  Chapter 4 introduces more agile techniques, including work visualization, staff liquidity and a focus on outcomes. (more…)

Waterfall

A waterfall is an example of a complex flow!

The simple cumulative flow diagram (CFD) used in Metrics: Cumulative Flow Diagrams – Basics introduces most of the concepts needed to read and use a CFD. However, software development, regardless of the size of the work or the method used, is more complicated.  CFDs adapt to the true complexity of software development. CFDs allow teams and managers to visualize the flow of work . (more…)

A Cumulative Flow Diagram (CFD) is a measurement tool for tracking and forecasting work. CFDs are typically associated with Kanban, however, it can be used as a measurement tool for any type of work.  In its simplest form, a CFD is a set of measures that are presented in a visual form.  A simple version of a CFP shows the amount of work that has been completed, how much work is in-progress, and the amount of work still to be done over time. (more…)

 www.spamcast.net

                                 www.spamcast.net

Listen Now

Subscribe on iTunes

I am still on vacation (at least for a few more hours), and this week we have another mixtape for you. This week I have included the responses to the “if you could fix any two (or sometimes one) things” question I ask at the end every interview from the three most downloaded interviews of 2014. The top three were:

SPaMCAST 302 featured Larry Maccherone. Larry’s two wishes were:

  1. That we unlearn the natural tendency to look at how a number can be gamed rather than how it can be used.
  2. That he had access to all data and infinite time to analyze the data.

Listen to the whole interview with Larry!

SPaMCAST 318 featured Rob Cross. Rob wished that:

  1. Organizations would realize it is not the tools rather it is the data that counts.
  2. Organizations need to change their culture to focus on security.

Listen to the whole interview!

SPaMCAST 310 featured the return on Mike Burrows.  Mike only had one wish this time:

  1. Development organizations need to embrace balance as a value.

Mike made the list two years in a row! Listen to the whole interview with Mike.

If these excerpts tickled your fancy listen to the whole interview by clicking on the links shown above.

Next week we will return to regular programming with our essay on Agile Project Charters.

Listen Now

Subscribe on iTunes

I am on vacation for two weeks and could not leave you without some Monday morning mind candy, therefore, we are doing two very special shows this week and next.  This week I have included the responses to the “if you could fix any two (or sometimes just one) things” question I ask at the end every interview from the three most downloaded interviews of 2013.  The top three and one extra were::

SPaMCAST 224 featured Mike Burrows. Mike focused his wishes on:

  1. Changes agents need to take their role as change agents seriously.
  2. Delay is expensive.

Link: http://spamcast.libsyn.com/s-pa-mcast-224-mike-burrows-kanban-values

SPaMCAST 246 featured Tobias Mayer. Tobias focused his wish on:

  1. People, not management or consultants, need to own scrum. (One wish was enough for Tobias)

Link: http://spamcast.libsyn.com/s-pa-mcast-246-tobias-mayer-t-he-people-s-scrum

SPaMCAST 270 featured Alan Shalloway.  Alan focused his two wishes on:

  1. Everyone needs to acknowledge there are laws of software development.
  2. Assuming that everyone involved in delivering software is highly motivated.

Link: http://spamcast.libsyn.com/s-pa-mcast-270-alan-shalloway-sa-fe-lean-kanban

And just because I could . . . a bit of lagniappe, SPaMCAST 138 Featured Jo Ann Sweeney. Jo Ann focused her wishes on:

  1. Reminding the listeners that change often starts before IT starts a project there we need to listen carefully to the stakeholders.
  2. Project teams should care about end users.

Link: http://spamcast.libsyn.com/s-pa-mcast-138-jo-ann-sweeney-communication

If these excerpts tickled your fancy listen to the whole interview by clicking on the links shown above.

Next week the best excerpts from 2014!

Sometime the intangible obscures the tangible.

Sometime the intangible obscures the tangible.

In the Software Process and Measurement Cast 37, Kenji Hiranabe suggested that both software and the processes were intangible and opaque.  In SPaMCAST 36, Phil Armour put forth the thought that software is a container for knowledge.  Knowledge is only tangible when demonstrated, or in software terms, executed.  Combining both ideas means that a software product is a harness for knowledge to deliver business value; delivered using what is perceived to be an intangible process. The output of the process is only fully recognizable and testable for the brief period that the code executes. On top of all that, there is every expectation that the delivery of the product will be on-time, on-budget, high quality and be managed and orderly.  No wonder most development managers have blood pressure issues!

Intangibility creates the need for managers and customers to apply controls to understand what is happening in a project and why it is happening.  The level of control required for managers and customers to feel comfortable will cost a project time, effort and money that could be better spent actually delivering functionality (or dare I say it, reducing the cost of the project).  Therefore, finding tools and techniques to make software, and the process used to create software, more tangible and more transparent to scrutiny, is generally a good goal.  I use the term “generally” on purpose. The steps taken to increase tangibility and transparency need be less invasive than those typically seen in command and control organizations. Otherwise, why would you risk the process change?

Agile projects have leveraged tools like WIKIs, standup meetings, big picture measurements and customer involvement as tools to increase visibility into the process and functional code as a tool to make their knowledge visible.  I will attest that when well-defined Agile processes are coupled with proper corporate culture, an environment is created that is highly effective for breaking down walls.  But, (and as you and I know, there had to be a “but”) the processes aren’t always well defined or applied with discipline and not all organizational cultures can embrace Agile methods. There needs to be another way to solve the tangibility and transparency problems without resorting to draconian command and control procedures that cost more than they are normally worth.

In his two SPaMCAST interviews, Mr. Hiranabe laid out two processes that are applicable across the divide defined by waterfall and Agile projects.  In 2007 on SPaMCAST 7, Kenji talked about mind mapping.  Mind mapping is a tool used to visualize and organize data and ideas.  Mind mapping provides a method for capturing data concepts, visualizing the relationships between them and, in doing so making ideas and knowledge tangible.  In the SPaMCAST 37, Kenji proposes a way to integrate kanban into the software development process.  According to WIKIPEDIA,  “Kanban is a signaling system to trigger action which in Toyota Production System leverages physical cards as the signal”.  In other words the signal is used to indicate when new tasks should start, and by inference, the status of current work.  Kenji does a great job at explaining how the kanban can be used in system development.  The bottom line is that the signal, whether physical or electronic, provides a low impact means of indicating how the development process is functioning and how functionality is flowing through the process. This increases the visibility of the process and makes it more tangible to those viewing from outside the trenches of IT.

Executed code that does what was expected is the ultimate evidence that we have successfully captured knowledge and harnessed it to provide the functionality our customer requested.  The sprint demos in Scrum are a means of providing a glimpse into that knowledge and to build credibility with customers.  However if your project is not leveraging Scrum, then daily or weekly builds with testing can be leveraged to provide some assurance that knowledge is being captured and assembled into a framework that functions the way that you would expect.  You should note that demos and daily builds are not an either/or situation.  Do both!

The lack of tangibility and lack of transparency of the process of capturing knowledge and building the knowledgeware we call software has been a sore point between developers and managers since the first line of code was written.  We are now finally getting to the point where we have recognized that we have to address these issues; not just from a command and control perspective, but also from a social engineering perspective.  Even if Agile as a movement was to disappear tomorrow, there is no retreat from integrating tools and techniques like mind mapping and kanban while embracing software engineering within the social construct of the organization and perhaps the wider world outside the organization.  Our goal is to make tangible what intangible, and visible that which is opaque.