RE: [scrumdevelopment] mention of Scrum in "Software Development"
- Mike wrote:
> Might I add that PRESCRIPTIVE process and/orPaul wrote:
> organizational patterns are mutually exclusive with
> agility by definition?
> I don't think all organizational patterns are mutually exclusivePaul:
> with agility.
Sorry, my sentence should be parsed like:
"PRESCRIPTIVE process and/or organizational patterns"
i.e. All "process and organizational patterns" that are
DO ETVX task1
DO ETVX taks2
IF ITVX task2.state == somestate THEN
DO ETVX task3
DO ETVX task 14
This is what I was referring to.
If the above steps are part of the software development process,
agile is less about that.
It is more about "if in situation X do Y is a good solution"
i.e. declarative or rule-oriented.
> His analysis is flawed because the options prescriptivePaul wrote:
> and adhoc, do not describe the universe of possibilities.
> I'm not sure what you're trying to say here. Prescriptive, as inAs in programming a "prescriptive" process means step-by-step e.g.
> selecting a process element to be used in all cases, and ad hoc, as in
> selecting a process element to be used in a particular case, should
> cover all possibilities. It may not be the best way to divide the
> possibilities, it's the way he selected for the purpose at hand.
C, Java or C++, while "descriptive" means declarative: i.e.
> What I perceive, right or wrong, is that Scrum is a managementI certainly don't see things that way.
> framework, that enables self-organising teams to get on with
> development unhindered. It doesn't give guidance as to how those
> teams will get on with their work. XBreed fills in the "hole in the
XBreed is mostly about doing work with multiple teams. I really need to
change the face of it. Frankly, it got attention for
the wrong reasons, i.e. the mention of Scrum and XP used together,
which in all honesty wasn't all that important. (Scrum has had
long-held similar engineering practices that although not as well
documented work equally as well.)
The other "concurrent multiple team" practices are much more important,
> What would be the quickest way toward curing this misperception, soWell, as mentioned before on this list, not having Scrum engineering
> that I can point other folk in this corrected direction?
practices documented in "many places" is a problem. (If you recall
a conversation among a few us in the last 2 months that involved
Ron Jeffries, he strongly recommended writing more about them.)
The only documentation of "full engineering Scrum" is only
in web sites, and that is fairly vague.
We need other Scrum books that describe Scrum as a full "software
development method", not only its management practices.
The short cut of course is to use XP's engineering practices
because in the end are very similar.
> In the environments I find myself all too frequently (except in theWell, I understand your position: if you have "newbies" they do need
> recent economic downturn), if the developers did not have a process to
> follow, they would not know what to do, how to do it, or why they
> should be doing it. If you'll pardon the fine Scots word, you cannot
> stock a team with numptys and expect them to organise themselves.
> What we need to deal with is how to move forward from this
> situation toward something closer to the ideal.
help. But is "more process" the answer?
I prefer more:
more human interactions, like mentoring, over process and tools
(Wait I think I heard this somewhere else: http://www.agilemanifesto.org
Also, the "need to adapt", and hence to "improvise" goes beyond
When I show up to the office I never know what is the sequence of
steps that I am about to follow after our Daily Scrum.
I know what my "goals" for the day are but *any* combination of things
might be necessary to get them done:
* Some days we need to talk back to the customer first thing
* Some days we are testing hard to get bugs out -- even
early in the Sprint
* Sometimes a couple of us start improvising designs
* Sometimes we sit alone or with a pair and program
We make the process as go -- every day. So what I do know is that we
"follow the rules and stick to the Scrum and/or XP practices"
that will get us there.
Sorry if my first note was hard to parse,
- While I agree with Mike in general, it is of interest that the first Scrum
was building an OOAD tool and we decided the team should eat their own
dogfood. It was also the first round trip engineering tool.
Every developer had the model of his components on his wall.
Our senior consultant, Jeff McKenna, an ace Smalltalker, would walk into a
cube and an hour later the model was in shreds on the floor. He had shown
the developer how to refactor the model and eliminate half the code while
enhancing performance and functionality.
I've never seen another team that can operate at that level.
At 05:07 AM 11/14/2003, Mike Beedle wrote:
> > Mike has said repeatedly that he feels that
> > modeling isn't necessary in order to produce quality code. Scott
> > Ambler, myself, and some within the XP community have the opinion that
> > modeling, when necessary, and to the proper level of detail and
> > formality, provides an important element in the design and
> > implementation of software.
>This is also a fact:
> We produce hyper-productive, high-octane, high-quality,
> high-quantity software with little or no models.
>So no, models are not important to us, as they are not as
>important to most agile developers. (We minimize "documentation time"
>by documenting after the fact.)
>But like I said earlier, if you feel modeling helps your team, or
>is needed for political reasons, or you like how the models look on
>display on the walls, hey, more power to you.
>Good luck with all of your projects!!!!
>(It was nice to talk to you on the phone earlier this evening, btw.)
> > P.S. I'm looking forward to taking the CSM course some time in the
> > near future. Perhaps I'll walk away cured of my modeling sickness. :-)
>In 1994-1996 I was involved in a 100+ person, 30 million dollar
>software development project. By year 2 we had 1000+ pages of:
> Elaborated Use Cases
> Class Package Diagrams
> Class Diagrams
> Sequence Diagrams
> Test Plans
>but no working software. Within the last 4 months of the project
>I took over the project, *ignored all the previous models*,
>applied Scrum to the project and delivered the first instance
>of the application to production on 1/1/1996.
>(I have many other, almost countless experiences like that.)
>This is why I don't do models anymore -- they NEVER delivered the
>goods for me in the trenches.