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

UX role in Scrum teams

Expand Messages
  • Demetrius Nunes
    Hi there, Our customer is used to discuss, validate and accept user story definitions based on high fidelity screens and prototypes, which demands the UX
    Message 1 of 14 , Jul 27 3:44 PM
    • 0 Attachment
      Hi there,

      Our customer is used to discuss, validate and accept user story definitions based on high fidelity screens and prototypes, which demands the UX people to work ahead of the developers, showing these prototypes to the customer. Only after that, the Product Owner feels comfortable to commit the story to the backlog.

      Is it acceptable for UX people to work ahead of the developers to prepare and design the user interfaces and interactions of user stories before the actual sprint where these stories will be built, or, ideally, UX should always be working together with the developers on the same stories in the same sprint?

      The Product Owner feels comfortable working this way, as long as the developers participate thru the whole process and the UX people support the developers during the sprints, but I fear this might be a sub-optimization of the process, although is hard to see it being done any other way, specially because our customer is very attached to the UX quality of the user interfaces.

      The PO likes to make an analogy with the auto industry, in the sense that there is a product concept, design and prototyping phase of a car (in which manufacturing engineers are also involved), before the actual manufacturing phase, where engineers will then do most of the work figuring out how to build the assembly line for that car. Is this a good analogy?

      Best regards,
      Demetrius
      --
      ____________________________
      http://www.demetriusnunes.com
    • Robin Paterson
      ... This makes me very uncomfortable. This sounds like you re being committed to implement features because the customer has already seen the interface. This
      Message 2 of 14 , Jul 27 4:25 PM
      • 0 Attachment
        On 27/07/2010 23:44, Demetrius Nunes wrote:  
        Hi there,

        Our customer is used to discuss, validate and accept user story definitions based on high fidelity screens and prototypes, which demands the UX people to work ahead of the developers, showing these prototypes to the customer. Only after that, the Product Owner feels comfortable to commit the story to the backlog.

        Is it acceptable for UX people to work ahead of the developers to prepare and design the user interfaces and interactions of user stories before the actual sprint where these stories will be built, or, ideally, UX should always be working together with the developers on the same stories in the same sprint?

        The Product Owner feels comfortable working this way, as long as the developers participate thru the whole process and the UX people support the developers during the sprints, but I fear this might be a sub-optimization of the process, although is hard to see it being done any other way, specially because our customer is very attached to the UX quality of the user interfaces.

            This makes me very uncomfortable.  This sounds like you're being committed to implement features because the customer has already seen the interface.
            This also runs contrary to sashimi - there is no vertical slice from a single team.  There is no cross-functional behaviour here.

        The PO likes to make an analogy with the auto industry, in the sense that there is a product concept, design and prototyping phase of a car (in which manufacturing engineers are also involved), before the actual manufacturing phase, where engineers will then do most of the work figuring out how to build the assembly line for that car. Is this a good analogy?

            No, this is not a good analogy.
            The prototype of a car may look very different to the final model.  Depending on the company, the prototype may be a "blue sky" (I hate that term) model, or a slight variation on an existing model.  Regardless, making a prototype and making a model ready for mass production are two different things.  Making a model ready for mass production means examining your existing tooling, your existing supplies and suppliers, your existing expertise and your existing markets.  I'm struggling to think of a major manufacturer that doesn't also use families of parts (VAG is a brilliant example - Volkswagen, Audi, Skoda all share parts).  Anyone who thinks that building a prototype also involves buying brand new assembly line tooling, training workers to use it, and creating brand new families of parts is insane.  This happens rarely as it's such a huge risk.  Small increments = less risk.
            Engineers will look at the existing assembly line to see how the prototype can be altered to make it fit the existing set up - not the other way around.
            Have I understood you correctly?
        -R.

      • George Dinwiddie
        Demetrius, ... It s normal for UX to work ahead to help define the stories, but I think that developing high fidelity mockups and prototypes is wasted effort.
        Message 3 of 14 , Jul 27 4:43 PM
        • 0 Attachment
          Demetrius,

          On 7/27/10 6:44 PM, Demetrius Nunes wrote:
          >
          >
          > Hi there,
          >
          > Our customer is used to discuss, validate and accept user story
          > definitions based on high fidelity screens and prototypes, which demands
          > the UX people to work ahead of the developers, showing these prototypes
          > to the customer. Only after that, the Product Owner feels comfortable to
          > commit the story to the backlog.
          >
          > Is it acceptable for UX people to work ahead of the developers to
          > prepare and design the user interfaces and interactions of user stories
          > before the actual sprint where these stories will be built, or, ideally,
          > UX should always be working together with the developers on the same
          > stories in the same sprint?

          It's normal for UX to work ahead to help define the stories, but I think
          that developing high fidelity mockups and prototypes is wasted effort.
          Figuring out every last detail is not necessary before starting the
          story, and doing so often results in fragile implementations trying to
          hit "pixel perfect" rendition rather than something that will behave
          reasonably as browsers change.

          > The Product Owner feels comfortable working this way, as long as the
          > developers participate thru the whole process and the UX people support
          > the developers during the sprints, but I fear this might be a
          > sub-optimization of the process, although is hard to see it being done
          > any other way, specially because our customer is very attached to the UX
          > quality of the user interfaces.

          In what way do the UX people support the developers? Do they modify the
          designs as they're developed?

          > The PO likes to make an analogy with the auto industry, in the sense
          > that there is a product concept, design and prototyping phase of a car
          > (in which manufacturing engineers are also involved), before the actual
          > manufacturing phase, where engineers will then do most of the work
          > figuring out how to build the assembly line for that car. Is this a good
          > analogy?

          I think it's a great analogy. Your PO is choosing the GM strategy, of
          doing lots of up-front design because it takes months to change the
          tooling. The alternative is the Toyota strategy, of shaving tooling
          changes down to days, from months.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Peter Stevens (cal)
          Hi Demetrius, I had a similar situation. Three teams: UX, UI and java. The UX and UI guys were filling a pipeline with screen shots which the java guys were
          Message 4 of 14 , Jul 27 9:55 PM
          • 0 Attachment
            Hi Demetrius,

            I had a similar situation. Three teams: UX, UI and java. The UX and UI guys were filling a pipeline
            with screen shots which the java guys were supposed to implement.

            The UI team started doing Scrum first. Eventually they were so productive, that the customer/PO had
            to stop the team for 6 months until the Java people caught up. They never really did either, until
            they started doing Scrum too. So, first question: Are you producing an inventory of features waiting
            to be implemented? In this case, when the UI work resumed, many months later, they decided the
            pipeline was OK, but the UI team had to produce HTML/JavaScript templates with the java team would
            implement in the next sprint. By keeping the two teams in lockstep, it worked. (There were geography
            and language issues, which discouraged a collaboration directly in the sprint).

            I had another similar situation: One team developing a new UI to an existing application. We defined
            the application as User Stories, but needed to come up with an information architecture (IA). The
            stories defined what, and the IA described how (from the users point of view). The Product Owner was
            very interested in the IA. We went through multiple iterations with our best people working on the
            design, only to have the P-O redesign it once he saw it. (It reminded me of the letter writing
            example in Parkinson's Law: http://tinyurl.com/2vel7sb ). In this case, it was as much about control
            as about method.

            Perhaps the P-O thinks he is saving time and/or money by evaluating mock-ups rather than actual
            running systems. Maybe some experimentation with alternative approaches would be convincing.

            In general, I would suggest keeping your presentation layer as thin as possible and as decoupled
            from the application as possible so it is easy to change. A usability test with real users late in
            the project can really make a mess of your beautiful UI concept ...and your schedule ;-). I would
            look for signs of inventory accumulating, shortages of work, or excessive redesign. These indicate
            your process is wasteful. And I would try to find out why your P-O wants to work the way he does,
            then show him a better way to accomplish his goals...

            Hope this helps,

            Cheers,
            Peter



            On 28.07.10 00:44, Demetrius Nunes wrote:
            > Hi there,
            >
            > Our customer is used to discuss, validate and accept user story definitions
            > based on high fidelity screens and prototypes, which demands the UX people
            > to work ahead of the developers, showing these prototypes to the customer.
            > Only after that, the Product Owner feels comfortable to commit the story to
            > the backlog.
            >
            > Is it acceptable for UX people to work ahead of the developers to prepare
            > and design the user interfaces and interactions of user stories before the
            > actual sprint where these stories will be built, or, ideally, UX should
            > always be working together with the developers on the same stories in the
            > same sprint?
            >
            > The Product Owner feels comfortable working this way, as long as the
            > developers participate thru the whole process and the UX people support the
            > developers during the sprints, but I fear this might be a sub-optimization
            > of the process, although is hard to see it being done any other way,
            > specially because our customer is very attached to the UX quality of the
            > user interfaces.
            >
            > The PO likes to make an analogy with the auto industry, in the sense that
            > there is a product concept, design and prototyping phase of a car (in which
            > manufacturing engineers are also involved), before the actual manufacturing
            > phase, where engineers will then do most of the work figuring out how to
            > build the assembly line for that car. Is this a good analogy?
            >
            > Best regards,
            > Demetrius


            --
            Lean Agile Scrum Konferenz in Zürich mit Mary Poppendieck und Henrik Kniberg.
            Schlagen Sie die Brücke von Scrum Team bis zum schlanken Unternehmen!
            http://bit.ly/las-zh

            Peter Stevens, CSM, CSPO, CSP
            Independent Scrum Trainer and Coach
            Sierra-Charlie Consulting | Zurich | Switzerland

            Member of DasScrumTeam.de

            blog: http://scrum-breakfast.com
            tel: +41 44 586 6450
            cell: +41 79 422 6722
            skype: peterstev
          • Robin Paterson
            George, I like discussion... :-) ... Totally agree with your scum comments :-) ... Don t follow you here at all. Everyone does lots of up front design on new
            Message 5 of 14 , Jul 28 12:58 AM
            • 0 Attachment
              George,
                  I like discussion...  :-)

              On 28/07/2010 00:43, George Dinwiddie wrote:
               

              Demetrius,

              On 7/27/10 6:44 PM, Demetrius Nunes wrote:
              >
              >
              > Hi there,
              >
              > Our customer is used to discuss, validate and accept user story
              > definitions based on high fidelity screens and prototypes, which demands
              > the UX people to work ahead of the developers, showing these prototypes
              > to the customer. Only after that, the Product Owner feels comfortable to
              > commit the story to the backlog.
              >
              > Is it acceptable for UX people to work ahead of the developers to
              > prepare and design the user interfaces and interactions of user stories
              > before the actual sprint where these stories will be built, or, ideally,
              > UX should always be working together with the developers on the same
              > stories in the same sprint?

              It's normal for UX to work ahead to help define the stories, but I think
              that developing high fidelity mockups and prototypes is wasted effort.
              Figuring out every last detail is not necessary before starting the
              story, and doing so often results in fragile implementations trying to
              hit "pixel perfect" rendition rather than something that will behave
              reasonably as browsers change.

              > The Product Owner feels comfortable working this way, as long as the
              > developers participate thru the whole process and the UX people support
              > the developers during the sprints, but I fear this might be a
              > sub-optimization of the process, although is hard to see it being done
              > any other way, specially because our customer is very attached to the UX
              > quality of the user interfaces.

              In what way do the UX people support the developers? Do they modify the
              designs as they're developed?

                  Totally agree with your scum comments  :-)

              > The PO likes to make an analogy with the auto industry, in the sense
              > that there is a product concept, design and prototyping phase of a car
              > (in which manufacturing engineers are also involved), before the actual
              > manufacturing phase, where engineers will then do most of the work
              > figuring out how to build the assembly line for that car. Is this a good
              > analogy?

              I think it's a great analogy. Your PO is choosing the GM strategy, of
              doing lots of up-front design because it takes months to change the
              tooling. The alternative is the Toyota strategy, of shaving tooling
              changes down to days, from months.

                  Don't follow you here at all.
                  Everyone does lots of up front design on new models.  Everyone.  It's their brand.  The models have to be new and exciting, yet familiar.  There's also the inevitable compromise in manufacture.  Prototypes are supposed to keep the creative juices flowing before the harsh realities of market forces take hold and all the innovative features of your wonderful prototype are watered down to fit the manufacturing schedules  :-)
                  At the risk of sounding condescending (I'm not, I'm just looking for some healthy debate), are you inadvertently clouding this topic with lean ideas?  Toyota have some great - and totally obvious (most great ideas are totally obvious when they're pointed out) - ideas on process control (but that doesn't mean they're right in all circumstances).  I'd be surprised if GM hadn't adopted some of these ideas (or would I? *!*ouch*!*).  Most manufacturers invest significantly in quality control and manufacturing efficiency.  When I was a mechanical engineering undergrad (and then post-grad) some years ago, we were taught the same kinds of things, except they weren't called lean.  Most large auto manufacturers aren't radically different in operation to each other.
                  [As another interesting (well, I think) point, when reading the lean book (as I'm sure you have), you can see parallels with scrum in that many adopters only did so because they were in crisis.]
              -R.

              - George


            • JC Grosjean
              Hi Demetrius, Communication, coordination and collaboration are the keys to integrate UX activites in Scrum teams. Actually I don t care if it is acceptable or
              Message 6 of 14 , Jul 28 2:39 AM
              • 0 Attachment
                Hi Demetrius,

                Communication, coordination and collaboration are the keys to integrate UX activites in Scrum teams. 
                Actually I don't care if it is acceptable or not, as an agile coach one of my goals is to make the "process" effective and valuable in context and to avoid wastes : working ahead is necessary most of the time .

                Agile is an interesting challenge for a UX specialist, a challenge both related to PO and Team activities. During a sprint, he has to design the content of next sprints (n+1, n+2) (needs analysis, storyboarding, wireframing...), collaborate with developers on the current sprint and usually evaluate results of the previous sprint (n-1) (with users/ stakeholders).

                Here is how I proceed as a coach and UX specialist. 
                A good starting point is to link UX activities with the user story readiness (and lifecycle). I ask the PO to to have the user stories he wants to include in a sprint, "80 % READY" for the sprint planning (Scrum ceremonial the first day of the sprint). 
                To do that: just enough UX & BA activities must be done (needs analysis, storyboarding, wireframing, business rules ...), and the MOST IMPORTANT I ask the PO and Team (with UX and testers) to have a specification workshop related to these specific stories, friday afternoon or monday morning (as they like) just before sprint planning. This collaborative workshop focused on examples, storyboarding and wireframing on the whiteboard to define together conditions of satisfaction of the user stories is crucial and usually well appreciated by people.
                Of course, it doesn't replace the collocation and the collaboration (Conversation) between PO, UX and Team during the sprint, mainly for adjustments and feedback. It is the remaining 20 % of the user story.

                I hope this helps

                Jean Claude

                Jean Claude GROSJEAN
                Agile Coach I UX Specialist
                Valtech Paris
                www.agile-ux.com (in english)
                www.qualitystreet.fr (in french only)



                2010/7/28 Peter Stevens (cal) <peterstev@...>
                 

                Hi Demetrius,

                I had a similar situation. Three teams: UX, UI and java. The UX and UI guys were filling a pipeline
                with screen shots which the java guys were supposed to implement.

                The UI team started doing Scrum first. Eventually they were so productive, that the customer/PO had
                to stop the team for 6 months until the Java people caught up. They never really did either, until
                they started doing Scrum too. So, first question: Are you producing an inventory of features waiting
                to be implemented? In this case, when the UI work resumed, many months later, they decided the
                pipeline was OK, but the UI team had to produce HTML/JavaScript templates with the java team would
                implement in the next sprint. By keeping the two teams in lockstep, it worked. (There were geography
                and language issues, which discouraged a collaboration directly in the sprint).

                I had another similar situation: One team developing a new UI to an existing application. We defined
                the application as User Stories, but needed to come up with an information architecture (IA). The
                stories defined what, and the IA described how (from the users point of view). The Product Owner was
                very interested in the IA. We went through multiple iterations with our best people working on the
                design, only to have the P-O redesign it once he saw it. (It reminded me of the letter writing
                example in Parkinson's Law: http://tinyurl.com/2vel7sb ). In this case, it was as much about control
                as about method.

                Perhaps the P-O thinks he is saving time and/or money by evaluating mock-ups rather than actual
                running systems. Maybe some experimentation with alternative approaches would be convincing.

                In general, I would suggest keeping your presentation layer as thin as possible and as decoupled
                from the application as possible so it is easy to change. A usability test with real users late in
                the project can really make a mess of your beautiful UI concept ...and your schedule ;-). I would
                look for signs of inventory accumulating, shortages of work, or excessive redesign. These indicate
                your process is wasteful. And I would try to find out why your P-O wants to work the way he does,
                then show him a better way to accomplish his goals...

                Hope this helps,

                Cheers,
                Peter



                On 28.07.10 00:44, Demetrius Nunes wrote:
                > Hi there,
                >
                > Our customer is used to discuss, validate and accept user story definitions
                > based on high fidelity screens and prototypes, which demands the UX people
                > to work ahead of the developers, showing these prototypes to the customer.
                > Only after that, the Product Owner feels comfortable to commit the story to
                > the backlog.
                >
                > Is it acceptable for UX people to work ahead of the developers to prepare
                > and design the user interfaces and interactions of user stories before the
                > actual sprint where these stories will be built, or, ideally, UX should
                > always be working together with the developers on the same stories in the
                > same sprint?
                >
                > The Product Owner feels comfortable working this way, as long as the
                > developers participate thru the whole process and the UX people support the
                > developers during the sprints, but I fear this might be a sub-optimization
                > of the process, although is hard to see it being done any other way,
                > specially because our customer is very attached to the UX quality of the
                > user interfaces.
                >
                > The PO likes to make an analogy with the auto industry, in the sense that
                > there is a product concept, design and prototyping phase of a car (in which
                > manufacturing engineers are also involved), before the actual manufacturing
                > phase, where engineers will then do most of the work figuring out how to
                > build the assembly line for that car. Is this a good analogy?
                >
                > Best regards,
                > Demetrius

                --
                Lean Agile Scrum Konferenz in Zürich mit Mary Poppendieck und Henrik Kniberg.
                Schlagen Sie die Brücke von Scrum Team bis zum schlanken Unternehmen!
                http://bit.ly/las-zh

                Peter Stevens, CSM, CSPO, CSP
                Independent Scrum Trainer and Coach
                Sierra-Charlie Consulting | Zurich | Switzerland

                Member of DasScrumTeam.de

                blog: http://scrum-breakfast.com
                tel: +41 44 586 6450
                cell: +41 79 422 6722
                skype: peterstev


              • Johannes Staffans
                I like the specification workshop idea. In my experience, it can take a while for the UX team to get with the program and align their work with the backlog.
                Message 7 of 14 , Jul 28 5:26 AM
                • 0 Attachment
                  I like the specification workshop idea. In my experience, it can take a while for the UX team to "get with the program" and align their work with the backlog. Starting out, our UX department would produce detailed mock-ups of different parts of the system without much regard to what the teams would actually be implementing in the coming sprints. Lots of wasted work was done, because a lot of the features for which analysis and mock-ups were made didn't even end up in the product.

                  It really is vital to get the UX people tightly involved, to make sure that they focus on what is most important: fleshing out the highest-priority stories for upcoming sprints and supporting the team in the current one (designs might have to change due to technical issues etc).

                  Regards,

                  Johannes Staffans




                  On Wed, Jul 28, 2010 at 11:39 AM, JC Grosjean <jcgrosjean@...> wrote:
                   

                  Hi Demetrius,


                  Communication, coordination and collaboration are the keys to integrate UX activites in Scrum teams. 
                  Actually I don't care if it is acceptable or not, as an agile coach one of my goals is to make the "process" effective and valuable in context and to avoid wastes : working ahead is necessary most of the time .

                  Agile is an interesting challenge for a UX specialist, a challenge both related to PO and Team activities. During a sprint, he has to design the content of next sprints (n+1, n+2) (needs analysis, storyboarding, wireframing...), collaborate with developers on the current sprint and usually evaluate results of the previous sprint (n-1) (with users/ stakeholders).

                  Here is how I proceed as a coach and UX specialist. 
                  A good starting point is to link UX activities with the user story readiness (and lifecycle). I ask the PO to to have the user stories he wants to include in a sprint, "80 % READY" for the sprint planning (Scrum ceremonial the first day of the sprint). 
                  To do that: just enough UX & BA activities must be done (needs analysis, storyboarding, wireframing, business rules ...), and the MOST IMPORTANT I ask the PO and Team (with UX and testers) to have a specification workshop related to these specific stories, friday afternoon or monday morning (as they like) just before sprint planning. This collaborative workshop focused on examples, storyboarding and wireframing on the whiteboard to define together conditions of satisfaction of the user stories is crucial and usually well appreciated by people.
                  Of course, it doesn't replace the collocation and the collaboration (Conversation) between PO, UX and Team during the sprint, mainly for adjustments and feedback. It is the remaining 20 % of the user story.

                  I hope this helps

                  Jean Claude

                  Jean Claude GROSJEAN
                  Agile Coach I UX Specialist
                  Valtech Paris
                  www.agile-ux.com (in english)
                  www.qualitystreet.fr (in french only)



                  2010/7/28 Peter Stevens (cal) <peterstev@...>

                   

                  Hi Demetrius,

                  I had a similar situation. Three teams: UX, UI and java. The UX and UI guys were filling a pipeline
                  with screen shots which the java guys were supposed to implement.

                  The UI team started doing Scrum first. Eventually they were so productive, that the customer/PO had
                  to stop the team for 6 months until the Java people caught up. They never really did either, until
                  they started doing Scrum too. So, first question: Are you producing an inventory of features waiting
                  to be implemented? In this case, when the UI work resumed, many months later, they decided the
                  pipeline was OK, but the UI team had to produce HTML/JavaScript templates with the java team would
                  implement in the next sprint. By keeping the two teams in lockstep, it worked. (There were geography
                  and language issues, which discouraged a collaboration directly in the sprint).

                  I had another similar situation: One team developing a new UI to an existing application. We defined
                  the application as User Stories, but needed to come up with an information architecture (IA). The
                  stories defined what, and the IA described how (from the users point of view). The Product Owner was
                  very interested in the IA. We went through multiple iterations with our best people working on the
                  design, only to have the P-O redesign it once he saw it. (It reminded me of the letter writing
                  example in Parkinson's Law: http://tinyurl.com/2vel7sb ). In this case, it was as much about control
                  as about method.

                  Perhaps the P-O thinks he is saving time and/or money by evaluating mock-ups rather than actual
                  running systems. Maybe some experimentation with alternative approaches would be convincing.

                  In general, I would suggest keeping your presentation layer as thin as possible and as decoupled
                  from the application as possible so it is easy to change. A usability test with real users late in
                  the project can really make a mess of your beautiful UI concept ...and your schedule ;-). I would
                  look for signs of inventory accumulating, shortages of work, or excessive redesign. These indicate
                  your process is wasteful. And I would try to find out why your P-O wants to work the way he does,
                  then show him a better way to accomplish his goals...

                  Hope this helps,

                  Cheers,
                  Peter



                  On 28.07.10 00:44, Demetrius Nunes wrote:
                  > Hi there,
                  >
                  > Our customer is used to discuss, validate and accept user story definitions
                  > based on high fidelity screens and prototypes, which demands the UX people
                  > to work ahead of the developers, showing these prototypes to the customer.
                  > Only after that, the Product Owner feels comfortable to commit the story to
                  > the backlog.
                  >
                  > Is it acceptable for UX people to work ahead of the developers to prepare
                  > and design the user interfaces and interactions of user stories before the
                  > actual sprint where these stories will be built, or, ideally, UX should
                  > always be working together with the developers on the same stories in the
                  > same sprint?
                  >
                  > The Product Owner feels comfortable working this way, as long as the
                  > developers participate thru the whole process and the UX people support the
                  > developers during the sprints, but I fear this might be a sub-optimization
                  > of the process, although is hard to see it being done any other way,
                  > specially because our customer is very attached to the UX quality of the
                  > user interfaces.
                  >
                  > The PO likes to make an analogy with the auto industry, in the sense that
                  > there is a product concept, design and prototyping phase of a car (in which
                  > manufacturing engineers are also involved), before the actual manufacturing
                  > phase, where engineers will then do most of the work figuring out how to
                  > build the assembly line for that car. Is this a good analogy?
                  >
                  > Best regards,
                  > Demetrius

                  --
                  Lean Agile Scrum Konferenz in Zürich mit Mary Poppendieck und Henrik Kniberg.
                  Schlagen Sie die Brücke von Scrum Team bis zum schlanken Unternehmen!
                  http://bit.ly/las-zh

                  Peter Stevens, CSM, CSPO, CSP
                  Independent Scrum Trainer and Coach
                  Sierra-Charlie Consulting | Zurich | Switzerland

                  Member of DasScrumTeam.de

                  blog: http://scrum-breakfast.com
                  tel: +41 44 586 6450
                  cell: +41 79 422 6722
                  skype: peterstev



                • George Dinwiddie
                  Robin, ... The ideas behind Lean and the ideas behind Scrum are not so very different. Both depend on shortening timelines to incorporate learning and enable
                  Message 8 of 14 , Jul 28 7:56 AM
                  • 0 Attachment
                    Robin,

                    On 7/28/10 3:58 AM, Robin Paterson wrote:
                    >> > The PO likes to make an analogy with the auto industry, in the sense
                    >> > that there is a product concept, design and prototyping phase of a car
                    >> > (in which manufacturing engineers are also involved), before the actual
                    >> > manufacturing phase, where engineers will then do most of the work
                    >> > figuring out how to build the assembly line for that car. Is this a good
                    >> > analogy?
                    >>
                    >> I think it's a great analogy. Your PO is choosing the GM strategy, of
                    >> doing lots of up-front design because it takes months to change the
                    >> tooling. The alternative is the Toyota strategy, of shaving tooling
                    >> changes down to days, from months.
                    >>
                    > Don't follow you here at all.
                    > Everyone does lots of up front design on new models. Everyone. It's
                    > their brand. The models have to be new and exciting, yet familiar.
                    > There's also the inevitable compromise in manufacture. Prototypes are
                    > supposed to keep the creative juices flowing before the harsh realities
                    > of market forces take hold and all the innovative features of your
                    > wonderful prototype are watered down to fit the manufacturing schedules :-)
                    > At the risk of sounding condescending (I'm not, I'm just looking for
                    > some healthy debate), are you inadvertently clouding this topic with
                    > lean ideas? Toyota have some great - and totally obvious (most great
                    > ideas /are/ totally obvious when they're pointed out) - ideas on process
                    > control (but that doesn't mean they're right in all circumstances). I'd
                    > be surprised if GM hadn't adopted some of these ideas (or would I?
                    > *!*ouch*!*). Most manufacturers invest significantly in quality control
                    > and manufacturing efficiency. When I was a mechanical engineering
                    > undergrad (and then post-grad) some years ago, we were taught the same
                    > kinds of things, except they weren't called lean. Most large auto
                    > manufacturers aren't radically different in operation to each other.
                    > [As another interesting (well, I think) point, when reading the lean
                    > book (as I'm sure you have), you can see parallels with scrum in that
                    > many adopters only did so because they were in crisis.]

                    The ideas behind Lean and the ideas behind Scrum are not so very
                    different. Both depend on shortening timelines to incorporate learning
                    and enable changing directions.

                    I'm in flight right now, so I can't look up the story, but from
                    memory... Car manufacturers have to decide how many of which cars to
                    produce. GM, and "most large auto manufacturers" spend a lot of effort
                    estimating this well in advance. It takes a lot of time to change the
                    tooling in their plants, so they want to minimize the changes. Toyota,
                    on the other hand, invested in making the tooling quicker and easier to
                    change. This has allowed them to react more quickly as the market
                    changes. When demand changes, they can switch to producing the vehicles
                    that are selling.

                    I see analogous behavior in UX designs. When the user interface is
                    designed /in detail/ on paper, then often they turn out to be more
                    difficult to realize (particularly for all browsers) than expected. The
                    designers can't incorporate what the developers learn from trying to
                    implement them, and the development costs go up as the development time
                    stretches out.

                    Whether you call it Scrum, Lean, Agile, or Sploosh, the point is to
                    shorten cycles, compare the results with desires, learn and adjust.

                    It seems to work much better when the UX design is done to the point
                    that the intent and general layout is clear, and the details are done
                    "just in time" with the collaboration of the designer and developer. A
                    great deal of learning happens. Equivalent, but cheaper, designs are
                    found. Degradation on old browsers is handled in the best possible
                    manner without side-lining development in producing exact duplicates on
                    browsers that don't support the whiz-bang features used to envision the
                    design.

                    - George

                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * http://blog.gdinwiddie.com
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • Robin Paterson
                    Hi George, ... Indeed. I just find it interesting (but, alas, understandable) that these things aren t adopted with great fervour until there s a crisis.
                    Message 9 of 14 , Jul 28 12:33 PM
                    • 0 Attachment
                      Hi George,

                      On 28/07/2010 15:56, George Dinwiddie wrote:
                       

                      Robin,

                      On 7/28/10 3:58 AM, Robin Paterson wrote:
                      >> > The PO likes to make an analogy with the auto industry, in the sense
                      >> > that there is a product concept, design and prototyping phase of a car
                      >> > (in which manufacturing engineers are also involved), before the actual
                      >> > manufacturing phase, where engineers will then do most of the work
                      >> > figuring out how to build the assembly line for that car. Is this a good
                      >> > analogy?
                      >>
                      >> I think it's a great analogy. Your PO is choosing the GM strategy, of
                      >> doing lots of up-front design because it takes months to change the
                      >> tooling. The alternative is the Toyota strategy, of shaving tooling
                      >> changes down to days, from months.
                      >>
                      > Don't follow you here at all.
                      > Everyone does lots of up front design on new models. Everyone. It's
                      > their brand. The models have to be new and exciting, yet familiar.
                      > There's also the inevitable compromise in manufacture. Prototypes are
                      > supposed to keep the creative juices flowing before the harsh realities
                      > of market forces take hold and all the innovative features of your
                      > wonderful prototype are watered down to fit the manufacturing schedules :-)
                      > At the risk of sounding condescending (I'm not, I'm just looking for
                      > some healthy debate), are you inadvertently clouding this topic with
                      > lean ideas? Toyota have some great - and totally obvious (most great
                      > ideas /are/ totally obvious when they're pointed out) - ideas on process
                      > control (but that doesn't mean they're right in all circumstances). I'd
                      > be surprised if GM hadn't adopted some of these ideas (or would I?
                      > *!*ouch*!*). Most manufacturers invest significantly in quality control
                      > and manufacturing efficiency. When I was a mechanical engineering
                      > undergrad (and then post-grad) some years ago, we were taught the same
                      > kinds of things, except they weren't called lean. Most large auto
                      > manufacturers aren't radically different in operation to each other.
                      > [As another interesting (well, I think) point, when reading the lean
                      > book (as I'm sure you have), you can see parallels with scrum in that
                      > many adopters only did so because they were in crisis.]

                      The ideas behind Lean and the ideas behind Scrum are not so very
                      different. Both depend on shortening timelines to incorporate learning
                      and enable changing directions.

                          Indeed.  I just find it interesting (but, alas, understandable) that these things aren't adopted with great fervour until there's a crisis.  I've certainly worked in places before where there's been a "lean drive" or "six sigma drive" or an "agile drive", and nobody at the coal face really cares, no matter how great they think the techniques are, because they know it's just a management  fad that will soon be forgotten until the next big thing.  The commitment just isn't there.  Unless (some) people are forced to change, they'll always find a reason why not to.


                      I'm in flight right now, so I can't look up the story, but from
                      memory... Car manufacturers have to decide how many of which cars to
                      produce. GM, and "most large auto manufacturers" spend a lot of effort
                      estimating this well in advance. It takes a lot of time to change the
                      tooling in their plants, so they want to minimize the changes. Toyota,
                      on the other hand, invested in making the tooling quicker and easier to
                      change. This has allowed them to react more quickly as the market
                      changes. When demand changes, they can switch to producing the vehicles
                      that are selling.

                      I see analogous behavior in UX designs. When the user interface is
                      designed /in detail/ on paper, then often they turn out to be more
                      difficult to realize (particularly for all browsers) than expected. The
                      designers can't incorporate what the developers learn from trying to
                      implement them, and the development costs go up as the development time
                      stretches out.

                         
                          I see exactly what you mean here, and I completely agree, but I still can't see the valid auto analogy.
                          If we were designing a car, then we could do it as designers and create a car with all the features that we wanted.  We could be as detailed as we wanted.  However, once manufacturing gets invlolved, we'd doubtless be informed that "this aspect can't be done", or "this design means a huge tooling change", or "this car will need this, this and this to be legal in the state of California", or "if that's what you want, then it'll take 48 months to set up production, and none of our other ranges will be able to share parts".  If we've already shown the prototype to our customer base, then someone's in for a disappointment.
                          However, if we design our car as a team, with a manufacturing rep/specialist with us, then we can avoid most of the issues above, right at the design stage.
                          I strongly disagree that once a prototype is built that everything revolves around it.  Engineering is a compromise.

                      Whether you call it Scrum, Lean, Agile, or Sploosh, the point is to
                      shorten cycles, compare the results with desires, learn and adjust.

                          I'm with you here 100%!


                      It seems to work much better when the UX design is done to the point
                      that the intent and general layout is clear, and the details are done
                      "just in time" with the collaboration of the designer and developer. A
                      great deal of learning happens. Equivalent, but cheaper, designs are
                      found. Degradation on old browsers is handled in the best possible
                      manner without side-lining development in producing exact duplicates on
                      browsers that don't support the whiz-bang features used to envision the
                      design.

                          OK, now JIT is something that was drummed into me at Uni - and this is going back quite a few years now, which is why I'm still in disagreement with the autos analogy.  The auto industry has had decades to refine its manufacturing techniques - some better than others - and I'm still of the opinion that an auto prototype may not look like the finished article once manufacturing realities are factored in.  Many prototypes don't incorporate basic features - AC, ICE, crash protection, all the global regulations on particular parts - and so it's inevitable that compromises will be made along the line.  I still think that this is a bad analogy (although, ultimately, all analogies break down eventually).
                          Again, I completely agree with everything else you've said here.
                          Having a UX team work on high fid screens no longer makes them prototypes - it's a finished article that the "other" team then has to implement.  The cross functional aspect is lost, customer expectation is already set, and the ability of scrum to react dynamically is lost (to a greater or lesser extent).

                          We seem to be in complete agreement about the Sploosh side of this, but disagree about the analogy.  Interesting  :-)

                      - George


                      -R.

                    • Wouter Lagerweij
                      Hi Demetrius, There s a lot of discussion in this thread already about how to approach this kind of situation, and I agree mostly with Jean Claude that it s
                      Message 10 of 14 , Jul 30 2:16 AM
                      • 0 Attachment
                        Hi Demetrius,

                        There's a lot of discussion in this thread already about how to approach this kind of situation, and I agree mostly with Jean Claude that it's best to link it to the backlog preparation (getting stories READY). 

                        But that probably won't get you out of this, as you'll have to convince your product owner that this will work as well or better then the current process. He seems (rightly) concerned with getting customer feedback early on, and thinks that can only be done using detailed screens and prototypes.
                        One way you could approach him (depending on the current results) is by asking if you can *increase* customer/stakeholder participation by doing more frequent feedback sessions with them, before *and during* the sprint. 
                        I realise that this is not always possible due to time contraints on the customer's side, but if you can try it, it should make it possible to integrate the UX work more into the sprint, and has the added bonus of making the work even more transparent to the customer.

                        Wouter




                        On Wed, Jul 28, 2010 at 12:44 AM, Demetrius Nunes <demetriusnunes@...> wrote:
                         

                        Hi there,

                        Our customer is used to discuss, validate and accept user story definitions based on high fidelity screens and prototypes, which demands the UX people to work ahead of the developers, showing these prototypes to the customer. Only after that, the Product Owner feels comfortable to commit the story to the backlog.

                        Is it acceptable for UX people to work ahead of the developers to prepare and design the user interfaces and interactions of user stories before the actual sprint where these stories will be built, or, ideally, UX should always be working together with the developers on the same stories in the same sprint?

                        The Product Owner feels comfortable working this way, as long as the developers participate thru the whole process and the UX people support the developers during the sprints, but I fear this might be a sub-optimization of the process, although is hard to see it being done any other way, specially because our customer is very attached to the UX quality of the user interfaces.

                        The PO likes to make an analogy with the auto industry, in the sense that there is a product concept, design and prototyping phase of a car (in which manufacturing engineers are also involved), before the actual manufacturing phase, where engineers will then do most of the work figuring out how to build the assembly line for that car. Is this a good analogy?

                        Best regards,
                        Demetrius
                        --
                        ____________________________
                        http://www.demetriusnunes.com


                      • Roy Morien
                        I am a little puzzled by this conversation. I just see the activity of preparing prototypes and mockups as just another way to detail the requirements. There
                        Message 11 of 14 , Jul 31 9:54 PM
                        • 0 Attachment
                          I am a little puzzled by this conversation. I just see the activity of preparing prototypes and 'mockups' as just another way to detail the requirements. There has been a rather common misconception among practitioners and authors that prototypes are always throw-aways. This is not true ... at least, this is not necessary. What is essentially wrong with defining the user interface in some detail ( the 'detailed screens) and thereby creating an Interface prototype possibly with links to other screens? Then when everyone agrees that this is pretty much what it should look like, you then start to fill in the background code. You can do this in a very Scrum way.
                           
                          The only argument that I can see against this, reasonably, is that the 'specification' manifested in the user interface prototype can become out of date, if it is done too early in the development project, before sufficient information has been gathered to ensure that this is in fact a good representation of final requirements.
                           
                          I see such interface prototypes as almost being an 'on screen' storyboard. I also see it as being very useful for gaining client acceptance, raising client confidence, and giving a very good impression that the project is going ahead knowledgeably ... but be careful that this is not a mirage.
                           
                          Regards,
                          Roy Morien
                           

                          To: scrumdevelopment@yahoogroups.com
                          From: wouter@...
                          Date: Fri, 30 Jul 2010 11:16:29 +0200
                          Subject: Re: [scrumdevelopment] UX role in Scrum teams

                           
                          Hi Demetrius,

                          There's a lot of discussion in this thread already about how to approach this kind of situation, and I agree mostly with Jean Claude that it's best to link it to the backlog preparation (getting stories READY). 

                          But that probably won't get you out of this, as you'll have to convince your product owner that this will work as well or better then the current process. He seems (rightly) concerned with getting customer feedback early on, and thinks that can only be done using detailed screens and prototypes.
                          One way you could approach him (depending on the current results) is by asking if you can *increase* customer/stakeholde r participation by doing more frequent feedback sessions with them, before *and during* the sprint. 
                          I realise that this is not always possible due to time contraints on the customer's side, but if you can try it, it should make it possible to integrate the UX work more into the sprint, and has the added bonus of making the work even more transparent to the customer.

                          Wouter




                          On Wed, Jul 28, 2010 at 12:44 AM, Demetrius Nunes <demetriusnunes@ gmail.com> wrote:
                           


                          Hi there,

                          Our customer is used to discuss, validate and accept user story definitions based on high fidelity screens and prototypes, which demands the UX people to work ahead of the developers, showing these prototypes to the customer. Only after that, the Product Owner feels comfortable to commit the story to the backlog.

                          Is it acceptable for UX people to work ahead of the developers to prepare and design the user interfaces and interactions of user stories before the actual sprint where these stories will be built, or, ideally, UX should always be working together with the developers on the same stories in the same sprint?

                          The Product Owner feels comfortable working this way, as long as the developers participate thru the whole process and the UX people support the developers during the sprints, but I fear this might be a sub-optimization of the process, although is hard to see it being done any other way, specially because our customer is very attached to the UX quality of the user interfaces.

                          The PO likes to make an analogy with the auto industry, in the sense that there is a product concept, design and prototyping phase of a car (in which manufacturing engineers are also involved), before the actual manufacturing phase, where engineers will then do most of the work figuring out how to build the assembly line for that car. Is this a good analogy?

                          Best regards,
                          Demetrius
                          --
                          ____________ _________ _______
                          http://www.demetriu snunes.com



                        • PeteCRuth@aol.com
                          In a message dated 7/31/2010 9:55:58 P.M. Pacific Daylight Time, roymorien@hotmail.com writes: I see such interface prototypes as almost being an on screen
                          Message 12 of 14 , Aug 1, 2010
                          • 0 Attachment
                             
                             
                            In a message dated 7/31/2010 9:55:58 P.M. Pacific Daylight Time, roymorien@... writes:
                            I see such interface prototypes as almost being an 'on screen' storyboard. I also see it as being very useful for gaining client acceptance, raising client confidence, and giving a very good impression that the project is going ahead knowledgeably ... but be careful that this is not a mirage.
                            Back when I started using prototypes and code generators to accelerate the development process, "real" developers complained that I wasn't playing by the rules. Now when I crank out a prototype to help the team visualize a particular approach, "real" developers complain that I'm not playing by agile rules or Scrum rules. The only group that has virtually never complained about my extensive use of prototypes are the actual users of the systems I build.  Of all the tools in my toolbox, prototypes have always been a very effective means of getting to what users really want. Not surprisingly, many of the prototypes find their way into the final code, and that's by design. So whether it's Scrum-but or Scrum-Butt, it works for my clients.
                             
                            Regards,
                             
                            Pete
                          • Roy Morien
                            I m with you all the way on this one, Pete. Let me recount a story about this situation. I wanted to be put on the list of system providors for a government
                            Message 13 of 14 , Aug 1, 2010
                            • 0 Attachment
                              I'm with you all the way on this one, Pete.
                               
                              Let me recount a story about this situation.
                               
                              I wanted to be put on the list of system providors for a government department. They asked me to show them what I could do ... proof of concept (that I knew what I was doing). So I asked them for the specs of a particular, not very large, system that they were putting out for EOI.
                               
                              Using my prototyping approach and code generators, I developed the system in a week, and took it back to the government department for evaluation. They were quite bewildered at first to see the system already up and running in a pretty complete form. In fact, they almost seemed a bit miffed that I had done it, almost as if I had already been given the nod to develop the system.
                               
                              Anyway, they looked at the system with interest, and nodded wisely, and seemed to be quite satisfied with my demonstration of competence and ability to deliver. The told me that they would 'be in touch'. I said, half jokingly, OK, if you pay me $10,000 now I will install the system and you can start using it now. This suggestion was met with some rather dubious looks, and I was asked to submit a formal proposal and quote. I did this, at a price of $10,000 with any follow up fees for extras and extensions, although the system basically already met all their specs. I was happy with $10,000 for a week's work.
                               
                              I didn't get the job! I heard that another contractor had been given the contract, for a price of $35,000. When I enquired about this, I was told that my system did not meet their standards ... the code did not meet their code standards, and because I had told them that there was no need to modify the code, just regenerate it if changes to the database or the user interface occured, I did not meet the contract requirements of providing source code that their programmers could modify.
                               
                              This happened a long time ago, and the contract price today would probably be 3 times that in today's dollars, so it wasn't a big job ... , although $100,000+ is not to be sneezed at. but the complete ignorance by the IT people then of prototyping, rapid development methods, code generators etc., was amazing. Unfortunately, that situation has not changed a lot in the intervening years.
                               
                              This was certainly not the only time that I met IT people who completely failed to understand about these things. I have also had the experience of 'prototype' systems being pounced on by enthusiastic users wanting immediate installation and use, and I had to put them off because I knew the system still lacked needed facilities. The users based their enthusiasm on what they could see.
                               
                              Lessons to be learned and passed on!
                               
                              Regards,
                              Roy Morien

                              To: scrumdevelopment@yahoogroups.com
                              From: PeteCRuth@...
                              Date: Sun, 1 Aug 2010 03:28:35 -0400
                              Subject: Re: [scrumdevelopment] UX role in Scrum teams

                               
                               
                               
                              In a message dated 7/31/2010 9:55:58 P.M. Pacific Daylight Time, roymorien@hotmail. com writes:
                              I see such interface prototypes as almost being an 'on screen' storyboard. I also see it as being very useful for gaining client acceptance, raising client confidence, and giving a very good impression that the project is going ahead knowledgeably ... but be careful that this is not a mirage.
                              Back when I started using prototypes and code generators to accelerate the development process, "real" developers complained that I wasn't playing by the rules. Now when I crank out a prototype to help the team visualize a particular approach, "real" developers complain that I'm not playing by agile rules or Scrum rules. The only group that has virtually never complained about my extensive use of prototypes are the actual users of the systems I build.  Of all the tools in my toolbox, prototypes have always been a very effective means of getting to what users really want. Not surprisingly, many of the prototypes find their way into the final code, and that's by design. So whether it's Scrum-but or Scrum-Butt, it works for my clients.
                               
                              Regards,
                               
                              Pete


                            • PeteCRuth@aol.com
                              I ve been down that road many times, Roy. What surprises me is that even now, it still happens fairly often. I ve mentioned before that my best clients are
                              Message 14 of 14 , Aug 1, 2010
                              • 0 Attachment
                                I've been down that road many times, Roy. What surprises me is that even now, it still happens fairly often. I've mentioned before that my best clients are usually either desperate or daring: they're either up against a looming deadline for a custom application system, or they're intrigued by the approach to "building" software in a fraction of the time it usually takes to do it themselves using more traditional methods. Of course, resistance to change is a hallmark of many fields, and software development is no exception. Scrum and other agile methods are good examples of this: while many Scrum practices have been in use for many years, when they got all rolled up into a comprehensive approach, many cried "foul". Go figure!
                                 
                                Regards,
                                 
                                Pete
                                 
                                In a message dated 8/1/2010 12:51:24 A.M. Pacific Daylight Time, roymorien@... writes:
                                 

                                I'm with you all the way on this one, Pete.
                                 
                                Let me recount a story about this situation.
                                 
                                I wanted to be put on the list of system providors for a government department. They asked me to show them what I could do ... proof of concept (that I knew what I was doing). So I asked them for the specs of a particular, not very large, system that they were putting out for EOI.
                                 
                                Using my prototyping approach and code generators, I developed the system in a week, and took it back to the government department for evaluation. They were quite bewildered at first to see the system already up and running in a pretty complete form. In fact, they almost seemed a bit miffed that I had done it, almost as if I had already been given the nod to develop the system.
                                 
                                Anyway, they looked at the system with interest, and nodded wisely, and seemed to be quite satisfied with my demonstration of competence and ability to deliver. The told me that they would 'be in touch'. I said, half jokingly, OK, if you pay me $10,000 now I will install the system and you can start using it now. This suggestion was met with some rather dubious looks, and I was asked to submit a formal proposal and quote. I did this, at a price of $10,000 with any follow up fees for extras and extensions, although the system basically already met all their specs. I was happy with $10,000 for a week's work.
                                 
                                I didn't get the job! I heard that another contractor had been given the contract, for a price of $35,000. When I enquired about this, I was told that my system did not meet their standards ... the code did not meet their code standards, and because I had told them that there was no need to modify the code, just regenerate it if changes to the database or the user interface occured, I did not meet the contract requirements of providing source code that their programmers could modify.
                                 
                                This happened a long time ago, and the contract price today would probably be 3 times that in today's dollars, so it wasn't a big job ... , although $100,000+ is not to be sneezed at. but the complete ignorance by the IT people then of prototyping, rapid development methods, code generators etc., was amazing. Unfortunately, that situation has not changed a lot in the intervening years.
                                 
                                This was certainly not the only time that I met IT people who completely failed to understand about these things. I have also had the experience of 'prototype' systems being pounced on by enthusiastic users wanting immediate installation and use, and I had to put them off because I knew the system still lacked needed facilities. The users based their enthusiasm on what they could see.
                                 
                                Lessons to be learned and passed on!
                                 
                                Regards,
                                Roy Morien


                                To: scrumdevelopment@ yahoogroups. com
                                From: PeteCRuth@aol. com
                                Date: Sun, 1 Aug 2010 03:28:35 -0400
                                Subject: Re: [scrumdevelopment] UX role in Scrum teams

                                 
                                 
                                 
                                In a message dated 7/31/2010 9:55:58 P.M. Pacific Daylight Time, roymorien@hotmail. com writes:
                                I see such interface prototypes as almost being an 'on screen' storyboard. I also see it as being very useful for gaining client acceptance, raising client confidence, and giving a very good impression that the project is going ahead knowledgeably ... but be careful that this is not a mirage.
                                Back when I started using prototypes and code generators to accelerate the development process, "real" developers complained that I wasn't playing by the rules. Now when I crank out a prototype to help the team visualize a particular approach, "real" developers complain that I'm not playing by agile rules or Scrum rules. The only group that has virtually never complained about my extensive use of prototypes are the actual users of the systems I build.  Of all the tools in my toolbox, prototypes have always been a very effective means of getting to what users really want. Not surprisingly, many of the prototypes find their way into the final code, and that's by design. So whether it's Scrum-but or Scrum-Butt, it works for my clients.
                                 
                                Regards,
                                 
                                Pete


                              Your message has been successfully submitted and would be delivered to recipients shortly.