Posted by jc-Qualitystreet on 2011/02/21
… the team is now sprint#9, one week before the end of the release.
- All items of the Product Backlog are DONE (except the 5 user stories placed in the “to do” column of the current sprint. These stories are already delivered to internal testers)
Product Backlog: no "To do" items remaining!
- Customer is delighted by the product he has received (incrementally). Very positive feedback sprint after sprint.
- Product quality is good: the application is fast, robust and secure
- Team satisfaction is high (best score)
Team Satisfaction High : "I am glad I’am part of the team and satisfied with how our team works together"
- Trust and transparency are characteristics of the team
- Management satisfaction is high. managers plan to keep the team and to assign it a new product to work on
- Sprint burndown chart of the current sprint is good
A good Burndown Chart !
- Team velocity is good and steady since 4 or 5 sprints
- Team focus factor is high
- Team accuracy of estimation is good
- Action items of the previous action plan are done
Actions items are tracked. Everything was done at the end of the sprint. The poster was displayed on the wall during the sprint.
- Just a few defects in the Bug tracking system
- No impediment
No impediment in the Impediments list
What else?
Just that it was a pleasure to coach such a good team! Thanks you guys.
Posted by jc-Qualitystreet on 2011/02/14
I usually say to Agile teams that the most important outcome of a sprint (or release) retrospective (but also important workshops), is the Action Plan.
Scrum Retrospective Action Plan. A crucial element of facilitation.
Both past and future oriented, the SCRUM retrospective meeting aims to discover what the team did well, understand what went wrong, and to find ways to improve. It’s an important and intense exchange and communication event.
But completing an action plan, at the end of the retrospective, is the only way to make it fully successful and to engage the team in a continuous improvement approach (Inspect & Adapt) for better performance.
Simple
Concise and just enough…
Only a short list of actions (4 max) and three columns that make it simple and effective.
- What (the action: task-oriented, smart and with a verb)
- Who (the owner of the action)
- When (the agreed due-date)
Visual and visible
Build in collaboration on a large sheet of paper. At the end of the meeting, the action plan will join the team’s information radiator, into the team’s workplace to make it visible every day by everybody’s eyes. Communication is crucial for continuous improvement, and visual management is an effective strategy to make the follow up and to maintain engagement.
At the end of the next sprint, actions items of the previous plan will be reviewed: Done or KO…
SMART
Of course, the actions included in the “what” column are SMART:
- Specific
- Measurable
- Achievable
- Realistic
- Time-bound
Then, I like to get the team’s commitment to the plan before closing the meeting and doing the ROTI (Return On Time Invested).
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/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!
