Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

How To Do Change Management in Scrum?: User Stories

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 2

HOW TO DO CHANGE MANAGEMENT IN SCRUM?

There is no explicit change management function in a scrum setup. Change process is embedded in the sprint
where direct access to users in sprint review allows for feedback and knowledge sharing. 

In an agile environment we also assume that people are interested, engaged and self-motivated. All
employees are accountable themselves to seek the information they need in order to deliver to their goals.
HOW TO DO LONG-TERM PLANNING IN SCRUM?

Long-term planning is done light-weight. Scrum is optimized for incremental product development, and
long-term plans should be kept at high level and refrain from commitment. A Product roadmap is a high
level feature idea that together with the Product vision serves to get a better helicopter view. The roadmap is
constantly changing and is not a commitment.

HOW TO DEAL WITH RESOURCE PLANNING?

OR

HOW TO DEAL WITH DEPENDENCIES?

Scrum and agile development is based on humans collaborating on creating great things together.
“Resources” is a term that associates to soulless machines and should be forbidden. In a practical sense
teams are organized by people with all the competencies to solve what is prioritized in the product backlog.
Hence the need to move team members is minimized. A team should be co-located and 100% dedicated. If
there is a need to "allocate resources" or understand what skills are needed in the scrum team, you could start
of with 2-3 developers, a UX-designer and a tester. Plus a scrum master and a Product Owner. After a few
sprint iterations, you will see what's needed in order to be succesful. This is not so easy to simulate. If you
need to create some kind of forecast, you need to commit to at least 3 months of scrum for 8 people. This is
around 6 sprints, which is enough to start seeing the first results of your product development.

WHO IS THE LEAD DEVELOPER IN A SCRUM TEAM?

Scrum recognizes no other titles than “developer/team member”, “scrum master” and “product owner”. It
optimizes towards anyone in the team taking as much responsibility as they are capable of. Furthermore,
reducing the bottleneck related to highly specialized roles and senior titles.
WHERE DO I STORE MY USER REQUIREMENTS?

In scrum we work with User Stories, which means that it all starts with a user need, rather than a detailed
requirement. In a User story, we write it like this: "As a <person> I need <feature> so that I can do
<something>". 

We also add the Acceptance Criteria, which is a list of things to finish the sentence "I will accept this story
when I can...". The User stories represents a need from the Product Owner, who represents the users. The
User Story will later be broken down in to workable tasks, that each and everyone could be finished during
the sprint as well as potentially shippable, adding to a new product feature increment.
HOW DO WE SCALE SCRUM?
The first line of defense against large projects is to attack them not with one large team but with multiple
small teams. If we at point really need to scale, there are a couple of frameworks that helps us understand
and could be useful to avoid getting in to complexity which comes with multiple roles, hierarchy and top-
down management - some frameworks also has a lot of pre-planning/pre-impediment removal. This could be
good, but be aware that all "of the shelf" frameworks are usually prescriptive, meaning it tells people what to
do. One of the core agile princples is to value people over processes and tools and it's important to not forget
that. 
Out-of-the-box ready solutions like SAFe (Scaling Agile for Enterprise) are highly disencouraged because of
the above. Our main goal with running with agile in the first place is to enable and set the scene for
innovation. Though innovation can be processed through synthesizing of ideas, we believe SAFe doesn't
allow for this to the same extent. We simply want to start with the people.
Once the people understands where we want to go, and they know "convential" methodologies where we try
to be perfect and super-plan it all doesn't work, we can start having a conversation about scaling scrum. We'd
recommend (Large-Scale Scrum)
Read what Ken Schwaber, founder of scrum, thinks about SAFe.
WHAT TO DO WHEN TEAM MEMBERS CAN'T PICK UP THINGS FROM THE BACKLOG?

The idea of a "scrum" in an agile context is that the team "scrums" around solving the problem by finding a
solution together. Ideally everyone should be able to take any user story from the backlog, but in reality this
may be hard to achieve. In agile environments, with highly motivated individuals in high performing teams,
team members see new user stories outside their normal specialization or knowledge area as a challenge and
an opportunity to learn. One way would be to pair-program with colleagues and another to explore and learn
new things. So instead of having highly specialized team members (aka back-end, front-end), T-shape
profiles or better explained "broader area of expertise" is needed to be fully successful.
WHERE ARE THE MANAGERS IN AGILE ORGANIZATIONS?

Nowhere. In agile organizations managers needs to transform from traditional "Theory X"
Command and control/push principles to a "Theory Y" people focused leadership designed to
motivate, engage and empower self-organized teams. With a flat organizational structure where
senior leaders are available and reachable to team members. Basic leadership principles like
empowered teams are covered in our leadership training.

As one person participating in the trainings said:

Be the frame for the picture - > Make the agile team stand out not by limiting (framing) but by
enhancing the strength and details.

You might also like