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

Comments (19)

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.

16 stuaxo commented Permalink

Please humanise the language... I realise the language used might be succinct, but it is incredibly offputting management speak and needs humanising. <div>&nbsp;</div> "Solution delivery" - This is awful and has to go (replace with something that keeps the same meaning). <div>&nbsp;</div> "Stakeholder" - "People involved" is longer, but avoids the buzzword <div>&nbsp;</div> I realise your describing in general what would change, but I would hope that when it comes down to it, the newer manifesto is not worded like this, it would be very offputting. Also, there are a lot of things in this summary, I'd hope it will still be small at the end. <div>&nbsp;</div> In summary: it needs to be short and in human language - we "do" things, we don't "action" them etc,..

17 barbarawhite 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 :-) <div>&nbsp;</div> <div>&nbsp;</div> <a href="http://www.ukmortgagecomparison.com" rel="dofollow">Mortgage Quote</a>

18 ScottAmbler commented Permalink

I just made the following updates: <br /> 1. Reworded principle #7 as Eric suggests. <br /> 2. Reworded principle #14 along the lines of what Horia suggests.

19 Mark.Lines commented Permalink

I am not sure if the rewording of #7 is quite right. One might argue that not all solutions show evidence of tangible business value. For instance, what if your project entailed a technology replatforming of your corporate website to java to be consistent with the corporate standard? You could argue that it reduces support costs, but is it quantifiable? Another example might be changes to an application that are government mandated due to changes in regulations? What is the quantified business value? <div>&nbsp;</div> I DO however like the emphasis on value delivered, since the previous wording of "working software is the measure of progress" shows no connection to value. So what if it is working software, if it is inconsistent with stakeholder needs? <div>&nbsp;</div> Any ideas for rewording, I hate to lose the "working software" bit? How about "Demonstrated business value via working software"?

Add a Comment Add a Comment