A simple presentation on the increased value you get fron iteative approaches to software development.
This is not a deep, evidence based moel - it's more a simple principle based view of how value is earned faster. (It's part of the agile dogma, in fact.)
It's posted here because it's a potentially useful communicatio tool when arguing for iterative development.
Subscribe to:
Post Comments (Atom)
Popular Posts
-
Due to popular demand I have aggregated some information on User Stories and created a simple template. If you feel this would be useful to... -
I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ... -
Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
-
You've heard many reasons why project fail. Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
-
The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
-
In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
-
This is a guest post by Jeff Hobbs. Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
-
In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n... -
I'm a massive Lord of the Rings fan. Every year, I spend part of my holiday vacation rewatching the 12 hours of the blu-ray extended edit... -
The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
This approach of course requires the business be able to accept the incremental and iterative releases from the agile time.
ReplyDeleteIn our experiences in enterprise IT this is problamatic in many instances. Billing is one example. On the other hand Enterprise Customer Service is a natural for incremental releases. Claims process is on the opposite end - fixed verified and validated releases.
The conjecture - and its a credible conjecture - that agile provides increased value over macro-level point releases needs a context and a domain.
Like any Agile advocate, I'm a big believer in the short iteration cycle. I like to think of it as closing the feedback loop to accelerate learning how best to satisfy the need. As to what galleman said about getting acceptance, you might want to take a look at this lecture that I gave at Brooklyn College.
ReplyDeleteGlenn
ReplyDeleteYou are right; there are some tough issues - around billing as a vendor and budgeting for in house projects.
It's a process change that has some fundamental affects on the sponsors and senior mangement as well as the developer team.
We are (I am) still wrapping it with a formal business case, set of estimates and broad scope statement.
I think in the second budgeted year we might test their responiveness to a more incremental budgeting approach.
Plone (Glenn?)
ReplyDeleteI liked your presentaion. Some interesting thoughts.
Would you care to post it up to slideshare and I'll post/comment here.
See this post by Rowan Bunning on budgeting for scrum within standard financial processes
ReplyDelete