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

123Re: book, "Agile Software Development with Scrum"

Expand Messages
  • jonas.b@home.se
    Nov 26, 2001
      Thanks for you answer!

      > Jonas,
      > <Are there any plans of more Scrum books? Aren't books very
      > important in order to facilitating making Scrum more popular?
      > (compare with XP where they have many books from different
      > viewpoints)>
      > I've cc'ed this to other Scrum practioners who may plan to be or
      > be writing books. As I said, my next book if regarding value driven
      > project/product management using Scrum.


      > <Does Scrum address the issue of burn outs and negative stress?
      > (E.g. in RAD different persons are responsible for different phases
      > in order to prevent too much negative stress)
      > Is it perhaps "enough" with empowering the team to make the
      > commitment (so that they take on as much work as they can handle)
      > and to control the chaos? Or is it perhaps ut to the ScrumMaster to
      > prevent burn outs from happening?>
      > I've never seen a Scrum team burnout. Sprints are only thirty days,
      > and the team is doing what it commits to, with complete flexibility
      > to adjust the functionality to deliver business value (Sprint
      > However, sometimes the team gets into team heroics, wanting to blow
      > someone's socks off, or really makes an extraordinary effort to
      > prepare a product for a show, or a specific customer. In these
      > cases, I've recognized their efforts by giving them several days
      > (a five day weekend?) and a gift certificate that they can use to
      > take their families to dinner (after all, the family was without
      > the team member). I feel justified doing so because the team has
      > contributed extraordinarily.

      Hopefully do all ScrumMasters act that way.

      > <Is most of requirements enginnering issues unnecessary? The
      > backlogs seems to be quite informal and the aim seems to be more
      > focused in defining as much as necessary for the stakeholders to
      > roughly the same picture of the system.
      > Is the backlogs mentioned in contracts? If so, it would require the
      > backlogs to be quite formal.>
      > Requirements engineering started because of the contractual style of
      > initiating and managing projects. When a team was stuck with a
      > cost, time, functionality and quality - but emerging requirements
      > and unstable technology - they usually reduced functionality
      > (sometimes reduced quality,also). So requirements engineering was
      > built in ... you promised us this, show us how you delivered it.
      > Talk about making a bad situation worse!! In Scrum, we drive for
      > business value. Give us a vision of what you want, describe the
      > business objective, and the development team(s) will
      collaboratively > work together to deliver the value every Sprint.
      Since requirements
      > emerge, particularly as the customers see the working functionality
      > and change their mind about how to use it, Scrum facilitates
      > taking advantage of what's in hand. In contractually managed
      > projects, change orders are used to control change, but what they
      > really do is stifle change.

      Sadly I must agree with you! (Sadly since I've just taken I course
      called 'Reuirements Engineering' :-)

      > <How do you write contract when using Scrum? Because it is up to the
      > team to decide how much to do within a sprint the Sprint Backlog are
      > not so feasible for contract, is it? Or do you only make the
      > agreement with the customer that he pays for man-hours and have to
      > rely on the company to give him as much value for his money?>
      > Exactly. The contract focuses on vision and business value, what
      > system has to help make occur in a fixed period of time. The team
      > and customer then work on the "art of the possible", fitting the
      > most important functionality in within the required time to deliver
      > the value. DSDM has a saying that 20% of the functionality delivers
      > 80% of the business value. I agree.
      > <Is it possible for the customer to abort the project between any
      > Sprints?>
      > At the end of each Sprint, the customer can change cost (more team,
      > less teams, no teams), functionality (different functionality than
      > planned for the next Sprint), quality (make it buggier?). The
      > customer gets to drive the project Sprint by Sprint.

      Power to the people and Power to the customer! I like that!

      > <Here in Sweden it is some debate over fixed-price vs. current
      > account, where one side states that it is the developer who should
      > take the risk (thus fixed-price), whereas the other side states that
      > it is impossible to predetermine the price (thus current account).>
      > Why is each side trying to stick the other side with risk? Note the
      > word "side". The moment you have sides, everyone loses. Trust
      > evaporates, and mediocrity results. Every technology project is
      > risky and Scrum requires that both sides collaborate to manage the
      > risk and the uncertainty, focusing on results in a unpredictable
      > environment. By producing working product every thirty days, the
      > "risk" is never more than 30 days of cost, and judgements are based
      > on inspection of working product rather than belief in assertions.

      I second that!

      > <When talking about shared/team responsibility the story of the four
      > men often arise:
      > "This is a story about four people named Everybody, Somebody,
      > Anybody and Nobody.
      > There was an important job to be done and Everybody was sure that
      > Somebody would do it.
      > Anybody could have done it, but Nobody did it.
      > Somebody got angry about that, because it was Everybody's job.
      > Everybody thought Anybody could to it, but Nobody realised that
      > Everybody wouldn't do it.
      > It ended up that Everybody blamed Somebody when Nobody did what
      > Anybody could have done."
      > Is it unapplicable on Scrum? Is it plain nonsense?>
      > How horrible!! and, yes, it happens all of the time, but not with
      > Scrum. Scrum has the team commit to what they can do over the next
      > Sprint and gives them absolute authority and isolation to do their
      > best to deliver to their commitment. At the end of the team, the
      > team has to demonstrate working product functionality that
      > demonstrates value. Team and working functionality. These are the
      > only things looked at when the Sprint ends.
      > Based on what the team has done, the customer may at that point
      > decide not to fund any further Sprints, or to trade out the entire
      > team and get a new team. A Sprint really puts the team on the spot
      > --- as a group they have committed; as a group, they will be
      > It gives us what we've always asked for, the authority and time to
      > do our best. Now we have this freedom for a whole 30 days. Let's
      > what we can build, let's show off a little, let's have some fun and
      > build something really useful, great and neat. We've all seen
      > teams that are so dysfunctional from interal arguments and
      > politics that they can't perform (Boston RedSox come to mind).
      > game, just like every Sprint, this dysfunction is real obvious and
      > can be addressed.

      Yes, quite horrible but a nice play on words :-)
      I like the Scrum way much more.

      > <Isn't it easy that the product transforms into different products
      > too much when you're not fixating the end goal? Like starting out
      > be a pc program and then transforms into a internet application and
      > so forth.>
      > The value to the business, the Sprint Goal for each Sprint, the
      > customer decision about what to build in the next Sprint, keeps the
      > team focused.
      > Technology decisions become subservient to business value
      > The business person is left with the tradeoff of increasing
      > marketshare immediately with old technology that will require more
      > maintenance, or increasing marketshare more slowly while
      > implementing more versatile new technology. The business person
      > thinks, "if I'm delivering this functionality sooner than the
      > competition on connected browsers, will I get more customers, OR,
      > should I go for existing functionality on wireless devices and
      > create a marketing campaign that shows us as advanced and our
      > competition as behind the times?" Business decisions drive
      > technology decision, for the life of the product and for the
      > initiation of each Sprint.

      Won't it be hard to create a stable architecture if you don't have
      the end goal in sight? Or it is sufficient to use the information in
      the backlog as a foundation?

      > <In Scrum there are no such thing as time reporting, right? Can the
      > members choose to work 30 hours week?
      > Isn't it common that the customer would like to see figure of how
      > much time is spent on different activities?>
      > Yeetch!!! What do you care about my hours, my dress, my anything if
      > the team is collaborating with the user and delivering business
      > value. The deal at the start of the Sprint is, "we'll agree on what
      > business value to deliver over the Sprint, and then we the team
      > complete autonomy to figure out how we'll do so." If the team
      > figures that they work best together during the night hours and
      > management insists that they work during the day, management has
      > placed an impediment on the team that prevents it from delivering
      > the most business value. As such, management is violating their
      > primary responsibility ... the productivity of the organization and
      > the overall sustenance and survival of the orgnization. This type
      > change in thinking takes time, but the teams love it because it
      > treats them as responsible adults and holds them to it.

      No dress code? :-)
      But they still have to report how much they work to the company,
      right? Or is the salary fixed? (That would be great, but is it

      > <Are process improvement models, e.g. CMM,SPICE,ISO9001 applicable
      > to> Scrum?>
      > Maybe, but I don't really care. Process improvement was put in
      > to try to make the defined processes work better (see chapter 6 in
      > the book). The underlying assumption is that everyone would have to
      > follow the improved process and therefore greater productivity and
      > predictability would occur.
      > Scrum only puts a framework in place. When we wrap Scrum around XP,
      > we're wrapping Scrum around a great set of engineering processes,
      > but XP processes also aren't "defined", pert chart based processes,
      > so much as a framework.

      Perhaps there will emerge Emperical-CMM :-)

      > <Which career paths is possible with Scrum? Only developer
      > ->ScrumMaster? If so, isn't this a drawback?>
      > Scrum tightly links the business and the teams. People evolve and
      > self-organize into the roles that they fulfill best. Some engineers
      > become sales-support or customer implementation because they love
      > working in customer environments. This evolves based on personal
      > desires, skills, and tendencies tied to business needs. This, of
      > course, drives HR nuts, because HR is mostly designed around
      > predictable, defined, hierarchical career paths. Change the review
      > process so that teams (not just individuals) are rewarded. Open
      > everything up and let people thrive based on their contributions,
      > not politics and all of the "Dilbert" stuff. There are no
      > "system architects" and "lead designers" in Scrum teams. There are
      > only people who are respected and listened to based on their
      > experiences, skills, and effort.

      I like the idea. But doesn't it cause problems if highly skilled and
      experienced engineers recieve the same salary as newly examined
      Are the Scrum team persistent? Do they remain the same in several
      projects if they are well-fuinctioning?

      > <Is it customary to educate different stakeholders in Scrum before
      > starting the project? I know of one company that is using DSDM that
      > offers a one-day education about DSDM. How else can you prevent the
      > customer from hiring a competitor who promise the functionality at a
      > fixed price?>
      > DSDM and Scrum deliver fixed price contracts. However, both require
      > collaboration that focuses on delivering the most business value
      > that price in that timeframe. In chapter 5 of the book, Mike and I
      > talk about someone building security into an existing system. Scrum
      > is introduced as no big deal, just a way of dealing with the
      > complexity and allowing management to make adjustments based on
      > what's found. My next set of research is how to introduce
      > collaborative, adaptive, emergent, self-organizing processes like
      > Scrum into an organization as a way of doing business, top down.
      > Right now, with Scrum being implemented bottom up, we low ball the
      > organizational effects. The business people pick up on the benefits
      > and then start wanting "scrum, or whatever that approach is" used
      > more widely.

      So now Scrum is inserted as a flu shot. And when everyone sees the
      remarkable effect they are addicted.

      > <When scaling Scrum up to a large project it seems that the cross-
      > functional teams are lost (the book talks about test, CM, support
      > teams and so forth). Is this the case? Aren't cross-functional an
      > essential part of Scrum?>
      > Teams can be used to address any set of work, such as product
      > support or new product development. Include or exclude
      > responsibilities from teams as needed so that the team can move as
      > quickly as possible without creating long term problems. Jeff
      > Sutherland and I once gave development teams at an organization
      > development responsibility only. They put out code that was
      > difficult to maintain and the support teams got behind. So we
      > implemented a "once you code it, you own it forever" rule which
      > slowed the development teams down, but had them build better
      > software.

      Quite incompatible with the collective ownership rule of XP :-)

      > Best of luck with your thesis. You are in the middle of something
      > really neat.
      > Ken Schwaber

      Thanks! And thanks for all the answers! I don't know if they'll stop
      coming until I've seen Scrum in action so just tell me when to
      stop! :-)
      Yes I start to realise that Scrum is quite neat!

      Jonas Bengtsson
    • Show all 11 messages in this topic