I agree with the Ron, Jeff (and others)about the problems with retaining "some of the old" while trying to introduce the new. Many folks are not comfortable just jumping into a completely new environment, so you can encourage them to change by careful, considered retention of a small number of "safe" practices. However, keeping too much of the old will cause failure, and then the team will blame the failure on the new, not on their own reluctance to change.
Use cases are one of those practices that tend to encourage a BRUF approach, so it is very difficult to get people to start writing tests or code before the use cases are "done." It is important the the PO is responsible for the use case scenarios, not the team. The team only implements the scenarios given by the PO - they do not write scenarios. The PO may choose to modify the use case scenarios based on talks with the team, but that's their choice.
What I found useful was to run a one-day sprint where we start with a draft use case, "flesh out" the main success scenario, write the test case for it, collect or create the test data, agree on a design, write the code (pair programming), run the tests, fix any problems, and demo the working code.
If you don't feel up to running this yourself, several CST companies provide this approach in a range of 1-5-day variants. The key to the success of this approach is that it lets the team actually see the WHOLE "life cycle" of a sprint in a short time, with real results that apply to their bottom line (not a "classroom exercise.")
I've seen the light go on in the eyes of several teams and "managers" after doing this. I've also seen teams decide to stay with BRUF because they were not comfortable with not "knowing the big picture" before writing code. Ultimately it is the team's choice, not yours or that of the management.
If your organization has a mandate to maintain the use case model, one way to manage a collection of use cases without weighing down the Team is to give ownership of the use cases to the PO and the enterprise QA team. Since new functionality comes from the PO, changes to existing use cases are a good place for the PO to start. Since errors are the result of inconsistency between user actions and the implemented scenarios, recording these inconsistencies as a change request referencing use case scenario(s) fits well with the way that many QA organizations operate.
--- In email@example.com, Jeff Anderson <Thomasjeffreyandersontwin@...> wrote:
> There is no magic formula to getting people to change their behavior,
> way of working etc...
> I think you need to point out the inherent waste involved in your
> approach and ask good questions and demand answers eg how similar are
> the test cases to the use cases? (Show examples to your leadership,
> point out the duplication, suggest a common artifact), how much of
> your testing cycles are getting consumed by regression? (Get numbers
> from your team, show potential efficiency through automation, etc)
> The good thing is that you are working in iterayions that are
> hopefully short enough to expose your issues, now you just need a
> venue to act on them.
> On 3/10/10, Ron Jeffries <ronjeffries@...> wrote:
> > Hello, PeteCRuth.
> > The thing that troubles me is that I have /never/ met a programmer
> > who wanted to do documentation. Not one, in a half-century.
> > If these are programmers, some very odd force is acting on them.
> > If they are not programmers ... then I'm curious how the team is
> > made up.
> > R
> > On Wednesday, March 10, 2010, at 4:48:16 PM,
> > you wrote:
> >> Spending time "fleshing out" use cases and test cases might be symptomatic
> >> of a variety of things, among them:
> >> 1. that they were not clear in their original form (as unlikely as that
> >> might be)
> >> 2. they feel the need to "reinforce" their original understanding of the
> >> content
> >> 3. they are uncomfortable with moving on to the coding and testing
> >> 4. someone is demanding this documentation
> >> 5. they have a fetish for documentation
> >> 6. they haven't yet "bought in" to the "agile thing" yet
> >> 7. they feel the need to "cover their butts" if things go wrong
> >> 8. they might be embarrassed about not "doing it right"
> > Ron Jeffries
> > www.XProgramming.com
> > www.xprogramming.com/blog
> > Working in a team room reduces significant interruptions
> > by making most interruptions very insignificant.
> Sent from my mobile device
> Jeff Anderson