Comments for Disciplined Agile Delivery

Comment on IBM Rational Updates DAD Process Offerings by Carson Holmes

Carson Holmes — Thu, 16 May 2013 03:09:15 +0000

Sorry for not responding sooner. The DAD process template in it’s current state (both mine and IBMs) does not track decision points in the DAD decision framework…but this is an excellent idea! There is a retrospective work item that could be used for this somewhat, but not ideal. I will add this work item type in time for my Innovate presentations.

Also, you may want to look at the Software Development Practice Advisor, which keeps track of practice decisions, a dynamic playbook, human resources/skills, and measures practice efficacy for each iteration with data integrated from ALM solutions. Forward engineering of process templates for ALM solutions is also coming later this year. Overlaying the DAD goal-based decision points as another view for configuring practice choices in Advisor is also being discussed.

Comment on IBM Rational Updates DAD Process Offerings by scottwambler

scottwambler — Sun, 12 May 2013 19:30:19 +0000

Tom, I’ve asked the person whom I believe to be most knowledgeable about this plug in to respond. If you don’t hear anything within a week I guess the best bet is to email IBM.

Comment on IBM Rational Updates DAD Process Offerings by Tom

Tom — Fri, 10 May 2013 21:22:08 +0000

I’m curious how the decision points in DAD are manifested in RTC. My guess is a work item, but not sure. We’re doing a team transformation to agile and we plan on using RTC with DAD.

Comment on Webinar – “Disciplined Agile Delivery: Going Beyond Scrum” by David Parker

David Parker — Thu, 09 May 2013 21:48:54 +0000

Any luck making it publicly available? It sounds like a great topic.

Comment on What Happens When People Don’t Agree? by Gene Hughson

Gene Hughson — Thu, 02 May 2013 16:04:54 +0000

Indeed! No process whatsoever can make up for a refusal to communicate.

Comment on Roles in Disciplined Agile Delivery by What Happens When People Don’t Agree? | Disciplined Agile Delivery

What Happens When People Don’t Agree? | Disciplined Agile Delivery — Thu, 02 May 2013 15:39:40 +0000

[...] and responsibilities. One of the reasons why DAD defines rights and responsibilities for various roles, which we adapted from source methods such as Scrum and Agile Modeling, is to help distinguish the [...]

Comment on Ranged Burndown Charts by Two velocities: Gross vs Net. | Disciplined Agile Delivery

Two velocities: Gross vs Net. | Disciplined Agile Delivery — Wed, 01 May 2013 13:43:05 +0000

[...] two velocities to chart, not just one, this leads us to evolve burndown charts into what is called ranged burndown charts, the topic of my next blog [...]

Comment on Webinar – “Disciplined Agile Delivery: Going Beyond Scrum” by Julian Holmes

Julian Holmes — Wed, 01 May 2013 08:12:18 +0000

The webcast was hosted and recorded by the Global Rational User Community, with the recording placed on their site: http://rational-ug.org/content-library/m/files/606.aspx
If we are also able to place it on a public site, we will post an update here.

Comment on Webinar – “Disciplined Agile Delivery: Going Beyond Scrum” by Beth Elliott (@iconbeth)

Beth Elliott (@iconbeth) — Tue, 30 Apr 2013 19:21:04 +0000

Was this webinar recorded? If so, how may we access it?

Comment on It Requires Discipline to Keep Inception Short by scottwambler

scottwambler — Fri, 19 Apr 2013 14:06:47 +0000

Nancy, you’ve identified some common issues that many organizations still face. Here are some thoughts for you:
1. Early in a project the information that you have isn’t very accurate. Stakeholders will struggle to tell you what they want, this is human nature, and even if they were good at telling you what they want they would change their minds anyway. In addition you may not have a completely clear idea as to how you’re going to approach building/configuring the solution nor will you even have a clear idea as to who will be on your team and how available they are. All of this information is important input into your schedule and estimates. So, because the input is “fuzzy” so is your output. The implication is that at the beginning of a project your time and cost estimates should be given in ranges. These ranges will reflect the uncertainty, or the fuzziness, of the information you have at hand. In the book we cover these sorts of ideas in Chapter 10 and even promote a ranged burndown chart approach for updating the estimates based on improving information.
2. One of the strengths of the DAD framework is that it makes your process-related options explicit. As a result there is in effect an infinite number of ways that you can tailor DAD to reflect the context of the situation that you face. So, the case study reflects only one of many ways to take a DAD-based approach.
3. Calculation of ROI, NPV, the business case, and other issues will also be based on this fuzzy/uncertain information. I find that many organizations want you to invest time in creating these sorts of things, which clearly has a cost associated with doing so, yet rarely do they track after the fact whether you acheived what you originally promised. This is a sign that something is wrong in your governance strategy. I suspect it’s because management inherently knows that the initial ROI… calculations are little better than works of fiction yet are unwilling to realize that there’s little value in spending much time on them.
4. In DAD we clearly promote the idea that you should identify and then mitigate risks, that you should invest a bit of effort in common to a common vision for your effort, that you should invest some time in identifying the initial scope, and other project initiation activities. We also promote the idea that you should invest as little effort as possible in doing so because you will increase project risk by doing too much up front planning.
5. It sounds as if your organization is still suffering a bit from a more traditional mindset. This is a common problem. You need to help your management team understand that what they are requesting increases the cost, schedule, and risk to your project. In Chapters 7-10 we explicitly discuss the advantages (few) and disadvantages (many) of heavy/detailed approaches to requirements, architecture, and planning required to fulfill such requests. In Chapter 20 we describe strategies for governing agile project teams effectively. From the sounds of it your organization is still applying traditional governance strategies, or at least traditional-leaning strategies, and as a result are likely causing harm to the teams that they hope to be helping.
6. To explore the inherent waste in your existing governance process, consider creating value stream maps to explore what is actually occuring.
7. Feel free to contact us via http://ScottAmbler.com if you’d like some help adopting a disciplined agile approach.