Yup, the four critical tools: 1) Team, 2) Whiteboard, 3) Marker, 4) Eraser. :-)


--- In scrumdevelopment@yahoogroups.com, Ilja Preuß <iljapreuss@...> wrote:
>
> When I use UML, it's typically to organize the thoughts *of a team*,
> and get them into the heads of the team members. And for that, a
> whiteboard works much better than any software tool. Bad handwriting
> is not a problem, since you can ask the writer what it means. If you
> still can't read it, get a marker and do it better.
>
> Cheers, Ilja
>
> 2010/2/26 Jeff Anderson <Thomasjeffreyandersontwin@...>:
> > I use UML, maybe a bit more formally than most on the agile board, but not
much.
> >
> > Some good oss tool can actually make it faster to organize thoughts
> > and get them to code, than whiteboard models done by techies who have
> > bad hand writing.
> >
> > Maintaining even reasonable details is a hassle reserved for a small
> > portion if the system at best, and even then only to help communicate
> > common patterns and such, most of which are not obvious up front...
> >
> > On 2/25/10, dsrkkk <dsrkkk@...> wrote:
> >> I am trying to know whether UML modeling is used for scrum projects.
> >>
> >> dsr
> >>
> >>
> >
> > --
> > Sent from my mobile device
> >
> > Jeff Anderson
> >
> > http://agileconsulting.blogspot.com/
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to:   scrumdevelopment@...
> > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...!
Groups Links
> >
> >
> >
> >
>

I usually describe a Baseline as "a named, consistent, reviewed version". That
is, it's a published version with ceremony around it.

How much ceremony is required depends on the circumstances. If your software
development effort is the whole product, then you may be perfectly fine relying
on continuous integration and regular iteration feedback. Or not, depending on
how wide the stakeholder community is. The point of the Baseline is just that
it's published (as opposed to "the current state of things"), so a wider
community can review it.

If your software is one component of a larger product, it's very likely that
you'll need to do software Baselines (specific, identified versions) to
coordinate with product-level Baselines.

regards,
scott

--- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
>
> Hi, Paul,
>
> pauloldfield1 wrote:
> > (responding to All)
> >
> > Normally if I hang back, someone says what I would have said.
> > Several days into this thread I haven't spotted it yet, so:
> >
> > The Baseline is a mechanism to bring together a set of things
> > such that they are consistent with each other - say so that the
> > code you are testing, and the tests you are running, both match
> > the same requirements, and the user documentation that you would
> > send along if you released this code.
>
> Isn't that what Version Control is for?
>
>   - George
>
> --
>   ----------------------------------------------------------------------
>    * George Dinwiddie *                      http://blog.gdinwiddie.com
>    Software Development                    http://www.idiacomputing.com
>    Consultant and Coach                    http://www.agilemaryland.org
>   ----------------------------------------------------------------------
>

Hi woynam,

with the risk of being way off topic :)

As you wrote, using RUP gave you hundreds of UML diagrams back in the days,
which you found useless later on.
RUP never tells you what or how many diagrams to draw. If you decide to draw
hunderds, well good for you. If you want to draw one on a white board and take a
snapshot of it, that works for RUP as well.
So really the problem was the implementation of RUP and not RUP itself.

I know that it is possible to run RUP the agile way. The two big problems with
RUP is that it needs a massive up-front understanding of it and then a great
deal of configuration (which is not that agile).

Sorry for the mini-rant :) I just feel that RUP gets an unfair amount of blame
for a lot of things, where the actual root cause was bad implementation (i.e.
the people using RUP).

-Mikael

--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
>
>
>...
>
> When we first started building our new platform 12 years ago, we adopted RUP.
We had *hundreds* of detailed UML diagrams, particularly interaction diagrams,
i.e. sequence diagrams. That was all fine and good, but once we rolled out
version 1 of the software, and proceeded to design and code version 2, we
quickly discovered the pain of maintaining all those diagrams.
>
> When we delivered version 2, I went back to see how many diagrams were
actually updated. It turned out that almost no diagrams were updated, and yet we
successfully delivered the 2nd release. So, what do you think I concluded about
the value of formal UML diagrams? About that time we discarded RUP in favor of
agile, and our lives got a whole lot easier. :-)
>
> Mark
>

I hear you. I'm certainly not blaming RUP. We chose to formalize the diagrams as
part of our RUP "business case", i.e. our customized RUP blueprint. Part of the
reason for the formal diagrams was that we had faith in the ability of Rational
Rose to generate code, and possibly reverse engineer. That faith was badly
misplaced. Rose was basically a piece of junk. The code generator produced code
that didn't even compile! This was the early days of Java, and the tools weren't
quite up to speed.

Actually, our use of RUP was fairly lightweight. I was an advocate of a
lightweight process, having come out of an environment that was basically (pre)
XP, but the business was transitioning to OO, and iterative development at the
time, and wanted to take a more "conservative" approach.

We relaxed the requirements to create formal UML models, and stuck with RUP for
a bit longer, but eventually we morphed into an agile shop. Sure, I guess it's
possible to have an Agile RUP implementation, but like the illusive Yeti,
they're hard to find. ;-)

Mark

--- In scrumdevelopment@yahoogroups.com, "mikael.brodd" <mikael.brodd@...>
wrote:
>
> Hi woynam,
>
> with the risk of being way off topic :)
>
> As you wrote, using RUP gave you hundreds of UML diagrams back in the days,
which you found useless later on.
> RUP never tells you what or how many diagrams to draw. If you decide to draw
hunderds, well good for you. If you want to draw one on a white board and take a
snapshot of it, that works for RUP as well.
> So really the problem was the implementation of RUP and not RUP itself.
>
> I know that it is possible to run RUP the agile way. The two big problems with
RUP is that it needs a massive up-front understanding of it and then a great
deal of configuration (which is not that agile).
>
> Sorry for the mini-rant :) I just feel that RUP gets an unfair amount of blame
for a lot of things, where the actual root cause was bad implementation (i.e.
the people using RUP).
>
> -Mikael
>
> --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
> >
> >
> >...
> >
> > When we first started building our new platform 12 years ago, we adopted
RUP. We had *hundreds* of detailed UML diagrams, particularly interaction
diagrams, i.e. sequence diagrams. That was all fine and good, but once we rolled
out version 1 of the software, and proceeded to design and code version 2, we
quickly discovered the pain of maintaining all those diagrams.
> >
> > When we delivered version 2, I went back to see how many diagrams were
actually updated. It turned out that almost no diagrams were updated, and yet we
successfully delivered the 2nd release. So, what do you think I concluded about
the value of formal UML diagrams? About that time we discarded RUP in favor of
agile, and our lives got a whole lot easier. :-)
> >
> > Mark
> >
>

Mark,

You need the 5 frames per second to keep up with an *Agile* team.

   - George

woynam wrote:
> You're right, as usual. I think I need a Nikon D3x, so I can take 24.5
megapixel picture of the whiteboards. :-)
>
>     http://www.nikonusa.com/Find-Your-Nikon/Product/Digital-SLR/25442/D3X.html
>
> Continuous improvement is one of the key tenants of agile, and what could be a
better improvement than going from 2 megapixels to 24.5 megapixels? Why, that's
over an order of magnitude improvement! :-)
>
> Mark
>
> --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
>> Hello, Mark.  On Thursday, February 25, 2010, at 12:26:52 PM,
>> you wrote:
>>
>>> Sure, we use it. Generally it's a bunch of team members standing
>>> around a whiteboard scribbling. Once a design is agreed upon, then
>>> it's off to the keyboards to code. If the diagram is worth saving,
>>> I take a picture of it with a cheap digital camera.
>> You're doin it wrong. The company should buy you an EXPENSIVE
>> digital camera.

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

Scott,

scott preece wrote:
> I usually describe a Baseline as "a named, consistent, reviewed
> version". That is, it's a published version with ceremony around it.

That ceremony can be as simple as tagging in your VCS.

> How much ceremony is required depends on the circumstances. If your
> software development effort is the whole product, then you may be
> perfectly fine relying on continuous integration and regular
> iteration feedback. Or not, depending on how wide the stakeholder
> community is. The point of the Baseline is just that it's published
> (as opposed to "the current state of things"), so a wider community
> can review it.

Only if your separate your software development from the rest of the
product development, which I would suggest is a bad idea.  All the stuff
related to the product should be developed together and versioned together.

> If your software is one component of a larger product, it's very
> likely that you'll need to do software Baselines (specific,
> identified versions) to coordinate with product-level Baselines.

Do 'em together and tag them with one label.  Separating software as a
"special thing" from hardware, user manuals, and whatever makes as
much^H^H^H^H little sense as separately developing the GUI, the domain
code, and the database.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

I have not read any of the responses, so I apologize if I repeat what someone
else has said already.

I would really try to push for a coach to come in for a short while to help the
team to change their habits.

Additionally there are some really good videos online by Ken Schwabber, Jeff
Sutherland, Mike Cohn. Try to get the team to watch them, do a couple lunch and
learns. The one video in particular that I found incredibly inspirational was
ken's google tech talk.

Try baby steps, even one developer at a time. Get one developer on your side,
get him to work with qa upfront to define acceptance tests. Get some early wins,
this will help others to see the way.

Jack
www.agilebuddy.com
twitter.com/agilebuddy
blog.agilebuddy.com

--- In scrumdevelopment@yahoogroups.com, "Griner, Jennie" <jennifer.griner@...>
wrote:
>
> Some quick background, my group decided to implement an agile approach
> on our last release.  Ignoring any work that was done before this
> decision was made, we had 13 month long sprints, followed by four
> additional months of panic mode testing and bug fixing.  I had done my
> research on what I thought agile meant for us, and would try to bring up
> things that weren't really agile, and was ignored.  Needless to say, we
> basically did a waterfall with some mini waterfalls in the middle (if
> you can even consider it that because we hadn't even fixed bugs as we
> came across them, they were all saved for those last four months).
>
>
>
> So, the powers that be have gotten together after a retrospective of
> that release and decided that things weren't agile, and we're going to
> actually be agile this time.  However, it appears to me that they still
> can't get some of the older ways of doing things out of their systems.
> We still have to have the requirements for a story fully documented
> (though they did change the DoD to say "agreed on" rather than "signed
> off" and they did change the item regarding Use Case and User Interface
> to include the words "if needed."
>
>
>
> Management still insists on fully detailed test cases that can then be
> passed on to a tester on the regression team in later iterations, but we
> can't leave the job of writing it to the regression tester, so the test
> member of the team must complete this prior to the end of the sprint,
> even though we know that things could continue to change up until the
> end.  This is after a test strategy must be completed along with test
> scenarios (high level test cases) for that sprint.
>
>
>
> As for bug fixes, it's hard to tell as we're halfway into our first
> sprint, and I don't think we've received a single build with the new
> code in it.  The DoD does say that the bug fixes will be made, but it
> did for our last release as well.  The team as a whole does seem to have
> made a commitment to follow the DoD much better this time, so that is a
> plus.
>
>
>
> But how do I approach some of these issues?  I've asked for formal Scrum
> training (which no one in our group has received yet, which I think it
> part of the issue), and some training has been set up, but as far as I
> know, I am not going to receive it.  I feel like I need to be heard, but
> at the same time I need to make sure that my duty to my Scrum team (as
> is currently defined) isn't skipped out on either.  Am I just stuck with
> how someone else has decided things are?
>
>
>
> Jennifer L. Griner, MCP, MCDBA
>
> Quality Control Specialist, ProSystem fx Engagement
>
> CCH, a WoltersKluwer business
>

At the end of the day, it's usually people who interact with software. As a
result, it's important that people use the software. So usability is a big
reason as already mentioned above. Additionally, manual testing may catch some
edge conditions that might have been missed by automated functional or unit
tests.

Jack
www.agilebuddy.com
blog.agilebuddy.com
twitter.com/agilebuddy

--- In scrumdevelopment@yahoogroups.com, Andrew Wagner <wagner.andrew@...>
wrote:
>
> What place should manual testing have in the development process, if any?
> And how would you back up your opinion?
>

Jennie

Forget about Agile for a second, your management is forcing your team
teams to do some fundamentally dysfunctional things, focus on that.

Ask your team members if they feel there is a better approach to
working, and how they can remove the biggest impediments. Push those
ideas up to management and demand an action plan. If this falls on
deaf ears than there is no point in pursuing *agile* practices, your
management isn't even equipped to listen to the people who are
responsible for building the product...

Get your team used to feeling like they can bring up new ideas to
improve and actually get permission to change things.


On 2/26/10, Hillel Glazer <agilecmmi@...> wrote:
> Gaad-zukes, Jennie!
>
> I was reading your reply to Steve and my eyes started to bleed.  In my head,
> every few sentences I was hearing that sound effect of the needle scraping
> across a record (an effect many of today's developers have NEVER heard in
> real life and in a few years anyone who recognizes it on hearing or can even
> parse the verbal description of it will be chasing grandchildren!).
>
> Anyway... I've worked with companies who have worked with Rally consultants
> and the results are pretty good.  Obviously it nearly always means the
> organization is using Rally's tool, but that's neither here nor there and
> possibly a good thing.  I didn't hear the needle-scraping thing when you
> noted this.
>
> However, on a lot of the other stuff, I was quite worried for your
> organization.  If I had to give a "field diagnosis" in the absence of other
> data or deeper analysis, I would say that there are several interacting
> attributes your organization is experiencing, irrespective of the likely
> concern that leadership/management want change but don't know effective ways
> of getting it.
>
> From what you describe and knowing nothing else, your organization exhibits
> symptoms of one that lacks:
> - clearly articulated and widely agreed-upon development work flows
> - several basic engineering (or software-engineering-specific) disciplines
> - several basic tenets of product management
> - clear articulation of testing scope, roles, and goals
> - a product evolution/promotion/release pattern that prevents wrong product
> from getting too far
> - much of any internalization of how to realize the benefits of iterative
> and incremental development.
>
> Quite basically, Steve's right, you really need some coaching.  And you're
> right, it might have to be expensive.
>
> Good luck!
>
> Cheers!
> -->>  Hillel
> --
> Hillel Glazer, Principal & CEO
> Entinex, Inc.
> Process can't fix stupid.(TM)
>
> www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
> O-
>
>
> On Fri, Feb 26, 2010 at 11:51 AM, Griner, Jennie <
> jennifer.griner@...> wrote:
>
>>
>>
>>   >Hi Jennifer,
>>
>> >Why did anyone in your organization want to "implement an agile approach"
>> in the first place?  Normally, organizations that perceive the "need" to
>> pursue agile approaches are doing so to not repeat past failures (project,
>> product, morale, etc.) and to pursue specific, tangible, qualitative or
>> quantitative benefits they're not getting/seeing with how they're doing
>> things now (or in the past).  So... what was/is your organization's
>> reason?
>>
>>
>>
>> That’s a really good question, and it’s going to take some digging for me
>> to find the actual answer to it.  Here’s the trouble, my understand is
>> that
>> our organization as a whole is looking to adopt agile, and our group is
>> not
>> the first to try these methods.  I’m not sure how to figure out who the
>> person is that decided that this was the way to go.  I have a feeling,
>> though, that they’ve decided to “go agile” because it’s the thing to do.
>>
>>
>>
>> >With these reasons articulated, you can look for "things you don't like"
>> or "things you don't want to do again", understand what causes them, then
>> find the lean/agile alternatives (if there are any).  This is where Pete
>> points out that change might need to happen.  To avoid the things you
>> don't
>> want to show up in the future, you'll be changing that which causes those
>> things going forward.  Such changes will frequently involve breaking some
>> paradigms and resetting some expectations.  If you get push-back, you know
>> it's a Quixotic effort and your call whether to keep pursuit or not.
>>
>>
>>
>> To respond to Pete, I think part of the problem is that the agile adoption
>> is coming from the top down, rather than from the bottom up.  I have a
>> feeling that things would be working better if we, as the development
>> team,
>> said we want to do things more agile.  Though then we may have the push
>> back
>> that you mention below, where the powers that be don’t understand it and
>> don’t see the benefit to it.  In our case, the powers that be have said
>> that
>> we’re doing this.  However, I think that they still don’t understand it,
>> so
>> they’ve told us that we have to do it, and we’re kind of drowning since no
>> one really had a good grasp of what we wanted to do when we started.
>>
>>
>>
>> >And it's also another potentially telling use of words... "implement an
>> agile approach".  I may be reading too much into it, but I've seen this
>> phrase used when organizations were looking for some silver bullet to
>> solve
>> various, sundry and weakly-understood but deep seated issues.  To your
>> organization, how is the phrase "do things in a more lean and agile way"
>> different from "implement an agile approach"?  If it's not different, then
>> ignore this paragraph.  On the other hand, if you immediately sense dread
>> and resistance, then you're back out there with Don Quixote.  "Do things
>> in
>> a more lean and agile way" is a much more robust pursuit and takes a lot
>> of
>> commitment, self-awareness and honest introspection.  "Implement and agile
>> approach" sounds more like Dilbert's Pointy-Haired boss telling Dilbert to
>> "do more with agile" believing it's an automatic and magic pill to skimp
>> on
>> resources and time and still product a quality product.
>>
>>
>>
>> I think that this paragraph is 100% accurate.
>>
>>
>>
>> >The most effective way towards "implement[ing] an agile approach" is to
>> adopt lean and agile principles, then get to work "leaning-out" the waste
>> in
>> your organization and development practices.  Whether you implement Scrum
>> or
>> not is not the issue.  Fully embracing Scrum is more than daily stand-ups,
>> time-boxed iterations, and having a backlog.  Though, once fully embraced,
>> Scrum is a lot like the "gateway drug" to agile.  If your system is immune
>> to the benefits of all-out Scrum, it's likely immune to anything agile or
>> lean.
>>
>>
>>
>> It feels like our team is going through the motions.  As you say, just
>> doing daily meetings, sprints, and keeping a backlog.  I don’t think most
>> people have the actual mindset required to be open to change.
>>
>>
>>
>> >OK... so...having said all this... your team may be hampered by the
>> nature of the agreements you have with your customers.  It's not that you
>> can't be lean, agile, or using Scrum with government contracts, it's just
>> that you will have to re-frame some of the typical agile/Scrum practices
>> to
>> compensate for the likely lack of a present customer, the likely a-priori
>> agreement on scope, the likely pre-determination of project "phases".
>>  Please understand, you don't have to abandon agile/Scrum practices, you
>> just need to re-orient your work so that you can still deliver expected
>> deliverables but that you produce them following the beat of your own
>> drummer, not the government's.
>>
>>
>>
>> This makes total sense.  We’re dealing with product managers that have
>> made
>> promises to our corporate clients, but I think it has the same effect as
>> if
>> it were a government (or any other) contract.
>>
>>
>>
>> >Good luck!
>>
>>
>> Cheers!
>> -->>  Hillel
>> --
>> Hillel Glazer, Principal & CEO
>> Entinex, Inc.
>> Process can't fix stupid.(TM)
>>
>> www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
>> O-
>>
>>  On Thu, Feb 25, 2010 at 5:54 PM, <PeteCRuth@...> wrote:
>>
>>
>>
>>
>>
>>
>>
>> Your "powers that be" may be employing the age-old management strategy of
>> appearing to be supportive by offering concessions instead of commitment.
>> Transitioning to agile methods is tough enough for many organizations
>> without having to retain unnecessary practices that end up costing far
>> more
>> time and effort than they are possible worth. Unless they understand how
>> and
>> why agile methods improve the development process, it's unlikely they'll
>> commit fully to them. Commitment without understanding is often a prelude
>> to
>> potentially terminal misunderstandings, and if this is the case, finding
>> ways to avoid getting blowback on their clothes will be high on their list
>> of priorities if things begin to fall apart.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Pete
>>
>>
>>
>> In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time,
>> jennifer.griner@... writes:
>>
>>
>>
>> Some quick background, my group decided to implement an agile approach on
>> our last release.  Ignoring any work that was done before this decision
>> was
>> made, we had 13 month long sprints, followed by four additional months of
>> panic mode testing and bug fixing.  I had done my research on what I
>> thought
>> agile meant for us, and would try to bring up things that weren’t really
>> agile, and was ignored.  Needless to say, we basically did a waterfall
>> with
>> some mini waterfalls in the middle (if you can even consider it that
>> because
>> we hadn’t even fixed bugs as we came across them, they were all saved for
>> those last four months).
>>
>> So, the powers that be have gotten together after a retrospective of that
>> release and decided that things weren’t agile, and we’re going to actually
>> be agile this time.  However, it appears to me that they still can’t get
>> some of the older ways of doing things out of their systems.  We still
>> have
>> to have the requirements for a story fully documented (though they did
>> change the DoD to say “agreed on” rather than “signed off” and they did
>> change the item regarding Use Case and User Interface to include the words
>> “if needed.”
>>
>> Management still insists on fully detailed test cases that can then be
>> passed on to a tester on the regression team in later iterations, but we
>> can’t leave the job of writing it to the regression tester, so the test
>> member of the team must complete this prior to the end of the sprint, even
>> though we know that things could continue to change up until the end.
>> This
>> is after a test strategy must be completed along with test scenarios (high
>> level test cases) for that sprint.
>>
>> As for bug fixes, it’s hard to tell as we’re halfway into our first
>> sprint,
>> and I don’t think we’ve received a single build with the new code in it.
>> The DoD does say that the bug fixes will be made, but it did for our last
>> release as well.  The team as a whole does seem to have made a commitment
>> to
>> follow the DoD much better this time, so that is a plus.
>>
>> But how do I approach some of these issues?  I’ve asked for formal Scrum
>> training (which no one in our group has received yet, which I think it
>> part
>> of the issue), and some training has been set up, but as far as I know, I
>> am
>> not going to receive it.  I feel like I need to be heard, but at the same
>> time I need to make sure that my duty to my Scrum team (as is currently
>> defined) isn’t skipped out on either.  Am I just stuck with how someone
>> else
>> has decided things are?
>>
>> Jennifer L. Griner, MCP, MCDBA
>>
>> Quality Control Specialist, ProSystem *fx* Engagement
>>
>> CCH, a WoltersKluwer business
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

--
Sent from my mobile device

Jeff Anderson

http://agileconsulting.blogspot.com/

March 12, 2010
11am - 1pm PST / 2pm - 4pm EST

What do you do when your customer changes a requirement?  How do you keep going
when a team member is pulled away for a production issue?  What happens when you
start coding and realize a feature is much bigger than anticipated?  You will
learn how to deal with these issues and more in this virtual workshop.

RESERVE YOUR SEAT at:  http://www.AgilistaPM.com/adapting-to-change/

We will follow our case study, Acme Media, as they encounter issues and
constraints in the middle of an iteration.  We will also join them at the end of
the iteration and see how they adapt and replan based on acceptance testing,
team throughput, technical discoveries, and changes in the business environment.

We will also answer common questions about adapting in an Agile environment:

1.  Can we adapt at any time during a project?
2.  If we adapt all of the time, how do we get any work done?
3.  What is the process for adapting at the end of an iteration?

LEARNING OBJECTIVES:

* Understand the most common issues with software projects.
* Learn multiple options for dealing with each issue type.
* Using a tradeoff matrix to drive triage decisions.
* Learn how to demonstrate and drive acceptance testing at the end of an
iteration.
* Learn how to replan and prepare for the next iteration.

YOU WILL TAKE AWAY:

* Templates, Examples and Guides to use in your workplace after the workshop.

INSTRUCTOR: Greg Smith is a Senior Project Manager, ScrumMaster, and Agile coach
with ten years of experience leading project teams to a more agile process. Greg
has received numerous awards for his work in helping start-ups establish good
software practices, and for helping enterprises overcome bureaucracy and deliver
urgent projects. Greg has worked for companies including Philips Electronics,
The Seattle Times, R.R. Donnelley, Washington Mutual, and JP Morgan Chase. Greg
has been teaching Agile Project Management at Bellevue College since 2005. Greg
is also a co-author of the top rated agile adoption book, Becoming Agile in an
Imperfect World.

PDU's: 2
COST: $57

RESERVE YOUR SEAT at:  http://www.AgilistaPM.com/adapting-to-change/
.

--- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
>
> Scott,
>
> scott preece wrote:
> > I usually describe a Baseline as "a named, consistent, reviewed
> > version". That is, it's a published version with ceremony around it.
>
> That ceremony can be as simple as tagging in your VCS.

No, the "named" may be as simple as tagging; the ceremony inherently involves
people - it's the review/feedback part. The review points at the tagged version.

>
> > How much ceremony is required depends on the circumstances. If your
> > software development effort is the whole product, then you may be
> > perfectly fine relying on continuous integration and regular
> > iteration feedback. Or not, depending on how wide the stakeholder
> > community is. The point of the Baseline is just that it's published
> > (as opposed to "the current state of things"), so a wider community
> > can review it.
>
> Only if your separate your software development from the rest of the
> product development, which I would suggest is a bad idea.  All the stuff
> related to the product should be developed together and versioned together.

Well, yes - the synchronized version is the Baseline. That's the point: it's an
externalized version that is a synch point for the whole project. The schedules
and iteration rates for different aspects of the product may differ radically;
the rapid-iteration aspects, like software, will do many continuous-integration
cycles between versions of the hardware, which may well do numerous versions
between iterations of the silicon.

>
> > If your software is one component of a larger product, it's very
> > likely that you'll need to do software Baselines (specific,
> > identified versions) to coordinate with product-level Baselines.
>
> Do 'em together and tag them with one label.  Separating software as a
> "special thing" from hardware, user manuals, and whatever makes as
> much^H^H^H^H little sense as separately developing the GUI, the domain
> code, and the database.

Well, yes, the "one label" is the Baseline - it's the level of versioning that's
shared by all the pieces.

On the other hand, they ARE separate things, done by different people, using
different design tools, under different constraints. Concurrent engineering is
important - you want to have all aspects of the project working closely together
on design, constant communication about the details, and regular iterative
review (at the Baselines).

 

Wow, Jeff, that was beautiful!

Jennie... what *he* said!

Cheers!
-->>  Hillel
--
Hillel Glazer, Principal & CEO
Entinex, Inc.
Process can't fix stupid.(TM)

www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
O-

On Fri, Feb 26, 2010 at 10:18 PM, Jeff Anderson <Thomasjeffreyandersontwin@gmail.com> wrote:

Jennie

Forget about Agile for a second, your management is forcing your team
teams to do some fundamentally dysfunctional things, focus on that.

Ask your team members if they feel there is a better approach to
working, and how they can remove the biggest impediments. Push those
ideas up to management and demand an action plan. If this falls on
deaf ears than there is no point in pursuing *agile* practices, your
management isn't even equipped to listen to the people who are
responsible for building the product...

Get your team used to feeling like they can bring up new ideas to
improve and actually get permission to change things.

On 2/26/10, Hillel Glazer <agilecmmi@gmail.com> wrote:
> Gaad-zukes, Jennie!
>
> I was reading your reply to Steve and my eyes started to bleed.  In my head,
> every few sentences I was hearing that sound effect of the needle scraping
> across a record (an effect many of today's developers have NEVER heard in
> real life and in a few years anyone who recognizes it on hearing or can even
> parse the verbal description of it will be chasing grandchildren!).
>
> Anyway... I've worked with companies who have worked with Rally consultants
> and the results are pretty good.  Obviously it nearly always means the
> organization is using Rally's tool, but that's neither here nor there and
> possibly a good thing.  I didn't hear the needle-scraping thing when you
> noted this.
>
> However, on a lot of the other stuff, I was quite worried for your
> organization.  If I had to give a "field diagnosis" in the absence of other
> data or deeper analysis, I would say that there are several interacting
> attributes your organization is experiencing, irrespective of the likely
> concern that leadership/management want change but don't know effective ways
> of getting it.
>
> From what you describe and knowing nothing else, your organization exhibits
> symptoms of one that lacks:
> - clearly articulated and widely agreed-upon development work flows
> - several basic engineering (or software-engineering-specific) disciplines
> - several basic tenets of product management
> - clear articulation of testing scope, roles, and goals
> - a product evolution/promotion/release pattern that prevents wrong product
> from getting too far
> - much of any internalization of how to realize the benefits of iterative
> and incremental development.
>
> Quite basically, Steve's right, you really need some coaching.  And you're
> right, it might have to be expensive.
>
> Good luck!
>
> Cheers!
> -->>  Hillel
> --
> Hillel Glazer, Principal & CEO
> Entinex, Inc.
> Process can't fix stupid.(TM)
>
> www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
> O-
>
>
> On Fri, Feb 26, 2010 at 11:51 AM, Griner, Jennie <
> jennifer.griner@wolterskluwer.com> wrote:
>
>>
>>
>>   >Hi Jennifer,
>>
>> >Why did anyone in your organization want to "implement an agile approach"
>> in the first place?  Normally, organizations that perceive the "need" to
>> pursue agile approaches are doing so to not repeat past failures (project,
>> product, morale, etc.) and to pursue specific, tangible, qualitative or
>> quantitative benefits they're not getting/seeing with how they're doing
>> things now (or in the past).  So... what was/is your organization's
>> reason?
>>
>>
>>
>> That’s a really good question, and it’s going to take some digging for me
>> to find the actual answer to it.  Here’s the trouble, my understand is
>> that
>> our organization as a whole is looking to adopt agile, and our group is
>> not
>> the first to try these methods.  I’m not sure how to figure out who the
>> person is that decided that this was the way to go.  I have a feeling,
>> though, that they’ve decided to “go agile” because it’s the thing to do.
>>
>>
>>
>> >With these reasons articulated, you can look for "things you don't like"
>> or "things you don't want to do again", understand what causes them, then
>> find the lean/agile alternatives (if there are any).  This is where Pete
>> points out that change might need to happen.  To avoid the things you
>> don't
>> want to show up in the future, you'll be changing that which causes those
>> things going forward.  Such changes will frequently involve breaking some
>> paradigms and resetting some expectations.  If you get push-back, you know
>> it's a Quixotic effort and your call whether to keep pursuit or not.
>>
>>
>>
>> To respond to Pete, I think part of the problem is that the agile adoption
>> is coming from the top down, rather than from the bottom up.  I have a
>> feeling that things would be working better if we, as the development
>> team,
>> said we want to do things more agile.  Though then we may have the push
>> back
>> that you mention below, where the powers that be don’t understand it and
>> don’t see the benefit to it.  In our case, the powers that be have said
>> that
>> we’re doing this.  However, I think that they still don’t understand it,
>> so
>> they’ve told us that we have to do it, and we’re kind of drowning since no
>> one really had a good grasp of what we wanted to do when we started.
>>
>>
>>
>> >And it's also another potentially telling use of words... "implement an
>> agile approach".  I may be reading too much into it, but I've seen this
>> phrase used when organizations were looking for some silver bullet to
>> solve
>> various, sundry and weakly-understood but deep seated issues.  To your
>> organization, how is the phrase "do things in a more lean and agile way"
>> different from "implement an agile approach"?  If it's not different, then
>> ignore this paragraph.  On the other hand, if you immediately sense dread
>> and resistance, then you're back out there with Don Quixote.  "Do things
>> in
>> a more lean and agile way" is a much more robust pursuit and takes a lot
>> of
>> commitment, self-awareness and honest introspection.  "Implement and agile
>> approach" sounds more like Dilbert's Pointy-Haired boss telling Dilbert to
>> "do more with agile" believing it's an automatic and magic pill to skimp
>> on
>> resources and time and still product a quality product.
>>
>>
>>
>> I think that this paragraph is 100% accurate.
>>
>>
>>
>> >The most effective way towards "implement[ing] an agile approach" is to
>> adopt lean and agile principles, then get to work "leaning-out" the waste
>> in
>> your organization and development practices.  Whether you implement Scrum
>> or
>> not is not the issue.  Fully embracing Scrum is more than daily stand-ups,
>> time-boxed iterations, and having a backlog.  Though, once fully embraced,
>> Scrum is a lot like the "gateway drug" to agile.  If your system is immune
>> to the benefits of all-out Scrum, it's likely immune to anything agile or
>> lean.
>>
>>
>>
>> It feels like our team is going through the motions.  As you say, just
>> doing daily meetings, sprints, and keeping a backlog.  I don’t think most
>> people have the actual mindset required to be open to change.
>>
>>
>>
>> >OK... so...having said all this... your team may be hampered by the
>> nature of the agreements you have with your customers.  It's not that you
>> can't be lean, agile, or using Scrum with government contracts, it's just
>> that you will have to re-frame some of the typical agile/Scrum practices
>> to
>> compensate for the likely lack of a present customer, the likely a-priori
>> agreement on scope, the likely pre-determination of project "phases".
>>  Please understand, you don't have to abandon agile/Scrum practices, you
>> just need to re-orient your work so that you can still deliver expected
>> deliverables but that you produce them following the beat of your own
>> drummer, not the government's.
>>
>>
>>
>> This makes total sense.  We’re dealing with product managers that have
>> made
>> promises to our corporate clients, but I think it has the same effect as
>> if
>> it were a government (or any other) contract.
>>
>>
>>
>> >Good luck!
>>
>>
>> Cheers!
>> -->>  Hillel
>> --
>> Hillel Glazer, Principal & CEO
>> Entinex, Inc.
>> Process can't fix stupid.(TM)
>>
>> www.entinex.com | www.AgileCMMI.com | www.CMMIFAQ.info
>> O-
>>
>>  On Thu, Feb 25, 2010 at 5:54 PM, <PeteCRuth@aol.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>> Your "powers that be" may be employing the age-old management strategy of
>> appearing to be supportive by offering concessions instead of commitment.
>> Transitioning to agile methods is tough enough for many organizations
>> without having to retain unnecessary practices that end up costing far
>> more
>> time and effort than they are possible worth. Unless they understand how
>> and
>> why agile methods improve the development process, it's unlikely they'll
>> commit fully to them. Commitment without understanding is often a prelude
>> to
>> potentially terminal misunderstandings, and if this is the case, finding
>> ways to avoid getting blowback on their clothes will be high on their list
>> of priorities if things begin to fall apart.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Pete
>>
>>
>>
>> In a message dated 2/25/2010 12:47:01 P.M. Pacific Standard Time,
>> jennifer.griner@wolterskluwer.com writes:
>>
>>
>>
>> Some quick background, my group decided to implement an agile approach on
>> our last release.  Ignoring any work that was done before this decision
>> was
>> made, we had 13 month long sprints, followed by four additional months of
>> panic mode testing and bug fixing.  I had done my research on what I
>> thought
>> agile meant for us, and would try to bring up things that weren’t really
>> agile, and was ignored.  Needless to say, we basically did a waterfall
>> with
>> some mini waterfalls in the middle (if you can even consider it that
>> because
>> we hadn’t even fixed bugs as we came across them, they were all saved for
>> those last four months).
>>
>> So, the powers that be have gotten together after a retrospective of that
>> release and decided that things weren’t agile, and we’re going to actually
>> be agile this time.  However, it appears to me that they still can’t get
>> some of the older ways of doing things out of their systems.  We still
>> have
>> to have the requirements for a story fully documented (though they did
>> change the DoD to say “agreed on” rather than “signed off” and they did
>> change the item regarding Use Case and User Interface to include the words
>> “if needed.”
>>
>> Management still insists on fully detailed test cases that can then be
>> passed on to a tester on the regression team in later iterations, but we
>> can’t leave the job of writing it to the regression tester, so the test
>> member of the team must complete this prior to the end of the sprint, even
>> though we know that things could continue to change up until the end.
>> This
>> is after a test strategy must be completed along with test scenarios (high
>> level test cases) for that sprint.
>>
>> As for bug fixes, it’s hard to tell as we’re halfway into our first
>> sprint,
>> and I don’t think we’ve received a single build with the new code in it.
>> The DoD does say that the bug fixes will be made, but it did for our last
>> release as well.  The team as a whole does seem to have made a commitment
>> to
>> follow the DoD much better this time, so that is a plus.
>>
>> But how do I approach some of these issues?  I’ve asked for formal Scrum
>> training (which no one in our group has received yet, which I think it
>> part
>> of the issue), and some training has been set up, but as far as I know, I
>> am
>> not going to receive it.  I feel like I need to be heard, but at the same
>> time I need to make sure that my duty to my Scrum team (as is currently
>> defined) isn’t skipped out on either.  Am I just stuck with how someone
>> else
>> has decided things are?
>>
>> Jennifer L. Griner, MCP, MCDBA
>>
>> Quality Control Specialist, ProSystem *fx* Engagement
>>
>> CCH, a WoltersKluwer business
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

--
Sent from my mobile device

Jeff Anderson

http://agileconsulting.blogspot.com/


------------------------------------

To Post a message, send it to:   scrumdevelopment@eGroups.com

To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
   http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
   Individual Email | Traditional

<*> To change settings online go to:
   http://groups.yahoo.com/group/scrumdevelopment/join
   (Yahoo! ID required)

<*> To change settings via email:
   scrumdevelopment-digest@yahoogroups.com
   scrumdevelopment-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
   scrumdevelopment-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
   http://docs.yahoo.com/info/terms/

Scott,

You can do it high-ceremony if you want, communicating though documents.
   It certainly doesn't have to be that way, though.  I don't recommend
it; it's too easy for things to go off-track but un-noticed.  Then those
baselined documents are just used for apportioning blame.

scott preece wrote:
> On the other hand, they ARE separate things, done by different
> people, using different design tools, under different constraints.
> Concurrent engineering is important - you want to have all aspects of
> the project working closely together on design, constant
> communication about the details, and regular iterative review (at the
> Baselines).

Yes, but those people don't have to be working separately.  That
"regular iterative review" can be daily, in conversation.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

(responding to Ron)

> > If you work in such a way that you don't introduce the possibility
> > of such inconsistencies, you never need to use that mechanism.
>
> > Okay, I'm sure Ron has been saying that repeatedly, using
> > different words.  I hope the words I use are of some help.
>
> No, actually, I didn't say that as far as I know.
>
> COntinuous Integration obviates much of the need for baselining.
>
> There, how's that? :)

Well, you know what folk are like - I hear what I want to hear :-)

I'd say doing all you need to do so that you can convert a requirement
into a running tested feature shortly after you get it is the best
way to find you don't need baselines.  Continuous Integration
helps, particularly where you have several people or pairs
working on different requirements or tasks.  Gathering the
requirements in detail any distance ahead of when you will deliver
them is a good way to ensure a desire for baselines; the requirements
have time to grow stale, and various folk may start work based on
those requirements.  One could choose not to go that route. It
may require a bit of learning how.

Paul Oldfield
Capgemini

(responding to George)

> > The Baseline is a mechanism to bring together a set of things
> > such that they are consistent with each other - say so that the
> > code you are testing, and the tests you are running, both match
> > the same requirements, and the user documentation that you would
> > send along if you released this code.
>
> Isn't that what Version Control is for?

Indeed.  The baseline is a consistent set of versions, for use
where the 'latest' version of everything doesn't give one
enough consistency.  I'm not sure it's possible to have baselines
*without* a version control system (but that's an avenue of
debate I don't want to explore...).

Paul Oldfield
Capgemini

> Is there any role for traceability in scrum? How can we handle links
> in scrum?

Channeling my colleague Michael Bolton, and example would be very good.

What are you thinking of tracing? What value does tracing provide? Links
to what?

--
Don Gray (336)414-4645
http://www.donaldegray.com

Things do not change; we change.
Henry David Thoreau

Improve your changing at the AYE Conference Nov 7-11, 2010
AYE: Exploring Human Systems in Action http:\\www.AYEconference.com

Not sure where you got "documents" in what I said - I just said "review". What
you do with the customer at the end of an iteration is a review. That's what I'm
talking about - the Baseline is a point where everybody looks at the current
state of things and provides feedback.

Working together is fine, if you can do it, but for large company, complex
product projects, it's unusual. Again, the components develop on different
schedules, making it unlikely that everybody is working on the project all the
time over the life of the project. Teams will ramp up and down depending on how
long their involvement in the project is. And, of course, in most large
companies the people are likely to be in different places - silicon designers in
a facility that has fabs, hardware people in a facility with bench spaces.

regards,
scott


--- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
>
> Scott,
>
> You can do it high-ceremony if you want, communicating though documents.
>   It certainly doesn't have to be that way, though.  I don't recommend
> it; it's too easy for things to go off-track but un-noticed.  Then those
> baselined documents are just used for apportioning blame.
>
> scott preece wrote:
> > On the other hand, they ARE separate things, done by different
> > people, using different design tools, under different constraints.
> > Concurrent engineering is important - you want to have all aspects of
> > the project working closely together on design, constant
> > communication about the details, and regular iterative review (at the
> > Baselines).
>
> Yes, but those people don't have to be working separately.  That
> "regular iterative review" can be daily, in conversation.
>
>   - George
>
> --
>   ----------------------------------------------------------------------
>    * George Dinwiddie *                      http://blog.gdinwiddie.com
>    Software Development                    http://www.idiacomputing.com
>    Consultant and Coach                    http://www.agilemaryland.org
>   ----------------------------------------------------------------------
>

Scott,

I'm well aware that large companies do many things that are
counter-productive to their goals.  The point I'm making, that you're
glossing over, is that /they don't have to do it that way/.

   - George

scott preece wrote:
> Not sure where you got "documents" in what I said - I just said
> "review". What you do with the customer at the end of an iteration is
> a review. That's what I'm talking about - the Baseline is a point
> where everybody looks at the current state of things and provides
> feedback.
>
> Working together is fine, if you can do it, but for large company,
> complex product projects, it's unusual. Again, the components develop
> on different schedules, making it unlikely that everybody is working
> on the project all the time over the life of the project. Teams will
> ramp up and down depending on how long their involvement in the
> project is. And, of course, in most large companies the people are
> likely to be in different places - silicon designers in a facility
> that has fabs, hardware people in a facility with bench spaces.
>
> regards,
> scott
>
>
> --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
>> Scott,
>>
>> You can do it high-ceremony if you want, communicating though documents.
>>   It certainly doesn't have to be that way, though.  I don't recommend
>> it; it's too easy for things to go off-track but un-noticed.  Then those
>> baselined documents are just used for apportioning blame.
>>
>> scott preece wrote:
>>> On the other hand, they ARE separate things, done by different
>>> people, using different design tools, under different constraints.
>>> Concurrent engineering is important - you want to have all aspects of
>>> the project working closely together on design, constant
>>> communication about the details, and regular iterative review (at the
>>> Baselines).
>> Yes, but those people don't have to be working separately.  That
>> "regular iterative review" can be daily, in conversation.
>>
>>   - George
>>
>> --
>>   ----------------------------------------------------------------------
>>    * George Dinwiddie *                      http://blog.gdinwiddie.com
>>    Software Development                    http://www.idiacomputing.com
>>    Consultant and Coach                    http://www.agilemaryland.org
>>   ----------------------------------------------------------------------
>>
>
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...! Groups Links
>
>
>
>

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

Hi Drskkk,

Scrum doesn't get into what to work on or how to do it -- it defers decisions on
that to the product owner (for the what) and the team (for the how).

If you need traceability, your product owner should require that as a project
constraint and let the team choose how to obtain it. One possibility would be to
add some steps and checks into the development process -- just as you would do
with any other project management framework. There might be others.

If your question is whether Scrum is compatible with traceability, the answer is
yes: a team I worked for used Scrum (or at least some sort of scrum-but) in a
PCI-DSS compliant company. PCI-DSS requires traceability of code changes to
requirements and to individual programmers and reviewers, which I guess is what
you're asking about.

--
Salut,

Jordi Salvat i Alabart
CSP


--- In scrumdevelopment@yahoogroups.com, "dsrkkk" <dsrkkk@...> wrote:
>
> Hello,
> Is there any role for traceability in scrum? How can we handle links in
> scrum?
> dsr
>

Yes, thanx for the clarification Ron.

Acceptance Criteria should probably be part of a team's definition of "Done" -
so the items "done" earlier in the sprint should already be known to be
"acceptable".  The later items will be known to be acceptable closer to the end,
but are sometimes rushed with a potential lapse in rigour that I would call
"get-there-itis" (to borrow the term from the airline industry).

So yes, the confidence level should be high already prior to any dress-rehearsal
demo, which itself should be limited to reassurance.  When you have the "whole
company" showing up for a review the next morning, a manual demo test can
increase confidence for the team, especially the person actually doing the demo.
Or perhaps its just me: I would never walk into a meeting with the CEO present
to present/demo something without having done some manual "testing".

Aside: Thank-you Ron for all you have given via XP!

-johnny


--- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
>
> Hello, john_hermann.  On Monday, February 22, 2010, at 10:16:20
> PM, you wrote:
>
> > One team I worked with would do a manual dress-rehearsal demo the
> > evening before the Review meeting (the following morning).  This
> > preparative "testing" gave them a confidence level for what
> > stories would likely be accepted by the PO, and indeed what
> > stories to demo at all, since you should probably not demo stuff you know is
not "acceptable".
>
> Yes ... however the team should know, long before the demo, whether
> what they have done is acceptable.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> Inigo Montoya: You are wonderful!
> Man in Black: Thank you. I have worked hard to become so.
>

Yes, baselining seems to be fairly non-agile, and rooted in traditional PM.  It
exists mostly for logistics (vs. development) projects, where a lot can be known
up-front, and hence there is little "excuse" to deviate from plan.  When you do
deviate, management wants to see the deltas of "actuals" from plan/"baseline",
to see what went "wrong", to create indexes, to make predictions, etc.  Such
deltas are checked frequently to make sure that the output is not going off
track, or out of budget, or off schedule.

In Scrum, such a delta comparison occurs when comparing velocity sprint to
sprint, and making predictions about what can be accomplished in the next sprint
based on the previous one(s).  Since sprints are short, the "check" occurs
frequently enough, and since sprints are ideally "atomic" in scope, no
deviations from "baseline" should occur intra-sprint. (There are always
exceptions.)  So I agree with whoever it was who said earlier that Scrum already
takes care of the needs of baselining.

Also, as has been mentioned elsewhere, a performing team will eventually
stabilize into a fairly regular velocity.  Perhaps story points can even be
eliminated, thus counting only the number of stories themselves.  If the team
changes, or has not stabilized, then the "baselining" of Scrum helps keep things
organized.

-johnny


--- In scrumdevelopment@yahoogroups.com, Monde Hans <monde.hans@...> wrote:
>
> Baselining to done for Control and Configuration management.
> Like tracking all the variances from the plan and Change Management.
> Agile does not have this.
>
> M.
>
> On Tue, Feb 23, 2010 at 2:53 PM, <sharmila.patwardhan@...> wrote:
>
> >
> >
> > I some how disagree that baselining does not welcome changes........
> > Baselining is only about knowing what needs to be done and in case of
> > changes which all places it would impact
> >
> >
> >
> > Best regards,
> >
> > *Sharmila Patwardhan*, Sr. Q&P Consultant
> > *Tieto*
> >
> >
> >  ------------------------------
> > *From:* scrumdevelopment@yahoogroups.com [mailto:
> > scrumdevelopment@yahoogroups.com] *On Behalf Of *Ron Jeffries
> > *Sent:* Tuesday, February 23, 2010 17:48
> >
> > *To:* scrumdevelopment@yahoogroups.com
> > *Subject:* Re: [scrumdevelopment] Re: Baselining and Scrum
> >
> >
> >
> > Hello, sharmila. On Monday, February 22, 2010, at 10:35:10 PM,
> >
> > you wrote:
> >
> > > Another thing about baselining was if the stories have a scope
> > > change as per the baseline, in a time and material kind of
> > > contract the customer has to agree to pay the additional cost or
> > > bare the consequences of the change.
> >
> > Baselining assumes that change is bad. Agile assumes that change is
> > good.
> >
> > Ron Jeffries
> > www.XProgramming.com
> > www.xprogramming.com/blog
> > The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
> >
> >
> >
>
>
>
> --
> I keep six honest serving-men (They taught me all I knew); Their names are
> What and Why and When And How and Where and Who.
>

(responding to dsr)

> Is there any role for traceability in scrum? How can we handle
> links in scrum?

There are about 14 distinct reasons to have traceability, if you
count them all up.  Almost all of these are irrelevant if you are
working in an agile fashion, and most or all of the rest are covered
by having a set of regression tests at 'green' (or not, as the case
may be).

Paul Oldfield
Capgemini