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

Re: [agile-usability] Seeking Input: CreativeCommons ebook argues for extensive "Application Envisioning" (Iterations -1, 0) for knowledge work products

Expand Messages
  • William Pietri
    Hi, Jake. When I asked what you thought the right length for iteration zero is, I was looking for an amount of time. I m still curious as to your answer.
    Message 1 of 6 , Dec 9, 2008
    • 0 Attachment
      Hi, Jake. When I asked what you thought the right length for iteration zero is, I was looking for an amount of time. I'm still curious as to your answer.

      Broadly, it seems like you're addressing problems of a mixed Agile/non-Agile development team. And you're doing that in a way that moves in a direction of less agility.

      I think your concerns are great, but I think you can achieve the same or better results by being more Agile, not less. In particular, I think the habit of extensive up-front planning creates the problem of insufficient strategic thinking.

      That sounds weird, but here's what I think happens:
      1. A special group of people does a lot of research and design.
      2. Artifacts embodying the design are handed over. Maybe there's some continuity of personnel, maybe not.
      3. When the development starts, people work mainly off the backlog, following the plan.
      4. After a few iterations of this, people are out of the habit of doing research and design, and in the habit of following orders.
      5. New information comes in and is often ignored, as the analysis and phase is "done". Or worse, because people are working off a design backlog, neither releases nor research happen, so no new information comes in.
      6. Eventually, the team either runs out of inventoried designs or is forced to recognize that those designs are stale or wrong.
      7. At this point, the team is well off course, but has no practice in fixing that.

      When you get to that stage, there are several negative effects:
      • Either the big thinkers are elsewhere, or have gone so long without seriously thinking about the big picture that a new, large effort is required to get everybody thinking about strategy.
      • Because no research has been done in a while, starting research again is hard and awkward.
      • With no habit of responding to research, people are used to guessing, so getting research listened to is difficult.
      • Because people aren't used to changing the software, the software will be hard to change.

      Basically, teams get good at what they do, and they do what they're good at.  By creating a big inventory of research and design, you almost guarantee the teams will be less inclined to do more research or design when needed. And when they try, they won't be very good at it.

      Having tried it both ways, I favor solving this problem by being more Agile. That involves doing continuous research, continuous analysis, and continuous design. All alongside continuous development, testing, and releasing, naturally.


      You could be right that software is not as mutable as people hope. However, unless you've worked on a green-field project with a team experienced with all of the XP practices, and unless you do it in a way without a lot of design inventory at the beginning, I guarantee that software can be more mutable than you would expect.

      William

      Jacob Burghardt wrote:

       

      Hi William,

       

      Thanks for having a look at the “Working through Screens” ebook.  I am glad to hear that the basic idea of more research and design effort for knowledge work apps is hitting the mark for you.

       

      In response to your specific questions:

       

      “1. What do you see as the right length for an iteration zero?”

       

      I maintain that iteration zero ends when the team has generated a series of potential design strategies and sketched application concepts, and product and senior management has chosen one of them as the visualized vision for their application.  This could take more than one iteration, and the ideal length depends on the overall team’s knowledge of the domain and the complexity of their envisioned product.  The basic point is that the core product team has an opportunity to collaboratively dive into research and design in order to propose a number of compelling options for the larger vector, forms, and narratives of their product (with only as much detail as is needed to communicate their essential proposals). It is about getting to a shared idea and raw image of a product so that, going into iterative development, team conversations are much clearer, because the application idea has a defined skeleton to build out from. Perhaps not as important when the product is an iteration of a well known genre (e.g. an online calendar).  Potentially very important when teams are striving to mediate complicated knowledge work in new ways (e.g. an architect’s building information modeling application).

       

      “2. How is an extensive iteration zero different from the research and design segments of a phased process?”

       

      To state the obvious: products typically begin with a top level business and marketing strategy -- an initiating charter.  In the rationalization of software development, agile and otherwise, this charter is often broken into smaller pieces as soon as possible.  In that rationalization process, it is easy to skip a big picture understanding for what the experience of the product might be like, and to loose out on high value opportunities to consider the strategic implications of truly divergent concepts for that big picture.  So I’m arguing for an extensive “research and design” process *before* phased development commences, to then be continued within phased development. Industry changing innovation in knowledge work products can start with strategic opportunity hunting, larger reframing of approaches to work, and broader experience mapping – across the entirety of an offering.  Initiating charters can be valuably explored in tangible ways before development begins.

       

      “3. Why isn't the whole project a time for design research, exploration, and analysis in pursuit of a big picture?”

       

      It definitely is, but at a somewhat finer level.  In my experience, the band of truly strategic exploration of different user experience possibilities is relatively narrow once code gets started.  This is where I take issue with Agile doctrine: I believe that, in practice, due to real world constraints, software is rarely as mutable as many people claim.  And even when there is considerable mutability, it can be difficult to evolve a team’s deeply rooted mindset about their product when they are struggling to understand its complex and foreign domain.  Sketches and strategic models are a dime a dozen – its easier to consider radically different branches and genuinely explore meaningful ideation spaces when still working with quick representations.  I fully subscribe to the idea that too much documentation is a bad thing, but I think that shared visualizations of design strategy and experience concepts (selected from an ecosystem of potential choices) can be extremely high value.

       

      “I ask because personally I consider a formal iteration zero the sign of a company that still isn't fully agile. I've done it both ways, and I definitely prefer it when the first iteration is the first iteration.”

       

      This is exactly why I wanted to engage with the Agile-Usability community.  For the reasons described above, I maintain that this idea of fully agile is leading to lost opportunities for meaningful advancement in specialized knowledge work applications – tools that people use every day while practicing their chosen professions.

       

      Thanks again for your feedback and interest -- I truly appreciate it. Please do let me know what you think of these responses, if you have the time.

       

      Jake

       

      View .html version of full ebook:  http://www.flashbulbinteraction.com/WTS_opening.html  

      Download 11”X17” .pdf version of full ebook: http://www.flashbulbinteraction.com/Working_Through_Screens_Book.pdf (8.3 MB)

       


    • Jacob Burghardt
      William, Thank you for your thoughtful reply. You bring up some great points. Iteration zero length: I gave an open answer because there are a lot of
      Message 2 of 6 , Dec 10, 2008
      • 0 Attachment

        William,

         

        Thank you for your thoughtful reply.  You bring up some great points.

         

        Iteration zero length: I gave an open answer because there are a lot of variables at play (teams + product complexity).  Something concrete: I have worked with teams to collaboratively accomplish “application envisioning” exercises in ~3 intensive weeks.

         

        About the potential team problems that you described due to up front strategic thinking about user experience in an iteration zero:

         

        Let me say that I am a big believer in core teams, not the *start team* and the *finish team*.  You insightfully describe some issues that can stem from the transition from separate, big picture definers and designers to a larger software development team.  I find that while highly effective teams may grow as they move forward to deliver value, they generally do not place an emphasis on handing off batons.

         

        “Extensive up-front planning creates the problem of insufficient strategic thinking”

        That’s a very interesting idea.  I agree that if a team is handed a design strategy and application concept that feels monolithic and complete, they may feel that there is nothing left for them to think about in a strategic way over the course of bringing a knowledge work application to life.  That definitely would be a problem, as these design problems are often multi-faceted and exceedingly complex – but it is not what I’m suggesting for “application envisioning.” 

         

        In my view, a compelling output of iteration zero (or whatever a team chooses to call their early envisioning phase) presents the larger vector, conceptual forms, and narratives of a product in a way that:

         

        1) Is inspiring, not belittling. It communicates clear value and strategic rationale, actually instilling a desire to make the product an implemented reality.

        2) Is visibly changeable and incomplete.  It is a sketch that communicates the essential ideas of targeted user experiences, but does not draw a tightly confined box around the specifics of the outcome.

         

        I do not have examples that I can share of what I mean – a consultant’s dilemma that I will try to remedy soon.  However, I believe that the above two points reduce the likelihood of the cultural norm you describe where up front, strategic research and design lead to a sense of R&D completion or skill rustiness when it comes time to apply this mindset to Agile iterations.

         

        I have worked with several high quality Agile teams. However, I think it’s safe to say that I have not worked in a “green-field project with a team experienced with all of the XP practices.”  I will start benchmarking teams I come into contact with against this standard to see if it changes my perspective on how best to arrive at truly innovative, useful, and meaningful knowledge work applications.

         

        Building on the “Working through Screens” e-book (http://tinyurl.com/67lvoz), I plan on putting together a publication that is more procedural and has concrete examples of potential deliverables.  I look forward to following up with you at that point to see what you think! 

         

        Until then, I hope that the 100 envisioning ideas in “Working through Screens” – many of which are also applicable to research and design within Sprints – provide some measure of value to the Agile-Usability community.

        Best,

        Jake 

        Jacob Burghardt
        Principal Consultant
        Flashbulb Interaction, Inc.
        "Driving vision at the forefront of knowledge work user experiences"
        E: jburghardt@...    
        W: www.FlashbulbInteraction.com  
        LinkedIn: http://www.linkedin.com/in/jacobburghardt

         

         

      • William Pietri
        Thanks for your reply, Jacob. Suppose your ideal team went through the inception process you describe, and then threw away all the artifacts. Would that
        Message 3 of 6 , Dec 12, 2008
        • 0 Attachment
          Thanks for your reply, Jacob.

          Suppose your ideal team went through the inception process you describe, and then threw away all the artifacts. Would that provide roughly equivalent value?

          I ask because it sounds like you mainly value the exploration and thinking. Getting rid of the artifacts (or, for the nervous, locking them in a vault or something) would reduce the risks caused by large design inventories, personnel transitions, and HiPPO distortions.

          William

          Jacob Burghardt wrote:

          William,

           

          Thank you for your thoughtful reply.  You bring up some great points.

           

          Iteration zero length: I gave an open answer because there are a lot of variables at play (teams + product complexity).  Something concrete: I have worked with teams to collaboratively accomplish “application envisioning” exercises in ~3 intensive weeks.

           

          About the potential team problems that you described due to up front strategic thinking about user experience in an iteration zero:

           

          Let me say that I am a big believer in core teams, not the *start team* and the *finish team*.  You insightfully describe some issues that can stem from the transition from separate, big picture definers and designers to a larger software development team.  I find that while highly effective teams may grow as they move forward to deliver value, they generally do not place an emphasis on handing off batons.

           

          “Extensive up-front planning creates the problem of insufficient strategic thinking”

          That’s a very interesting idea.  I agree that if a team is handed a design strategy and application concept that feels monolithic and complete, they may feel that there is nothing left for them to think about in a strategic way over the course of bringing a knowledge work application to life.  That definitely would be a problem, as these design problems are often multi-faceted and exceedingly complex – but it is not what I’m suggesting for “application envisioning.” 

           

          In my view, a compelling output of iteration zero (or whatever a team chooses to call their early envisioning phase) presents the larger vector, conceptual forms, and narratives of a product in a way that:

           

          1) Is inspiring, not belittling. It communicates clear value and strategic rationale, actually instilling a desire to make the product an implemented reality.

          2) Is visibly changeable and incomplete.  It is a sketch that communicates the essential ideas of targeted user experiences, but does not draw a tightly confined box around the specifics of the outcome.

           

          I do not have examples that I can share of what I mean – a consultant’s dilemma that I will try to remedy soon.  However, I believe that the above two points reduce the likelihood of the cultural norm you describe where up front, strategic research and design lead to a sense of R&D completion or skill rustiness when it comes time to apply this mindset to Agile iterations.

           

          I have worked with several high quality Agile teams. However, I think it’s safe to say that I have not worked in a “green-field project with a team experienced with all of the XP practices.”  I will start benchmarking teams I come into contact with against this standard to see if it changes my perspective on how best to arrive at truly innovative, useful, and meaningful knowledge work applications.

           

          Building on the “Working through Screens” e-book (http://tinyurl.com/67lvoz), I plan on putting together a publication that is more procedural and has concrete examples of potential deliverables.  I look forward to following up with you at that point to see what you think! 

           

          Until then, I hope that the 100 envisioning ideas in “Working through Screens” – many of which are also applicable to research and design within Sprints – provide some measure of value to the Agile-Usability community.

          Best,

          Jake 

          Jacob Burghardt
          Principal Consultant
          Flashbulb Interaction, Inc.
          "Driving vision at the forefront of knowledge work user experiences"
          E: jburghardt@...    
          W: www.FlashbulbInteraction.com  
          LinkedIn: http://www.linkedin.com/in/jacobburghardt

           

           


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