Re: [scrumdevelopment] My trivial experience of scrum
While informative and likely accurate this discussion is digressing from practical recommendations for ablmf.
ablmf, suggest you discuss with your boss what his/her expectations are in changing from "chaos" to a "formal" development process. Consider him/her as you would a client. Hopefully, once these have been articulated (e.g. predictability) you can have a pragmatic discussion of "waterfall" vs. "scrum" on the merits.
While not an ideal solution, it is possible to craft a process that blends aspects of waterfall and scrum that would at least create some momemtum for continuing acceptance.
If the boss responds that he/she is more "comfortable" with "formal" then suggest you comply and/or look for scrum opportunities elsewhere.
--- On Wed, 8/19/09, Adam Sroka <adam.sroka@...> wrote:
From: Adam Sroka <adam.sroka@...>
Subject: Re: [scrumdevelopment] My trivial experience of scrum
Date: Wednesday, August 19, 2009, 12:26 PM
I agree. Except, in my experience this kind of organizational change
is futile to attempt without high-level buy-in from the management. If
ablmf's boss is not willing to accept the changes and/or attaches a
lot of conditions ("We can't do practice A right now, because...")
Then the change won't happen, won't be complete, or won't be
Dealing with organizations that are resistant to change is a lot like
dealing with addicts. There is a lot that can be done to help them to
be successful, but first they need to admit that they need help and
ask for it.
On Wed, Aug 19, 2009 at 4:06 AM, victor
oliveira<victor.oliveira@ concretesolution s.com.br> wrote:
> One problem I see from your experience is that your company needs a cultural
> change for this to work.
> This takes time, and imposing the process is not only against agile culture
> itself, it is a formula for failure.
> You need to start a cultural change. You need to create awareness on what
> are the problems and what people in the community are saying about these
> problems. Buy books and make them available. Call experienced people to
> At the same time, talk to your boss. Explain to him that to change the
> process for the whole company it will take time and a true cultural change.
> Ask him for a pilot on the "new method".
> Try to find an important piece of backlog, get a small team that wants to
> try it and learn it. Get some hungry people onboard.
> While continuing with the cultural change, work on your project and make
> your results visible to everyone.
> After a bunch of sprints, it will be hard for the organization to resist the
> next changes.
> Best Regards,
> Victor Hugo de Oliveira
> Scrum & Agile Blog
> http://csvo. wordpress. com
> Concrete Solutions
> new edition: http://www.concrete solutions. com.br/index_ eng/
> On Wed, Aug 19, 2009 at 2:41 AM, <ablmf@yahoo. com.cn> wrote:
>> I asked some questions in this group and I got some very helpful
>> suggestions. Here is my trivial and painful experience of scrum. Hope it
>> will help you to avoid these mistakes I made.
>> Last year, my boss, other 9 people, and I left our last company and joined
>> this company. We are supposed to build a similar product that we had built.
>> Our new company is big, but not mature. It has no regular software
>> development process and we have to create one for our team.
>> In the last company we worked, these things are clearly defined. We had to
>> use a strict V-model which is forced by filling many forms ad by a separated
>> QA department. When we worked on a project, we just tightly followed our
>> process manual.
>> But I never like that process. We never finished the plan on time, we
>> wrote too many useless documents, we cheated when we filled these audition
>> So, last year when we began, I thought maybe we should use something more
>> efficient as we don't have enough human power. ( I led a *small* team in the
>> last company, it had 15 people).
>> I suggested to use scrum. But,as you can expect, I failed.
>> Here is some problems I met :
>> 1. Backlog is not considered as a formal requirement.
>> For my colleagues, requirement should be a "specification" which clearly
>> defined the features of our product after 6 months, and could be given to
>> sales man as a market.
>> So although I translated the "specification" into a backlog, my boss only
>> read it once and continued to ask for "newer" specification.
>> He thought the format of backlog is too informal, features(backlog) items
>> are not grouped by logic so he could not see clearly what the product could
>> 2. No long term plan (predict)
>> Scrum doesn't have the concept of long term plan and my boss felt it was
>> hard to believe we can not tell him what features after 6 months or 1 year.
>> 3. No detailed plan for everyone
>> My colleagues are used to be told "you have to do xxx in 4 days and if you
>> could not finish you work overtime", so they feel really uncomfortable when
>> there isn't a form predict what he should next Thursday afternoon.
>> 4. Daily stand up meeting
>> Many feel it's very annoying to have a meeting everyday, even if it only
>> took 10 minutes, and it is also useless to know what other people had done
>> "My module do not use database, why should I know that someone else
>> changed db?"
>> "I just started working but this damn meeting stopped me!"
>> 5. No concept of a "project"
>> "Requirement Analysis -> Design -> Coding -> UT -> IT -> ST". We are used
>> to this model of software development, and we are used to plan how long each
>> phase will take.
>> Clearly, this style of plan do not fit scrum's plan sytle.
>> And each phase should output a formally accepted document before next
>> phase start. Which is also not compatible with scrum's concept of "done".
>> My boss feel that no project means no management.
>> 6. Pair programming
>> "Don't you have something more important to do? I can do it myself!" When
>> I suggest pair with my colleagues, most of the time they would say that.
>> 7. TDD
>> Most our code is written in C with glib, I tried to TDD, but it's really
>> hard. Need to write too many code of mock object.
>> I just succeed to use it in the python part of the system.
>> I tried to apply scrum to our development process for 2 sprint then I gave
>> On the plan meeting of the 3 sprint, one of my colleague intensively
>> opposed continuing scrum.
>> He took some backlog items and told me he could finish this in one week
>> without any help if I stop waste his time.
>> After a year, I think now I could see the whole thing calmly. I made
>> several mistake:
>> 1. Although we are a new team, but most of us are highly trained with a
>> high ceremony process.
>> I had no chance to apply an agile process at once.
>> If I really want to succeed, I should start with more tiny steps.
>> 2. I should find problems and suggest to resolve them with new method, I
>> should not force something just because I think it's good.
>> 3. I didn't see from on my colleagues' side. Actually, I now can see that
>> they had strong reason when the oppose.
>> To be honest, after a year, the team is in chaos. We are not using scrum,
>> but we do not have any formal process also. We just *decide* what features
>> will be include in next version and we assign the task to one of us. God
>> knows if he / she could finish it on time and if he / she working or just
>> surfing internet. I was frustrated , I used most of my time coding and I
>> didn't consider management or process anymore.
>> But now my boss could not bear the chaos anymore, and I am asked to build
>> a formal development process.
>> Don't know what to do.