Archive for the ‘Development Methodologies’ Category

Professional Scrum Master

March 23, 2012

Hi all.

Looking forward to attending the PSM course on Monday 26/03.
Shortly after I’ll be going for the exam.

I’ve been mostly working in a scrum environment since around 2007.
Now I’m looking at solidifying some of that experience and knowledge, and gaining a little more hopefully?

Here’s the outline.

Scrum.org has designed the Professional Scrum Master (PSM) program to have the utmost rigor. The program’s courses, assessments, and certifications give participants the knowledge they need to use Scrum effectively and the credentials they need to communicate this ability in the marketplace.

Audience

The audience of the PSM course includes those that help lead the software development process in an organization. PSM is specifically targeted at the role of the Scrum Master, but the lessons are applicable to anyone in a role that supports a software development team’s efficiency, effectiveness, and continual improvement.

The Course

The Professional Scrum Master course is the first significant update of the Certified ScrumMaster (CSM) course that Ken Schwaber first created in 2002. This course covers Scrum basics, including the framework, mechanics, and roles of Scrum. But it also teaches how to use Scrum to optimize value, productivity, and the total cost of ownership of software products. Students learn through instruction and team-based exercises, and they are challenged to think on their feet to better understand what to do when they return to their workplaces.

Scrum.org maintains a defined curriculum for the Professional Scrum Master courses and selects only the most qualified instructors to deliver them. Each instructor brings his or her individual experiences and areas of expertise to bear, but all students learn the same core course content. This improves their ability to pass the Professional Scrum Master assessments and apply Scrum in their workplaces.

The Professional Scrum Master course (previously known as the Scrum In Depth course) covers Scrum basics, including the framework, mechanics, and roles of Scrum. But it also teaches how to use Scrum how to optimize value, productivity, and the total cost of ownership of software products. Students learn through instruction and team-based exercises, and they are challenged to think on their feet to better understand what to do when they return to their workplaces.

The course curriculum covers:

  • Scrum Basics. What is Scrum and how has it evolved?
  • Scrum Theory. Why does Scrum work and what are its core principles? How are the Scrum principles different from those of more traditional software development approaches, and what is the impact?
  • Scrum Framework and Meetings. How Scrum theory is implemented using time-boxes, roles, rules, and artifacts. How can these be used most effectively and how can they fall apart?
  • Scrum and Change. Scrum is different: what does this mean to my project and my organization? How do I best adopt Scrum given the change that is expected?
  • Scrum and Total Cost of Ownership. A system isn’t just developed, it is also sustained, maintained and enhanced. How is the Total Cost of Ownership (TCO) of our systems or products measured and optimized?
  • Scrum Teams. Scrum Teams are self-organizing and cross-functional; this is different from traditional development groups. How do we start with Scrum teams and how do we ensure their success?
  • Scrum Planning. Plan a project and estimate its cost and completion date.
  • Predictability, Risk Management, and Reporting. Scrum is empirical. How can predictions be made, risk be controlled, and progress be tracked using Scrum.
  • Scaling Scrum. Scrum works great with one team. It also works better than anything else for projects or product releases that involve hundreds or thousands of globally dispersed team members. How is scaling best accomplished using Scrum?

Prerequisites

The Professional Scrum Master course is primarily targeted at those responsible for the successful use and/or rollout of Scrum in a project or enterprise. Attendees will be able to make the most of the class if they:

  • Have attended the Professional Scrum Foundations course
  • Understand the basics of project management.
  • Understand requirements and requirements decomposition.
  • Have been on or closely involved with a project that builds or enhances a product.
  • Have studied the Scrum Guide.
  • Have read one of the Scrum books.
  • Want to know more about how Scrum works, how to use it, and how to implement it in an organization.

Assessment and Certification

As a matter of principle, Scrum.org feels that certification should be available to all those who possess a particular level of knowledge — not only to those who have taken a class. As a result, they offer the option of Professional Scrum Master I and II assessments to the public — not only to those who have taken the Professional Scrum Master course. The Professional Scrum Master program features two assessments and two levels of certification.

Employing Scrum

August 29, 2011

In this post, it’s my intention to bring some clarity to the following question.

Why does a business decide to employ Scrum as the chosen framework that their development team/s use for managing the business’s projects / work items?

Philosophy

A team that sets out to run by the Scrum framework, should

  • Do so with the intention that Scrum is just a path way to building a more efficient team.
  • Expect that in a years time, the process’s they are using,
    should be different to those that they started using when they first started working with Scrum.

What I mean by this is, textbook Scrum is a great starting point,
but you shouldn’t expect to be doing things the same way in say, a years time.

Teams enter the scrum playing field with the Kaizen philosophy of aiming for continual improvement.
Not just in terms of product output, but also on a personal level.
Who wants to buy into a methodology that only provides benefit to the business they work for?

The team should

  • Learn it’s strengths and weaknesses.
  • Celebrate and acknowledge success.
  • Continually improve on areas that require improvement.

Scrum is designed to facilitate these principles.

Many of the Scrum procedures focus on the five foundational elements of Kaizen.

  1. Teamwork
  2. Personal discipline
  3. Improved morale
  4. Quality circles
  5. Suggestions for improvement

Out of the above elements
The following three key factors arise.

  1. Elimination of waste and inefficiency.
  2. The Kaizen five-S framework for good housekeeping.
    1. tidiness
    2. orderliness
    3. cleanliness
    4. standardized clean-up
    5. discipline
  3. Standardization.

Artefacts

User Story

An item of work to be completed in a Sprint.
Often a good idea to aim at creating User Stories that can be completed within a week by one or two members.
Some written by the team often with the help of Stakeholders, Product Owner.
Some written by a developer which formulates the User Story based on understanding of the Stakeholders requirements.
Written from the perspective of the end user,
or who will get the benefit of the completed work item.
The three components of the User Story are,
Actor, Action, Achievement, as in the following form.
As an <Actor> I want to <Action> so that <Achievement>

For example

As the User of the new system, I want to be able to submit a new support ticket,
so that I can record the clients concern in sufficient detail.

Task

Tasks are created in the Sprint Planning meeting,
once the User Stories have been pulled onto the Task Board.
Each User Story is broken down into tasks by the team, and then given a time estimate.
Each task shouldn’t take more than a day for one person, preferably no more than 5 hours.
Both functional and non-functional requirements should be considered.
A typical set of tasks may include the following

  • Test Conditions (or just a design session for the story)
  • Test Suite
  • Unit Tests
  • A set of development tasks
  • Acceptance Tests
  • Integration Tests
  • Code Review
  • Documentation (wiki, barely sufficient)
  • End user documentation

Release Burn down Chart

On large projects,
where most/all of the User Stories have been defined prior to start of Sprints,
a manager can also maintain a Release Burn down.
This shows the amount of work left before product release.
The Release Burn down usually covers multiple / many iterations (sprints).

Sprint Burn down Chart

Shows quantitatively, the remaining work left on the Sprint Backlog.
This is updated after each daily Standup.

Product Backlog

The collection of User Stories waiting to be pulled into a Sprint.
Created before Sprints start, and maintained while Sprints are running.
Each user story is given a Story Point value, based on gut feel of how much work is involved in the User Story.

Sprint Backlog

The User Stories that have been pulled onto the Task Board by the Scrum Master, at the Product Owners request, at Sprint Planning.
The Sprint Backlog is owned by the team.
Workers pull tasks from Todo column into In Progress through to Complete.
Each worker aiming to have as few tasks In Progress at any one time.

Definition of Done

This is a team statement that defines what it means for every User Story to be completed.
If a User Story is done,
it forms part of the Potentially Shippable product that each sprint must deliver.
A list of done criteria.
An example could be

  •         Code Complete
  •         Unit tests written and executed
  •         Integration tested
  •         Performance tested
  •         Documented (just enough)

Roles

Stakeholders

Those that have a direct interest in the project (customers, vendors)
Directly affected by the projects outcome.
Only directly involved in the process during the Sprint Review meetings

Product Owner

Represents the Stakeholders, and what they want.
Is accountable for ensuring that the team delivers value to the business.
Often a member of the development team,
but shouldn’t be combined with the role of Scrum Master.

Managers

Responsible for setting up the team,
scheduling and actioning Scrum Master concerns (team blockers).

Scrum Master

It’s the Scrum Masters responsibility to make sure the team delivers what it signed up to deliver.
Acts as a buffer between the rest of the team members and any distracting influences.
Remove impediments, and liaises with Manager.
Enforces rules,
and keeps team members working to Scrum guidelines
Keeps team focused on task board and what they have to deliver.
Facilitator, Servant Leader.

Team

The body of individuals that form a multi functional unit,
responsible for delivering the Potentially shippable body of work defined by the Sprint Backlog each Sprint.
Typically made up of 7 plus or minus 2 cross-functional workers.
Roles included: BA’s, Testers, Technical Writers, Engineers.
The Scrum Team in Scrum terminology are known as ‘Pigs’,
whilst everyone else are known as ‘Chickens‘.
See Pigs and Chickens for the story.

Meetings

Sprint Planning

First section

Product Owner and Team communicate and decide on which User Stories from the Product Backlog will be pulled into the Sprint Backlog.
Often Planning Poker is used to make sure the Team still agrees with the Story Point values attached to each User Story.

Second section

Attended by the Team, which defines the Tasks and attach time values to them.
Time values are then added up to create the total expected hours for the Sprint.
The Team,
then records all the hours available from all of the Team members minus contingency time.
If the total expected hours are greater than the available hours,
the Team lias and decide whether or not to pull a User Story from the Sprint Backlog back to the Product Backlog.
The Product Owner will then be consulted on which User Story to remove.

Standup

Usually time boxed to 15 minutes.
Performed every morning, same place, same time.
Everyone is welcome,
but only Team, Scrum Master and Product owner are usually allowed to speak.
Make sure the Task Board is updated prior to meeting commencing.
While talking to the Task Board, each Team member specifies the following

  • What they have done since last Standup
  • What they intend to do today
  • What they see as blockers, or hindering them in achieving goals

Scrum Master address’s any blockers and provides direction to alleviate.
Larger organisations have a Standup of Standups to discuss overlapping concerns.

Sprint Review

Held on the last day of the Sprint.
Review work that was completed and not completed.
Delegate completed sections of work to Team members to demo to Stakeholders.

Show And Tell

Each member demo’s the work they were assigned to demo to the Stakeholders.
This provides insight into how the team is progressing.
Assists with buy-in.
There should be no surprises here,
because the Stakeholders were included in creating User Stories,
and the Product Owner has worked closely with them.

Sprint Retrospective

Reflect on finished sprint.
What went well, what didn’t go so well.
How we can improve the process.
Produce action plans for points raised and assign to a Team member to facilitate for the next Sprint.
Between 30 to 60 minutes in duration.

Procedures

Planning Poker

Applies Story Points to the User Stories.
Each team member holds a card up with a number,
representing how much work they think is involved in completing the User Story.
The DoD must be defined,
and often the member knowing the most about the User Story will provide a brief detailed explanation of what they think is involved.
Often performed when initial Product Backlog is created, and also as part of the Sprint Planning meeting.
This aids the Product Owner in prioritisation and planning ahead.

Sprint

A set length period of time in a series,
in which a collection of User Stories,
that the team has committed themselves to completing are embarked upon.
This period of time usually ranges from one week to four weeks and is performed consecutively.
A successful Sprint is defined by having all of it’s User Stories complete according to the DoD.

Summary

Text book Scrum, has for many business’s, what often seem like wasteful procedures.
Often what you find, once you’ve started with Scrum,
is that quite a few of these procedures are in fact very helpful,
and provide real benefits to both business and all those involved in the framework.

Teams enter the Scrum playing field with the express intention of improvement.
We have the luxury of learning from other teams mistakes and improvements,
as Scrum is not a new idea.
As Agile methodologies are fairly well defined,
and offer considerable flexibility to allow and promote change,
in the environments they are employed in.