Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

scrumdevelopment · Scrum Users

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 7475
  • Category: Development
  • Founded: Feb 1, 2000
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
Messages 45494 - 45523 of 56894   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#45494 From: "woynam" <woyna@...>
Date: Fri Feb 26, 2010 3:24 pm
Subject: Re: UML and Scrum
woynam
Send Email Send Email
 
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
> >
> >
> >
> >
>

#45495 From: "Steve Ropa" <theropas@...>
Date: Fri Feb 26, 2010 3:42 pm
Subject: Re: UML and Scrum
steveropa
Send Email Send Email
 
That's why I always liked Booch better.  My handwriting is so bad my boxes end up looking like clouds anyway!

Sent: Friday, February 26, 2010 7:39 AM
Subject: Re: [scrumdevelopment] UML and Scrum

 

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@gmail.com>:
> 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@yahoo.com> 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@eGroups.com
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@eGroups.comYahoo! Groups Links
>
>
>
>


#45496 From: "Griner, Jennie" <jennifer.griner@...>
Date: Fri Feb 26, 2010 3:58 pm
Subject: RE: How do I help my team be more agile?
daisy99_
Send Email Send Email
 

>HI Jennie,

 

>There are a few things that come to my mind here.  One is that you very well might want to bring in some outside help in the way of a consultant, but I won't go down that path.

 

I believe that this is actually the plan, so hopefully this will help.  Maybe if someone else that they’re paying a ton of money says these things, then they’ll believe them and maybe try to implement it.  We’re shooting to have them come in and help us through our second sprint.  They’ll be working with two of our sprint teams and then those teams will help pass on the new insights to the rest of the team.  I believe we’re getting someone from Rally to come in.  Does anyone have any experience with their consulting work?

 

>This feels like a classic case of "we want to be agile but not change how we do things".  That is very hard to overcome, but here are a few thoughts.  These thoughts are based only on what you have stated here, so I reserve the right to be totally wrong!

 

>1.  I get the feeling that your stories are very large.  The fact that the stories have requirements enough to need to be fully documents, or to be able to compare them to Use Cases, makes me think the stories are large.  See if you can't go through an exercise in slicing them into much smaller segments.

 

During the pre planning (at least for the team that I’m on), the designer took some time to come up with a draft of the requirements.  Each detailed requirement became a story.  For example, “I want to access a pane” is one of our stories.  To me that seems small enough, but what’s happening is that that team is taking on four stories this sprint, and then really kind of working on them in as one entity (or two, since there are really two pairs of stories that go together).  So then the requirements document is fleshed out further with the work that we’re doing within the sprint.

 

>2.  On the subject of size, I would also suggest decreasing the length of your iterations dramatically.  Many of us have found 1-2 weeks to be the best sizes of iterations.  In the case of teams that are struggling, the amount of thought that goes into fitting these smaller iterations is extraordinarily valuable.  A case like what you describe leads me to suggest one week iterations.

 

Looking back at the project plan, our sprint is supposed to only be 13 days long, and ending today, which is definitely not going to happen.  Maybe they combined sprint 1 and 2, which would make it 27 days long rather than the 13 and 14 originally planned, which may have worked better.  I think I read in an email yesterday about the critical thinking working much better in shorter sprints, since you don’t have time to waste, you make the most of your time.  I think that this is a great idea, and I’ll see if I can pass any of that information on.  Of course, now I have to dig into the whole sprint was supposed to end today, but there’s been no communication regarding changes to that.  Hrm…

 

>3.  Lastly, I would like to hear more about the regression team and the test cases that are passed on to them.  Is there a way we can automate the acceptance and unit tests, thus removing most of the need for a "regression phase"?

 

Our testing team has been split into two mini-teams: Enhancement Testers and Regression Testers.  The enhancement testers will be members of the scrum team and responsible for testing the enhancements.  The regression testers will “sprint” alongside the enhancement testers, but they’ll test the areas of the product not undergoing any changes.

 

We continually try automation, but we seem to have troubles actually getting it to really work for us.  We’ve been able to automate the testing of the portions of our product that don’t change much, so that the regression testing can be performed much quicker than by a manual tester, but those tests still come after the fact.  We had white-box testers with our last release, and I thought we were supposed to have them with this release, but I haven’t heard anything about that team.  Also, going along with my original comments, of bugs not being fixed, the bugs that the white-box testers wrote up weren’t being fixed any sooner than the bugs found by the manual testers, which most likely ended up with a duplication of bugs.  One bug would be written up twice, once from the code side, and once from the UI side.  I’m not sure what the developer does as far as unit testing, so I don’t know how much may be automated.  Are there any good resources for automating the acceptance testing?  I think part of the issue is that we’re having a hard time seeing how to automate something that isn’t stable.  Most likely it’s a case of the tools that we’re using.  They take so much work to code the tests, that we can’t waste time when things are changing.

 

>Regards,

>Steve

 

Thanks for your feedback Steve.  I’m really excited about how I see agile working, and would love to really feel like we were actually moving towards it.  My fear is that we’re going to continue to have waterfalls in each sprint, but I’m trying to be hopeful.

 

At one point in our last release, I actually got called into a conference room and told that I needed to quit asking to be invited to meeting that I wasn’t supposed to be in.  The meeting in particular was a meeting where the development team was discussing how they were going to implement the infrastructure of our new product.  In the end, the infrastructure wasn’t implemented the way we were told it would be, so we found a lot of issues late in the game.  We thought it was going to work one way, as that’s how it was supposed to work on paper, but when they discussed it, they ended up choosing a different way.  The original way didn’t leave a huge risk in a certain area, but the actual implementation did.  We didn’t know, so we hadn’t tested it as in depth as we would have, had we known how they had done it.  But I was in trouble for wanting to be in the meetings where they were discussing it.

 

 

Sent: Thursday, February 25, 2010 1:45 PM

Subject: [scrumdevelopment] How do I help my team be more agile?

 

 

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


#45497 From: "Steve Ropa" <theropas@...>
Date: Fri Feb 26, 2010 3:47 pm
Subject: Re: UML and Scrum
steveropa
Send Email Send Email
 
One case for some of the tools is to reverse engineer the existing object model.  Ideally, it would be small enough and clear enough as not to be necessary, but for older systems it can be very helpful.  I am a visual/spatial thinker and have had many occasions where reverse engineering an existing code base has quickly helped my find seams to start teasing apart for refactoring purposes.  It has also uncovered some rather intricate "smells".
 
I wouldn't necessarily maintain a repository of diagrams or anything, but I might from time to time run the system through a tool to see what the current state of affairs is.  Of course, over time this should become less and less necessary as the code starts to become more coherent.

Sent: Friday, February 26, 2010 7:32 AM
Subject: Re: [scrumdevelopment] UML and Scrum

 

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@yahoo.com> 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/


#45498 From: "scott preece" <sepreece@...>
Date: Fri Feb 26, 2010 4:23 pm
Subject: Re: Baselining and Scrum
sepreece
Send Email Send Email
 
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
>   ----------------------------------------------------------------------
>

#45499 From: "Griner, Jennie" <jennifer.griner@...>
Date: Fri Feb 26, 2010 4:57 pm
Subject: RE: How do I help my team be more agile?
daisy99_
Send Email Send Email
 

This sounds like a FANTASTIC idea.  I’ll see what I can do.

 

Jennifer L. Griner, MCP, MCDBA

Quality Control Specialist, ProSystem fx Engagement

CCH, a WoltersKluwer business

 

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Archer, Jonathan
Sent: Thursday, February 25, 2010 5:17 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] How do I help my team be more agile?

 

 

Something I have seen be quite valuable in my own organization is the “lunch and learn” – we find a good video about a pertinent topic (release planning, sprint planning, testing, estimating) and watch it together, over lunch and then discuss 

What I read below sounds like an “understanding” / “education” problem and the watch & discuss approach is a nice subtle way to get people thinking about new ideas. You can go from those conversations to “shall we give that a try in the next sprint?” quite easily…

 Jon


From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Griner, Jennie
Sent: Thursday, February 25, 2010 1:45 PM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] How do I help my team be more agile?

 

 

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


#45500 From: "mikael.brodd" <mikael.brodd@...>
Date: Fri Feb 26, 2010 4:48 pm
Subject: Re: UML and Scrum
mikael.brodd
Send Email Send Email
 
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
>

#45501 From: "Griner, Jennie" <jennifer.griner@...>
Date: Fri Feb 26, 2010 4:51 pm
Subject: RE: How do I help my team be more agile?
daisy99_
Send Email Send Email
 

>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

 

 


#45502 From: "woynam" <woyna@...>
Date: Fri Feb 26, 2010 5:52 pm
Subject: Re: UML and Scrum
woynam
Send Email Send Email
 
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
> >
>

#45503 From: George Dinwiddie <lists@...>
Date: Fri Feb 26, 2010 7:05 pm
Subject: Re: Re: UML and Scrum
gdinwiddie
Send Email Send Email
 
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
   ----------------------------------------------------------------------

#45504 From: Hillel Glazer <agilecmmi@...>
Date: Fri Feb 26, 2010 8:21 pm
Subject: Re: How do I help my team be more agile?
hillelglazer
Send Email Send Email
 
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

 

 





#45505 From: George Dinwiddie <lists@...>
Date: Fri Feb 26, 2010 10:11 pm
Subject: Re: Re: Baselining and Scrum
gdinwiddie
Send Email Send Email
 
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
   ----------------------------------------------------------------------

#45506 From: "JackM" <jack@...>
Date: Sat Feb 27, 2010 2:46 am
Subject: Re: How do I help my team be more agile?
jmilunsky
Send Email Send Email
 
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
>

#45507 From: "JackM" <jack@...>
Date: Sat Feb 27, 2010 3:07 am
Subject: Re: Manual testing
jmilunsky
Send Email Send Email
 
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?
>

#45508 From: Jeff Anderson <Thomasjeffreyandersontwin@...>
Date: Sat Feb 27, 2010 3:18 am
Subject: Re: How do I help my team be more agile?
thomasjeffre...
Send Email Send Email
 
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/

#45509 From: Hillel Glazer <agilecmmi@...>
Date: Sat Feb 27, 2010 5:01 am
Subject: Re: How do I help my team be more agile?
hillelglazer
Send Email Send Email
 
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@...> 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@...> 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/


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

To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! 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/



#45510 From: "donnaareed" <donna@...>
Date: Sat Feb 27, 2010 4:55 am
Subject: VIRTUAL WORKSHOP - Adapting to Change Throughout an Agile Project (3/12)
donnaareed
Send Email Send Email
 
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/
.

#45511 From: "scott preece" <sepreece@...>
Date: Sat Feb 27, 2010 4:13 pm
Subject: Re: Baselining and Scrum
sepreece
Send Email Send Email
 
--- 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).

#45512 From: Thomasjeffreyandersontwin@...
Date: Sat Feb 27, 2010 4:20 pm
Subject: Re: How do I help my team be more agile?
thomasjeffre...
Send Email Send Email
 

Hillel

Thx! :)
Jeff Anderson


On Feb 27, 2010, at 12:01 AM, Hillel Glazer <agilecmmi@...> wrote:

 

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/



#45513 From: George Dinwiddie <lists@...>
Date: Sat Feb 27, 2010 4:35 pm
Subject: Re: Re: Baselining and Scrum
gdinwiddie
Send Email Send Email
 
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
   ----------------------------------------------------------------------

#45514 From: "pauloldfield1" <PaulOldfield1@...>
Date: Sun Feb 28, 2010 7:36 am
Subject: Re: Baselining and Scrum
pauloldfield1
Send Email Send Email
 
(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

#45515 From: "pauloldfield1" <PaulOldfield1@...>
Date: Sun Feb 28, 2010 7:40 am
Subject: Re: Baselining and Scrum
pauloldfield1
Send Email Send Email
 
(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

#45516 From: "dsrkkk" <dsrkkk@...>
Date: Sun Feb 28, 2010 12:38 pm
Subject: Scrum and Traceability
dsrkkk
Send Email Send Email
 
Hello,

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

dsr

#45517 From: Don Gray <don@...>
Date: Sun Feb 28, 2010 3:45 pm
Subject: Re: Scrum and Traceability
systemssmith
Send Email Send Email
 
> 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

#45518 From: "scott preece" <sepreece@...>
Date: Sun Feb 28, 2010 3:42 pm
Subject: Re: Baselining and Scrum
sepreece
Send Email Send Email
 
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
>   ----------------------------------------------------------------------
>

#45519 From: George Dinwiddie <lists@...>
Date: Sun Feb 28, 2010 5:26 pm
Subject: Re: Re: Baselining and Scrum
gdinwiddie
Send Email Send Email
 
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
   ----------------------------------------------------------------------

#45520 From: "jsalvatialabart" <jordi.salvat.i.alabart@...>
Date: Sun Feb 28, 2010 10:40 pm
Subject: Re: Scrum and Traceability
jsalvatialabart
Send Email Send Email
 
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
>

#45521 From: "john_hermann" <john_hermann@...>
Date: Mon Mar 1, 2010 12:10 am
Subject: Re: Manual testing
john_hermann
Send Email Send Email
 
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.
>

#45522 From: "john_hermann" <john_hermann@...>
Date: Mon Mar 1, 2010 1:25 am
Subject: Re: Baselining and Scrum
john_hermann
Send Email Send Email
 
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.
>

#45523 From: "pauloldfield1" <PaulOldfield1@...>
Date: Mon Mar 1, 2010 7:57 am
Subject: Re: Scrum and Traceability
pauloldfield1
Send Email Send Email
 
(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

Messages 45494 - 45523 of 56894   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help