24906Re: [scrumdevelopment] Potentially releasable software
- Nov 1, 2007Mark:You raise a very interesting question.Lets examine it quite literally. "Potentially" shippable "software" - just because you have "potentially" shippable "software" does not mean you should but you can. If it needs to pass through some additional auditing/ test/ regulatory procedures - that should comprise activities which are additional to "main software". I know you can argue that till they pass this, you dont know if the code is shippable or not. I think you have to think of "software" quite literally - is it unit tested, integration tested, packaged, documented so that only the factors that SCRUM team can't control or does not want to [for better productivity or convenience] are left for the release sprint.Hope that helps!thanks
Robin Dymond <robin.dymond@...> wrote:So you have two very good opinions, both are right, and I recommend you follow both.
Patientkeeper releases patient records software weekly to I think around 200 hospitals. I don't know their FDA requirements. Ilja is asking a perfectly reasonable question. However patient keeper did not do this overnight. It took lots of work and discipline to get to that place.
Think about what changes you can make this iteration, in the next iteration, etc. so that you too can release to your customers with a push of the button, and it is relatively painless for all. Some companies, like JDA software use Agile, but their customers will only accept a certain frequency of releases. Some customer environments require manual updates to things like terminals or POS or other equipment, so the cost of doing updates can be high.
Most enterprse software implementations have not HAD to make installations and updates painless, so the effort into release/install automation has not been made. It is a worthwhile investment because of the increased speed to market you and your customers gain. However your business will need to make a decision to get there, and plan to deal with all of the barriers as you would any other feature in the backlog.
www.innovel. netOn 11/1/07, Ilja Preuss < it@iljapreuss. de> wrote:Mark Graybill wrote:
> - Our software is classified by the FDA as a Class II medical device so
> getting filing done every 30 days is a challenge.
I wonder how PatientKeeper is doing it.
> - Our full testing suite takes a full week.
What are you planning to do to decrease this time?
> - From a project standpoint, 30 day Sprints are challenging and 15 day
> Sprints impose a near impossibility to produce a releasable product or
> even potentially releasable at the end of every Sprint.
What are the roadblocks to getting a releasable product in that time frame?
> - The idea of deploying at this frequency has not been well received by
> our customers.
That probably means that receiving a deployment is in some way "painful"
to your customers. Where is that pain coming from, and how could you
mitigate it? What would be needed to make it a no-brainer?
> The proposal in debate is this:
> - Each user story involves a procedure to bring it to potentially
> releasable status.
I always thought that was the *definition* of a user story. Isn't it?
> - The end result is a feature tested and integrated into the product.
Sure. "Done done".
> - But the product itself does not go through full testing every Sprint.
If you don't fully test the product, how do you never whether you are
> - Have alpha releases that only require an alpha contract and do that
> every two Sprints.
What does "alpha contract" mean in this context, and how would it help?
VP, Managing Partner
cell: (804) 239-4329
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
- << Previous post in topic Next post in topic >>