Loading ...
Sorry, an error occurred while loading the content.

Re: Spurring the adoption of unit testing (Re: [scrumdevelopment] Re: Is Scrum a block to Agile?)

Expand Messages
  • mike.dwyer1@comcast.net
    Hmm; Some thoughts: does the developer environment reflect the production systems? (my guess is not) Does the testing occur on a sample set of machines that
    Message 1 of 51 , Aug 2, 2005
      Some thoughts:  does the developer environment reflect the production systems?  (my guess is not)
      Does the testing occur on a sample set of machines that reflect the probable range of versions in production?  (my guess not).
      So you are probably building fixes that inadvertantly take advantage of patches to older configuration versions.  Suggest that you include a list of compatible / minimum version levels for all software the code uses or exchanges information with.
      While not agile it is good release mgt.
      Mike Dwyer

      "I Keep six faithful serving-men
      Who serve me well and true:
      Their names are What and Where and When
      And How and Why and Who." - Kipling
      -------------- Original message --------------

      > Keith Lancaster wrote:
      > >
      > > You have probably looked into this, but many times the
      > > problem is that it actually IS working on one machine
      > > and not the other. Do you have machine configurations
      > > under control, i.e., have standard configurations that
      > > the developers use? Is everyone using CM (source code
      > > control) of some sort, and are they using it
      > > correctly?
      > Good points, no our machine configurations aren't under CM but
      > everything to build each project is.
      > The developer configuration is standard, we do use a proprietary app
      > server but configuration of that is straight forward. Where we get into
      > trouble is generally our db upgrade paths as most of the time developers
      > don't run through those scenarios.
      > > There are many factors that could lead to
      > > this kind of situation. A good defect management
      > > system will allow you to track "bounces" - how many
      > > times a defect goes back and forth between dev and QA.
      > > Patterns tend to emerge, sometimes pointing to a
      > > developer, sometimes the QA person, sometimes the dev
      > > and test environment, and sometimes the requirements
      > > (being unclear, ambiguous, etc.).
      > >
      > Interesting. I'll take a look to see if we can get that information.
      > > Your manager does not appear to use the stick...does
      > > he/she use the carrot? Does the team get rewarded for
      > > shipping on time with few defects? Are there any
      > > positive incentives to do better work? Are deadlines
      > > realistic and are people held to them? If your
      > > developer has to work evenings and weekends alone to
      > > get his work done while everyone else is at home, he
      > > may eventually start looking for ways to become more
      > > efficient. If there is NO positive or negative
      > > consequence to doing better work and there is no sense
      > > of ownership / pride in the team, you have few
      > > options. The bottom line in all of this is the
      > > attitude of the developers - something that unit
      > > testing and process alone cannot fix. As for your
      > > problem guy, I've had developers on my team that were
      > > exactly like him that we ultimately had to re-assign
      > > or let go. Sometimes there is no alternative, sadly.
      > >
      > I think this very close to the mark. When I think about it, there
      > really is very little positive or negative reinforcement here. That is
      > something I'll need to bring up in concert with discussing what my boss
      > wants to achieve from moving to a more agile process.
      > Thanks!
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      > <*> To visit your group on the web, go to:
      > http://groups.yahoo.com/group/scrumdevelopment/
      > <*> 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/
    • Deb
      I ve been away from this list for a while, I hope the following is not redundant: ... Some reflections: (not particularly in relation to your note, Bob) I
      Message 51 of 51 , Nov 23 10:07 AM
        I've been away from this list for a while, I hope the following is
        not redundant:

        Bob: your comment hits home:
        > It requires someone with the vision
        > and a mastery of the corporate culture and politics to get
        > something like Scrum going strong. To bring others in at their
        > own pace without starting a holy war. And it's a full time
        > job.

        Some reflections: (not particularly in relation to your note, Bob)

        I think we need to stop expecting that every ScrumMaster has this
        skillset, or even the personality to develop it. Just as we
        encourage our own team members to leverage one anothers' strengths,
        we SMs should identify and support those who "do enterprise change"
        well, and let them lean on the rest of us to help make their
        initiatives work.

        I find I'm very happy doing the SM gruntwork, helping a change
        leader with my observations, intuitions and supporting work. I'm not
        at the place where I want to (or should) lead the effort. I feel
        that getting clear on my place in this is an important step toward
        contributing effectively on the enterprise scrum team. There are a
        number of different, important roles to be played by SMs with
        different personalities within such an effort.

        So I'm wondering: How can we help each other identify our own best
        niches, and foster better teamwork among SMs? (Cat herders seem to
        make very bad cats :-)

        We can't learn this from the outside - we need to get our feet wet,
        and "inspect-and-adapt" as we go. That means we'll continue to make
        mistakes and recover from them. But I think that opening up such a
        dialogue among us could help us learn and recover faster and teach
        one another better. I know that the Gathering wants to address this
        need to some extent - but once or twice yearly seems a long interval
        for our inspect-and-adapt cycles, to me.

        Once again, I'm musing in public. Well, perhaps someone else is
        doing the same and we'll find some kind of synergy here :-)


        --- In scrumdevelopment@yahoogroups.com, "bobschatz" <bschatz@s...>
        > Being one of the folks that replied privately to Tobias, I'll put
        > thoughts out there.
        > Change is incredibly hard. There's no doubt about that. Scrum has
        > way of unearthing all of the ugly things that have worked their
        > into the development AND business processes of building software.
        > There are people and organizations that can adopt change faster
        > because they are either in enough pain, or they all know that
        > traditional ways just won't work. I discussed this with Ken
        > over two years ago when I urged him to prioritize his own backlog.
        > Some organizations with "play" with agile until they are convinced
        > in their own time that it will work for them.
        > Others will never do it.
        > One of my fears three years ago was that we'd have a bunch of
        > running around trying to make a living off of Scrum. Jumping into
        > organizations, holding classroom sessions with process manuals,
        > moving on. I live with Scrum every day in building products and my
        > company depends on it's success for survival. I spend everyday
        > observing and thinking of how it could be better the next day.
        > Sprint after Sprint; year after year. I've been in daily Scrum
        > meetings everyday for over 3 years. It's a challenge of a career.
        > don't think of the adoption as a start and an end. It's more like
        > journey that you don't really see ending. You just focus on what
        > at hand and deal with the success, failure, issues, changes, etc.
        > that you must face each day.
        > When I speak at conferences I talk about success factors that no
        > consultant can deliver to an organization. Successful change
        > requires outstanding leadership. It requires someone with the
        > and a mastery of the corporate culture and politics to get
        > like Scrum going strong. To bring others in at their own pace
        > without starting a holy war. And it's a full time job.
        > Because we are in a business where everything is expected at light-
        > speed we think that our new techniques should be embraced by all
        > because they're just that obvious.
        > The truth is that the adoption rate will follow the same patterns
        > other initiatives have. Some fast and successful, others slow or
        > failures. The important thing is to learn something along the way,
        > and focus on ways to add value to making the organization better
        > small steps. The good news is that every success in projects using
        > these techniques can, and will, help remove barriers for others.
        > will also serve as a reinforcement for those who created the
        > success. At Primavera, I made sure we invited other companies into
        > our environment to see how we were using Scrum. That gave my team
        > boost in confidence, and the visitors now had a vision of what it
        > would look like in their organization. Were we
        > not. Scrum is not about perfection, it's about doing something of
        > value, getting feedback, learning, and trying it again. I've had
        > many discussions with other executives in my position and helped
        > them understand their role in being a strong leader of change. We
        > all need to learn how to manage expectations. Not only of others,
        > but our own as well. Agile adoption is going in the right
        > and those of us that "get it" need to be available to coach and
        > others that want to join us in the journey.
        > I typically close my presentations with this advice:
        > Be Patient, Positive, PersistentÂ…Don't give up!
        > Bob Schatz
        > Solstice Software, Inc.
        > Chief Development Officer
        > bschatz@s...
        > bobschatz@y...
        > --- In scrumdevelopment@yahoogroups.com, Tobias Mayer
        > <tobyanon@y...> wrote:
        > >
        > > Scrum is touted as "can be implemented in a couple of days at
        > organization" (or words to that effect. While this is true, what
        > does it actually mean in practice?
        > >
        > > My recent experience with Scrum being introduced in a top-down
        > within a large organization has shown that "doing Scrum" takes
        > priority over good practices. After six months of doing Scrum,
        > almost no difference is perceived in the underlying engineering
        > practices at this particular organization. The promises from
        > consultants that "the teams will change their practices after two
        > three sprints" has not been fulfilled. There are many reasons for
        > this, most, if not all, have a cultural and/or political basis.
        > >
        > > I am thinking of one team in particular, who for months were
        > suffering from vague requirements, inability to estimate, lack of
        > decent upfront testing - certainly no unit testing, lack of good
        > design and a well-componentized code base (and little training to
        > teach them other ways of doing things), over commitment, burn-out,
        > and on and on... Stuff got released, but then it always did,
        > Scrum. The quality did not noticeably improve. The team appeared
        > exhausted. While these concerns were all aired - repeatedly - it
        > was only when the team finally announced "we don't think we want
        > do Scrum anymore" that action was finally taken. The exec team
        > into "firefight" mode to solve the problem - or, as I see it, to
        > a good face on it again.
        > >
        > > When the act of "doing Scrum" becomes more important than the
        > quality of the product being produced, or the level of
        > of the workers, then "doing Scrum" becomes an empty, meaningless
        > piece of market-speak. The danger of making Scrum so easy to
        > implement - and encouraging organizations to do this is that it
        > become a sham. People on both the inside and the outside of such
        > Scrum projects will quickly recognize this for what it is. Scrum,
        > of course, will be blamed for being ineffective. Yet another
        > scapegoat will have been identified.
        > >
        > > Scrum has not been altogether unsuccessful at this
        > Where the current process was so broken that nothing was being
        > produced at all Scrum has helped teams to begin delivering. Many
        > people on the Scrum pilot teams are enjoying the experience of
        > better communication, and a sense of empowerment. This is all
        > good. But the bottom line is, that the essential practices of
        > creating good software - great software - are not being introduced.
        > >
        > > Does anyone else have similar experiences with Scrum in a large
        > enterprise (the problems I mention may not be confined to large
        > enterprises, but it is likely they are)? What might some
        > be? If you are at Agile2005 this week, find me and let's chat.
        > >
        > > Tobias
        > >
      Your message has been successfully submitted and would be delivered to recipients shortly.