Software Development Organizations: Preparing for Life After COVID-19 (Part 3)

Read Part 1   Read Part 2

This is part 3 of an essay based on a presentation I did as part of IFPUG’s Knowledge Cafe Webinar Series. The presentation is titled Software Development: Preparing For Life After COVID-19. I have not heard if the final version has been posted. I do have a copy of the audio which I will edit.  I will also post a PDF of the slides in the near future (email me if you like to have a copy of the slides before they are posted). 

Once we have an idea of what is important: throughput, cycle time, productivity, and delivered defects, deciding when we care about measuring becomes critical. The answer is simple on paper, focus on the product backlog, what is between “Start and Done” and what crosses the line of done (production!). That we care about these three slices of time reflects the need to focus on how the work flows. Only counting the flow of value when it is done is a recognition that, at least in software, if code isn’t in production, you have not delivered.

 

Software Development Organizations: Preparing for Life After COVID-19 (Part 1)

 

On 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. Putting aside the impact of the current pandemic on healthcare, the environment, or office design, there will be pressure on the bottom line that managers will react to. Being effective and efficient is table stakes for survival, let’s raise the ante and know how effective and efficient we are to protect our jobs and those of our colleagues.  The first half of what will be synthesized into a script follows below.  

 

Effectiveness In Software Development: Preparing For Life After COVID-19

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:

 

Efficiency In Software Development: Preparing For Life After COVID-19

 

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:

 

Software Development: Preparing For Life After COVID-19

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:

 

Three Simple Measures: Meetings

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:

 

Guest Post: From Story Points to Test Driven Development – A Dev Team Story

From Story Points to Test Driven Development – A Dev Team Story

By Rebecca Schira

I’ve been supporting agile teams for almost six years. What is the one common issue I’ve seen across many teams and two companies during that time? Everyone loves story points or at least proclaims to love them. But why? The common answers we’ve all heard -they’re easier to understand, they’re a good way to do a gut check, etc. Without fail, each and every one of these teams sucked at estimating how much work they could accomplish.

 

Simple Checklist: Considerations Before Measuring Internal Customer Satisfaction

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. 

 

Consider Self-Sufficiency Before Measuring Internal Customer Satisfaction

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.  

 

Three Considerations Before Measuring Internal Customer Satisfaction

 

Most 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.