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

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

Expand Messages
  • Jacob Burghardt
    (Apologies for limited cross posting) I have recently posted a free, CC ebook online that may be of interest to the Agile-Usability community (links at bottom
    Message 1 of 6 , Dec 7, 2008
    • 0 Attachment

      (Apologies for limited cross posting)

       

      I have recently posted a free, CC ebook online that may be of interest to the Agile-Usability community (links at bottom of this message)

       

      ”Working through Screens: 100 Ideas for Envisioning Powerful, Engaging, and Productive User Experiences in Knowledge Work”

       

      In the introduction of the book, I argue that complex, specialized products for knowledge work present challenges that are different than many other product development situations.  For a variety of reasons, I maintain that teams seeking to advance these tools in compelling, valuable, and innovative ways should not dive into iterative development without a visualized understanding of the design strategy and primary user experience scenarios of their intended offerings.

       

      Let me make clear: I am no way arguing for exhaustive, up front documentation.  I recognize the value of the Agile mindset and processes (that’s why I am starting this thread).  However -- for many knowledge work applications -- I believe that “iteration zero” (or -1, or whatever a team chooses to call their earliest phase) should be an extensive, elaborative time for design research, exploration, and analysis in order to arrive at a shared “big picture” vision that is much more expressive and comprehensible than a product’s high level, initiating charter.

       

      Some excerpts from the free eBook:

       

      “Do not assume that a compelling knowledge work tool will arise solely from the iterative aggregation of many discrete decisions during the long haul of a product development process. Create a divergent ecosystem of concepts for your product’s big picture and primary experiences… Explore a breadth of directions and strategies before choosing a course. Plan on staying true to the big ideas imbedded in the concepts that your team selects, while knowing that those ideas will evolve along the way to becoming a reality.”

       

      “At the end of a knowledge work product’s initiating conversations, when it appears that a project will become a funded and staffed reality, there is often a strong desire from all involved to see “something” other than high level abstraction and textual description. The common response to this desire is where foundational user experience problems begin to crystallize. In a characteristic *straight to the details progression*, teams quickly, instinctually move from high level consideration of product strategy into the smallest specifics of a product’s definition, design, and implementation. Their approach jumps abruptly from the global to the extremely granular, without the connective

      tissue of a holistic middle ground.”

       

      “I believe that current deficiencies in technologies for knowledge work are strongly tied to our often low expectations of what it can mean to support complicated activities with computing. Our shared ideas of what constitutes innovation in this space have, in many cases, become tightly constrained by our infrastructural sense of what these technologies can and should be. Too often, we are not seeing the proverbial forest due to our shared focus on a small grove of trees. In our cultural accommodation to what computing has come to “mean” in our working lives, it seems that we may have lost some of our capacity for visionary thinking.”

       

      “When technologists find it difficult to understand the many specifics of foreign and elaborate work practices, they may unwittingly hold onto an initial, roughly hewn, consensus view about knowledge workers’ activities and needs. This view can become their framing point of reference throughout the development of their product, despite incoming information that could valuably transform it. In practice, the momentum of a disoriented group’s initial concept for their computing tool often places certain ideas at the primary, driving core of what is eventually developed and released.”

       

       

      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)

       

      Very curious to hear any input that the Agile-Usability community might have on these ideas!

       

      Best regards,

       

      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
      Hi, Jacob! I ve taken a quick peek, and that looks very appealing. I ve got it on my list of things to read through properly. I definitely agree with your
      Message 2 of 6 , Dec 8, 2008
      • 0 Attachment
        Hi, Jacob!

        I've taken a quick peek, and that looks very appealing. I've got it on my list of things to read through properly. I definitely agree with your basic thesis, that a lot of knowledge-work apps could be vastly improved through more research and more attention paid to design.

        For now, though, I have a few questions about this:

        Jacob Burghardt wrote:

        Let me make clear: I am no way arguing for exhaustive, up front documentation.  I recognize the value of the Agile mindset and processes (that’s why I am starting this thread).  However -- for many knowledge work applications -- I believe that “iteration zero” (or -1, or whatever a team chooses to call their earliest phase) should be an extensive, elaborative time for design research, exploration, and analysis in order to arrive at a shared “big picture” vision that is much more expressive and comprehensible than a product’s high level, initiating charter.


        In particular I'm wondering:
        1. What do you see as the right length for an iteration zero?
        2. How is an extensive iteration zero different from the research and design segments of a phased process?
        3. Why isn't the whole project a time for design research, exploration, and analysis in pursuit of a big picture?

        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.

        William

      • Jacob Burghardt
        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
        Message 3 of 6 , Dec 9, 2008
        • 0 Attachment

           

          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)

           

        • 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 4 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 5 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 6 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.