Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Agile and UCD: Building the Right Thing, the Right Way

When integrated, Agile software development and User-Centered Design (UCD) allow development teams to extract the right information from their users, to verify assumptions, and to validate design decisions.


advertisement
gile software development has hit the mainstream! Since the Agile Manifesto was published, various software development methodologies that follow the manifesto's values have steadily gained popularity. Many organizations are adopting these lightweight processes to get their software built.

Many of the Agile methodologies recognize and value the input of users as domain experts:

  • Extreme Programming requires that a customer/expert user be part of the team on a day-to-day basis.
  • Crystal Clear requires the software to be put in front of users at least twice to gather feedback before the software can be released.
  • Scrum expects regular demonstrations of the product, albeit to stakeholders, at the end of every sprint.

These are all good suggestions that will help create more useful and usable software. However, consider the very real possibility that no users will be available to sit with the team day to day, or an available user is not representative of the majority of the user base. It is not sufficient just to say that a user should be part of the team. Development teams need ways to extract the right information from their users, to verify assumptions, and to validate design decisions.



Fortunately, another emerging methodology, User-Centered Design (UCD), focuses entirely on designing to meet the goals of real users. If Agile software development is about building the thing right, then UCD is about building the right thing. Understanding the needs and goals of the users is incredibly important to the success of software projects. It is certainly as important as other issues that receive a lot more attention, such as delivering on time and the maintainability of a system. Who wants to build software that is not going to be used or makes it harder for users to do their jobs? And how long will users accept clunky, difficult-to-use software? Projects often need to be re-implemented due to an unmaintainable code base or a legacy technology. If you are building software in a competitive market, the issue of software usability can mean the difference between a profitable company and going bust.

This article explains how to integrate Scrum with UCD, as Scrum recently has become the most popular Agile methodology. However, because Agile methodologies have very similar properties (frequent and early delivery, valuing working software over design documentation, responding to change, and so on), you can apply the principles and benefits discussed here to integrate UCD with any of the other Agile methodologies.

Scrum and Product Increments

Scrum is a lightweight process for software development projects, based on a few core principles. It is not a rigorous process that should be followed to the letter, but is rather a framework to give a team the tools they need to communicate and adapt the way they work depending on their environment.

Figure 1. Scrum Process Diagram: A backlog of features is fed into each sprint at the beginning. Each sprint produces a new functional increment to the product.
The Scrum process has the following core characteristics (see Figure 1):
  • Product backlog: A prioritized list of features for the project.
  • Sprint: A regular period of time in which the team commits to deliver one or more items from the backlog. When the work for the sprint is set, it cannot be changed without aborting the sprint. The result of a sprint must be a fully functional and potentially releasable increment of the software.
  • Sprint kickoff meeting: A planning meeting at the beginning of the sprint where the team members estimate which features from the backlog they think they can commit to delivering within the sprint.
  • Daily standup: A short meeting held once a day that provides an opportunity for every member of the team to report on progress made the previous day, raise any issues, and make people aware of what they are planning to work on the following day.
  • Sprint burndown chart: A big, prominently displayed chart that shows the progress of the team against the work remaining for the rest of the sprint.
  • Sprint demo: A demonstration to the project sponsors at the end of the sprint showcasing the work that has been completed within the sprint.
  • Sprint retrospective: A short meeting for the team to review their working practices over the last sprint and identify areas to change in their day to day process.
A Scrum team is made up of the following core roles:
  • Product owner: The person who makes the decisions about which new features are planned for the product, and in which sprint these features are implemented.
  • Scrum master: The person who helps the team get the work done. The Scrum master's primary responsibility is to remove any obstacles that may stop the team from meeting their commitments.
  • Self-organizing team: The group of people who are responsible for estimating and implementing the features requested by the product owner.

The power of Scrum is its simplicity and rigor. The team performs a contiguous number of sprints. The output of each of these sprints is a visible product increment (i.e., new features that can be demonstrated and potentially released to the users). This gives the team a regular sense of achievement and makes the progress of the team very visible to the rest of the organization. With Scrum, there is nowhere to hide!



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap