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

Scrum SOS

Expand Messages
  • Keith McDonnell
    Hi all, I need some advice ... badly. I ve started working as a developer for a company who assured me that they use Scrum. However, when I started I found
    Message 1 of 10 , Jan 31, 2008
      Hi all,

      I need some advice ... badly.

      I've started working as a developer for a company who assured me that
      they use Scrum. However, when I started I found that:

      -> The scrum master "doesn't really believe in Scrum" & insists on using
      M$ Project.

      -> The product backlog includes tech tasks, is not prioritised and some
      features are vague.

      -> The interface design team work seperately with the product owner to
      produce wireframes which are used as the basis for sprint planning.

      There seems to a waterfall process here -- shouldn't the UI team & dev
      work together ?

      Shouldn't the wireframes flow from business value features expressed as
      user stories not the other way around ?

      -> Daily standups run outside sprints & include everyone (including CEO)

      I've worked with Scrum for a few years now and this company are new to
      the process. The developers & interface designers agree that the process
      is sub optimal.

      Any advice how I can get them back on track ?

      Keith
    • Andreas Leidig
      Hi, I think they should change, BUT... ... do they really want to? - How would you help them improve with scrum if they don t commit? So, first thing is to
      Message 2 of 10 , Jan 31, 2008
        Hi,

        I think they should change, BUT...

        ... do they really want to? - How would you help them improve with
        scrum if they don't commit?

        So, first thing is to convince them that they want to do scrum. And
        "they" means all of the participants.

        Andreas
      • mpkirby
        Rather than convincing them to change, convince them that the current process is introducing something into the work product or culture that is wrong. For
        Message 3 of 10 , Jan 31, 2008
          Rather than convincing them to change, convince them that the current
          process is introducing something into the work product or culture that
          is wrong.

          For example, when we did feature "X", the product owner was really mad
          we missed something in the GUI designs. If we had all been involved in
          developing them, we wouldn't have introduced that defect.

          Or, "The scrum team seems to spend a lot of time waiting for the GUI
          design team to finish their designs. Could we help? Maybe some of the
          work we could do, allowing them to concentrate on the truly creative parts.

          In other words, focus on the points of pain, gently nudging the culture
          to a more ideal state. Just because they don't use scrum, doesn't mean
          they need to change. And just because a company uses scrum, doesn't
          mean it is perfect. Think of it as doing a series of retrospectives,
          and using that to drive improvements.

          Mike




          Keith McDonnell wrote:
          >
          > Hi all,
          >
          > I need some advice ... badly.
          >
          > I've started working as a developer for a company who assured me that
          > they use Scrum. However, when I started I found that:
          >
          > -> The scrum master "doesn't really believe in Scrum" & insists on using
          > M$ Project.
          >
          > -> The product backlog includes tech tasks, is not prioritised and some
          > features are vague.
          >
          > -> The interface design team work seperately with the product owner to
          > produce wireframes which are used as the basis for sprint planning.
          >
          > There seems to a waterfall process here -- shouldn't the UI team & dev
          > work together ?
          >
          > Shouldn't the wireframes flow from business value features expressed as
          > user stories not the other way around ?
          >
          > -> Daily standups run outside sprints & include everyone (including CEO)
          >
          > I've worked with Scrum for a few years now and this company are new to
          > the process. The developers & interface designers agree that the process
          > is sub optimal.
          >
          > Any advice how I can get them back on track ?
          >
          > Keith
          >
          >
        • Andreas Leidig
          Hi Mike, you express exactly what I meant but didn t write. The key is really to make them want to change. But still there is more to it than only the project
          Message 4 of 10 , Jan 31, 2008
            Hi Mike,

            you express exactly what I meant but didn't write. The key is really to make them want to change. But still there is more to it than only the project goal. I would first make sure if the goal is the most important factor in the process (as it should be). Many organizations concentrate more on blaming, securing or increasing personal power. In such environments it may be extremely difficult to make them aware of what they are really doing.

            Andreas
            Am 31.01.2008 um 12:39 schrieb mpkirby:

            Rather than convincing them to change, convince them that the current 
            process is introducing something into the work product or culture that 
            is wrong.

            For example, when we did feature "X", the product owner was really mad 
            we missed something in the GUI designs. If we had all been involved in 
            developing them, we wouldn't have introduced that defect.

            Or, "The scrum team seems to spend a lot of time waiting for the GUI 
            design team to finish their designs. Could we help? Maybe some of the 
            work we could do, allowing them to concentrate on the truly creative parts.

            In other words, focus on the points of pain, gently nudging the culture 
            to a more ideal state. Just because they don't use scrum, doesn't mean 
            they need to change. And just because a company uses scrum, doesn't 
            mean it is perfect. Think of it as doing a series of retrospectives, 
            and using that to drive improvements.

            Mike


          • George Dinwiddie
            ... How do the CEO, the scrummaster and others feel? If they think things are fine as they are, then things are pretty stuck until they think otherwise. That
            Message 5 of 10 , Jan 31, 2008
              Keith McDonnell wrote:
              > I've worked with Scrum for a few years now and this company are new to
              > the process. The developers & interface designers agree that the process
              > is sub optimal.
              >
              > Any advice how I can get them back on track ?

              How do the CEO, the scrummaster and others feel? If they think things
              are fine as they are, then things are pretty stuck until they think
              otherwise. That means the starting point is with them.

              If they are not satisfied, and want help, then you can learn to coach
              them or bring in a coach. Where that coaching starts depends on with
              what are they not satisfied and what help do they think they want.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Ken Schwaber
              Talk with the others and see if they are willing to do two things: 1. Keep all Sprint lengths the same. 2. Define done for the next six Sprints and adhere to
              Message 6 of 10 , Jan 31, 2008

                Talk with the others and see if they are willing to do two things:

                1. Keep all Sprint lengths the same.
                2. Define “done” for the next six Sprints and adhere to it when selecting product backlog and being allowed to discuss stuff as “done” at the Sprint Review”

                 

                If they can’t do these items, you are in what is called iterative, incremental death march. There are only two ways out: a desire of the developers at your new company to improve, and the door.

                 

                Ken

                 


                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Keith McDonnell
                Sent: Thursday, January 31, 2008 6:02 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Scrum SOS

                 

                Hi all,

                I need some advice ... badly.

                I've started working as a developer for a company who assured me that
                they use Scrum. However, when I started I found that:

                -> The scrum master "doesn't really believe in Scrum" & insists on using
                M$ Project.

                -> The product backlog includes tech tasks, is not prioritised and some
                features are vague.

                -> The interface design team work seperately with the product owner to
                produce wireframes which are used as the basis for sprint planning.

                There seems to a waterfall process here -- shouldn't the UI team & dev
                work together ?

                Shouldn't the wireframes flow from business value features expressed as
                user stories not the other way around ?

                -> Daily standups run outside sprints & include everyone (including CEO)

                I've worked with Scrum for a few years now and this company are new to
                the process. The developers & interface designers agree that the process
                is sub optimal.

                Any advice how I can get them back on track ?

                Keith

              • Mark Graybill
                Keith, It seem they have the following issues, correlating to a mutated implementation of scrum: 1. Lack a fundamental understanding of the scrum elements and
                Message 7 of 10 , Jan 31, 2008
                  Keith,
                   
                  It seem they have the following issues, correlating to a mutated implementation of scrum:
                   
                  1. Lack a fundamental understanding of the scrum elements and roles - the what and how.
                  2. Doesn't know how to let go of existing ways and to make change.  This is a natural roadblock that typically occurs with change within an organization.  You need to have buy-in and follow-through.
                   
                  What you described seems like such a mutation that unless what they did previously somehow worked, I'd probably wager on this setup failing.
                   
                  Here is what I might suggest - keeping in mind "they" is literally everyone - especially the glue roles:
                   
                  A. They need to work toward a paradigm shift:
                   
                  1. They should ask themselves why they want to do scrum.  If it is because projects typically are late, underdelivered and/or over budget, then:
                  2. They need to accept there are aspects of the process and methodical aspects of and forces involved with software development they do not fully understand (otherwise they could fix their own process).
                  3. Read the Agile Manifesto and trust that:
                      . If everyone is needed to develop the software (all stakeholders) then the effectiveness of that group in developing the software is proportional to the collaborative and interactive effectiveness of that group.
                      . The more the collaboration and interaction is face-to-face, and the more clear/concise and direct the communication is, the more effective it is.
                      . The more repeatable order is associated with the collaboration and interaction, the more effective it will be.
                  4. Decide to do scrum whole-heartedly, and decide to endure the iterative aspects (and growing pains) of learning it.
                   
                  B. Training
                   
                  1. Get scrum master training for everyone, preferably in house. I recommend Kenny Rubin if you can do it in house.  This will likely accelerate assimilating scrum.
                  2. Assign someone to act as internal consultant that will become an expert, and attend meetings and help improve scrum practices. This person should be someone who has buy-in and is well-respected in your organization (and they should have the type of demeanor that tends to be pleasant and positive).
                  3. Regularly refresh your knowledge (you can have in-house) and refine practices accordingly (use the retrospective well).  Repitition is one principle of learning.
                   
                  C. Practice
                   
                  1. Decide to do scrum and decide to invest on getting it right as soon as possible.
                  2. Perhaps do in parallel to existing project work for about 4 sprints the following:
                      . With the internal consultant having cheat-sheets in hand and moderating, practice/role-play each scrum meeting (from P.O. team meetings to product, release and sprint planning, to the daily stand-up). 
                      . The purpose of these meetings is to practice how to execute the meeting rather than worrying about content.  However, I recommend using for practice content from software already built (keep it simple though).
                  3. Also do scrum for the current projects.  The above may slow you down in the beginning, but the end results should yield far more repeatable productivity than what you have now.
                  4. Keep sprint duration to 2 weeks for both practice and real scrumming - for at least 4 months.
                  5. Use your retrospectives for both practice and real scrumming to identify what to improve, how to improve it and assign someone responsible for ensuring execution of the improvement plan.  Repeat every retrospective.
                   
                  D. Follow-through.
                   
                  1. Keep it simple - avoid building complexity (e.g. MS Project).
                  2. Keep it positive.
                  3. Recognize the stages of team development may be occurring (form, storm, norm, perfom) and talk about how the team in this regard on a regular basis.
                  4. View building professional relationships as significant and important.
                  5. Be patient and think critically.
                  6. Have consistent and effective leadership.
                  7. Understand the problems with estimation and the levels of precision scrum has to address them (product, release, and sprint planning).
                  8. From a project perspective, scrum has in place to cover all levels of planning, and to recognize potential changes to the plan as early as possible (e.g. daily standup: report roadblocks; task remaining time grows).
                  9. Seek to make the team environment safe
                  10. Un-learn the meaning we have previously assigned to estimating - especially in hours.  Expect to err in most of your sprint planning (not making the hours, missing tasks, etc.) - expect it.  Until you let go of this, it will be a hindrance to effective scrum planning - a hysteretic force tangible but inexplicable (to those in our profession anyway).
                  11. Plan above the sprint level using units of measure not associated or even sounding like hours.
                  12. Be persistent and unrelenting in your goal to improve the practice of scrum in your organization.
                  14. Keep team sizes down (3-5 n/i scrum master).  If split, split on boundaries with minimal dependencies between the groups.
                  15. If possible, have each team
                  16. Improve disaggregation (AKA decomposition) - trying to keeping in mind team and sprint sizes, and team makeup.
                  17. If applicable, have those who contribute in all areas of the software development lifecycle be members (e.g. architect, tech-writer, and V&V/test).
                  18. Recognizing failure is a positive thing.  Defending failure or rationalizing negative attitudes against say scrum is not.  Like finding defects in software, view recognizing failure in scrum as defects in your process, practices or methods.  Such simply reveals opportunity to improve toward perfection not otherwise known.
                  19. There may be storm and pain before the quiet and enjoyment.
                  20. Software devleopment should become more rewarding and fun if you do scrum correctly.  Moreover, it will establish confidence in the group and with upper management/executives you may not currently be accustomed to.
                   
                  Hope this helps.

                  Cheers!
                   
                  Mark
                   
                  ----- Original Message -----
                  Sent: Thursday, January 31, 2008 5:02 AM
                  Subject: [scrumdevelopment] Scrum SOS

                  Hi all,

                  I need some advice ... badly.

                  I've started working as a developer for a company who assured me that
                  they use Scrum. However, when I started I found that:

                  -> The scrum master "doesn't really believe in Scrum" & insists on using
                  M$ Project.

                  -> The product backlog includes tech tasks, is not prioritised and some
                  features are vague.

                  -> The interface design team work seperately with the product owner to
                  produce wireframes which are used as the basis for sprint planning.

                  There seems to a waterfall process here -- shouldn't the UI team & dev
                  work together ?

                  Shouldn't the wireframes flow from business value features expressed as
                  user stories not the other way around ?

                  -> Daily standups run outside sprints & include everyone (including CEO)

                  I've worked with Scrum for a few years now and this company are new to
                  the process. The developers & interface designers agree that the process
                  is sub optimal.

                  Any advice how I can get them back on track ?

                  Keith

                • srinivas chillara
                  My initial reaction on seeing Mark s post was Blimey! This is not really brief! . However, very detailed and useful advice. I think you should go ahead with
                  Message 8 of 10 , Jan 31, 2008
                    My initial reaction on seeing Mark's post was "Blimey!
                    This is not really brief!". However, very detailed and
                    useful advice. I think you should go ahead with this.


                    But humans are like lemmings you know. They often
                    cannot see/admit that there are problems. Good luck!
                    There are posts here where good Scrum Masters are
                    wanted, so maybe you can apply!


                    > Keith,
                    >
                    > It seem they have the following issues, correlating
                    > to a mutated implementation of scrum:
                    >
                    > 1. Lack a fundamental understanding of the scrum
                    > elements and roles - the what and how.
                    > 2. Doesn't know how to let go of existing ways and
                    > to make change. This is a natural roadblock that
                    > typically occurs with change within an organization.
                    > You need to have buy-in and follow-through.
                    >
                    > What you described seems like such a mutation that
                    > unless what they did previously somehow worked, I'd
                    > probably wager on this setup failing.
                    >
                    > Here is what I might suggest - keeping in mind
                    > "they" is literally everyone - especially the glue
                    > roles:
                    >
                    > A. They need to work toward a paradigm shift:
                    >
                    > 1. They should ask themselves why they want to do
                    > scrum. If it is because projects typically are
                    > late, underdelivered and/or over budget, then:
                    > 2. They need to accept there are aspects of the
                    > process and methodical aspects of and forces
                    > involved with software development they do not fully
                    > understand (otherwise they could fix their own
                    > process).
                    > 3. Read the Agile Manifesto and trust that:
                    > . If everyone is needed to develop the software
                    > (all stakeholders) then the effectiveness of that
                    > group in developing the software is proportional to
                    > the collaborative and interactive effectiveness of
                    > that group.
                    > . The more the collaboration and interaction is
                    > face-to-face, and the more clear/concise and direct
                    > the communication is, the more effective it is.
                    > . The more repeatable order is associated with
                    > the collaboration and interaction, the more
                    > effective it will be.
                    > 4. Decide to do scrum whole-heartedly, and decide to
                    > endure the iterative aspects (and growing pains) of
                    > learning it.
                    >
                    > B. Training
                    >
                    > 1. Get scrum master training for everyone,
                    > preferably in house. I recommend Kenny Rubin if you
                    > can do it in house. This will likely accelerate
                    > assimilating scrum.
                    > 2. Assign someone to act as internal consultant that
                    > will become an expert, and attend meetings and help
                    > improve scrum practices. This person should be
                    > someone who has buy-in and is well-respected in your
                    > organization (and they should have the type of
                    > demeanor that tends to be pleasant and positive).
                    > 3. Regularly refresh your knowledge (you can have
                    > in-house) and refine practices accordingly (use the
                    > retrospective well). Repitition is one principle of
                    > learning.
                    >
                    > C. Practice
                    >
                    > 1. Decide to do scrum and decide to invest on
                    > getting it right as soon as possible.
                    > 2. Perhaps do in parallel to existing project work
                    > for about 4 sprints the following:
                    > . With the internal consultant having
                    > cheat-sheets in hand and moderating,
                    > practice/role-play each scrum meeting (from P.O.
                    > team meetings to product, release and sprint
                    > planning, to the daily stand-up).
                    > . The purpose of these meetings is to practice
                    > how to execute the meeting rather than worrying
                    > about content. However, I recommend using for
                    > practice content from software already built (keep
                    > it simple though).
                    > 3. Also do scrum for the current projects. The
                    > above may slow you down in the beginning, but the
                    > end results should yield far more repeatable
                    > productivity than what you have now.
                    > 4. Keep sprint duration to 2 weeks for both practice
                    > and real scrumming - for at least 4 months.
                    > 5. Use your retrospectives for both practice and
                    > real scrumming to identify what to improve, how to
                    > improve it and assign someone responsible for
                    > ensuring execution of the improvement plan. Repeat
                    > every retrospective.
                    >
                    > D. Follow-through.
                    >
                    > 1. Keep it simple - avoid building complexity (e.g.
                    > MS Project).
                    > 2. Keep it positive.
                    > 3. Recognize the stages of team development may be
                    > occurring (form, storm, norm, perfom) and talk about
                    > how the team in this regard on a regular basis.
                    > 4. View building professional relationships as
                    > significant and important.
                    > 5. Be patient and think critically.
                    > 6. Have consistent and effective leadership.
                    > 7. Understand the problems with estimation and the
                    > levels of precision scrum has to address them
                    > (product, release, and sprint planning).
                    > 8. From a project perspective, scrum has in place to
                    > cover all levels of planning, and to recognize
                    > potential changes to the plan as early as possible
                    > (e.g. daily standup: report roadblocks; task
                    > remaining time grows).
                    > 9. Seek to make the team environment safe
                    > 10. Un-learn the meaning we have previously assigned
                    > to estimating - especially in hours. Expect to err
                    > in most of your sprint planning (not making the
                    > hours, missing tasks, etc.) - expect it. Until you
                    > let go of this, it will be a hindrance to effective
                    > scrum planning - a hysteretic force tangible but
                    > inexplicable (to those in our profession anyway).
                    > 11. Plan above the sprint level using units of
                    > measure not associated or even sounding like hours.
                    > 12. Be persistent and unrelenting in your goal to
                    > improve the practice of scrum in your organization.
                    > 14. Keep team sizes down (3-5 n/i scrum master). If
                    > split, split on boundaries with minimal dependencies
                    > between the groups.
                    > 15. If possible, have each team
                    > 16. Improve disaggregation (AKA decomposition) -
                    > trying to keeping in mind team and sprint sizes, and
                    > team makeup.
                    > 17. If applicable, have those who contribute in all
                    > areas of the software development lifecycle be
                    > members (e.g. architect, tech-writer, and V&V/test).
                    > 18. Recognizing failure is a positive thing.
                    > Defending failure or rationalizing negative
                    > attitudes against say scrum is not. Like finding
                    > defects in software, view recognizing failure in
                    > scrum as defects in your process, practices or
                    > methods. Such simply reveals opportunity to improve
                    > toward perfection not otherwise known.
                    > 19. There may be storm and pain before the quiet and
                    > enjoyment.
                    > 20. Software devleopment should become more
                    > rewarding and fun if you do scrum correctly.
                    > Moreover, it will establish confidence in the group
                    > and with upper management/executives you may not
                    > currently be accustomed to.
                    >
                    > Hope this helps.
                    >
                    > Cheers!
                    >
                    > Mark
                    >
                    > ----- Original Message -----
                    > From: Keith McDonnell
                    > To: scrumdevelopment@yahoogroups.com
                    > Sent: Thursday, January 31, 2008 5:02 AM
                    > Subject: [scrumdevelopment] Scrum SOS
                    >
                    >
                    > Hi all,
                    >
                    > I need some advice ... badly.
                    >
                    > I've started working as a developer for a company
                    > who assured me that
                    > they use Scrum. However, when I started I found
                    > that:
                    >
                    > -> The scrum master "doesn't really believe in
                    > Scrum" & insists on using
                    > M$ Project.
                    >
                    > -> The product backlog includes tech tasks, is not
                    > prioritised and some
                    > features are vague.
                    >
                    > -> The interface design team work seperately with
                    > the product owner to
                    > produce wireframes which are used as the basis for
                    > sprint planning.
                    >
                    > There seems to a waterfall process here --
                    > shouldn't the UI team & dev
                    > work together ?
                    >
                    > Shouldn't the wireframes flow from business value
                    > features expressed as
                    > user stories not the other way around ?
                    >
                    > -> Daily standups run outside sprints & include
                    > everyone (including CEO)
                    >
                    > I've worked with Scrum for a few years now and
                    > this company are new to
                    > the process. The developers & interface designers
                    > agree that the process
                    > is sub optimal.
                    >
                    > Any advice how I can get them back on track ?
                    >
                    === message truncated ===



                    Now you can chat without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php
                  • Robin Dymond
                    Hi Keith, This is quite common, many companies have compromised Agile implementations. There is probably too many points in the other responses to understand
                    Message 9 of 10 , Feb 2, 2008
                      Hi Keith,

                      This is quite common, many companies have compromised Agile implementations.

                      There is probably too many points in the other responses to understand what to do out of those many points, and what drives change in your organization.

                      Why do they claim they are doing Scrum? What benefits are they trying to achieve? Discuss this with the CEO and management and gather data - politely and respectfully since everyone probably thinks they are doing the right thing. Compare their goals to what they are doing currently with what Scrum says, show the gaps, and how following the process will help them reach their goals faster/better etc.

                      You need to change minds, and to do that you need to engage not at the Scrum level, but at the business/people outcomes level, and show how these outcomes would be better served by changing their behaviors. The could be Scrum, but it is probably other things too, like Lean, XP, User Stories, TDD, etc. Getting Scrum right is just the start, there is much more to consider on an ongoing quest for continuous improvement.

                      cheers,
                      Robin.


                      On Jan 31, 2008 6:02 AM, Keith McDonnell <keith@...> wrote:

                      Hi all,

                      I need some advice ... badly.

                      I've started working as a developer for a company who assured me that
                      they use Scrum. However, when I started I found that:

                      -> The scrum master "doesn't really believe in Scrum" & insists on using
                      M$ Project.

                      -> The product backlog includes tech tasks, is not prioritised and some
                      features are vague.

                      -> The interface design team work seperately with the product owner to
                      produce wireframes which are used as the basis for sprint planning.

                      There seems to a waterfall process here -- shouldn't the UI team & dev
                      work together ?

                      Shouldn't the wireframes flow from business value features expressed as
                      user stories not the other way around ?

                      -> Daily standups run outside sprints & include everyone (including CEO)

                      I've worked with Scrum for a few years now and this company are new to
                      the process. The developers & interface designers agree that the process
                      is sub optimal.

                      Any advice how I can get them back on track ?

                      Keith


                      --
                      Robin Dymond
                      VP, Managing Partner
                      Innovel, LLC
                      www.innovel.net
                      cell: (804) 239-4329
                    • Nicholas Cancelliere
                      I have to agree with Robin here. What you are experiencing is sadly all to common. Scrum is not a prescriptive method, but an empirical one. See my thoughts
                      Message 10 of 10 , Mar 1, 2008
                        I have to agree with Robin here. What you are experiencing is sadly
                        all to common. Scrum is not a prescriptive method, but an empirical
                        one. See my thoughts below:

                        On Feb 2, 2008, at 10:41 PM, Robin Dymond wrote:

                        > Hi Keith,
                        >
                        > This is quite common, many companies have compromised Agile
                        > implementations.
                        >
                        > Hi all,
                        >
                        > I need some advice ... badly.
                        >
                        > I've started working as a developer for a company who assured me that
                        > they use Scrum. However, when I started I found that:
                        >
                        > -> The scrum master "doesn't really believe in Scrum" & insists on
                        > using
                        > M$ Project.
                        >
                        Was this person the project manager before they came into the
                        Scrummaster role? It is sometimes difficult for these people to make
                        the transition. Are they a CSM (certified scrummaster)? Attending a
                        CSM class might help turn on the light-bulb.

                        Just because you're using Microsoft Project doesn't mean you arn't
                        doing Scrum. It probably isn't the *best* tool though for tracking a
                        product backlog, sprint backlog and related burndowns. They might be
                        using it because they have to report into the PMO using this tool. If
                        they're using to to make Gantt charts and try and the like - then yes
                        that's odd behavior for a Scrummaster. Gantt charts have a lot of
                        things wrong with them which I will not go into detail here.
                        > -> The product backlog includes tech tasks, is not prioritised and
                        > some
                        > features are vague.
                        >
                        When you say technical tasks are you referring to constraints? For
                        example, "The system supports 25 concurrent page views at any given
                        time, without slowing down." These type of stories can be okay, they
                        usually are expressed as things valuable to purchasers of the software
                        or system you're building (rather than the end-user). In this example
                        someone buying the software might want to make sure it can support a
                        certain load.

                        A backlog that isn't prioritized? This worries me. One of the main
                        components to Scrum is that you have a prioritized backlog from which
                        the Team takes it work from.

                        Have you (and your team members) said, "We are not able to commit to
                        any sprint work because your requests are vague." If the team is not
                        pushing back and accepting the status quo, then it's unlikely that the
                        product owner is going to change -- why should he, you guys seem to be
                        working anyhow - right? I think this type of discussion should come
                        about in your retrospectives (which I hope you're having).
                        > -> The interface design team work seperately with the product owner to
                        > produce wireframes which are used as the basis for sprint planning.
                        >
                        >
                        Cockburn and others will tell you that you want to delay interface
                        design as late as possible. When you start to focus on the actual
                        design of the page you are all wrapped up in implementation and
                        defocus on the user goal. It also stifles the creativity of the team
                        because they are essentially presented with the solution, instead of
                        allowed to come to one on their own.

                        An example a buddy of my told me once: A user story said "As a user I
                        need to type my password on a keypad." Why a password, why a keypad?
                        The explanation is, "Well it needs to be secure, so I will type my
                        password into the keypad." Ah ha - so you want it to be secure! Why
                        not use a thumbprint scanner, or a RFID chip or magnetic swipe card?
                        Those are all valid implementations to achieve the same end.
                        Technology changes over time - it might be keypads are more expensive
                        than magnetic swipe cards, or one is more extensible than the other,
                        etc. (This is a simple example - but it shows what happens when you
                        focus on implementation and not the goal.)

                        > There seems to a waterfall process here -- shouldn't the UI team & dev
                        > work together ?
                        >
                        >
                        Yes! Scrum teams are cross-functional. If you have a team of UI
                        people, a team of developers and a team of QA people - your management
                        is missing the point.

                        > Shouldn't the wireframes flow from business value features expressed
                        > as
                        > user stories not the other way around ?
                        >
                        Yes, as I said in my earlier reply -- try to delay user interface
                        decisions as long as possible. Focus on the user goals, make sure you
                        understand them, and then focus on implementation when you get down to
                        that level. Together both the UI and developers should be working on
                        figuring that out (when it comes to actually implementing the feature).

                        > -> Daily standups run outside sprints & include everyone (including
                        > CEO)
                        >
                        How many people is "everyone?" I am okay with outside folks (we call
                        them Chickens) attending my stand-ups. It helps me not have to write
                        a status report, if everyone who would be reading that status report
                        instead attends the stand-up and hears and sees first-hand where the
                        project is. You do want to limit it to a reasonable number of folks
                        though (for obvious reasons), I'd say for a team of 7-8 people, no
                        more than 12 total at the stand-up. It is also good practice to have
                        them stand outside of the circle, it reminds them both of their role
                        (as a quite chicken) and keeps the team undistracted.

                        > I've worked with Scrum for a few years now and this company are new to
                        > the process. The developers & interface designers agree that the
                        > process
                        > is sub optimal.
                        >
                        > Any advice how I can get them back on track ?
                        >


                        Have you suggested attending a CSM training or bringing in a coach?
                        Your team might benefit greatly from some coaching engagements. It
                        sometimes helps to bring in someone from outside the situation who is
                        objective. Also what you are experiencing is nothing too new, and as
                        I said sadly often all to common -- so it's likely the coach will have
                        experienced this before at other companies. Every company and
                        situation is slightly different though and there is no prescriptive
                        solution unfortunately.

                        Best of luck,
                        Nicholas
                        > Keith
                        >
                        >
                        > scrumdevelopment@...
                        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                        >
                        >
                        >
                        > Your email settings: Individual Email|Traditional
                        > Change settings via the Web (Yahoo! ID required)
                        > Change settings via email: Switch delivery to Daily Digest | Switch
                        > to Fully Featured
                        > Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
                        >
                        >



                        --
                        Nicholas Cancelliere, CSM/CSP
                        Austin, TX

                        Certified Scrum Practitioner
                        Certified Scrum Master

                        Over 10 years of web application development experience and an Agile
                        nut!
                      Your message has been successfully submitted and would be delivered to recipients shortly.