“Americans hate their jobs more than ever” … ”Majority of Americans dislike their jobs” …

These are only 2 examples of a quick google search that returned over 44.1 million pages. Try “I hate my job” and the content of the pages returned is also very sad.

I don’t intend to go into socio-psychological analysis in this post but I wonder if something as simple as trusting your employees to do their job properly would actually increase job satisfaction?

For most people, enjoying their job would simply mean doing the same type of work but in a different work setting. Many people have spent years studying to develop their expertise in a specific field that they love. Then, one day, they start working and life becomes miserable – not because they hate what they are doing but because of the way the are treated at work. Once again, I don’t want to go into harassment or this type of treatment. The only point I’m raising is that letting professionals determine the best way for them to complete their work would is such a simple of increasing job satisfaction.

“Yes, but I’m the boss” – you reply.

So what? The fact that you were hired to lead or manage people in achieving a team or departmental objective doesn’t make you the most qualified individual to resolve day-to-day issues.

“Yes, but I’ve done this job before” – you insist.

Once again, so what? The individuals performing the job now bring different skill sets and expertise to the equation and as such are qualified to address their work as they see fit. You may provide guidance or answer your employee’s questions when they come ask for help but not tell them how to do their job.

Put together a community of expertise so people doing similar work can support each other. Provide tools if they need, support your employees in finding the right answers to their problems but don’t tell them how to do it.

There is a small Japanese car-manufacturer that understood that concept a while ago. They are now the largest car manufacturer in the world. Don’t you wonder how they achieved their success?

You might be interested in these related posts:

1. Stop treating me like a grown-up
2. Stuck in a dead-end job…
3. Someone is looking for a job

For those interested, I’m sharing “Introduction to Scrum“. It is a power point presentation covering the following topics:

• Problems with a traditional approach
• What is Scrum?
• Why use Scrum?
• How does Scrum work?
• The Product Owner
• The Scrum Master
• The Team
• The Product Backlog
• Benefits of using a Product Backlog
• The Sprint Backlog
• The Scrum Cycle
• The Burn Down Chart

You can copy, distribute, and use the content of the presentation in accordance to Creative Commons Attribution 2.5 License.

You might be interested in these related posts:

1. Scrum Artifact: Burn Down Chart
2. What is Scrum?
3. Scrum Role: The Scrum Team

Scrum is an Agile management process that uses an iterative and incremental approach to deliver complex software development projects.

The Scrum Cycle

The three fundamental roles of Scrum are : the Product Owner, the Scrum Master, and the Scrum Team.

The Scrum cycle is divided into five activities to be completed by the Scrum Team in order to meet their commitment to deliver on the work included as part of the sprint backlog.

Define

During the definition phase, the project team (the Scrum Master and the Scrum Team) meets with the Product Owner to determine and agree on the priority of the team for the duration of the sprint. The intent is not to agree on the details during this stage but the high level direction the team will follow. The outcome of the definition stage is to start populating a product backlog.

Plan

Planning consists of selecting the high level items from the product backlog and evaluate the value of the various items as well as the estimated efforts to complete the work. As part of a negotiation process between the Product Owner and the Scrum Team, a subset of the product backlog is selected which is then called the Sprint Backlog.

Build

Much happens during the building phase where the development team members select and execute tasks from the Sprint Backlog until all work is completed and a “product” is ready to present to the Product Owner.

Review

At the end of each sprint, the Scrum Team presents the various items that have been developed during the sprint to the Product Owner. This practice has a few clear benefits in that unless metrics can be demonstrated in the application – not on paper or in theory – and shown to provide the expected information, they are not completed.

Retrospect

The final step of the iteration is the retrospection which has a few objectives where the most important one is to allow the team to reflect on the successes and determines which areas need to be improved prior to entering the next sprint. As such, the team collectively assesses its own performance and determine the best way to adapt in order to successfully achieve its next sprint.

You might be interested in these related posts:

1. Scrum Artifact: Sprint Backlog
2. Scrum Role: The Scrum Team
3. Scrum Artifact: Product Backlog

The Burn Down Chart

Definition

A burn-down chart is a graphical representation that shows the progress made during the development cycle.

The Burn Down Chart can be used to show outstanding work for a release or for a sprint and in both cases, the chart represents the amount of work remaining for the completion of the release or sprint versus time.

How the Burn Down Chart works?

The vertical axis (Y-axis) of the chart presents the work remaining to complete the release or sprint while the horizontal axis (X-axis) represents the time.

Scrum Burn Down Chart

The chart typically presents 2 lines going from the top left section of the chart towards the bottom right.  While the first line presents an estimate of work delivered over time, the second line shows the actual values. As such, the Burn Down Chart is useful for predicting when the work scheduled for the current release or sprint will be completed.

You might be interested in these related posts:

1. Scrum Artifact: Sprint Backlog
2. Scrum Artifact: Product Backlog
3. Introduction to Scrum – Shareable Power Point Presentation

The Scrum Team

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the Scrum Team.

Definition

The Scrum Team is a self-organized group of up-to 7 individuals with no pre-defined roles who work in collaboration to deliver upon their commitments. The Scrum Team is often comprised of cross-functional individuals who work to successfully complete the activities identified as part of the sprint backlog.

What the Scrum Team does

The Scrum Team is responsible for the following activities:

• Following a negotiation with the Product Owner, selects the goal of the sprint;
• Organizes itself and its work;
• Plans and executes the tasks identified during the Sprint Planning Meeting;
• Determines the appropriate methods of delivering on their commitments;
• Presents the resulting work to the Product Owner.

You might be interested in these related posts:

1. Scrum Role: Product Owner
2. Scrum Role: Scrum Master
3. Scrum Artifact: Sprint Backlog

The Scrum Master

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the Team.

Definition

As an Agile Project Manager, the Scrum Master is the person responsible to ensure the adoption and adherence to the Scrum process. With no formal authority over the Team, the Scrum Master facilitates the various activities and maintains the Burn Down Chart.

What the Scrum Master does

As a liaison between the Product Owner and the Team, the Scrum Master is responsible for the following activities:

• Helps the team maintain their productivity by removing barriers and preventing interferences;
• Supports the Product Owner in achieving the project’s goals;
• Facilitates communication between the Product Owner and the Team;
• Updates the Burn Down charts and other artifacts to make team progress visible;
• Organizes and facilitates the key meetings: definition, planning, building, demonstration, and retro-spection.

References:

• Scrum Alliance -Scrum Roles
• Learning Scrum – The ScrumMaster
• The ScrumMaster Role

You might be interested in these related posts:

1. Scrum Role: The Scrum Team
2. Scrum Role: Product Owner
3. What is Scrum?

The Sprint Backlog

Definition

Similar to the Product Backlog, the Sprint Backlog is a list of tasks that the Scrum team is committing to deliver within the current Sprint. The Sprint Backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of the Sprint.

How the Sprint Backlog works

Based on the priorities set by the Product Owner, the Scrum team selects as many items from the Product Backlog as they believe they can complete within the current Sprint.

Sprint Backlog creation happens in the second part of the Sprint Planning meeting with the participation of every team member.  It is critical that the team selects the items and size of the Sprint Backlog since they will be the ones committing to completing the tasks.

During the Sprint the Scrum Master maintains the Sprint Backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done.

• Learning Scrum – The Sprint Backlog
• Scrum (development) – Wikipedia, the free encyclopedia
• Scrum Alliance -9 Tips for Creating a Good Sprint Backlog

You might be interested in these related posts:

1. Scrum Artifact: Product Backlog
2. Scrum Role: The Scrum Team
3. What is Scrum?

The Product Owner

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the team.

Definition

The Product Owner is the one person responsible for the project’s success. The Product Owner leads the development effort by conveying his or her vision to the team, outlining, and prioritizing it based on business value. As such, the Product Owner is responsible for representing the interests of everyone with a stake in the resulting project.

The Product Owner differs from that of the traditional Product Manager role in many ways.

What the Product Owner does

As the owner of the product vision, the Product owner shoulders all the responsibility for the project success and is ultimately responsible to the Team, stakeholders and to the company.  Here are some of the activities perform by the Product Owner:

• Creates and maintains the Product Backlog;
• Prioritizes and sequences the Product Backlog according to business value or ROI;
• Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single Sprint;
• Conveys the Vision and Goals at the beginning of every Release and Sprint;
• Represents the customer, interfaces and engages the customer;
• Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives;
• Inspects the product progress at the end of every Sprint and has complete authority to accept or reject the work done;
• Can change the course of the project at the end of every Sprint;
• Communicates status externally;
• Terminates a Sprint if it is determined that a drastic change in direction is required;
• Understanding and communicating the customer needs;
• Meeting the project goal and financial targets such as return on investment (ROI);
• Collaborates with the team and aligns with the stakeholders throughout the entire release.

References:

• Learning Scrum – The Product Owner
• Top 10 Activities of the Product Owner
• Agile Product Owner and Agile Product Manager in the Enterprise: Part 1- On Product Owners AND Product Manager
• Scrum Product Owner
• InfoQ: Creating Product Owner Success 

You might be interested in these related posts:

1. Scrum Role: The Scrum Team
2. Scrum Artifact: Product Backlog
3. Scrum Role: Scrum Master

As I’m gathering information and slowly writing the content of my book, there is some information I need to refer to in the book but I don’t want to include as it distracts the reader. As such, I decided to start keeping that information and post it on this blog. It will be easy to know when a blog post is done in the context of the book as it will be tagged “the agile bi book“. Today’s post relates to the Product Backlog.

The Product Backlog

Definition

The Product Backlog is simply a list of customer requirements needed to complete the project and sorted by business value. It is initially prepared at the beginning of a project by the Product Owner and remains active throughout the duration of the project as completed items get removed while new items are added.

How the Product Backlog works

As time goes by, the highest priority items in the Product Backlog get broken down into smaller chunks as they become part of the Sprint Backlog.

The Product Backlog is property of the Product Owner while the business value is set by the Product Owner, the development effort is set by the team. 

Benefits of using a Product Backlog

• It’s a simple list, discussed face-to-face;
• It provides the customer with control;
• The product backlog is allowed to change;
• Inspection and adaptation;
• It resolves dependencies timely;
• It allows for some longer term planning.

In Summary

The Product Backlog:

• is simply a list of things needed to be done in the context of the project;
• always lists items that add value for the customer;
• may include functional requirements and non-functional requirements;
• can also include items required by the team, but only the ones that will eventually bring value to the customer;
• cannot include low level tasks. 

References:

• Scrum Alliance -Scrum Artifacts
• Scrum (development) – Wikipedia, the free encyclopedia
• Product backlog | Agile Software Development
• Learning Scrum – The Product Backlog

You might be interested in these related posts:

1. Scrum Artifact: Sprint Backlog
2. Scrum Role: Product Owner
3. What is Scrum?

I failed.

There it is, in writing for the world to see. You might think it is a bad idea to write about a project that failed – especially since I was the product owner. Fair point but I would have to disagree for the following reasons:

• If we spend time reflecting on the reasons behind our failures, we can learn more than when we succeed. Success leads us to believe we know how to lead a project and that we are a key contributor to the success of the project. What can we learn from success? Failure is a humbling experience and spending time to analyze our decisions allows us to improve our abilities in the long run. So failure isn’t good but failure without retrospection is even worst – unless you are looking to repeat your mistakes.
• If you want to grow as a person, you need to take some risks. The same logic applies to organizations that want to grow, they will also take some risks. As a consequence, if you want to take risks, you better tolerate failures. As Michael Dell once said, it’s OK to fail as long as you fail quickly and gracefully.
• Someone else (I don’t remember who it was) said that you judge people’s character not by the number of time they failed but by how quickly to got back up on their feet and went on to tackle another challenge. The point here is not to run away from your failures but not to sob and feel sorry for yourself.

So here’s the short version of my failed project.

About six months ago, I presented to our executive committee the idea of launching a content based web community geared toward Agile software development.  There area already some well known sources of information around agility and some more specific geared toward Scrum but there isn’t a single leading source of information in French (being located in Canada and serving Quebec and France, this is an important need for people we work with). I thought it would be a great way to contribute valuable content to individuals and organizations looking for help in their implementation of agility.

As a true innovator, my boss challenged me to think of the next generation of a web community. Let’s not use what exists today and let’s create a place where people will enjoy gathering – not just a blog or a wiki but something better! So the project began.

After a few weeks, a few of us had brainstormed the new concept, pitched the idea to a few colleagues and went on to do a Sprint 0 (see below for the definition of a Sprint 0). The new concept was a tool that would support collaborative text edition where the community would vote on the best content. Since it is unlikely that we will initiate the same project twice, I might write about some of the project details in an upcoming post. Stay tuned for that.

So a small development team and a Scrum Master were assigned and we started our first sprint of 2 weeks. Than the usual product demo took place followed by the sprint retro. Then another round of sprint planning, execution, demo, and retro. We repeated the process for a few weeks until we realized we weren’t making enough progress. Quality code was being written, must product demos were successful, the team retrospection were informative and the team was increasing its velocity. So why weren’t we getting closer to the goal?

The make a long story short, the concept turned out to be innovative and the development project turned into an R&D project where most of the efforts were spent on the research part. So after 4 months of iterative development, I killed the project!

What I learnt in the process is the following:

• In an organization where there are many competing priorities, launching a new content based web community is a challenge in itself. Adding to the complexity of the original project by launching an innovative collaborative text editing plate form isn’t a smart idea. It would have been a thrill to hit a home run but getting to first base would have been a better strategy. It might not be as glamorous but it is a safer bet and there is always the opportunity to build incrementally after you get the first version out.
• Execution is much more difficult than coming up with an idea. Since the idea seemed good and that people agreed with the concept it was easy to believe we could deliver an outstanding product.
• Every organization is resistant to change, so when a new idea is launched internally it is critical to explain the vision and the benefits to as many people as possible to get their buy-in and identify potential pockets of resistance. It is naive to assume that everyone will see the value of the new concept and will immediately accept it. Once the idea is conceived, promote it as if it was already ready to launch.

It is great to work with an organization that supports entrepreneurship and that invests in its people. Next time around, I will get to first base…

Note: The purpose of a Sprint 0 is to draft a project charter that includes the following elements: vision for the project, objectives, assumptions, success factors, success criteria, roles and responsibilities, priority matrix (scope, time line, and budget), risks, and mitigation. In addition to a project charter, the planning stage allows the project team to start populating the product backlog.

You might be interested in these related posts:

1. Scrum Role: Product Owner
2. Owner of the Strategic Process
3. Scrum Artifact: Product Backlog