To answer this question we must ask first a related question: Why any new functionality should affect any previous functionality with which apparently there is no relationship? Because software is a whole instead of just individual parts. The simil here is the human body.
When you change something that you might think is not related to something else and suddenly you realize that something else failed, it requires an Engineer if we are talking about software or a Doctor if we are talking about health to actually give you response.
Yes, software must be seen as a whole and this is the reason why we have automated tests that look for regressions in the software world, the same way ideally a Doctor will follow up with tests across your body looking for signs of problems after prescribing a solution for any other problem.
Lean software teams should recognize that anything we do anywhere can have an effect somewhere else. Whether that is incomprehensible for some or not is irrelevant because it is simply a fact of life.
And this is why quality-first is the only effective approach to delivering software. Without it you are probably facing a 45% to 65% defect ratio which is holding your team from delivering more features as you keep fixing the problems you keep introducing as you go. I have found that e2e test driven development is an effective way to deliver quality-first software products.
Wednesday, January 20, 2021
Thursday, January 14, 2021
The Software Industry needs more Full Stack Product Owners (FSPO)
What is this term that I have coined as "FSPO" or "Full Stack Product Owner"?
An FSPO is an organization member that leaves their usual duties for a given amount of time to focus on delivering software that resolves challenges presented in their daily line of work.
An FSPO is a stakeholder first, then a product owner (PO) after, not the reverse. It is wearing these two hats, what makes an FSPO as effective as a Full Stack Developer (FSD). The existence of an FSPO for a minimal marketable feature (MMF) will reduce the number of people involved in providing a solution and with it the transaction costs related to its delivery. I personally have empirically demonstrated that depending on the availability and commitment of stakeholders we can get 5 to 10 times faster deliveries when an FSPO is put in charge of any MMF versus having a Stakeholder and a PO in charge of the same MMF.
An FSPO is not needed though when the given MMF can be deployed to production without acceptance from stakeholders. When this happens the PO is enough because the transaction costs are zero. This occurs when the PO is a subject matter expert in the Product or the feature being enhanced and has earned the two qualities that any FSPO must possess: responsibility and authority to deliver the specific MMF.
Using the FSPO role saves big dollars in the SDLC, however the challenge is to find people that can perform this job. Just as with finding FSD, this is a scarce resource. The introduction of the FSPO role represents a literal inversion of control (IoC) for product delivery because instead of the traditional "tell me what you want, here is what I understood, here it goes again after teh feddback loop 1, here it goes again after the feedback loop 2 ..." we go with "you tell me to do this and here it is to a T".
The FSPO performs a number of duties:
Ultimately all stakeholders that wish to become FSPO will get a big bump in their professional careers as technology continues to increase its importance when it comes to enabling the success of the organization. The introduction therefore of the FSPO role is a win-win for the Organization and the Stakeholder.
An FSPO is an organization member that leaves their usual duties for a given amount of time to focus on delivering software that resolves challenges presented in their daily line of work.
An FSPO is a stakeholder first, then a product owner (PO) after, not the reverse. It is wearing these two hats, what makes an FSPO as effective as a Full Stack Developer (FSD). The existence of an FSPO for a minimal marketable feature (MMF) will reduce the number of people involved in providing a solution and with it the transaction costs related to its delivery. I personally have empirically demonstrated that depending on the availability and commitment of stakeholders we can get 5 to 10 times faster deliveries when an FSPO is put in charge of any MMF versus having a Stakeholder and a PO in charge of the same MMF.
An FSPO is not needed though when the given MMF can be deployed to production without acceptance from stakeholders. When this happens the PO is enough because the transaction costs are zero. This occurs when the PO is a subject matter expert in the Product or the feature being enhanced and has earned the two qualities that any FSPO must possess: responsibility and authority to deliver the specific MMF.
Using the FSPO role saves big dollars in the SDLC, however the challenge is to find people that can perform this job. Just as with finding FSD, this is a scarce resource. The introduction of the FSPO role represents a literal inversion of control (IoC) for product delivery because instead of the traditional "tell me what you want, here is what I understood, here it goes again after teh feddback loop 1, here it goes again after the feedback loop 2 ..." we go with "you tell me to do this and here it is to a T".
The FSPO performs a number of duties:
- Create a wireframe specification (wf-spec) for the very low fidelity conceived UI/UX. This can be influenced by a UI/UX expert but in many cases, specially those related to ongoing applications, such step is not necessary. This is definitely influenced by other stakeholders.
- Create an outline of functional and non functional requirements for the MMF. This brainstorming specification (br-spec) is influenced by a number of other stakeholders.
- Create end to end specifications (e2e-spec). This will be influenced by software developers as they collectively will need to find ways to implement the assertions being requested.
- Review automated e2e-spec implementations (automated e2e tests) delivered by developers often and on demand.
- Test the MMF deployed in dev servers often and on demand.
- Test the MMF in full when deployed to the test environment and all e2e tests have passed per the continuous integration (CI) service.
- Smoke test the MMF when deployed into the production environment.
- Classify issues as bugs when the developer did not follow the e2e-spec to a T or defects when the specification itself was faulty.
- Keep track of the development pace and find the root cause of slowness. Apply theory of constraints to get the pace back up.
- Get back to their organization duties using the features they themselves help to create and collecting the next round of enhancements, calculate their possible return, risk and statistics-backed cost to help with the authorization from the prioritization comittee.
Ultimately all stakeholders that wish to become FSPO will get a big bump in their professional careers as technology continues to increase its importance when it comes to enabling the success of the organization. The introduction therefore of the FSPO role is a win-win for the Organization and the Stakeholder.
Friday, January 08, 2021
kubectl cp from pod to local
- Get into the pod and make sure you locate the *relative* path of the file. When you run the shell in your pod you might land in root or in some other path so this is important
- Use as source of the relative path without "./" in the "kubectl cp" command after the name of the pod and a colon
- Use as target the local path (absolute or relative) of the *file* you want to create or replace as the result the "kubectl cp" command. The detination must be a file if the source is a file.
kubectl cp mypod:my/relative/path/in/my/pod/file.ext ~/file.ext
Subscribe to:
Posts (Atom)