Chapter 13. - Work Methodology
👩‍🏭

Chapter 13. - Work Methodology

How To Do Full Context Software Development?

The work methodology I present here is not meant to replace any currently employed practices like scrum, kanban or even waterfall. It's an augmentation that can be adopted to any of them. So what this is about? As a first step, I want to teach you how to evaluate the net benefits (or hindrances) that a given technology or other programming related choice can bring to a specific project from a full context perspective. Next is to integrate that process into every technical decision making situation that exists in your work. The final step is about how to keep things continuously aligned with the changing needs and constraints of a project.
It all starts with identifying the relevant BOU values in your situation. The goal is to ensure that every decision is well aligned with them. This includes both technology choices and feature planning. Most importantly, the setup requires cooperation across all professions involved in software delivery. It will lead to huge additional benefits. The project will have clearly defined goals in every aspect that are know throughout the organization just as all the value adding factors and aspects of the product. That offers tremendous help in aligning any kind of decision with the mission and strategy of the company.
Whenever possible, we should not try to tackle that alone. Ideally, we could be working on it collaboratively with business, design, all of development, QA and operations. Not everyone is needed for every part but in the end we are in it together and only unified efforts can deliver the best possible results. However this is not the main topic of this chapter. The 4 guides will show you how to do the setup, here I want to focus on something else. Let's assume we have our Full Context defined with the desired values clearly identified in business, user and organizational terms. What we will discuss is how to make sure our actions are in line with those values.

High Level Overview

The process is simple but the knowledge required to do it right is not. From a tech decision perspective the best we can do for the users is identifying every relevant, impactful SQA, TQA and CQA that affect the desired CX elements and make choices that deliver on those. In addition we can use our unique insights to drive feature planning in a direction that prioritizes what matters the most for our users.
For organizational performance we should focus on 3 things and finding the right balance between them. Reducing waste generated by- and maximizing control over- the processes, while aligning our decisions with the interests of the developers and other colleagues. The right balance will deliver the best levels of productivity and utilization.
These are the factors that vary the most during the lifetime of a project. The least frequently involved but most fundamental requirement of a tech choice is enabling the business opportunities necessary for the project. Whenever you are making such a decision, you should evaluate which are the most appropriate tools and platforms in terms of capabilities.
The importance of these factors are changing over the lifetime of projects. We usually need people from other professions to tell us when that happens so it's essential to keep in touch with the whole organization. When priorities change we should review and update the importance of the related technical factors in our context definitions.
The connections established in the book will guide you in evaluating which full context elements are influenced by a tech change. Then it's a matter of how well you understand the nature and importance of the BOU values of your project to make good estimates about the impact of a change. If the values of each area are well defined by experts, you won't have to do any guesswork. The priorities will be there and you will be able to see the impact of any development choice instantly. That's our goal, the situation we want to achieve. When we are there, using this methodology can be really fun! Seeing the wider effects of our work is a thrilling and gratifying experience.

In Practice

Whenever you face a technical decision, I propose the following process to align your choice with the desired outcomes.
  1. Identify which quality attributes would be affected
  1. Trace them to the Financial API
  1. Estimate their impact over the CPUB factors
  1. Choose the option with the highest relevant score!

I.

By relying on your technical expertise you need to identify all the affected quality attributes from every domain. (Technology, Software, Code and Processes) You might review their list from the book.

II.

I don't need to tell you anything here. All the connections are static and described in the material. You will quickly develop a general sense about what's related to what if you didn't already.

III.

You might be familiar with Story Points from SCRUM. I came up with a very similar system called Impact Points. Is it lame? You tell me, but I'm sure it's useful! First you need to estimate the impact of the QA changes over the related CPUB factors. Rate them on a scale of 1, 10, 100, 1000. They can be negative so use * -1 in that case. If multiple QAs affect the same factor sum up their Impact Points. Set up a baseline example for each step on the scale. (examples are coming).

IV.

Evaluate how the different options match the priority of the BOU values as defined In your Full Context description. Choose the alternative that delivers the most value according to their BOU impact. Then lay back and enjoy the well made decision, the confidence you felt, and the overwhelming recognition that you will surely gain for the success of your work. 😉
 

How did you like this chapter?