• 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?

11 MarvinToll commented Permalink

Mark... a five year journey at Ford Motor Company has led us to a revised Principle #11 similar to: <div>&nbsp;</div> "The best requirements emerge from self-organizing teams." <div>&nbsp;</div> And a new Principle: <div>&nbsp;</div> "Patterns that include working software are an effective way to transmit Architecture/Design ideas."

12 ScottAmbler commented Permalink

I thought I’d wait a few days before jumping into the discussion. There have been some great suggestions that I thought I’d comment on: <br /> Geri – For anyone not familiar with the Enterprise Unified Process, the site is http://www.enterpriseunifiedprocess.com/ <div>&nbsp;</div> Steven – Most software engineers are also dealing with delivering documentation, evolving the usage/process around the system being delivered, and so on. So they’re doing more than just software. Agree that we could improve the wording of 13 and 14, will update the blog later today. As with evolving assets, agile teams should be expected to give back to the overall enterprise just as other teams do. They also shouldn’t be building silo apps – I’ve seen too many agile teams get into serious trouble building silo applications all in the name of doing the simplest thing possible. This is a Whole Enterprise issue as Mark mentions in another comment. As for 15, it’s also a Whole Enterprise issue, and if a few “agile fanboys” don’t like it then I’m willing to learn to live with the guilt. ;-) <div>&nbsp;</div> Valentin – Solution delivery is likely a better term than just delivery. Will update the blog later today and see if people like it. Stakeholder is an inclusive term for customer. We’ve seen, and continue to see, many agile teams get into trouble because they interpret customer to be just the business, ignoring many other important stakeholders by doing so. If you get a chance look into Outside-In Software Development as it has an excellent description of the various types of stakeholders. My discussion of the Active Stakeholder Participation (http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm ) practice includes a summary. There may be the need for a principle around working with other project teams which are working in parallel with yours, need to think about that a bit. <div>&nbsp;</div> Ravi – That’s a lean concept that you bring up, and a very good one at that. Whether you have timeboxes or not is a decision that the team should make. Sometimes they make sense, sometimes not. Perhaps a Lean Manifesto should call this out, but I’m not sure that an agile manifesto should. <div>&nbsp;</div> Eric – Good point, although isn’t delivering business value implied by Principle #1? As an aside, we actually call out delivering business value in the definition of Disciplined Agile Delivery (DAD). <div>&nbsp;</div> Cebess – Can you discuss this further? Not really sure what you’re getting at. By the way, the minority of agile teams are co-located. The 2008 IT Project Success Survey (http://www.ambysoft.com/surveys/success2008.html ) shares some interesting stats on this issue. <div>&nbsp;</div> Marvin – You’re one of many people who feel the need to evolve the manifesto, thanks for your input. Organizational ecosystem is a term from the enterprise community, and Jim Highsmith uses the term ecosystem a fair bit too. Once again, it goes to Mark’s point about Whole Enterprise. I won’t be at the Agile and Beyond conference although would like to be. I wouldn’t change principle 11 as you suggest for a few reasons. First, you appear to be dropping the concept of evolutionary design and architecture, something I’d be reticent to do. Second, my experience is that the best way to communicate architectures is face-to-face, as I indicate in my Agile Architecture (http://www.agilemodeling.com/essays/agileArchitecture.htm ) and Agile Enterprise Architecture ( http://www.agiledata.org/essays/enterpriseArchitecture.html ) articles. Patterns are a great technique too, as are reference architectures (which is what you might also be getting at) and there are clearly other strategies which work well in given situations. <div>&nbsp;</div> Mark – You’re dead on with the Whole Enterprise concept. I’ve written a fair bit about this with EUP and to a lesser extent my work around Agile Data (http://www.agiledata.org) where it addresses enterprise architecture and data administration issues. As you point out, it is not only possible to be agile at the enterprise level it is also highly desirable to do so. <div>&nbsp;</div>

13 ScottAmbler commented Permalink

I just made some minor changes: <br /> Principle #2 - Used the term solution delivery as suggested by Valentin <br /> Principle 13 and 14 -- Reworded for consistency as suggested by Steven <div>&nbsp;</div> I suspect that 14 still needs some work.

14 HoriaSlusanschi commented Permalink

For principle #14, consider reflecting all the aspects of Muda/Mura/Muri. Minimizing work-in-progress is just one aspect of waste (Muda). Visualizing workflows is one technique that may help us deal with overburden, unreasonableness or absurdity (Muri), but not the only one. Uneveness of flow (Mura) is not even alluded to. <br /> Perhaps, consider something like: <br /> 14. Aim to achieve a smooth flow of delivery, with a sustainable pace, keeping work-in-progress to a bare minimum. Consider visualizing workflows, beware overburdening and unreasonableness.

15 ScottAmbler commented Permalink

Horia, that's an interesting suggestion, although I think you've hit on several principles, not just one.

Add a Comment Add a Comment