Posted by jc-Qualitystreet on 2010/10/18
Larry Constantine is the co-author with Lucy Lockwood of « Software for Use » (1999), well-known in the HCI (Human Computer Interaction) field for his « Essential use cases technique » and his « Usage-centered design methodology ».
He wrote an article (part 1 and part 2) a month ago on Agile and Experience Design Marriage, with an introduction a bit provocative:
« when experience design is married with agile development, the results can be a crisis of faith on either or both sides »
In part 1, Larry insists on deep philosophical differences and variance in practices… As a UX practitioner and Agile Coach, involved in various agile projects, I unfortunately have to confirm some of his observations:
- Agile methods still don’t incorporate usability and UX practices
- Marriage is often « one way », experience designers accommodate to the dictates of agile methods and schedules, even if UX tend to become now the key differentiator in the IT marketplace.
- UX is not the key driver for development
- UX is still a lack in most agile projects
That said, I don’t agree with, what Larry Constantine calls « core incompatibilities » in the couple. What a negative approach!
Of course, « agile methods employ rapid, iterative refinement, with short, incremental development cycles« . And, yes, « they tend to favor a functionality-first, inside-out process, beginning with early and easy successes that deliver working code« . So what? Is it so incompatible with user experience and usability techniques? I don’t think so!
Rapid prototyping, Guerilla usability testing, Personas and just enough user research, innovation games, Vision or Design workshops are examples of fabulous UX & Usability techniques. They can be effectively applied within agile development cycles.
I rather see the iterative and incremental development as an opportunity to gather, at frequent intervals, feedback… real feedback… rich feedback. Receiving feedback from the team, the customer or of course the users is, according to me the most important element on IT projects.
Time to market, value and simplicity are now crucial for most organizations evolving in a highly competitive environment. It is both a reality that UX specialists need to understand and a strength that lead them to focus only on valuable activities. And I am really convinced that we need to adapt our approach, our tools and deliverables for more effective collaboration with other actors involved in IT projects (not only agile…).
In part 2, Larry Constantine described in detailed the key ingredients to make a better marriage between Experience Design and Agile Development…
- Respect of each other’s work and skills (I personaly think we’re all professionals)
- Equality in the development process (I personaly think User Interface Design should be considered as an essential prioritization criterion of the product backlog !
- Knowledge about each other’s skills and areas of expertise… to get respect and equality (I personaly think learning is a key whatever the context !)
- Independence though but coordinated activity
… A more optimistic view that I appreciate. I also like his conclusion:
« Now, may your union be a long and prosperous one! »
Posted by jc-Qualitystreet on 2010/03/30
Agile Coach vs ScrumMaster: it is sometimes a bit blurry … probably because the ScrumMaster acts sometimes as an agile coach, using coaching techniques and probably because the Agile coach is sometimes asked to play the role of ScrumMaster in Scrum projects.
But according to me: « The ScrumMaster is not an Agile Coach » … here are some elements of comparison:
|
AGILE COACH
|
ScrumMaster
|
| Mission |
High variability. Never the same.
For a person and / or a Team and /or an Organization
A strong clarification of the objectives and a precise analysis of the context are required.
For this journey toward agility, concrete and measurable result should be defined. |
Little variability. Often the same
For the team
Objectives are usually unambiguous, related to a well defined role description:
– Ensuring that the team is fully functional and productive,
– Ensuring that the Scrum process is followed in terms of values, practices and rules
– Enabling close collaboration
– Protecting the team,
– Removing Impediments
|
| Scope |
Agility (broader) and Change |
Scrum |
| Link with the Project |
The agile coach is not involved in the project (independent) |
The ScrumMaster is involved in the project |
| Link with the team |
Not part of the team
Does not protect the team |
With the team daily
Protects the team |
| Activity – Presence |
Variable and not continuous depending on the context and needs. Stronger presence at the beginning of the mission, less thereafter. The Coach is looking for the autonomy of his client … |
Continuous. Throughout the project period. |
| Training |
Trained in methods, roles and Agile practices.
Trained in coaching (certified or not)
Good knowledge of IT projects life cycles, roles, actors and activities
Basic knowledge of psychology |
Trained in the role of ScrumMaster (certified or not) |
| Experience in agility (depth … Years of experience.) |
Required |
Not necessary |
| Experience in agility (width … Implementation in various contexts, with multiple teams) |
Required |
Not necessary |
| Acts as a Trainer |
+ + + |
No |
| Acts as a Facilitator |
+ + |
+ + + |
| Acts as a Mentor |
+ + + |
+ |
| Acts as a Coach |
+ + + |
+ |
| Acts as a Consultant |
+ |
No |
| Is the agent of change |
+ + + |
+ |
Scale: +++ (Yes Very Much) ; ++ (Yes Much) ; + (Yes Little) ; No
It’s my Vision, what’s yours ?
Posted by jc-Qualitystreet on 2009/11/21
and incredible leverages for an effective collaboration !
- Feedback and tests (the most interesting thing)
- Human first (essence of UX and UCD but also the first value of Agile Manifesto !)
- Personas and user roles
- Collaboration
- Simplicity
- Change
Shared values and principles : an illustration :
AgileUx:so close. JC Grosjean
Posted by jc-Qualitystreet on 2009/11/19
Even if rare examples of « Big Bang » agile adoption exist, as Salesforce in 2007 (not without a very strong preparation), I am convinced that a successful agile transformation requires two or three (max) pilot projects.
REAL PROJECTS, REAL TEAMS: TWO PREREQUISITES.
First, the selected pilot project is an opportunity to change and to learn but it must be also sufficiently representative to be usefull and effective in a transformation approach. Do not experiment what could be agility in real life, do not try agile methods in your own organizational context before a general adoption is a mystery to me. You miss an important source of knowledge, refinement and improvement and also a good opportunity to initiate change management.
BUT HOW TO SELECT THE APPROPRIATE PILOT PROJECTS?
This is a recurrent but crucial and challenging question… Mike Cohn answered it recently by proposing 4 attributes to help the choice. His four criteria suit me well:
- Duration: The ideal pilot project should be neither too short (to be credible, representative and to give a learning opportunity) nor too long (for an effective capitalization and a rapid agile generalization).
In short : Between 2 and 5 months (max) with 4 to 7 iterations
- Size: The ideal pilot project should start with a single, small collocated team. A distributed team or several small teams would add unnecessary complexity during the pilot phase, unless working with distributed teams is the norm within the organization.
In short: One single, small and collocated team
- Importance: Unimportant projects will lead to less commitment and won’t be representative and credible… but critical or top priority projects would entail too much pressure for a team in a leaning situation. A good balance must be found for the ideal pilot project.
In short: Medium importance, not critical but valuable for the organization
- Business sponsor engagement: The ideal pilot project should have an engaged business sponsor. His commitment is a key to remove any obstacles. He will also be the best ambassador to promote the new methodology.
In short: One engaged business sponsor
In summary, to launch an agile transformation, the ideal pilot project is both:
1. A real project with a real team
3. A project of a duration of 2 to 5 months (max), for example with 4 to 7 iterations
4. A project with a single, small and collocated team
5. A medium priority and non critical project but valuable for the organization
6. A project with an engaged business sponsor
Posted by jc-Qualitystreet on 2009/01/18
12 best practices compiled by Jeff Patton that have proven their efficiency with multiple teams.
Here is the list of the emerging practices with a quick review.
1 Drive: UX practitioners are part of the customer or product owner team
MUST User Experience activities support analysis and prioritization tasks carried out by of the Product Owner (scrum) / Client (XP). This can go up to write User Stories and even play the Product Owner role. This position does not harm our cooperation with the development team. In one of my recent projects, we had a Product Owner Team (speaking one voice) working with the UX consultant to facilitate understanding and putting User Stories into context.It was very efficient.
2 Research, model, and design up front – but only just enough
MUST Sprint 0 offers us a good opportunity to do our job, but timeframe is diiferent … UX must go straight to the point: personas, quick modeling…Sprint are short (2, 3 or 4 weeks) and people expect expertise from us.
3 Chunk your design work
MUST No choice but not an easy thing. During the first iteration, it is a real difficulty.
4 Use parallel track development to work ahead, and follow behind
MUST It is a real challenge but it is also the most exciting part of the job in an Agile context. During a specific iteration (n), UX practionners have to:
- design the content of next iterations (n+1, n+2)
- collaborate with developers on the current iteration
- evaluate results of the previous iteration (n-1)
5 Buy design time with complex engineering stories
CAN Very contextual.
6 Cultivate a user validation group for use for continuous user validation
CAN It helps and it is great if the pool of users is the target (but the pool must be large enough). It could be also a way to initiate change…
7 Schedule continuous user research in a separate track from development
CAN A question of time and resources but impossible if there is only one UX guy in the organization…
8 Leverage user time for multiple activites
SHOULD OK, but do not forget that visiting users for nterviews, questionnaires, card sorting, screen reviews requires time for preparation, analysis and restitution…
9 Use RITE to iterate UI before development
MUST Feedback and adaptation are the keys. Teams do not want to wait; they don’t care about a formal and standard usability testing reports.
10 Prototype in low fidelity
MUST Paper, PPT, Visio, whiteboard … everything is OK if you give value to the team and the project.
11 Treat prototype as specification
MUST Always ! High level Storyboard + User Stories + Wireframes : a magic potion
12 Become a design facilitator
MUST It is my conviction : facilitation is the future of our profession !
