Better Software - November 2008 - (Page 25)

must work together daily throughout the project. In this context, it is often considered that the UCD practitioners would operate as part of the customer team [3] to help drive the direction of the product. Validate with real-world usage UCD is an iterative process that calls for designers to validate and refine their design regularly. While the design is being created, many techniques are used to perform this validation that provide value through quick and short feedback loops. Despite this, we maintain that the design of a successful user experience cannot be completed without feedback from people using the real system. This is where we get benefit from the primary agile principle mentioned earlier: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. To be able to perform and respond to this level of validation, it is necessary to have the design team integrated with the development team to run the tests and modify its design based on the findings. Handover is the enemy of understanding Whenever one team is responsible for creating something it will hand over to another team, there is a risk that the receiving team won’t understand the theory or mental model behind the item. This is a common problem even when the two teams have similar backgrounds, but it is compounded when the teams have very different skill sets and backgrounds, as is the case with development and design teams. When designers want developers to implement their ideas, it is not enough to pass on screen shots or scribbles. There must be a shared understanding of the problem domain and the theory describing the reasons why certain decisions have been made. Like the Agile Manifesto says: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. people forget to iterate, or at least forget to plan to iterate. It is quite common for an agile software development team to forget that the point of all the feedback is to allow customers to inspect and verify the features that they have requested. The result is that it comes as a shock to the customer that valuable features must be postponed when a recently implemented feature needs to be iterated over again. When taking a user-centered approach to agile development, it is critical that we make time to iterate so we can respond to user feedback without pushing out features that we have told the customers they will receive. There are a couple of strategies to manage this: Take a percentage of your initial estimate and add it to the schedule, or consider Alistair Cockburn’s approach of creating three cards for user rights [6] by planning the implementation and two additional iterations of each story. However you solve this problem, the first step is recognizing that while providing shorter feedback loops to the customer and users is valuable, it doesn’t count for much if we don’t plan to get the benefit from the feedback we receive. Keep in mind the importance of the agile principle that says we should: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. opment team and, therefore, not being aware of the technical constraints upon the proposed design. This is addressed by the agile principle: Business people and developers must work together daily throughout the project. Conclusion In today’s marketplace, experience is king. In the eyes of end-users, what makes software great is their perceived experience. So how do we build great software? As one would expect, there is no magic formula. Not only does agile provide us with tangible software sooner but it also provides the transparency and constant feedback against which we can validate and steer decisions. User-centered design can help us remain focused on the goals, frustrations, and desires of our end-users. A successful combination of these two philosophies, while sometimes painful for the practitioners involved, will result in the creation of product experiences that provide the “wow” factor to captivate the discerning users of today’s marketplace. {end} refereNceS: [1] www.core77.com/reactor/06.07_merholz.asp [2] www.wdsglobal.com/news/whitepapers/ Divided responsibilities; divided teams Agile developers often focus more on the delivery of software than on valuable software. Following the “you aren’t gonna need it” [7] mindset, agile developers run the risk of just developing the minimum of what they are asked without actively taking the responsibility to volunteer information regarding alternative approaches to the product owner or UCD practitioner. We must actively challenge the mindset of divided responsibility—“You spec and design it; we’ll build what you spec.” Everyone should work toward the shared vision of a successful experience. The flip side of this is the UCD practitioner or product owner’s not actively seeking collaboration from the develwww.StickyMinds.com 20060717/20060717.asp [3] www.agileproductdesign.com/blog/emerging_best_ agile_ux_practice.html [4] alistair.cockburn.us/index.php/Incremental_ versus_iterative_development [5] www.stickyminds.com/s.asp?F=S13178_COL_2 [6] alistair.cockburn.us/index.php/Three_cards_for_ user_rights [7] c2.com/xp/YouArentGonnaNeedIt.html Sticky Notes For more on the following topic go to www.StickyMinds.com/bettersoftware. n Further reading No time to iterate A common flaw, articulated by both Alistair Cockburn [4] and Jeff Patton [5], is that on an agile development team NOVEMBER 2008 BETTER SOFTWARE 25 http://www.core77.com/reactor/06.07_merholz.asp http://www.wdsglobal.com/news/whitepapers/20060717/20060717.asp http://www.wdsglobal.com/news/whitepapers/20060717/20060717.asp http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development http://www.stickyminds.com/s.asp?F=S13178_COL_2 http://alistair.cockburn.us/index.php/Three_cards_for_user_rights http://alistair.cockburn.us/index.php/Three_cards_for_user_rights http://c2.com/xp/YouArentGonnaNeedIt.html http://www.StickyMinds.com/bettersoftware http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2008

Better Software - November 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Getting Agile with User-Centered Design Google Web Toolkit Simple Summaries of Complex Projects Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.