Agile Design - Chicago IXDA Presentation
Upcoming SlideShare
Loading in...5
×
 

Agile Design - Chicago IXDA Presentation

on

  • 1,422 views

a description of how I incorporate design and development in an agile method

a description of how I incorporate design and development in an agile method

Statistics

Views

Total Views
1,422
Slideshare-icon Views on SlideShare
1,407
Embed Views
15

Actions

Likes
3
Downloads
0
Comments
0

3 Embeds 15

http://www.linkedin.com 11
https://www.linkedin.com 3
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • A typical waterfall project produces page after page documenting the end-to-end requirements for the entire project -- not for the phase or for the iteration but for the entire project. All of this work, of course, is done in a silo with only the most cursory involvement with development.
  • Once all 9,238 lbs. are heaved over the wall at the handoff meeting with a cheery “good luck!”, the silos are once again inhabited and silence is golden.
  • Whether the application is being implemented as designed is the big mystery until the final unveiling n months later. Unless you are one of those fortunate designers who’s embedded in a development team and is, therefore, accessible for questions. But those types were rare.
  • While agile was taking hold of development, design was still stuck in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements.
  • A great idea, I thought. But first I need to look into exactly what is it about Agile teams that makes them tick. And how can that translate to design.
  • Well, the individuals with overlapping skills idea ties in with Tim Brown’s T-shaped people. Actually, it suits it to a “T” (ahem). And designers, like developers, are rarely one-dimensional and like flexing their creative muscles.
  • So, blending Agile and UxD means we’re still using the same tools (task flows, wireframes, etc.) but we’re no longer separated from other team members and we’re designing as we go along. Sounds like a plan!
  • The upside is that we now have a larger role in the overall project -- the rigid assembly line definition of requirement > designer > dev is losing it’s rigidity. The downside, if you can even call it that, is that as a designer you have to live with levels of uncertainty because you’re designing as the project progresses and sometimes there will be unknowns that will remain unknowns.
  • Theory’s great but let’s get practical here.
  • At Pathfinder, we do user driven software development which means the users’ needs and requirements define the features needed for the application. So much more accurate than throwing darts on a board or gazing into a crystal ball.
  • User research yields user modeling; user modeling, in turn, informs data modeling. But it’s of no use if the research is ignored by the developers. Integrating design into the entire SDLC meant creating meaningful documentation. I’ve had very good luck diagramming personas in a UML style, which is a language most developers are comfortable with.
  • And a tenet of Agile is user stories. I take the high-level needs of the personas and begin to diagram out the tasks. I also start to write the user stories for each tasks -- again, at a high level but at this point in the project, that’s all that is needed in order to get an idea of the overall scope of the project.
  • Our high-level user stories generate the Feature List. Now we can start scoping the project and determining what needs to be built and when it can be built -- iteration planning. Once that is accomplished, we start writing requirements, but only for the features slated for development in the upcoming iteration.
  • A feature, in our world, is something that can be developed in one iteration, regardless of how your team defines the length of an iteration. A feature page explains the design of that feature.
  • Each feature page has the above listed sections -- examples follow.
  • Our user stories state the user needs and the business benefit from meeting that need. Acceptance tests, which are written as scenarios and based off the user stories, define when a feature is complete, i.e., when all the defined scenarios are met. If a scenario is not defined, it is not a part of the feature that’s being developed for this iteration.
  • User workflows should diagram the end-to-end flow for the feature. Sometimes a workflow can only be drawn with other features in the flow. If that’s the case, those areas need to be denoted as not being in this feature, to be developed later, etc. Some sort of indication that it’s in the flow to be helpful but not to be developed at this time.
  • The wireframe shows the screen layout and the annotations note the various widget behaviors.
  • Functional specifications describe how a feature will work and are written entirely from the user’s perspective.
  • The last line is the most important benefit in my book. Instead of being shuttled off to the side or having only a brief involvement, designers are now an integral part of the team throughout the entire life of the project.
  • Once you get out of the silo, you realize you have much more room to play.

Agile Design - Chicago IXDA Presentation Agile Design - Chicago IXDA Presentation Presentation Transcript

  • AGILE AND ME a story with just enough documentation
  • A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department.
  • After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.
  • ? While agile was taking hold of development, design was still back in the waterfall method. So why not blend the two and run the entire project in an agile fashion, starting with requirements.
  • AGILE DESIGN in theory
  • Individuals with Overlapping Skills Agile teams are self-organizing and highlight TRANSLATING AGILE METHODS TO DESIGN
  • T
    • Tim Brown from IDEO talks about “T-shaped People” as those who have a core competency but branch out into other areas and can do them well (thus forming a T).
    Shaped Being OVERLAPPING SKILLS = T-SHAPED PEOPLE
  • UxD in an agile world
    • Still using the same tools (wireframes, etc.)
    • BUT ....
    • Project team is not divided into silos
    • Everything isn’t designed up front
    • Using more than your base skillset
  • UxD in an agile world
    • PROS ...
    • Expanding your project role
    • & involvement throughout entire SDLC
    • CONS ...
    • how is your comfort level with uncertainty?
  • AGILE DESIGN in practice
  • insert uxd at the beginning
    • User Driven requirements
      • Who is using the product?
      • What do the users require?
      • What does the business require?
      • What does development require?
  • DIAGRAMs THAT DEVELOPERS UNDERSTAND
    • User research yields user modeling; user modeling, in turn, informs data modeling. But it’s of no use if the research is ignored by the developers. Integrating design into the entire SDLC meant creating meaningful documentation that your audience can relate to.
  • tasks TO USER STORIES
    • As a General User associated with a Host Company, I need to be able to:
      • create new reports and be able to save them so I can easily access them in the future (or delete them)
      • have a list of standard reports that I can quickly run but can also modify/filter the results
      • be able to view contractors who have completed PQF
      • specify the orientation requirements for a contractor employee
    Expand your activity diagram to show subtasks and begin associating user stories with the persona.
  • from Personas to development
    • User Stories yield:
    • > User Driven Feature List
    • > Project Scope Determined
    • > Iterations Scheduled
    • > Iteration 0 begins:
            • start designing features for iteration 1
            • this is where feature design begins
  • DESIGNING A FEATURE just enough documentation
  • Iteration 0
    • For each feature in an iteration:
      • User Stories to be developed in that iteration
        • stating user needs and business goals
      • Acceptance Tests
        • defines when a feature is complete
      • Workflow Diagrams
        • diagrams the user path when completing tasks for this feature
      • Annotated Wireframes
        • what does the screen look like
        • what are the screen behaviors
      • Functional Specifications
        • describes how the feature will work from user’s perspective
  • Feature a - stories & tests User stories state the feature’s user needs and the business benefits. Acceptance tests, which are written as scenarios and based off the user stories, define when a feature is complete. If a scenario is not defined, it is not a part of the feature that’s being developed for this iteration.
  • Feature a - Workflow diagram Workflows diagram the end-to-end flow for the feature. If a section of the flow is out of scope for the current iteration or for this feature but needs to be in the flow for clarity, include it in the diagram but note that it’s out of scope for this iteration.
  • feature a - ANNOTATED WIREFRAMES Annotations note behavior of various elements on the page.
  • feature a - functional specs Functional specs describe how a feature will work and are written entirely from the user’s perspective. Functional specs only describe the work for that iteration
  • AGILE DESIGN in summary
  • UxD in an agile world means:
    • Not being in a silo
    • Not staying behind a wall
    • Designing as features are developed
    • Collaborating and Iterating as project progresses
    • Having an active voice throughout entire SDLC
  • Agile UXD : Your sandbox just got a whole lot bigger
  • ALICE TOTH senior consultant, uxd [email_address]