Comments for Scaling Software Agility

Comment on Scaled Agile Framework Practitioner and Consultant Certification Curriculum by Rich

Rich — Tue, 08 May 2012 12:41:38 +0000

Ah… answered my own question. I overlooked the curriculum link which points to what I needed

Comment on Meeting Deadlines: What’s Wrong with this Release Plan? (AERP7) by Jody

Jody — Mon, 07 May 2012 15:49:18 +0000

Uh, the before and after plans are exactly the same.

Comment on Picking Agile vs. Waterfall “Projects”: a Ten Point Quiz. by Derek Davidson

Derek Davidson — Wed, 02 May 2012 10:58:36 +0000

This post did make me smile Always good to see another agile evangelist spread the word!

On the topic of which, recently I asked the Googleian library why anyone should use scrum instead of waterfall in a software project. Answers were a little thin on the ground so I researched and wrote an article on it:

http://www.webgateinternational.com/2012/05/top-10-reasons-to-use-scrum-instead-of-waterfall/

Hope it proves useful!

Comment on Scaled Agile Framework Practitioner and Consultant Certification Curriculum by Rich

Rich — Thu, 26 Apr 2012 17:53:32 +0000

Having read “Agile Software Requirements”, such a curriculum sounds very interesting. The details of the curriculum leave me with a question. A couple of thousand dollars would be wasted if the class is just a re-hash of the book. What would you say is the “value-add” for the class for those who have already absorbed the content of the book? I see a few of them, but if you could amplify, that would be great.

Comment on An Agile Architectural Epic Kanban System: Part 2 – The Model by Christophe

Christophe — Thu, 05 Apr 2012 13:26:20 +0000

Hi Dean,

This is very good post. I have one question on:

“Backlog epics are discussed periodically. Based on decision criteria, epics in this state can be a) promoted to the next state b) demoted back to Funnel state, or c) deleted.”

Traditional portfolio management would want to make sure “epics” are aligned with the company’s strategy, that resource capacity is aligned with epics that are going to be implemented. So do you see a gated process with quarterly review of the “epics” and quarterly funding?

Best Regards,
Christophe

Comment on July 2012 Scaling Agile Keynote and Workshop in Frankfurt, Germany by Hans-Peter Korn

Hans-Peter Korn — Fri, 23 Dec 2011 16:59:42 +0000

just one small remark: The venue will be Walldorf (near Frankfurt Airport), NOT Stuttgart

Comment on New Whitepaper: Agile and High Assurance by New Whitepaper: Agile and High Assurance | MAK and Associates

New Whitepaper: Agile and High Assurance | MAK and Associates — Sun, 11 Dec 2011 02:11:57 +0000

[...] recently came across Agile and High Assurance white paper written by Dean Leffingwell. Many medical device software development companies struggle with the [...]

Comment on New Whitepaper: Agile and High Assurance by steveatmakcompliance

steveatmakcompliance — Wed, 07 Dec 2011 21:42:52 +0000

Sure Dean, I agree on more specifics,
In addition to the FDA’s Quality System Regulation specific to SW (21 CFR820.30); a medical device software MFG is required to make premarket submissions that has it’s owns set of (regulatory) requirements depending on the device’s classification, complexity, and risk. It is important to realize the requirements, resources, and costs associated with device submissions that have clear, concise, and complete software documentation.

In the FDA’s Guidance for the Content of Premarket Submissions for Software Constrained in Medical Devices as a general plus any device specific recommendations, i.e., FDA Guidance for the Submission of Premarket Notifications for Medical Image Management Devices, require software artifacts and traceability to support a determination by the FDA that the software is safe and effective.

The first hurdle is for the SW MFG to determine the device’s SW level of concern and device classification. The output from the process to determine the level of concern (FDA) and software safety classification (IEC 62304) establishes early on, the required software artifacts and level of documentation required for the premarket submission (including any device specific requirements).

Although risk management was mentioned, risk analysis, risk evaluation, and risk control traceability is required. This may pose additional discussion on how quality management, risk management and software development processes are integrated, but risk management must be included in the SW development process at the right times (good news is that device risk management is ongoing and its iterations can be integrated into an Agile process. Careful planning by the SW dev team is needed to have the information and documentation required for adequate risk management and traceability to design controls.

Detailed design documentation. the software architecture, state diagrams, flow charts, methods, algorithms and technology must be submitted. Much of this information is basic, but the SW development process needs to provide these outputs.

Software development environment and SW development processes. The FDA requires documented and controlled process. We can’t overlook the obvious, but a good software development plan is needed to document the processes, development environments and project deliverables required.

Comment on New Whitepaper: Agile and High Assurance by Dean Leffingwell

Dean Leffingwell — Wed, 07 Dec 2011 19:49:34 +0000

Thanks Steve,
Could you perhaps highlight the nature of the content required that is not addressed by the artifacts and traceability mechanisms highlighted in the whitecap? In other words, what specific gaps do you see?

I’m sure this would help others understand how to augment the methods that we described.

Comment on New Whitepaper: Agile and High Assurance by steveatmakcompliance

steveatmakcompliance — Wed, 07 Dec 2011 19:36:19 +0000

Dean, Craig, Yvonne;
Great job on the white paper and supporting research. One key area the white paper did not address is the content required for premarket submissions (510k, PMA, IDE, Clinical evaluation) for software medical devices. Much of the information required for these submissions is collected as output from the development process. Too often I find my FDA software company clients performing retroactive steps to document this content for their regulatory submissions.
Regards,
Steve.