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

Dirty glasses at a bar

I thought you were taking notes!

A Korn Ferry survey indicated that 67% of respondents felt that they are spending too much time on meetings and calls which “distract from making an impact at work.” Many organizations have tried to rein in meetings by trying tactics like no meeting days to increase focus time. It is a shame that the idea has not caught on. On a personal level, I habitually block chunks of my calendar to ensure I can not be automatically booked into meetings. Note, the Korn Ferry survey indicates that 35% of people invited to a meeting they feel will be unproductive still accept and attend. We need to fix this productivity sink. Measurement is table stakes for change. A few simple measurement approaches that are useful for beginning a dialogue are: (more…)

Check Mark

Check!

Understanding customer satisfaction is important. It might be more important for a product or services sold to someone outside the firm because of the link between satisfaction and sales —  no customers = no revenue. Understanding customer satisfaction for internal IT groups, groups that support the value chain, are often given short shrift. However, careers and budgets are influenced by satisfaction. Making sure you have the right approach and logistics for measuring internal customer satisfaction is critical for being successful. The questions described in earlier blog entries in this theme (see below) can be used as a really simple checklist. Review the questions below and answer them with either: yes, no, or no clue.  (more…)

Soap, Shampoo, Towel and Rubber Duckie

Everything you need for a proper bath!

The fourth category of considerations for an organization that is primarily focused on internal applications to think about before they start measuring customer satisfaction is self-sufficiency. However, before we start, after the first article in this theme, I was asked whether the overhead of the four considerations would put teams and individuals off from talking to their clients, customers, and stakeholders. The simple answer is no. Conversations with individuals about their satisfaction with your efforts are important feedback tools. Sprint Reviews and Demos are events that are structured to create those conversations.  Conversations and formally measuring customer satisfaction are not the same thing. Neither should preclude or interfere with the other but rather doing both will provide different types of information. If you are not talking with your stakeholders, I will put it more succinctly: you probably have a career issue that measurement will not fix.   (more…)

 

Rock piled by the shoreMost internal IT organizations do not have a lot of experience as professional customer research personnel, but they have to get a handle on how their work is perceived. Before tackling the collection and analysis of how customers and clients perceive their work there are four considerations, we take a deeper dive into three today. (more…)

Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 544 features our interview with Jeppe Hedaa.  Mr. Hedaa and I discuss his new book, Nucleon: The Missing Formula That Measures Your IT Development Team’s Performance. Our discussion centers on the book but also touches on meritocracy and why you want top performers on a team. This is a wide-ranging interview with thought-provoking ideas as we talk about Nucleon!

Jeppe’s bio:

Jeppe Hedaa has been working with complex systems development for more than 30 years, serving the largest IT development departments. He is the CEO and owner of 7N, who is an agent for top 3% IT specialists. 7N has departments in the US, Switzerland, Finland, Sweden, Norway, Poland, India and Denmark. In September 2018 he published the book “Nucleon: The missing formula that measures your IT department’s performance”, where he describes how to calculate a hard number for an IT team’s performance that could best be compared to that of horsepower in a car. In the book, he also measures the factors that hold back an organization’s delivery and identifies the most impactful areas for improvement.

Our review of Nucleon: http://bit.ly/2XQvB9T (more…)