Posted by jc-Qualitystreet on 2010/11/21
Agile development and user experience can work brillantly together… well, but how?
Even if the effort related to Agile User Experience (Agile UX) continues throughout the project (with « just in time » designing and user testing) the User Experience foundations must be initiated at the very beginning of the project, during the first sprints.
Starting to define the Product vision is a best practice. Key element of the vision, the PERSONAS (a fictional representation of target users you can use to help guide decisions about product, features, navigation, visual design…) have also the precious advantage to be directly linked to USER STORIES (brief description of functionality as viewed by the user and an essential agile artifact).
A persona template
First sprints are also the best moment to create a coherent vision of the User Interface structure, and to establish first Usability guidelines (then UI patterns), two elements that will enable UX specialists to maintain a consistent user interface across features and regular deliveries.
Once the product vision and posture established, the target users defined and the product backlog (list of all functionality desired) initiated, user experience of the application will continue just in time, sprint after sprint, following the iterative and incremental lifecycle.
Trust and collaboration are the keys, and UX practitioners MUST BE collocated with development team: visual artifacts, storyboards, mockups and wireframes, will serve the project and enable business and development teams to build the best user experience.
Wireframe with balsamiq: quick, easy and collaborative
But agile development lifecycle proposes new challenges and requires managing User Experience differently…
Practice #1
Support user representatives or business teams (Product Owner) in their analysis, specification and prioritization effort…
UX specialist is the user advocate but also Product Owner partner as well as a team member.
Practice #2
Do just enough user Research, user modeling and UI design up front
The Agile Persona : quick and easy
Practice #3
Adapt your collaboration with teams during a sprint:
- Progress one step ahead of the implementation by preparing and designing « just in time » contents of next iterations (sprint+1, sprint+2)
- Collaborate actively with developers on the functions that must be delivered at the end of the current sprint
- Evaluate with end users results of the previous sprint (sprint-1)
Practice #4
Consider feedback differently: direct, less formal, more frequent and more reactive both in the way to receive and to give it. Overuse face to face collaboration, guerilla usability testing and just enough reporting & documentation
Practice #5
Use rapid prototyping (effective wireframes) to foster collaboration and elicit rapid feedback. Make it valuable and adjusted to the context
Paper prototyping ... from collaborative workshop
Practice #6
Be a facilitator and engage people (both business, development and end-users) on collaborative workshops to design and evaluate the system
Persona workshop
Anything else ?
Posted by jc-Qualitystreet on 2010/11/15
During an agile transition program, do not let your managers by the roadside! Rather help them to become Agile managers and to control the evolution of their profession.
The « era of management 3.0« (agile and lean) is announced so make the middle manager a key player for change, between opportunity and necessity…
The case of middle management
« Top-Down » or « Bottom-Up », there is no debate anymore. We know today that a top management support and the ownership by the teams are both essential to ensure the success of the transition to agility. No, the issues of the Agile Enterprise are now in intermediate managerial layers of the organization.
Towards an Agile Middle Management
How to approach them? How to convince them? How to transform them?
My experience with Agile projects and agile coaching in various sectors (banking, industry, software vendor …) showed me that this is the middle management that holds the keys to agility on the Long Term. Indeed, middle managers can be the most active supporters or the worst impediment and therefore the most dangerous opponent of the agile transformation.
The opportunity to become an Agile Manager…
With only one goal: the success of teams…
The « Command & Control » management style based on Taylorism and scientific management (OST) has shown its limits… the agile manager explores new dimensions (mostly related to facilitation & leadership) to ensure the success of all. The role within an agile organization becomes a clever trade-off between maintaining / abandoning some responsibilities and acquiring new skills.
So, even if every management role is unique, context-specific, here is the list of the 6 core activities of the Agile manager:
- (Still) Manage the portfolio of projects and coordinate with other managers
- Define projects strategy at the organization level
- Set priorities
- Define budget and resources
- Do the staffing
- Work with peers as a team
- (Still) Manage recruitment
- Hire people
- But also fire and solve potential conflicts
- Support Projects and Agile self-organized Teams
- Promote autonomy and self-organization
- Remove impediments that the team or ScrumMaster are not able to manage
- Manage logistics
- Buy the supplies
- Challenge teams and help them to improve their knowledge about products, tools, technologies, methods…
- Create a relationship of trust, develop (career) and motivate people
- Make yourself available
- Get to know each person and his work
- Facilitate the acquisition of new skills
- Give feedback
- Give work recognition
- Delegate tasks
- (Still) Create an environment for success and energize change
- Communicate the vision
- Give a direction
- Adopt the appropriate management style
- Simplify usage
- Seek performance through appropriate tools and processes based on continuous improvement and waste elimination
- Initiate, support and animate communities of practices
- Give time and resources to agile communities, ScrumMaster, Product Owner, Agile Manager, Architects, UX Groups …,
- Promote communities of practices in the organization
And my role as an Agile Coach?
Engage conversations with managers and support them in their journey toward becoming an AGILE MANAGER !
Posted by jc-Qualitystreet on 2010/11/11
Or Agility at Home 🙂
Christmas is coming and for the third year we’ve done with kids, our letter to Santa Claus, or rather our prioritized Backlog for Santa Claus.
With Agile and Kaizen mindset, we seek to improve our process (see our 2009 process – English or our 2008 process – French)
- A prioritized and customized backlog !
Same constraints as previous years
- Santa Claus is very busy
- His sledge is not expandable
- The deadlines are tight
- The delivery date cannot be moved
Other elements of context
My kids are now experienced Product Owners 🙂
- They handle sticky notes and patafix with dexterity…
- They know they cannot have everything (even if you always want more)…
- Being good (or not) has an impact on Santa Claus’s motivation to deliver what they wish…
SO , they realize they must prioritize their Christmas backlog !
How do we set priorities to write the letter to Santa Claus?
Step 1: Needs analysis, Brainstorming and data collection
Passionate reading for weeks, intensive research from several sources… confrontation with friends at school. « Workshop collaboration » with parents at home and, finally, cutting potential gifts
Catalogs...
Brainstorming
Collaborative workshop with parents
Step 2: Backlog Initialization
Images are cut. Place one image by sticky note (pink ones for my daughter; yellow notes for my son). Question of maturity: this year my son was able to participate actively (he is now 3 ½ years old). The two backlogs are initiated.
One image by Sticky note
Backlog item example
Step 3: Backlog Prioritization
Notes are laid on the ground. My kids make their prioritization effort and rank them in order of preference. They place on the top toys they want most, the most important to them…
Prioritization effort
To set priorities: compare and use triangulation !
the list of items is prioritized
From the floor to the table
Step 4: Backlog Customization
Notes are now prioritized on the ground. We keep the principle of visual management but our product owner wish this year to customize their backlog.
- Final Backlog – Girl version
Step 5 : Backlog display
Go to the room for an optimal visibility
Visual management... In situ !
Results
We really had a great time and the children enjoyed it. They’re very very happy. And you know what ? … It was a pleasure to coach such good Product Owners 🙂
Posted by jc-Qualitystreet on 2010/10/19
The « AGILE TEAM RADAR » is a self assessment tool I like to propose during sprints retrospective to collect data, especially with teams new to agility.
The exercise is directly inspired by Diana Larsen and Ester Derby (Agile retrospectives)
The problem
Teams don’t always understand the importance of agile values, and don’t perceive how they are intimately linked to their everyday practices.
« Thanks for the theory… Ok for the values but now… please tell me more about continuous integration test automation and agile requirements »
An answer
The necessity and the opportunity to return to foundations again and again! A good way to start: the agile team Radar with its good focus on the core agile (actually XP) values !
Agile Values In Action
How to proceed?
Step 1: Introduce the activity (why, how… self assessment, collect data, measure progress ….)
Step 2: Write, introduce values to the team making a short description of each value and trying to connect them with everyday practices. Good definitions to start:
Communication: Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together
Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs
Courage: We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works alone. We will adapt to changes when ever they happen.
Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it’s simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work
Feedback: We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around
Step 3: Let the team make it real and link these values to their current practices… Let the discussion go !
Step 4 : Do the self assessment, anonymously, with a scale of 0-10 : how well the team is doing with the 5 agile values ?
Agile Value Card - Rate each value - 0 (not at all) to 10 (as much as possible) - It's anonymous !
Step 5: Collect the cards immediately after the exercise, Do the average by axis
Step 6: : Discuss the results and use it to track progress: NEXT SPRINT WE FOCUS ON FEEDBACK !
Sprint 1 vs Sprint 2 : Do you notice the progress ?
Benefits
- Precious to reinforce agile values
- Very useful to generate insights and discussion around practices / values
- Quick and easy
- Useful to identity strengths and weaknesses of a team in a « Kaizen » approach
- Very good for retrospectives and intresting in training and everyday coaching
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! »
