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

Comments (19)

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