Listen Now!

This week we revisit the age-old statements, “I don’t want to be measured” and its alter ego, “management will use metrics against me.”  While often stated as if they are questions, both are positions. We weave in two recent techniques from our Re-read of Agile Conversations to consider the interests behind the statements  

Also, Jeremy Berriault weighs in on the need for testing strategies in agile on this edition of this QA Corner.  

(more…)

This week Mauricio Aguiar and Christine Green join me to discuss the state and future of Software Measurement. Mauricio, Christine, and I are all recent Past Presidents of the International Function Point Users Group (the largest international software measurement association). The conversation is both provocative and enlightening. 

Note, the audio of my voice is a little muffled but the important parts of the conversation come from Christine’s and Mauricio’s lips. I know what the issue was and have added a step to my interview checklist. 

(more…)

This week, the PC version of the Kindle software I use seems to have lost its copy of Project to Product — I have gotten reasonably adept at reading on all of my devices therefore got the re-reading done. While not the end of the world, it makes this week’s chapter on disruption and the role of technical debt in some of the stories shared by Kersten even more poignant. In the chapter the author tells four stories of disruption — they are interesting in their own right. Still, if we look for a common thread I would suggest the communication needed to manage the balance between flow items (features, defects, risks, and debts). The right balance requires knowledge of external contexts such as changes in business dynamics and market risks and internal context, such as the amount of work required to support a product and the level of technical debt accumulated. Getting the balance right is a strategic portfolio decision that requires a broad range of parties at the table. 

(more…)

One of the most influential books in my career was Peopleware by Tom DeMarco and Tim Lister. One concept in the book was the concept of flow state, being fully in the zone so that a problem or piece of work can be focused on and delivered. Flow maximizes the amount of value delivered. Demarco and Lister’s introduction to flow paved the way for my interest in The Flow Framework. Chapter 3 of Project to Product introduces the Flow Framework.

(more…)
Play Now!

This week Dave Nicolette, author of Software Development Metrics from Manning Publications, and I talk about pragmatically using metrics. Dave and I talked about the value teams get from measurement regardless of the approach you are taking to deliver value. Measurement is feedback and measurement is leadership for guiding and improving how work is done.   

After you have listened I think you will want a copy of Dave’s book on metrics.  Use the link: http://mng.bz/r2Og  Also, yes there is more, you say you don’t want to pay full price?  Use the discount code podspam20 to get a 40% discount code (good for all Manning products in all formats).

(more…)

I participated in a panel today that had to wrestle with the question of why companies use agile. There are lots of good reasons, including improving delivery performance, increased ROI, and higher retention.  What is generally missing is context-specific proof. Realistically, all of the magazine articles or happy stories from consultants trying to sell you on adapting agile (or any other framework) pale in comparison to the ability to measure the impact of change. Which brings me to a re-edited version of an essay published two years ago.  

Does Agile Deliver Value? Yes And You Can Prove it!

Organizations and teams embrace a framework or technique for a purpose. That purpose is generally to address a real or perceived problem.  When you get very specific, each change is done for a different reason.  When teams or organizations are asked whether they attained their goals, solved the problems they intended, or realized the promised benefits, very few have gathered more than a handful of success stories before losing focus and moving to the next big thing. Unless you can answer whether the framework or technique delivered tangible value,  leaders will be reluctant to spend money on changes.  Best practices are a point in case.  Best practices are, by definition, practices that some have found useful (or at least that someone has professed are useful).  Every process improvement and/or best practice adoption that is not legally mandated needs to follow the following high-level feedback loop.

  1. Decide why you are making the change and what the outcome of the change will be in tangible terms. Developing a solid reason for why you are making a change may sound like a trivial step, however, the rationale will often directly impact the passion for making the change. People pursue survival changes with a lot more vigor than incremental quality of life improvements.
  2. Develop a hypothesis of why the change you are making will satisfy the rationale for the change.  Changes that actually work rarely are the outcome of magical thinking or dumb luck. If there is no logical reason the change you are proposing will have an impact you are very likely wasting time and money.  Use the scientific method!
  3. Set SMART goals that will be used to track and evaluate the change.  As a reminder, SMART stands for specific, measurable, achievable, relevant, and time-bound.  The goals should cover the journey and outcome based on the hypothesis crafted in step 2.
  4. Benchmark the process you are changing.  Consider collecting data specific to the change and data to evaluate the impact on the overall system.
  5. Make the change.  You still have to make and support the change.  Your journey measures will be helpful to make sure that the change is being implemented well.
  6. Collect the data to show the impact (compared to the benchmark developed in step 4) for several cycles after the change has been implemented.
  7. Use the data you collect to tune the process. Pick a feedback loop and tune the process.  Rarely are major changes perfect right out of the box.  Using feedback to tune the process helps to ingrain the change and to make sure it is delivering value.
  8. Report your findings.  Share the impact with everyone involved.  Positive data will help to reinforce the change and will help sell the next round of changes.  In scenarios where the change doesn’t deliver value reporting reinforces the principle of transparency.  If a change doesn’t deliver, don’t double down on a failure; revert back and try something else.

People make changes to how they work on a daily basis.  Some changes are minor and, in some cases, are not worth developing a full-scale proof of impact. For example, deciding on whether to order grilled tofu or pizza for the team lunch doesn’t require a proof of impact.  Some large-scale changes like adopting Scrum, Kanban, or DevOps require a great deal of time, focus, and money. It makes sense to be able to answer the question of whether you got what we thought you would get with something more substantive than a shrug.

Notes and Afterthoughts:

The world has changed substantially since January 2018, but knowing whether you are adding value, regardless of the definition, is even more important now!

www.tomcagley.com is up!  The site is a work-in-progress.  I would like your feedback so I can prioritize next steps (a minimum viable product has to grow or it will wither).

There is still time to register!

This is part 2 of an essay based on a presentation I am doing Friday, June 5th at 9 EDT (sign-up: https://bit.ly/3gH0Uy5). I am presenting as part of IFPUG’s Knowledge Cafe Webinar Series. The presentation is titled Software Development: Preparing For Life After COVID-19.

Management guru Peter Drucker said, “There is nothing so useless as doing efficiently that which should not be done at all.” Benchmarking is a tool to identify work that should not be done or done better while continuous improvement provides a structure for improving the opportunities found in the benchmark. There are many approaches to benchmarking and I suggest combining qualitative and quantitative assessments.  The combination is critical for identifying how to improve effectiveness and efficiency. In a post-COVID-19 environment, all of us will need to answer whether how we are working is delivering tangible value in a financially sound manner. If you don’t know the answer to the effectiveness and efficiency questions leaders will be reluctant to spend money on you, let alone large scale improvement exercises. Once you know where you stand then begin to make changes using a feedback loop to know whether or not your experiments are working. (more…)

The road is rarely straight and narrow but regardless, it is a road!

Thriving in the post-COVID-19 lockdown world will mean you have to be efficient, dependable, and effective. Effectiveness is the third core capability and is the hardest to define. The dictionary definition of effectiveness is “the degree to which something is successful in producing a desired result”. Translating that definition a bit for software development yields effectiveness as an assessment of whether a process, product or project is doing the right thing when compared to the goals of the organization. Being effective means having a consistent understanding of what the right thing is regardless of how dynamic the environment is. Needless to say, in the software world, no one has been able to consistently get needs and requirements nailed down for any length of time (we will reserve that topic for later). When I asked Andrew Jarr, Scrum Master at iovation (during a LinkedIn messaging conversation) what his approach was he responded, “I tend to think of an effective team in terms of delivering good outcomes for their stakeholders, how well/safely they communicate as a team, and how well individuals grow. Assessing effectiveness requires agreed upon proxy measures.  Examples of proxy measures often include: (more…)

 

Efficiency and Beatty

I have been asking senior executives how they expect organizational goals to change after the shock of COVID-19. Mark Summers, Senior Director of Quality at Northwestern Mutual and Vice President of TMMi America, started his response with a single word, “efficiency.”  Mr. Summers went on to say that efficiency meant doing the right things and doing them well. He concluded by suggesting that leaders would need to improve delivery — make it faster, more efficient and deliver more value. Efficiency is a measure of how much-wasted effort there is in a process or system. The concept is highly charged in a profession that still views itself as more of a mixture of art and craftmanship then of engineering practices. All value chains and the process they are made up of must: (more…)

I have observed several recessions including the Dot.Com debacle and more recently the financial crisis. They are not fun. One of the classic behaviors of enterprises (big and small) during these times is to manage the bottom line through the one lever they have the most direct control over, cost. According to statistics published on Fortunly, about 300,000 software development related jobs are outsourced annually in the United States – a downturn will exacerbate this flow. In order to meet the new austerity that awaits us on the other side of the worst of COVID-19, software development teams and organizations are going to have to re-focus on measuring and improving three core capabilities. They are: (more…)