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/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 ?
