Posted by jc-Qualitystreet on 2010/08/11
One of the first differences observed with Agile is the way we estimate the size and duration of an IT project.
The entire team is made responsible for the estimate of the product Backlog (the list of all functionality desired in the product). Indeed, the team is invited to estimate collectively this list of valuable items that will require his work.
Scrum teams use Story Points and Planning Poker for this activity.
- Story Points represent a measurement of the effort required by a team to implement a Story.
- Planning Poker is an effective (and funny) way to assign collectively story points to user stories on the product backlog. It is a special card game based on the Fibonacci sequence. The idea is to pick a representative story and assign it a point value, then estimate the other stories relative to this standard (consensus must be reached for each user story)
Planning Poker Deck
Collective intelligence is the pillar of this new way to estimate … an effective team-based estimation technique but not so natural at first. Relative size and consensus are not so easy for the teams new to agile.
The problem:
Teams often lose the thread of their estimates. They have difficulty in comparing or lack of benchmarks.
An answer:
Use a visual display of the planning poker values in columns, and place the user stories in the appropriate column during the activity.
Visual display of the estimates
Benefits:
- It is an effective form of visual management
- It facilitates comparison and triangulation
- It reinforces the concept of relative size (effort)
- It reinforces the idea that result is not frozen during the activity: change is easy t!
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/12/02
“Life is easy with personas” …
this is what I’ve been told by a client the last time I used the Personas method on an IT project.
A persona is a user-archetype, a fictional representation of target users you can use to help guide decisions about product, features, navigation, visual design…
http://www.slideshare.net/toddwarfel/data-driven-personas Todd Warfel (UPA 2007)
More than a simple artifact or a one-page description, the Personas method is a user centered design technique, initiated by Alan Cooper in 1999. It provides a team with a common and shared VISION of the users of a service or product, in a very engaging format.
Why personas are relevant in Agile contexts?
In agile projects, Personas should be seen as a fantastic tool in the hands of a Product Owner team (composed by the Product Owner, a User Experience specialist, a Business Analyst…) to align the cross-functional team (dev, test …) to a shared and realistic vision of the users of the product to develop.
Personas provide you with the opportunity to integrate real User Experience all along your product development project.
Indeed, they enable the team to stay continuously focused on user primary goals and tasks by emphasizing what they want, their behavior, their needs and expectations but also their potential impediments
Another major benefit is that a specific persona can be easily linked to user stories. The “user voice format” is a good opportunity to place the personas under the spotlight. It makes your user stories more credible, more engaging. It also facilitates CONVERSATION and CONFIRMATION activities associated to each user story.
Personas are a powerful communication tool within and outside of the team. They can be used at the organization level for training, commerce or marketing activities.
How to proceed?
Option 1: Using existing Personas
Personas are ready when you start the project ; just use them !. User research was done previously, and personas are already a key element of the product vision. No need to construct them, but the Product Owner has to introduce the personas to the team when he communicates the Vision. One of the benefits of the personas is that it makes this description easier, both visual and based on storytelling. Based on that knowledge, Elevator Pitch or Product Vision exercises will be more effective with the team.
Then during the sprints, personas are associated to user stories, and help guide decisions on the Product Backlog priorization and UI design. Crucial, don’t you think ?
A classic example with Zylom (not current version):
Two personas (Maria and Sophia, whose main goals are to play online, download games to play offline and get help if they need it) and their impact on UI Design in terms of color, shape, size, positioning of elements, layout and navigation menu structure.
Of course, Personas can also be used for testing activities: scenario based testing, usability testing, cognitive walkthrough …
I usually ask the team to include Personas on the Information radiator. It is an important communication act both from an internal and external perspective.
Option 2: Constructing new Personas
Personas don’t exist when the project starts.
Sprint / Iteration 0 is the perfect moment to initiate our “3 steps” process, of course in a collaborative way. This exploration sprint usually lasts from one to four weeks, depending on context.
Unfortunately a short timebox (one week for example) is a real difficulty especially for organizing workshops and planning user interviews. You’ll need to anticipate or to refine ….
Given availability issues, various impediments … “8 user interviews a week” is usually a maximum (actually it’s mine), but it gives you the opportunity to facilitate preparation workshops and to do quick stakeholders interviews in parallel.
You may understand why I like a duration of 3 or 4 weeks for a sprint 0 
Here is my process to build personas:
Step 1: Preparation consists in:
- Organizing one or two workshops with a Product Owner team and various stakeholders in order to be aligned to the objectives and the methodology, to identify data sources, to determine categories of people to interview (for example the core roles)
- Informing the entire team of the process
- Collecting data from various sources including user interviews. According to me, 3 interviews by roles or categories identified is a minimum.
Step 2 Construction consists in:
- Analyzing data: from facts to behavioral variables, then from variables to patterns
- Establishing Personas skeleton
- Giving birth to the personas (storytelling and Poster) : I initiate the work (based on a template and data analysis) but I like doing this task in one or two workshops (this time with the entire team, development included). It’s fun and fosters the appropriation process.
Personas: A template
- Validating personas with various stakeholders (a qualitative validation); I only did one time quantitative validation with a large questionnaire sent to hundreds of users.
Step 3: Communication & use consists in:
- Putting the Personas on the Information Radiator
- Linking the Personas to User Stories
- Using the personas for priorization, storyboarding and wireframing activities
- Making a communication plan dedicated to the Personas
TIPS !
- Mobilize the entire team around the approach
- Limit the number of Personas
- Define a primary Persona
- Start the personas construction with the Product Owner team, but inform and finish it with the entire team
- Anticipate three or four workshops in the agenda
- Bring your personas to life using big cards or posters containing a name, a title / role, a script (the storytelling allowing good back in the character’s life), a picture, goals, triggers, influencers, delighters, features expected …
Another example:
- Be careful on the choice of the photo: avoid celebrities, models or people you may know. remain credible.
- Don’t hesitate to communicate on your Personas: make a buzz !
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/11/13
Christmas is coming and kids know it. This is what happened to me last weekend …
My kids “Dad … Dad for Christmas … can we play the sticky notes game ”
Me: “Okay kids, but this time we’re going to change the rules”
In one year, I had the time to improve the process :) even if the constraints are almost the same:
- Santa Claus is very busy
- His sledge is not expandable
- The deadlines are tight
- The delivery date cannot be moved
In addition, my kids as good Product Owners have understood two important things making them realize the importance of priorities:
- You cannot have everything (even if you always want more),
- Being good (or not) can potentially impact on what you’d receive
Scrum / XP from … Home!
Or how we set priorities to write the letter to Santa Claus
Step1 : Brainstorming, data collection and workshops
Passionate reading for weeks, intensive research from several sources, and interviews with the little brother to finally cut in the magazines the images of the toys they like
Step 2: Backlog Initialization
The images are cut. In case of several kids, ask them to place their images in an envelope. Use one envelope by child then one image by sticky note. The backlog is initiated.
Step 3: Backlog Prioritization
Notes are laid on the ground. Ask the kids to rank in order of preference by placing on the top toys they want most, the most important to them…
… ..
….
Step 4: Backlog Display
Notes are now prioritized on the ground. We had to find a wall or a door to display them vertically (visual management …).
My daughter’s wall (not very reasonable):
My son’s wall (moderate …)
Retrospective: We had a good time and kids were very happy !
My wife and I’ll take care of the estimation (points/ euros)
Posted by jc-Qualitystreet on 2009/11/12
User stories are increasingly used on Agile projects. This popularity is a very good thing. Goal and business oriented, their simplicity and a immediate focus on acceptance criteria make them terribly effective on design projects.
Once the 3C described (Card, Conversation and Confirmation) and INVEST criteria well understood, when the team and Product Owner start to discover their own stories, they often ask me if the “User Voice” format must be respected …
This format is the following:
As a <User Role>
I can <Goal>
So That <Business Value>
A sentence in which,
- The role is the one that makes the action and who benefits
- The goal is the action executed
- The Business value represents the benefits that emerge from the action
So, should we use this format ? My answer is definitely YES!
- The “User Voice” gives meaning to the feature … why and for whom the team will develop the product
- It is a step closer to a user experience approach, especially to the Personas method.The role is often a Persona, representing a concrete realistic and shared vision of the end user.
- It is clearly ACTION and GOAL oriented (so efficient to design products)
- It justifies all the functionality of a business point of view, and requires the Product Owner and teams to systematically examine the value of each feature
My advice:
Give a concise and significant title to the User Story and then describe the user story using the “User Voice” format.
Posted by jc-Qualitystreet on 2009/07/23
Risk management is crucial on any IT projects.
It is a core activity of project management discipline, already well documented in Prince 2, PMBOK or CMMI (thus it is an essential part of an Agile CMMI model, expected by some of our client).
Unfortunately agile teams tend to abandon risk management considering applying agile practices is enough to avoid problems. We need to change it and reintroduce a risk management approach …
In an Agile-CMMI context, it’s a must !
The Good News … with adjustments, risk management is clearly more powerful with Agile methods. It is a great strength (often ignored or hidden). Monitored on a daily basis, the Agile Risk Board becomes a key element of the Information Radiator (with Task Board, Burndown chart, and User eXperience artifacts).
Agile Risk Board by Grosjean (based on De Marco - Lister)
IS AGILE RISK MANAGEMENT DIFFERENT ?
Yes it is ! Our Agile risk management :
- Is less formal and done in a Lean spirit (in terms of value, decision making and waste elimination…)
- Is collective and owned by the Team
- Is facilitated by an Agile project Manager (ScrumMaster, Coach XP)
- Is above all qualitative
- Is ubiquitous and continuous
- Is “action-oriented”
- Is improved by Agile values, principles and practices
- Provides us with much more control and monitoring points
HOW DO WE DO AGILE RISK MANAGEMENT ?
I plan the Risk management activities, and invite the team to determine how to best manage risks (depending on the context, Agile only, Agile-CMMI …). This is a short exercise that describes how agile management will be done in the specific project. Required, process oriented but useful and no time consuming.
Collectively during a workshop we seek to identify risks and prioritize them according to conventional parameters (probability of occurrence and potential impact). Taxonomy, check lists and brainstorming ! Classic.
The beginning and the end of each sprint are important milestones. Risks are formally included in the agenda of the Sprint planning meeting and Sprint Review. They are discussed with the team. A good thing if the Agile Project manager needs to report.
Risks are identified during all Scrum meetings (Planning release + Planning meeting, Daily Scrum, Sprint review and Retrospective)
Risks are assessed and managed with strategies for addressing them during all Scrum meetings. Strategies (Mitigate, avoid, transfer, accept ), associated risks and actions are written on the risk board (as the example above).
Risks are continuously monitored on the Information radiator, mainly through the Risk board but also with the Task board and BurnDown Chart (immediate visible result of good or ineffective risk management strategies). Risk management is now collective and HIGLY VISIBLE.
IS THE AGILE RISK MANAGEMENT CMMI / PMI COMPLIANT ?
Yes it is !Concerning risk management, PMI, the Project Management Institute (via PMBOK) and SEI, the Software Engineering Institute (via CMMI) have almost the same approach.
Risk Management (RSKM, Maturity Level 3) is the process area dedicated to risk in CMMI (Capability Maturity Model Integration). “The purpose of Risk management is to identify potential problems before they occur so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives”. Through RSKM, CMMI requires you answer three specific objectives:
-
Prepare for Risk Management => Yes
-
Identify and Analyze Risks => Yes
-
Mitigate Risks => Yes
The agile risk management and its specific practices described above enable you to answer these three objectives and to get direct or indirect evidences needed in appraisal contexts (SCAMPI).
Project Risk management Is one of the nine knowledge areas described in the PMBOK guide (Project Management Body of Knowledge). “The objectives of Project Risk Management are to increase the probability and impact of positive events and decrease the probability and impact of events adverse to the project”
Project Risk management contains 5 processes:
-
Risk Management planning => Yes
-
Risk identification => Yes
-
-
Risk response planning => Yes
-
Risk monitoring and controlling => Yes
One more time, the 5 processes map very well with Agile Risk management practices, even if the Agile Project Manager acts more as a facilitator.
THE BENEFITS: risk management is highly visible, monitored on a daily basis and is everyone’s business.
Posted by jc-Qualitystreet on 2009/05/06
And a tool so valuable :
-
To understand user’s needs
-
To benchmark services
-
To identify usages
-
To prioritize your product backlog and your development
-
To drive your vision and your strategy
-
Or just to know your product.
The Kano model has almost 25 years … but you can still easily apply it to your own Projects (IT or not).
The strengths of the model : simplicity, and the user feedback (questionnaire).
Thus, the Kano model is both a precious User Centered Design tool and a precious decision-making aid tool.
The Kano model seeks to connect requirements (response to needs, product attributes) and customer satisfaction, and classifies 3 types of requirements, that will influence the final customer satisfaction. Very useful and very efficient.
Must Have ( “Basic needs”)
These basic requirements are not always expressed but they are obvious to the customer and must be met. If you don’t do it, “you’re dead !”
These requirements are not a source of satisfaction but can cause major disappointment. They’re not the priority in term of development but must be there the D day.
E.g. brakes of a car; a bed in a hotel room …
Performance needs (”Linear”)
The need is expressed and customer satisfaction is proportional to the level of performance (and quality) of what is implemented. It is a strong source of customer satisfaction and a priority for Development.
It must be shown as soon as possible to the Users.
User feedback on these functions is crucial.
Delighters ( “exciters “)
These requirements are not necessarily expressed. Sometimes they’re unconscious.
This is the happy surprise that can make a difference, and an important source of satisfaction. If not there, no dissatisfaction, no frustration: they’re not expected.
Thus in terms of development, they are usually not a priority, except if it is your product or firm strategy.
E.g. The glass of champagne when you arrive at the restaurant, the wifi on the plane or in your hotel room, the mobile touch screen…
Exciters are the keys to Innovation.
Obviously, the model is not fixed and a specific function tends to go to” “the Must have”). The mobile world is the perfect illustration.
HOW DOES THE KANO MODEL WORK ?
The model is very simple: select a representative panel of users (20 … 30), pass them a questionnaire, analyze the responses and make the right decisions.
Step 1
Survey users (mostly by questionnaires) on each function through a pair of questions (functional and dysfunctional)
Functional question : “How would you feel if the product had feature X ?”
I like it
I expect it
I’m neutral
I live with it
I dislike it
Dysfunctional question : “How would you feel if the product didn’t have feature X ?”
I like it
I expect it
I’m neutral
I live with it
I dislike it
Step 2
Analyze responses for each function and each user questioned.
You have 6 possible categories (I = Indifferent; Uncertain Q = R = Reverse, and the top 3)
Step 3
Communicate final results for each function :
-
The function x is a “Must Have”
-
The function is a need expressed “Linear”
-
The function z is a requirement attractive “Exciter”
…
Posted by jc-Qualitystreet on 2009/02/13
Forget SCRUM failure debate for a minute…
What is really working on Agile projects ?
What kind of activities enable your team to deliver as fast as possible an outstanding product ?
Well, I’d say SCRUM; I’d say SCRUM practices but not only…
SCRUM is (too) popular now: latest statistics (2008) from Version One show that 71 % of agile teams are using it, with or without XP.
Great ! SCRUM is the best framework for project collaboration. It is also a simple process based on feedback and adaptation, ensuring high visibility and velocity.
SCRUM respects people and seeks to provide the highest value to the customer through powerful and mature practices: Integrated Team, Daily Scrum, Retrospective, Iteration planning, Short Iterations, Information radiators…
SCRUM is for sure the agile foundation of your projects, but this fantastic framework doesn’t cover everything :
- No recommendations on User Experience, Agile testing, Development practices, all so crucial on IT projects
- Partial and insufficient recommendations on Process Improvements and Cultural Changes (organization level)
My conviction : ADDITIONAL KEY ELEMENTS are required to succeed (their relative importance is contextual and depends on the nature of the project):
- User Experience activities (Interaction Design, Usability, Information architecture have proved their efficiency to support Team work and to facilitate project progress); and UX is directly linked to business value !
- Appropriate Agile Testing strategy, based for example on Brian Marick, Agile testing Quadrants (a great model)
- Lean thinking (Long term Philosophy and other management principles from the TPS or LSD, eliminate waste, amplify learning, deliver fast, …) applied to processes and organization
- XP Development best practices (still extreme in 2009?)
Anything else for you ?
