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

Comments (19)

1 Geri commented Permalink

I find that most software development descriptions seem to focus on a team in isolation (Agile, SCRUM, RUP, etc), which is not very realistic. That's why your Enterprise Unified Process book has been so important. <div>&nbsp;</div> We have to think of the whole ecosystem within which a solution will be delivered in order to be successful, whether it is the enterprise, a desktop application, or an embedded system. And you have to consider the environment the development team will work in. <div>&nbsp;</div> The lone programmer working in a corner is mostly a thing of the past. And project teams don't work in isolation either. <div>&nbsp;</div> I also appreciate the point that we are delivering a solution. This often includes much more than some software. Some of my projects ended up not delivering software at all, because we found a non-software solution was better at delivering business value to the enterprise. In other projects, the software was the smallest part of the solution. <div>&nbsp;</div> Thanks for the great reminders :-)

2 StevenShaw commented Permalink

The renaming of "software" to "solutions" and "customer" to "stakeholder" is fine and well understood. Though most of us are software engineers so "software" probably makes the most sense to us. <div>&nbsp;</div> With 13, from a word-smithing point of view, it should probably be stated as "Leverage and evolve..." to match the other principles. However, I am not comfortable with what it's saying. Do you always need to evolve assets? What assets? Aren't the asset's owners just some other stakeholder? <div>&nbsp;</div> I like 14, but to make it consistent with the wording of the other principles, it should probably read: "Minimize work in progress and visualize workflow". Also unsure about "to improve team effectiveness"- could perhaps leave it out. Seems the whole manifesto is about increasing effectiveness. <div>&nbsp;</div> I'm not fond of 15. Could be dropped. The phrase "organisational ecosystem" seems a little overblown. This principle seems to be about the necessary management "buy in" to agile and on the flip-side an acknowledgement that non-agile or not-so-agile teams should be accepted or tolerated. This is a tough sell to agile fanboys. I do think that I see where you're coming from but I don't think this item will gain much acceptance. After all, if you find a more productive way of working you tend to encourage others to do the same and perhaps even expect them to do so. Though most will accept that some things won't work as well for some teams/individuals. However, there's a kind of religious madness that's taken over in some quarters where a focus on smashing time-wasters/bureaucracy and driving for excellence/productivity have been replaced with fervourously following the doctrines of their favoured agile gurus.

3 Mark.Lines commented Permalink

Re: #13 - assets. In mainstream agile there tends to be a focus inward to the team and project. For instance Scrum talks about the importance of team focus with minimal distractions. <div>&nbsp;</div> Making an effort to look outward is important though. This is related to the ecosystem comment as well, where a healthy organization has a process/tools in place to harvest and publishes available assets for reuse. These assets are anything of value that might be useful to other teams such as code, templates, guidelines, patterns, frameworks, services etc. These assets certainly evolve over time. <div>&nbsp;</div> Scott has talked in the past about how if you don't have strategy and process for reuse in place, it won't happen. This doesn't have to be bureacratic, and should be lightweight and agile like everything else. We have all seen situations where teams are so focused on their own project that they miss using an available asset, and end up redesigning/building something that already existed. <div>&nbsp;</div> Regarding 15, I think that we are suggesting that organizations need to adapt to be flexible enough to support both agile and traditional approaches. Unfortunately PMOs are often prescriptive about what processes should be used and can be infexible about supporting agile methods. Coordination and sharing between teams, not just within them can be encouraged if the organization adapts its governance (gasp) practices in a lightweight fashion to support thes agile methods.

4 Valentin-TudorMocanu commented Permalink

[POINT 1] Focus on solution delivery – instead of software development <br /> It is a not so good simplification. The main problem that shall be solved is the software development process (SDP) that also includes building a solution and then delivery. It is true, more, and more software solutions include also third party software that not need full development. BUT, the process that has GREATEST problems is SPD part. <br /> Warning: A more general concept than SDP could be SBSDP- Software Based Solution Development Process. BUT, in SBSDP the higher risk part is pure SDP and will need special attention (otherwise is a process anti-pattern). <br /> Proposal 1: Do not (never) use “delivery”, but “solution delivery”. <br /> Proposal 2: Special notification that in “solution delivery”, the part that mostly needs agility is pure SDP. <div>&nbsp;</div> [POINT 2] „Full range of stakeholders” instead of customers or instead of business people. <br /> There are 2 related problems with this approach. Yes, it is true that not only the customer shall be involved in collaboration etc, but all involved stakeholders. BUT, the accent on customer has a purpose in Agile Manifesto: “Customer collaboration over contract negotiation” means two thinks: customer acceptance for allowing an Agile interface in the project with collaboration and intermediate deliveries&amp; acceptance that will partially replace the contract type agreement. If the “customer” is REPLACED with stakeholders here and in the principles, the meaning of Agile Manifesto will be strongly DAMAGED. <br /> Proposal: DO NOT REPLACE (!), just EXTEND old sentences with a pair sentence where is used also the word stakeholder. <div>&nbsp;</div> [POINT 3] &amp; new [Principle 13] <br /> The agile projects shall have organization support and shall offer feedback to organization trough the organization process assets. That mean agile projects shall use organization level persistence like support for improvement. In two words, a new dimension of agility: COLLABORATING PROJECTS (missing, not specified in AM). <div>&nbsp;</div> [Principle 14] <br /> Reduced project scope is a point of optimum for Agile projects (or rather a pre-condition) , where even Agile is a point of optimum for SDP. <div>&nbsp;</div> [Principle 15] <br /> Process and its improvement are effective ONLY if will enable ADAPT THE PROCESS concept that mean Agile and Non-Agile, depending on the project context. <div>&nbsp;</div> [POINT 4] <br /> Agile development as is stated in Agile Manifesto and as is well known in the development world it is just a particular case of "Agility", representing a already-(pre)tailored type of process.

5 RavichandranJv commented Permalink

Does "Working solutions over timeboxed delivery" make sense because there seems to be too much stress given to documentation whereas the expanded Agile principle is about delivery and not documentation.

6 EricJanMalotaux commented Permalink

7 is still somewhat vague: working solutions cannot be measured unless it is clear *how well* the solutions work. It could be made more specific: "Quantified business value is the primary measure of progress". See principles 1 and 2 on slide 3, "Gilb's Ten Key Agile Principles to avoid bureaucracy and give creative freedom", in "A Real Revolu*onary Agile Manifesto Value to Stakeholders – Not working code to customers" (http://www.gilb.com/tiki-download_file.php?fileId=389).

7 ProcessGuy commented Permalink

Why do developers not see past their Agile personalities? All of the points mentioned are practices and principles that should be applicable in ALL development environments. Quit applying the Agile word to everything that's good and make the world a better place, not just your backyard.

8 cebess commented Permalink

Interesting how the geographic constraint of being close to the customer that the original Agile folks fought so strongly for and the on-going support by a consistent team of personnel have been downplayed. That must be because they are such a restraint on the margin of the teams that provide solutions for money.

9 MarvinToll commented Permalink

Scott, <div>&nbsp;</div> I'm glad you have taken seriously my suggestion to iterate the Principles - few folks have. A few comments: <div>&nbsp;</div> 1) I never suggested we should iterate the Values... and don't think there is a need to substitute two words. <div>&nbsp;</div> 2) The fundamental problem Principle... that is #11... has not been touched. Altering of Principle #11 is a systemic change focusing on scaling Agile. <div>&nbsp;</div> 3) This 'organizational ecosystem' deal sounds like it came from someone in a research capacity... vs. someone that spends their day implementing 'working software'. <div>&nbsp;</div> Perhaps you could make it to the 'Agile and Beyond' Conference? This would be a good place to have a wide-open face-to-face discussion on the topic. <div>&nbsp;</div> http://AgileAndBeyond.org <div>&nbsp;</div> _Marvin

10 Mark.Lines commented Permalink

Marvin, you make a very good point about Principle 11. The "best architectures" that emerge from self-organizing teams may be "best" for the project, but how about the organization? Perhaps we need a "Whole Enterprise" practice similar to the "Whole Team" practice? <div>&nbsp;</div> How do we make it clear in the principles that agile at scale necessitates collaboration with enterprise concerns such as architecture, data, and governance bodies for the benefit of the enterprise as a whole? <div>&nbsp;</div> However, how do we make it clear that we this needs to be agile rather than overly ceremonious?

Add a Comment Add a Comment