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.

 

Why Measure Customer Satisfaction (Formally) In Internal IT Organizations

Measuring or assessing customer satisfaction is a fact of life for products and services for organizations that deliver to their customers. I receive several every day. Each text, email and phone call asking my opinion tells me that my opinion matters. The process of determining whether customers are happy is a form of attention. Internal customers are not always paid the same compliment, this is a rectifiable mistake. There are multiple ways to collect customer satisfaction data (a sample of techniques are in Customer Satisfaction Metrics and Quality) the next four segments of the blog are not going to focus on data collection techniques, but rather on internal customer satisfaction measurement rationale and infrastructure. Spending time upfront to understand whether what you are doing solves a problem or is a sustainable process is important. None of this is easy and doubly so because most collecting and analyzing the data aren’t marketing or market research personnel. There are four areas that need to consider before you send your first survey or schedule your first stakeholder interview.

 

When Do Story Points Make Sense?

Story Points: No Parking

Story points are a planning tool that has proponents and opponents. Like most tools, story points are not prima facie evil, it is only through misuse that they are problematic.  Problems tend to occur because leader, managers, and team members have a need (or at least a very strong desire) to know when a piece work will be done, what they are going to do next, whether they are meeting expectations, and in many cases what something will cost. Story points are a relative measure, a proxy of a proxy that makes answering any of these questions with precision very difficult. The best anyone can hope for is that the answers story points provide are accurate enough and provide a coherent feedback loop for teams. This could be considered damning with faint praise, however, in the right circumstances story points are a useful tool for a TEAM. I am a proponent of using story points in three scenarios.