Are Agile Projects Doomed to Half-Baked Design?

Download Are Agile Projects Doomed to Half-Baked Design?

Post on 19-Oct-2014




0 download

Embed Size (px)


Today's web-based applications go live every few weeks. Agile methodologies like Extreme Programming and Scrum, focus on short development cycles, accelerated feedback from users and customers, and incremental delivery. On the technical side these approaches can bring discipline and predictability to short release cycles. But can these incremental methodologies incorporate successful design techniques? Using case studies and examples from their own project experience, Alex and Leslie will discuss how to integrate design and Agile, discussing what works, what problems arise, and most importantly, the changes in mindset that are necessary on an integrated Agile design/implementation team.


<ul><li><p>Are Agile Projects Doomed to Half-Baked Design?</p><p>Alex Chaffee<br /><br /></p><p>Leslie Chicoine<br /><br /></p></li><li><p>Introduction</p><p>What is Design<br />What is Coding<br /><br />XP and Agile Programming<br /><br />Agile Design: How to merge Agile processes and design principles<br /><br />Q&amp;A</p></li><li><p>Web 2.0 = </p><p>?</p></li><li><p>Web 2.0 = </p><p>play</p></li><li><p>Web 2.0 = </p><p>play faster</p></li><li><p>Design Methods</p><p>Design</p><p>Start by defining design. Its a pretty big word.</p></li><li><p>Strategy</p><p>Graphics</p><p>User Centered</p><p>Front End Coding</p><p>User Interface</p><p>Information Architecture</p><p>Interactive</p><p>Interaction</p><p>Research</p><p>User Flow</p><p>Concepts</p><p>Design Methods</p><p>Design</p><p>Part of the reason its so big is all the possible outcomes, and this is how people normally talk about it. But every project has different outcome needs, and every team has different skill sets. So it make it hard to talk about design or prescribe it as these things.</p></li><li><p>I design.</p><p>Design Methods</p><p>A state of acting, a mode of thinking, and really everyone is a designer. So the person with the title is in charge of fostering the design or a project, and staying in that mind set when others may need to delve deeply into their own domains.</p></li><li><p>Research</p><p>Thought</p><p>Modeling</p><p>Communication</p><p>Play</p><p>Re-design</p><p>Design Methods</p><p>I design.</p><p>That mind set is about doing these kinds of things. And its these kinds of things that get an incredible boost from Agile Development. So Im going to go into more specific about these in a moment.</p></li><li><p>Coding</p><p>Coding Methods</p></li><li><p>Model-View-Controller</p><p>Databases</p><p>JavaScript</p><p>Java</p><p>Debugging</p><p>CSS</p><p>Version Control</p><p>IDEs</p><p>Research</p><p>Coding</p><p>Ruby</p><p>Design Patterns</p><p>UML Diagrams</p><p>Deploying</p><p>Perl</p><p>Object-Oriented Design</p><p>Best Practices</p><p>Scripting</p><p>Coding Methods</p></li><li><p>I code.</p><p>Coding Methods</p></li><li><p>I code.</p><p>Research</p><p>Thought</p><p>Modeling</p><p>Communication</p><p>Play</p><p>Re-design</p><p>Coding Methods</p><p>Coding is a creative act. A lot bad processes have come up by not recognizing this fact. For example, doing implementation in phases, pulling people from one project to another without context, and working in separate geographic locations. You have to be able to iterate, to play. You have to be able to traverse all of the levels.</p></li><li><p>Design is finding the problem, not the solution.<br />Leslie Chicoine</p><p>The Big Idea</p></li><li><p>The hard problems are</p>people problems(mis-) communication(not enough) feedback(not fully) comprehending constraintsprocess problemsdeadline and resource managementdesign flexibility in the face of frequent change<p>Where can we find a people-oriented process, and process-oriented people?</p></li><li><p>Extreme Programming is an Agile Process</p>Motto: Embrace ChangeOther Agile Processes include Scrum, Crystal Clear, Adaptive Software Development, Feature Driven Development, DSDM, Agile Modeling<p>XP Defined</p></li><li><p>Extreme Programming is an Agile Process</p>Values<p>Feedback</p><p>Communication</p><p>Simplicity</p><p>Courage</p><p>XP Defined</p></li><li><p>XP Practices</p><p>Collective Ownership</p><p>Pairing</p><p>Continuous Improvement</p><p>Continuous Integration</p><p> testing</p><p>refactoring</p><p>simple design</p><p>High code quality</p><p>Sustainable Pace</p><p>On-site Customer</p><p>design by discussion</p><p>frequent spontaneous </p><p>working sessions</p><p>Suggest and agree to process changes</p><p>Ask the room</p><p>Dont be stupid.</p><p>retrospectives</p><p>Incremental design, development, deployment</p><p>Weekly demos</p><p>XP Practices</p></li><li><p>XP Cycles</p>Rapid Iteration, small releasesFrequent planning/design sessionsIteration Planning, Release PlanningBreak down requirements into stories into tasksDaily StandupRegular All-Hands RetrospectivesFrequent (weekly) demosof deployed, 100% functional softwarereal code, real db, real ui, but only some of the storiescoders, clients, designers, PMs are all in the room<p>XP Cycles</p></li><li><p>XP Meets Waterfall Design</p><p>Extreme <br />Programming</p><p>Waterfall <br />Design</p></li><li><p>XP Meets Waterfall Design</p><p>Extreme Programming</p><p>Waterfall Design</p><p> </p><p></p></li><li><p>XP Meets Waterfall Design</p><p>Results of the washing machine are better, so how do we turn that stream into a machine?</p></li><li>The three things we do in XP that any team should do<p>Weekly demos</p><p>Daily standups</p><p>Pairing</p><p> Caution: May provoke resistance and hostility</p><p>XP Staples</p><p>Weekly demos cause resistance since people want to keep working -- either they chose too big a chunk to get done in a week, or they want to keep working on it until its perfect.</p><p>Daily standups cause resistance since people want to get in late, or theyre unwilling to ask for help or give it.</p><p>Pairing causes resistance since people feel like theyll be judged, or wont get credit, or theyre more comfortable, or productive, working alone.</p><p>But XP is about getting outside your comfort zone, and about whats best for the team</p></li><li><p>Agile Design</p><p>Agile Design</p></li><li><p>Plans are useless, but planning is indispensable.<br />-Dwight D. Eisenhower</p><p>Agile Design</p><p>The mind set.</p></li><li><p>Embracing change<br /><br />Communal design ownership<br /><br />Evolving solutions</p><p>Agile Design</p><p>Agile design is about being comfortable with embracing lots of on going changes, and sharing the ownership over designs with a whole team because this is how you evolve solutions and create a great project.</p><p>Unlike the Architecture metaphor we hear so often (this analogue collapses at the blue prints) we get to test our assumptions as we go. So really Agile is more akin to putting on a play or creating a movie</p></li><li><p>Agile Design</p><p>A great example is The Incredibles. I highly recommend going and renting this DVD and checking out The Making of extras section.</p></li><li><p>Agile Design</p><p>The major take away about how the multidisciplinary team works together to evolve the project.</p></li><li><p>Make it OK for people to challenge an idea or two, the good ideas can withstand it and the weaker ideas fall away and make room for something [better]. <br /><br />-Brad Bird, Writer/Director of the Incredibles</p><p>Agile Design</p><p>They created an environment where open discussion and opinions are welcome and where its OK to challenge ideas because as Brad Bird says The good ideas can withstand those challenges and the weaker ideas fall away.</p></li><li><p>Hell take good ideas from wherever they come from. <br /><br />He asks you, he wants to know what you think.</p><p>Agile Design</p><p>The team talks about how Brad Bird creates this environment and we can all learn to do the same. To take ideas from everyone on the team and to ask people what they think. Asking questions and providing people information is really key to this kind ofopen and Agile environment.</p></li><li><p>Scales of Design</p><p>Scales of Design</p><p>To frame this Im going to talk about the Scales of Design.</p></li><li><p>Concept<br />Business Goals<br />User Tasks / Motivations<br />Site Flow &amp; Wayfinding<br />Supporting Systems<br />Navigation<br />Widgets<br />Global Styles<br />Language<br />Buttons <br />Graphics<br />Fonts</p><p>Large Scale</p><p>Small Scale </p><p>Scales of Design</p><p>Similar to waterfall there are scales of an project. But were going to look at it from a slightly different lense.</p></li><li><p>The Large Scale is tested in the Small Scale. <br /><br />The Small Scale reveals if the Large Scale ideas are solid.</p><p>Scales of Design</p><p>By sliding up and down the scales you create a valuable feedback loop that informs the direction of the design.</p></li><li><p>Play faster.</p><p>Scales of Design</p><p>Take for example the Navigation for my company Satisfaction. Soon after we felt we had gotten a good pass over the concepts we started trying to break tasks out into tabs as you can see on the first rough top version.</p></li><li><p>Play faster.</p><p>Scales of Design</p><p>We delved down deeper using that top version to the page level but soon realized we trying to do two things on one page, so we broke it out and re-did the navigation. In the meantime we revisited the Large Scale business goals and realized that we didnt need Moderation, and hense</p></li><li><p>Play faster.</p><p>Scales of Design</p><p>Didnt need a space for that task. Soon we had a running code version, and at that point we started arguing about the wording of the Navigation. </p></li><li><p>Play faster.</p><p>Scales of Design</p><p>We added a few more sections, and still couldnt get the wording right. One set of words reflected where you could go, and the other reflected where you are. This led us to step up a Scale.</p><p>So we looked at our Scales again and noticed that on the page level the headers did the job of telling us where you are. So we going to remove that function from the navigation entirely.</p><p>And in fact it looks like we are going to kill the navigation all together. This stems from new iterations on the business model and concept Scale.</p></li><li><p>Concept<br />Business Goals<br />User Tasks / Motivations<br />Site Flow &amp; Wayfinding<br />Supporting Systems<br />Navigation<br />Widgets<br />Global Styles<br />Language<br />Buttons <br />Graphics<br />Fonts</p><p>Large Scale</p><p>Small Scale </p><p>Scales of Design</p><p>So its really important to frame problems in the various scales.</p></li><li><p>Problems vs. Solutions</p><p>Problems vs. Solutions</p></li><li><p>Design is finding the problem, not the solution.</p><p>Problems vs. Solutions</p><p>The big idea from earlier. The best way to do this is</p></li><li><p>Documents as communication space<br /><br />Not as blueprints</p><p>Problems vs. Solutions</p><p>Is to view the wireframes and documents as communication spaces for your team, not as blueprints to be handed down from on high.</p></li><li><p>Problems vs. Solutions</p><p>An example of this in practice is the Satisfaction Boards. The point of this space is to provide a space to talk about all the Scales and especially the resoning behind decisions. This is a very tangible space, a place to really challenge ideas and examine the Scales. In fact</p></li><li><p>Problems vs. Solutions</p><p>In this zoomed in verison you might be able to see that each of these is a stack of pages. We try to keep a record of the versions in each stack so that you can just go through and flip through and recall the various stages of reasoning. This is all leading to</p></li><li><p>Expose and flesh out the problems <br /><br />While manage constraints<br /></p><p>Problems vs. Solutions</p><p>Fleshing out the problems and exposing them to the whole team, while communicating and remembering the constraints.</p></li><li><p>Suggest solutions<br /><br />Share the outcome to create buy-in</p><p>Problems vs. Solutions</p><p>As the designer I often do suggest solutions because my head is well wrapped about the space. But by getting the rest of the team involved I gain really insightful perspectives and the team works together to create the outcome, which ultimately creates buy-in from everyone involved. This is so necessary when everyone needs to be working in the same direction. </p></li><li><p>Open Design</p><p>Open Design</p><p>Final but really key principle</p></li><li><p>Agile demands open: its got to be flexible and extensible.</p><p>Open Design</p><p>Coders know this, design is learning. Can be reflected in designs themselves</p></li><li><p>Open Design</p><p>Expose to create depth.<br /></p><p>Exposing structures reveals the depth of a project, reveals the concepts clearly</p></li><li><p>Concept<br />Business Goals<br />User Tasks / Motivations<br />Site Flow &amp; Wayfinding<br />Supporting Systems<br />Navigation<br />Widgets<br />Global Styles<br />Language<br />Buttons <br />Graphics<br />Fonts</p><p>Large Scale</p><p>Small Scale </p><p>Scales of Open Design</p><p>The first tangible reflections of the Large Scale concepts are these structural elements. We want to expose these clearly, the rest of the small scale details are secondary to these things. These are the meat of a project, we dont want to ever hide them with graphics or other Smaller Scales because they are the most direct reflection of the concepts, the point of the project.</p></li><li><p>Open Design</p><p>This is a new concept, so Im going to reframe it in this Japanese artwork. This is one of many series of paintings illustrating the Tale of Genji. An 11th centrury Japanese Novel. The book has been illustrated so many times that it has its own conventions. This illustration is a great example of Fukinuki- Yatai (Stage with roof blown-away). As you can see, its a little awkward, but there is no roof on this building. This convention indulges a voyeuristic urge to see everything, which plays on the novel itself which is the reveling life story of a man named Genji.</p></li><li><p>Open Design</p><p>Moo is a great example. Blog, other blogs bubbling up onto the home page.</p></li><li><p>Open Design</p><p>Flickr group photos stream is even up on the home page.</p><p> You can see under the hood of the community. This directly reflects their Large Scale conceptMoo is about show and tell, its about sharing. The more people share Moo cards, and Moo card ideas, the more reasons they have to buy even more Moo cards.</p></li><li><p>Open Design</p><p>Small Scale as reflection of Large Scale<br /><br />Design emerges from simple rules</p><p>So the Large Scale concepts are designed to be reflected through to the small scale using underlying principles or rules. The design emerges and evolves from there. The graphics are also held to the same rules, and shouldnt ever block or supercede the concepts. If they arent an evolution from the concepts then they should be removed!</p></li><li><p>Designers should</p>Design a week in advance of codingNot make your mockups pixel-perfectWork literally side-by-side with coders when implementing mockupsAllow coders to participate in IA/UI design Especially after the coding has already started</li><li><p>Coders should</p>Coders should ask designers or elsetime is wasted re-working solved issuessolutions are implemented that don't work with other parts of the designed systemcoders make assumptions based on mockupsCoders should give frequent live demos or elsedesigners don't know what parts of the design are/aren't workingdesigners don't know what parts of the design aren't working togethercoders don't know their code has bugs or needs tweaking</li><li><p>How to integrate with an outside design company?</p>Communication and feedback are naturally more stretched outSome unnatural (or at least un-Agile) barriers are imposedTime and spaceSignoff proceduresDocumentation / specsPerfectionismMistrustBring them in to your process as much as you canDont force them to adapt too much or theyll resent and demonize youIterate per-month at first, then per-weekInvite them to your demos (remotely if need be)</li><li><p>Alex Chaffee<br /><br />Leslie Chicoine<br /></p><p>Say Hi.</p></li></ul>