• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (11)

1 KateR commented Permalink

In the book Disciplined Agile Delivery, Scott Ambler and Mark Lines have changed the wording of the Agile Manifesto values and principles to fit better with software delivery within the enterprise. For example, "Working software over comprehensive documentation" becomes " Working solutions over comprehensive documentation", whilst your version is "Demonstrable capability over comprehensive documentation". From the explanations of both changes there appears to be the same intent behind them. Some of the other changes are also very similar, while others address slightly different aspects. Although changing the wording helps people to more readily understand how the principles and values apply to their particular circumstances, the most important thing, as you point out, is having the right mindset and understanding the objectives. You can't take any set of wording at face value. Having different variations of the wording might therefore be valuable, people can find a set that suits them, on the other hand it could prove confusing and somewhat dilute the concepts.

2 Hazel Woodcock commented Permalink

Kate, thanks for the comments. We were looking at targeting Agile at an audience that suffers all the issues of large scale software, plus the issues of physical hardware delivery, whether that be a car, a distributed comms system, or an upgrade to a railway. Our intent was not to dilute concepts, but rather to make them palatable to a different audience. By leaving the word 'software' in the principles, a systems audience would be tempted to pick and choose which principles were applicable, leading to an agile-ish approach that is not the holistic view intended. I do take your point that having multiple versions of something so fundamental could be confusing and I will try to mitigate this as our work progresses - I am not sure how yet, but it will be on my mind.
Thanks again for dropping by,
Hazel

3 fschop commented Permalink

I propose to replace the term "project team" by "project teams". Typically in systems development multiple project teams are involved, each making products or even systems with an individual reason for existence (e.g. commercially sellable), which are integrated in a larger system. This also allows the manifesto to apply to Agile System-of-Systems engineering.

4 Hazel Woodcock commented Permalink

Great point Frank, we want this to cover SoS development and that vertical thread of communication needs to extend through all the project teams that are involved. I will add this into my working notes for our next version.

5 CharlesRivet commented Permalink

Hi Hazel,

 
This is a very good piece of work! Thanks for providing this for the community!
 
I do have some comments and suggestions:
 
Manifesto:
 
You really need to keep the last paragraph of the Agile Manifesto:
 
“That is, while there is value in the items on the right, we value the items on the left more.”
 
This is a part of agile that some “extreme” agilists seem to sometimes forget…and I believe is fairly important.
 
1. I certainly like the idea of “demonstrable capability. From your explanation, I do agree that “continuous” would not be the right term, however, I am less sure about “regular”, which implies a constant cadence (the software delivery in agile is also often “regular”, e.g., every month). To tell the truth, I can’t think of a better word and I do agree that there is a need for differentiation, so I guess a better, short discussion as to what is meant by “regular” in this context would be warranted.
 
2. I think the sentence “The time when you want to accept changes to requirements is when the alternative is even more expensive because you are moving away from the customer’s needs” needs to be emphasized! It should also apply to both software and systems! However, I think that rebelling against changing requirements might be too harsh.
 
3. Models are good, as long as everyone involved can understand and interpret them correctly - which is one reason why some agilists have shied away from including models in their approach (to a sometimes religious extent).
 
4. As mentioned in other comments, “teams” (plural) would be better.
 
5. You have the same text in (5) as you had for (4)… and I don’t think it applies here!
 
6. Agreed. In addition, a good project organization would probably be to have the smaller teams co-located and teams of teams being geographically distributed (as a “best practice”). This would promote the best collaboration between the ones that need it the most (e.g., a base component team).
 
7. Agreed.
 
8. I would actually add “project teams” to the list rather than use it to replace “developers” (or use “engineers” instead of “developers”, if you prefer). IMHO, one of the points here is to prevent burnout and that needs to be addressed at the level of the individual.
 
9. Agreed.
 
10. Agreed (although I always has concerns about the way this was phrased…).
 
11. Agreed.
 
12. Agreed.

6 CharlesRivet commented Permalink

Hi Hazel,

 
This is a very good piece of work! Thanks for providing this for the community!
 
I do have some comments and suggestions:
 
Manifesto:
 
You really need to keep the last paragraph of the Agile Manifesto:
 
“That is, while there is value in the items on the right, we value the items on the left more.”
 
This is a part of agile that some “extreme” agilists seem to sometimes forget…and I believe is fairly important.
 
1. I certainly like the idea of “demonstrable capability. From your explanation, I do agree that “continuous” would not be the right term, however, I am less sure about “regular”, which implies a constant cadence (the software delivery in agile is also often “regular”, e.g., every month). To tell the truth, I can’t think of a better word and I do agree that there is a need for differentiation, so I guess a better, short discussion as to what is meant by “regular” in this context would be warranted.
 
2. I think the sentence “The time when you want to accept changes to requirements is when the alternative is even more expensive because you are moving away from the customer’s needs” needs to be emphasized! It should also apply to both software and systems! However, I think that rebelling against changing requirements might be too harsh.
 
3. Models are good, as long as everyone involved can understand and interpret them correctly - which is one reason why some agilists have shied away from including models in their approach (to a sometimes religious extent).
 
4. As mentioned in other comments, “teams” (plural) would be better.
 
5. You have the same text in (5) as you had for (4)… and I don’t think it applies here!
 
6. Agreed. In addition, a good project organization would probably be to have the smaller teams co-located and teams of teams being geographically distributed (as a “best practice”). This would promote the best collaboration between the ones that need it the most (e.g., a base component team).
 
7. Agreed.
 
8. I would actually add “project teams” to the list rather than use it to replace “developers” (or use “engineers” instead of “developers”, if you prefer). IMHO, one of the points here is to prevent burnout and that needs to be addressed at the level of the individual.
 
9. Agreed.
 
10. Agreed (although I always has concerns about the way this was phrased…).
 
11. Agreed.
 
12. Agreed.

7 CharlesRivet commented Permalink

Sorry about the double post - don't know what happened...

8 Hazel Woodcock commented Permalink

Charles, thanks for such a thorough and considered review - I have added in the proper notes for number 5 now.

 
I did not intend to lose the 'while there is value in the items on the right... ' part of the manifesto, it is of course an essential part. To make a sweeping, unfounded, generalization; I think systems projects are more likely to lean further to the items on the right than pure IT software projects due to the demands put upon the outputs that could be deployed for tens of years.
 
I will work through your other comments as well and ensure they are included in our ongoing work.

9 Ricardo Tome commented Permalink

Demonstrable capability is a wider and more appropriate term than valuable software. However, removing the term valuable is not advisable since the base of Agile is showing value earlier by defining a Minimum Viable Product. Making an effort to show something earlier in time is extremely important in Agile and there should be a focus to achieve early value. Not mentioning value really breaks one of the main Agile premises.

 
The word project (in project team) implies we are doing something with a beginning and a specified end. We should avoid it within an Agile context since we can apply Agile to Products having a start but without a defined end, and also to maintenance where the end is not defined as well. My proposal is: Every stakeholder involved in the value delivery should work together daily throughout the project. (I changed must to should since in a big environment it is not possible for everyone to meet daily)
 
“actual or modeled functionality”: I think it can be simplified and become more generic by just saying “Deliver value frequently”
 
Continuous delivery Vs Regular delivery: I understand when continuity doesn't happen but I think the gap is not solved with “regular delivery”. Regular means that we always have the same amount of time between instances, which may not be possible. Therefore, if the reason of not using the term “continuous” is because it is not possible to achieve always, it happens with regular delivery as well. In my opinion, the important premise is “early”. I would simplify by just having “Our highest priority is to satisfy the customer through early delivery of demonstrable value. Seek a sustained cadence for delivery.”

10 CharlesRivet commented Permalink

@Hazel :

 
I agree that in many systems organisations, the tendency will be towards the sttus quo and to lean towards the items on the right. However, I take this as a goal statement and not an imperative (which is always bad when adopting processes and methods). And then, there are COBOL applications that have been running for tens of years (;-)...
 
@RTome :
 
I like you "value" comment and agree that this has a place in this document.
 
The division between product and project has always been a bit fuzzy in agile, at least until SAFe, which tries to connect the two (with some remaining impedance mismatch, IMHO). One has to keep in mind here that the level of close collaboration required will be different depending on the size and where you are in the organisation. So whereas the "leaf" development teams (e.g., module development) will need to talk daily, the "root" teams (e.g., product line management, CxO) could meet less frequently. In very large (and especially distributed) teams, there is a need for a hierarchy (and for "product owners" at each level...).
 
Your "sustained cadence" also implies regularity and a set amount of time for the cadence (;-). I had the same concern in my comment, but could not figure out how to properly state what id desired/needed. I would think that this (#4) must be aligned with #12 to review what makes the most sense. Continuous improvement (governance) of the process is essential and that can be used to adjust the regularity of the cadence.

11 Hazel Woodcock commented Permalink

Ricardo and Charles, I will keep working on the regularly/frequently/often problem. With so few words involved, every one of them should be chosen with care. I very much appreciate the feedback you have given here and hope to be able to point you to a more polished version of the paper in the not too distant future. That new version will most certainly take account of the comments here along with additional input from a variety of other sources.

Add a Comment Add a Comment
  • Previous Entry
  • Main
  • Next Entry