February 3, 2024
Chapter 7 of Mastering Work Intake: From Chaos to Predictable Delivery dives into the nuances of using XmR charts for four flow metrics. They are:
This chapter is hugely useful. Read it carefully and read it more than once. Three points struck me during this read of Chapter 7.
(more…)January 27, 2024
Chapter Six, of Actionable Agile Metrics Volume II, Advanced Topics in Predictability, is titled Detecting Signals on PBCs. Finding a signal in the noise is like separating the wheat from the chaff. Adding to the pile of quotes, one of the most enduring is “Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.” A more appropriate version in the context of this chapter might be “Give a person some data and they will see a trend. Teach a person to detect a signal and they won’t be as silly” – doesn’t have the same punch, but the new version encapsulates Chapter 6.
(more…)January 20, 2024
The question of how much data is required to determine what is happening in a system is a perennial bugaboo. Those predisposed to acting tend to think less is more, while those with more reticence sometimes wait forever to make a decision. The question of how much data is needed is more than just a footnote in flow data.
(more…)January 13, 2024
We continue with Chapter Four of Actionable Agile Metrics Volume II, Advanced Topics in Predictability, titled Process Behaviour Charts, this week. Today we construct an XmR chart.
We begin with the X Chart which provides a visual representation of the data over time. I constructed this chart below in MS Excel using the X-Y Scatterplot option. The dashed line is the arithmetic average. Vacanti calls this the center line and it is to orient the person looking at the graph to the center. It is not to make predictions or for forecasting. I would also suggest calculating the median to understand the skew in the data (it is better than eyeballing it). In this case, the median and average are nearly the same. While the X Chart with centerline is useful, I strongly recommend not jumping to conclusions and making inferences from the data until we build the entire XmR chart and consider all the interpretation rules in the next chapter. The chart is shown below:
(more…)January 6, 2024
Chapter Four of Actionable Agile Metrics Volume II, Advanced Topics in Predictability, titled Process Behaviour Charts is a trojan horse. This chapter is substantially more than a rehash of Process Behaviour Charts. The chapter corrected a misconception I have had for at least twenty years which we will get to in Part 2 of our re-read of chapter 4 (we are taking two weeks on this chapter to set up chapters 5 and 6). Thanks, Mr. Vacanti.
(more…)September 20, 2018
A count of the Pokemon in my local park yesterday!
In today’s complex software development environment, it is easy to see every data collection issue as a complex automation problem. For example, I recently had a discussion with a team that is trying to determine how they would know whether a coding standard change they were contemplating would be effective. The team proposed capturing defects the coder/developer pairs found in TFS. The plan was to enter each defect found into the tool. After a discussion, the team decided to adopt a much simpler data collection solution with very low overhead. One of the classic quality tools is a tally sheet or check sheet. A check sheet is a form that used to collect information as it happens as a set of checkmarks or tally marks on the form. Check sheets are a very simple data collection tool. They are often a great way to pilot data collection before spending time and effort on automation or adding overhead to work. A check sheet is a form of the histogram where data where data collection and categorization occurs at the same time as visualization. (more…)
July 2, 2017
Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music
SPaMCAST 449 features our interview with Jasveer Singh. We discussed his new book, Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication. Jasveer proposes a new sizing methodology for estimation and other measurement processes.
Jasveer Singh holds a Master of Technology degree in Computer Technology from the Indian Institute of Technology, Delhi, and has studied Executive Master in Management at École de Commerce Solvay, Brussels, Belgium.
He has about 30 years of valuable senior-level international experience in the ICT area and has worked in the top IT/Telecom equipment manufacturer, operator, consultancy, and service companies in different countries (Bharat Electronics Limited, Alcatel, Siemens Business Services, WorldCom, Logica, and Sigos in India, France, Australia, Belgium, and Germany). A significant part of this experience has been in the management of software development (analysis, design, coding, testing), system design, quality assurance/control, and project management while working with different programming languages, object-oriented technology, database management systems, etc. His in-depth experience in these software domains led him to realize the improvements needed in the currently available methodologies for software size measurement and to develop the Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication (FSSM) which is a thorough methodology and great help for software projects.
Currently, he is based in Belgium and is the director of EUSFP.
E-mail: js@fssm.software
LinkedIn: https://www.linkedin.com/in/jasveer-singh-11230a12/
FSSM book: http://www.wiley.com/WileyCDA/WileyTitle/productCd-1119238056.html
FSSM online book: http://onlinelibrary.wiley.com/book/10.1002/9781119238126
FSSM website: www.fssm.software
Re-Read Saturday News
This week we wrap up our re-read of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson which was published by Henry Holt and Company in 2015. The concepts in Holacracy are an important addition to the discussion of management, governance, and leadership in the 21st Century. Read or re-read this week’s installment for more thoughts and comments!
Catch up on the all of the Holacracy entries: (more…)
June 4, 2017
Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music
SPaMCAST 445 features the return of a favorite, Capers Jones. It is always fun to talk with someone with their own page in Wikepedia. Capers and I talked about his new book, A Guide to Selecting Software Measures and Metrics. Capers is passionate about software quality and measurement. Capers said, “High-quality software is not expensive. High-quality software is faster and cheaper to build and maintain than low-quality software, from initial development all the way through total cost of ownership.” from The Economics of Software Quality. As usual, Capers was engaging, educational and controversial. Spending time with Capers is always a learning experience!
Capers biography is long and storied. Let it be said that Capers is a serial author, public speaker, pundit, guru and deep thinker. Check out his Wikipedia page or Linkedin.
Capers can be contacted at capers.jones3@gmail.com.
Capers first appeared on SPaMCAST 3 and last appeared on SPaMCAST 53
Re-Read Saturday News
This week we tackle Chapter 7 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015. Chapter 7 shows how to generate alignment between roles, circles, and the overall organization. Lots of inspect and adapt talk this week.
Catch up on the first four entries in the re-read
Week 1: Logistics and Introduction
Week 3: Distribution Authority
Week 4: Organizational Structure
Week 7: Facilitating Governance
Week 8: Strategy and Dynamic Control
Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.
A Call To Action
If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening. If you leave a review please send a copy to spamcastinfo@gmail.com. Reviews help guide people to the cast!
Next SPaMCAST
SPaMCAST 446 will feature our essay on questions. Questions are a coach and facilitator’s secret power! Do you have a favorite go-to question you like to ask? Care to share?
We will also have columns from Gene Hughson and Jon M Quigley (and maybe more)!
Shameless Ad for my book!
Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.
April 14, 2016
Not quite a Google bus
Labor, raw material, and capital productivity are easy concepts to understand. For example, labor productivity is the ratio of the products delivered per unit of effort. Increasing the efficiency of labor will either increase the amount of product delivered or reduce the amount of labor needed. Raw material or capital productivity follow the same pattern. The issue is that while labor, raw materials, and capital explain a lot of the variation in productivity, they do not explain it all. And in software product development other factors often contribute significantly to productivity improvement. Total factor productivity (TFP) is not a simple ratio of output to input, but rather is a measure that captures everything that is not captured as labor, capital or material productivity. Factors included in total factor productivity include attributes such as changes in general knowledge, the use of particular organizational structures, management techniques, or returns on scale. The components in TFP are often the sources of productivity changes in software development. (more…)
April 12, 2016
In simplest terms, productivity is the ratio of output per unit of input.
Almost every conversation about change includes a promise of greater productivity. In simplest terms, productivity is the ratio of output per unit of input. While the equation is for calculating productivity is straightforward, as we have discussed, deciding on which outputs from an organization or process to count is never straightforward. The decisions on the input side of the equation are often equally contentious. Three critical decisions shape what measures will be needed to supply the inputs used to calculate productivity. (more…)
Software Process and Measurement 