The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

jfs.world (121) [Avatar] Offline
#1
Please note: this is from the perspective of somebody who only has access to chapter 1 (not a buyer yet! still deciding).

I'm having a bit of a hard time trying to come to terms with some of the vagueness that I'm getting from what I've read. While I understand that some of this might be cleared up as I work through the later chapters, I'd rather have this all be cleared up front, especially in a book that aims to be practical, and in the introductory chapter of just such a book.

So here are a few clarifying questions.

1. How exactly would you define "process improvement"? Could you define it as, say, a change in one or more of the 3 factors (approach, process model, delivery mode) aimed at making improvements to software development? I understand that when any or all of these 3 factors change that all 3 will probably be affected; but given how the word "process" features prominently in one of the factors ("process model"), it might be good to define "process improvement" clearly. What "process" are you talking about?

2. "Approach" vs "process model": it seems to me like these 2 factors are so closely linked they could be collapsed together into one. If you're using the traditional approach, your process model would necessarily be the linear process model, right? Is there any reason then why "approach" has to be kept separate from "process model" as a separate factor?

3. When you talk about "delivery mode", you talk about software being built in only one of two ways: either bound by specific time, or else ongoing and continuous. But is it really only one of two? What about when something is simply defined as when the owner says it is "done"? or when you're using the adaptive approach, and the schedule is flexible (but maybe not the other parts of the iron triangle)? So a software development effort could possibly not have a specific end date/time... and yet be designed to eventually terminate?
david.nicolette (6) [Avatar] Offline
#2
Process improvement - any change to the way in which the work is carried out that results in better outcomes. The definition of "better outcomes" depends on what problems the team or organization is facing and what goals they may have for delivery performance or software quality. You are right to think that it may involve changes in any of the three key factors mentioned in the chapter. It may also involve changes in technical practices, reduction of process waste, and anything else that results in an improvement.

I think approach and process model are distinct considerations. It's possible to apply any process model with the traditional approach. People won't achieve the same benefits from moving to an iterative or time-boxed process model if they retain traditional assumptions about fixed budget, up-front design, and big-bang delivery, but they may realize some benefit just from chunking up the work and keeping closer track of progress so they can identify delivery risks earlier.

A discrete project is not (only) "bound by specific time." Projects are usually capitalized and have a fixed budget allocation. They have a distinct starting and ending date. Often, teams are formed to carry out a project and then disbanded when the project is finished. It's certainly possible to use a continuous development approach when there is a firm target date for delivery, but that single factor doesn't necessarily make it a "project."

I hope that helps!
jfs.world (121) [Avatar] Offline
#3
david.nicolette wrote:Process improvement - any change to the way in which the work is carried out that results in better outcomes. The definition of "better outcomes" depends on what problems the team or organization is facing and what goals they may have for delivery performance or software quality. You are right to think that it may involve changes in any of the three key factors mentioned in the chapter. It may also involve changes in technical practices, reduction of process waste, and anything else that results in an improvement.


ok

I think approach and process model are distinct considerations. It's possible to apply any process model with the traditional approach. People won't achieve the same benefits from moving to an iterative or time-boxed process model if they retain traditional assumptions about fixed budget, up-front design, and big-bang delivery, but they may realize some benefit just from chunking up the work and keeping closer track of progress so they can identify delivery risks earlier.


That's fine. My problem is my reading of the various different process models. Does it not read like the requirements, and definitely the scope / solution, are not fixed and might change in the iterative and time-boxed process models?

Iterative — Based on the assumption that a single pass through the requirements is unlikely to result in a good solution. With an iterative process, the requirements are revisited time and again, and the solution is built up through a series of iterations. This may involve progressive refinement of the solution, gradual addition of specific features, or a combination.

Time-boxed — The same as the iterative model, with the addition of two defining characteristics: (1) each iteration is the same length, and (2) a potentially shippable increment (or vertical slice) of the solution is delivered by the end of each time-boxed iteration.


Maybe it is my bias; but it's hard to read it otherwise given the language (especially the phrase "progressive refinement of the solution"). I think you have some nailing down / clarification (the very point of this thread) of some terms to do if you want to have the book to have real practical value. I assure you, I wont be the only one coming to the book with questions like these.

And note the traditional approach is defined/described thus:

The traditional approach involves a thorough analysis of stakeholder needs, a comprehensive solution design, a careful assessment of risks, and a fixed budget allocation in advance.


and

With the traditional approach, the scope, schedule, and budget are all fully defined in advance.


A discrete project is not (only) "bound by specific time." Projects are usually capitalized and have a fixed budget allocation. They have a distinct starting and ending date. Often, teams are formed to carry out a project and then disbanded when the project is finished. It's certainly possible to use a continuous development approach when there is a firm target date for delivery, but that single factor doesn't necessarily make it a "project."


This seems to be a tangential question that you're answering, and not my actual question. Perhaps one question will help to clarify things. How would you define "ongoing"? Is it possible for an ongoing delivery mode to have a planned ending date, and if so, how is that different from a "project"?
david.nicolette (6) [Avatar] Offline
#4
Your reading of the process models is correct. I wonder if the confusion is this: The models are descriptions of how things are meant to be, and what I would like people to do is assess how things actually happen against those models. The problem I observe in the field is that people assume that just because they are using (or believe they are using) a given model, that things are actually happening according to that model. That's where they go astray in choosing metrics appropriate to their situation. Not sure if that's clear.

It's very common that people use a time-boxed or iterative process in conjunction with a traditional approach to budget, scope, and timeline. They use metrics that are recommended by the process they're using - say, Scrum, XP, or Kanban - but in fact they are just driving out a set of predefined requirements. IMO they ought to measure what they're really doing and not necessarily what they think they're doing.

Re "project" vs. "ongoing work", consider these two ways of building and supporting a software product:

(a) The company defines a project to develop a new software product (could be for internal use or for sale, doesn't matter). They may form a new team to carry out the project, or they may assign the work to a longstanding team. The work is capitalized so the company can amortize the initial development cost over the planned lifetime of the product. When the initial version of the product is complete, the project is formally ended. For the remainder of the production lifetime of the product, any support issues and enhancements are handled by a different team - a support team that is funded on an expense basis. There is no "project" for the support work.

(b) The company decides they need a new product. They may form a new team to support the product, or they may assign the work to a longstanding team. There is no separation between the initial development work and ongoing support and enhancement. Initially the team spends proportionally more time doing "pure" development than support simply because there isn't any code yet. As time goes on, they spend proportionally more time on enhancements and support issues, because the product is in use. There may be numerous or frequent or continuous delivery of changes. Usually, all the work is expensed.

jfs.world (121) [Avatar] Offline
#5
david.nicolette wrote:Your reading of the process models is correct. I wonder if the confusion is this: The models are descriptions of how things are meant to be, and what I would like people to do is assess how things actually happen against those models. The problem I observe in the field is that people assume that just because they are using (or believe they are using) a given model, that things are actually happening according to that model. That's where they go astray in choosing metrics appropriate to their situation. Not sure if that's clear.

It's very common that people use a time-boxed or iterative process in conjunction with a traditional approach to budget, scope, and timeline. They use metrics that are recommended by the process they're using - say, Scrum, XP, or Kanban - but in fact they are just driving out a set of predefined requirements. IMO they ought to measure what they're really doing and not necessarily what they think they're doing.


I see. Well that definitely clears things up big time for me! That was precisely why I was confused. Your explanation is beautiful, but also highlights yet another layer of subtlety that may be hard to get in the subject matter. I needed that. Thanks! I've been approaching and reading this material like a geek; it's becoming clear that I will have to take another approach....

Re "project" vs. "ongoing work", consider these two ways of building and supporting a software product:

(a) The company defines a project to develop a new software product (could be for internal use or for sale, doesn't matter). They may form a new team to carry out the project, or they may assign the work to a longstanding team. The work is capitalized so the company can amortize the initial development cost over the planned lifetime of the product. When the initial version of the product is complete, the project is formally ended. For the remainder of the production lifetime of the product, any support issues and enhancements are handled by a different team - a support team that is funded on an expense basis. There is no "project" for the support work.

(b) The company decides they need a new product. They may form a new team to support the product, or they may assign the work to a longstanding team. There is no separation between the initial development work and ongoing support and enhancement. Initially the team spends proportionally more time doing "pure" development than support simply because there isn't any code yet. As time goes on, they spend proportionally more time on enhancements and support issues, because the product is in use. There may be numerous or frequent or continuous delivery of changes. Usually, all the work is expensed.



I'm not sure I'm getting this yet. Could it be that the major distinction between "ongoing" and "project" could be in terms of how the capital put into it is viewed, whether as a fixed capital expenditure/investment, or possibly (but not necessary!) unbound operating expense? Is that it? Would that be a better way to see the 2 different modes? I'm seeing that "ongoing" does not necessarily have to mean that there is no end date, so it's not possible to distinguish the 2 in terms of that. Thanks for your patience!