Plan to Learn is important concept and competency in Agile/SCRUM.
Management strives
to foster team learning in different ways. If the scrum team behaves as whole
team, if the scrum team is self-organized- this is when scrum master becomes
happy and satisfied. Hold on! There are always scope of learning and
improvement. The team is already performing, product owner is happy. Then why
team needs improvement? Striving and achieving for knowledge improvement is
again incremental and iterative process like SCRUM itself.
I must quote Mike Cohn’s
remarks here. He discussed how to ensure learning conditions exist in the team.
In the proactive pursuit of
team learning as a goal of the project, there are five conditions that are
necessary for team learning to occur:
1.
Teams must be
designed for learning.
2.
Individuals must
have concrete ways of sharing knowledge.
3.
Leaders must
reinforce the importance of learning.
4.
Teams need to be
presented with motivating challenges.
5.
A supportive
leaning environment must exist.
I believe these are the soft
skills the leaders can cultivate in the team. Scrum team along with leaders can
grow together as a “whole team”.
If the scrum environment is open
and management foster team learning, there are built-in meetings in scrum that
help to learn. Retrospective is one of them.
What is retrospective? Yes,
you are right. The parent of English word retrospective is Latin word retrospectare.
This means “Look back”. Why do we
look back? We look back with the intention to improve. This is team
improvement. The retrospective meeting is held by the whole team - Scrum
Master, Product owner, scrum team.
Who
is facilitator? Scrum Master. Scrum master can maintain retrospective log. This
is useful to validate the action items with next sprint’s events or actions.
When
does the meeting happen? Ideally it should happen at the end of each sprint,
when team’s memory is fresh. If the sprint length is two weeks, retrospective
normally happen at the end of the sprint, which is after sprint demo.
Ground
rules to have successful retrospective? Leaders may wish to lay ground rules
like:
1.
The team members need to give honest comments on what went well in the
last sprint, what did not go well.
2.
Agile/SCRUM preaches to keep retrospective meeting short, simple and
fresh. We followed Thinking Hat method to make the meeting interesting. We used
two kinds (colors) of sticky notes - Yellow hat and Black hat. Yellow hat
represents optimistic items - what went well. Black hat- what went wrong?
3.
Leaders should emphasize the learning aspect of retrospective, creating
open environment. He is refrained from pin-pointing a team member who did not
perform well and as a result velocity might not meet expectation.
4.
Promote active participation.
5.
Steal ideas from other scrum teams.
6.
Few steps/activities during retrospective meeting:
a.
Gather data,
b.
Analyze data
c.
Root cause analysis
d.
Generate insight
e.
Take decisions and
f.
Generate improvement plan if any.
The
improvement plan and the lessons learnt are to be applied from immediate next
sprint/iteration. For example, if there were significant impediments identified
in the middle of last sprint and the team mitigated the risk of derailment of
sprint schedule, should become a hot topic in the retrospective.
Retrospective
is different from project post mortem by nature. A project post-mortem is a process, usually performed at the
conclusion of a project. This is to determine and analyze elements of the
project that were successful or unsuccessful. Post-portem is performed when
project is in closing phase, meaning there is no scope of implementation of
lessons learned in the current project.
Learn through User Stories:
User stories can be defined
as Agile requirement that indicates who will benefit, what we’re trying to
accomplish, and clear acceptance criteria. Scrum team can learn about the
product/service they are working on if they are thorough with each user story.
Having
said this, user stories are different from well-formed requirement documents we
create and baseline in waterfall model. Let me explain this below:
Initially,
when the product is conceptualized, we have only high-level feature
descriptions. This might be called “Epic”. Epic can give general shape of a
product, but with missing specifics about functionality. Each feature is
progressively elaborated as the project progresses.
Why
progressively refine requirements?
·
Requirements
will change due to priorities change over time.
·
Deliver
as much as feature what is asked from scrum team, to give an early visibility
of the product to the product owner/customer.
- It helps us avoid falling into the trap of believing plan - While working in Waterfall model for quite sometime now, I have been creating test plan, reviewing test plan and baseline test plan. I do these series of activities when requirements for a project are said to be baseline. When I am happy considering my test plan is well-documented and is accepted by key stakeholders, I come to know there are quite a few CRs coming on the way and they have test impact. I have no other choice but to re-work on the plan including schedule.
Progressively refining a plan emphasizes the idea that even the best plan is subject to change.
User
stories are derived from Epic-level user stories. Epic
is divided into lower level deliverable user stories, forming product backlog.
So backlog is desired functionality not
present in the product. It is maintained by the product owner and can be shared
with whole team. In contrast with traditional requirement documents, product
backlog is dynamic in nature. Stories are added, removed, reprioritized each
sprint as more learned about the product. Fix of a defect can become a user
story in the next sprint or in current sprint if capacity allows.
User stories along with the
simple steps are written on a HTML file or WORD file, for the developers to
code. These are maintained in software tools.
One interesting fact is name
of the user stories are often written on sticky notes and arranged on walls or
tables to facilitate planning and discussions. Stories are arranged like: “Not
started”. “WIP (Work in Progress)”, “Completed” in the story wall. Don’t you
think if you are practicing agile/scrum, you are working in a vibrant ambiance?
Stories typically follow a
simple template:
As a (type of user), I want (goal) so that (some reason).
Gaining acceptance on user
stories:
Definition of “Done” – Team’s agreement on criteria to determine whether a story
is complete
Definition of
“Done Done” – Product owner’s acceptance on functionality required to confirm
successful completion of a user story.
I have heard an objection
while training the team on agile – “We are back-end software developers. We
work on database. Why do we have to create user stories?”
Yes. Back-end software
developers also have to create and follow user story if they are following
agile. We should remember user stories are small chunk of functionality a
team can produce in one iteration/sprint.
I have plan to further add some more topics under "Plan to learn" section:
1. Pair Programming
2. Simple design
3. Evolutionary design
4. Spiking
5. Refactoring
6. Team-based estimation
Coming up next .....till then Happy Reading!
No comments:
Post a Comment