All Posts Tagged Tag: ‘Project Management’

Don’t tell me you really want to increase your team’s performance – I won’t believe you 2

I bet you $50 that even if I told you the way to boost your team’s performance without increasing your costs – you wouldn’t do it. The situation is actually worst than that! I’ll add another $50 that I even know what you will tell me once I tell you. You will say “We can’t do that in our organization“.

Ready to find out?

Stop assigning people to projects and let them pick the project they wish to work on – that’s it!

I can hear you - ”We can’t do that in our organization” – there, I just saved $100.

Seriously, it is that simple. Think back to a project you worked on – were you assigned or did you select it yourself? Now do this exercise. Think back to something you enjoy, I mean you truly enjoy - were you assigned or did you pick it yourself?

Have you ever heard of Tom Sawyer withewashing the fence? As Mark Twain once said, “Work is something you are forced to do while leisure is something you choose to do”.

I don’t mean to pretend that work is a hobby but many organizations ignore people’s intrinsic motivation and personal drive when they (i.e. the managers) assign people to projects. No matter what the project is about, there will always be people interested in working on such a project. Ever heard of Crowdsourcing?

In most organizations, it may not be easy to let people select their own project, but it is feasible. Some organizational constraints may need to be modified, project assignment may need to be done differently, some resource planning may be required but all of this is feasible.

As one of the participant highlighted “I used to be bored to death in my normal job until one day, I asked (begged) to be part of a specific project. I’m so glad they granted my wish. I now work 55 hours a week! I am super motivated and nothing is going to make me want to leave that project”. Still think letting people select their project is a bad idea? - Analytical-Mind.

Go ahead, give it a try and see the results for yourself. I have tried this approach on many occasions and the results always impress me.

Posted on: 04-18-2011
Posted in: Autonomy and accountability, Collaboration and teamwork, Project Team

Status reporting in an Agile context – Introducing the SunSet Graph 3

You have implemented Scrum with some of your teams and get the following question – “How do we report project status to management?“.

If your organization is like most organizations, your choices are:

  1. You ask someone (the Scrum Master or the Project Manager) to convert (translate?) the information the team uses into the traditional management reports;
  2. You present the information exactly the same way the team is using it;
  3. You find a way to bridge the new reporting to the old reporting in order to reduce re-work.

If you have selected option #1, this post won’t help you much since there is no way for me to know what the traditional information reporting mechanism is within your organization.

If you selected option #2, you don’t need to read this post since you only need to show the information you already have compiled on its current form.

But if you went with option #3, you’re in luck. Well, kinda. My colleagues Mathieu and Elsa have come up with what they call, the SunSet graph [French] – because of its colorful presentation.

The Sprint Burn Down Chart

At the team level, many Scrum teams rely on the Sprint Burn Down chart. The Burn Down is very useful to present the amount of work remaining within the sprint in light of the time remaining. In addition, the Sprint Burn Down has the benefit of presenting true progress by comparison to a baseline in order to determine the team’s ability to meet the sprint timeline.

The Release Burn Down Chart

At a project level, a Release Burn Down chart can be used and is very useful for managers and people around the project to appreciate project progress as it presents actual progress in light of a project baseline. Just like the sprint burn down, the project burn down is a very visual way to present the amount of work remaining with regards to the amount of time left.


The SunSet Graph

The SunSet graph is a great complement to the other “Scrum” reports and is also geared toward management – although the team also benefits from producing it and having visibility to the information.

Just like the burn down charts, the Sunset graph gives visibility to the progress of the project – what is scheduled to be completed with regards to a baseline taking into consideration the estimated efforts by the team. With the associated product backlog, the sunset graph gives complete visibility to the content of the project. In addition to the Sunset graph, a financial graph can be added to give a one-view perspective of the project to managers interested in following the progress of the project.

The SunSet graph divides the user stories into 3 categories: Optional, Important, Mandatory. In a quick look, managers can easily follow the progress of the team in light of their commitment to deliver the stories based on the team’s velocity. Before the first Sprint, the team plots the number of sprints planned for the project (x-axis), the number of points to be delivered (y-axis), and the forecasted velocity.

At the end of each sprint, the team plots its progress by entering the number of stories completed and by adjusting their velocity based on actual numbers. The SunSet Graph Template can be downloaded.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 6 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 9 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 12 sprints.

The content of the template is updated at the end of each Sprint. Below, the SunSet graph after 15 sprints.

By using a visual presentation of the project progress. It becomes easier for managers to understand at a high level the issues encountered by the team. Managers can then focus on anticipating potential budget excess or non-delivery of mandatory stories as opposed to focusing on the content of the project. In addition the keeping managers informed, the Sunset graph supports the concept of the self-organized team.

Posted on: 12-7-2010
Posted in: Communication and knowledge sharing, Processes and Tools, Tools

Interesting blog posts (February 1, 2010) 0

Eric’s great posts on project management, comparing Scrum and PMI

One of my preferred antagonists was the all mighty monolithic Project Management Institute (PMI) and its PMP disciples. In an attempt to keep my friends close and my PERCEIVED enemies closer, a colleague and I decided to attend the PMI bootcamp – a five day course to prepare for the PMP certification. - An Agile coach’s journey into PMI country – Day 1 – I’m very disappointed! | Pyxis blog.

What we’ve got here is process number 3.4.4 in the PMBoK and this, I believe, is where the PMI got cocky. WBS is so central to the PMI that our trainers would actually say that if you don’t have the answer to a certification question and WBS is one of the options – choose it! - An Agile coach’s journey into PMI country – Where PMI got cocky. | Pyxis blog.

Isaac’s post on why CIO should love Agile Development

In agile, the CIO is getting the following significant advantages: Low up front business investment (…) Frequent delivery leads to better execution (…) Allowing Sponsors to prioritize at the beginning of each iteration leads to better Business / IT alignment (…) . - Social, Agile, and Transformation: Why the CIO Loves Agile Development.

Israel’s post on why the Agile triangle should replace the Balanced Score Card

My recommendation to clients who do Agile as a strategic initiative is to drop the Balanced Scorecard and use the Agile Triangle instead. - Use the Agile Triangle Instead of the Balanced Scorecard « The Agile Executive.

On the value of building trust and respect within teams

This is because people are the engine that drives a high performance project. Without a good team that embodies trust and respect, the best process and tools in the world will not help you. I am as geeky about process as the next agilist, I love experimenting with Kanban and Lean and know that they offer better ways of executing projects. However, bigger improvements can be had from the people side of things. - LeadingAnswers: Leadership and Agile Project Management Blog: Building Trust and Respect.

On Recruiting “Normal” employees

I want/need to hire someone. Not a difficult task, right? I've been doing this for years and it's a simple process. I mean let's be honest – I'm not trying to launch the Space Shuttle into outer space – I just need to hire one “normal” employee. And therein lies my problem: “Normal Employee” wanted. - Fistful of Talent: Wanted: Normal Employee.

On Communication

John Gottman’s pioneering research found that marriages are much more likely to succeed when the couple experiences a 5 to 1 ratio of positive to negative interactions whereas when the ratio approaches 1 to 1, marriages are more likely to end in divorce. Additional research also shows that workgroups with positive to negative interaction ratios greater than 3 to 1 are significantly more productive than teams that do not reach this ratio. - Jon Gordnon’s Blog: The Power of Positive Interactions

Nicholas’ post on Ergonomic design

People will not care how well something is built if it is not appealing to them first and easy to use. Car designers and software designers alike are victim of this reality. - Ergonomy lessons learned : Ergonomy sells. | Pyxis blog.

Jim Highsmith on the book “The Starfish and the Spider“

Is there a person in charge? Completely decentralized organisms have no head, as in there is no “head” of the Internet. They relate a funny story circa 1995, when a CEO looking for startup funding couldn’t convince a room of potential investors that there wasn’t an Internet president — the concept was beyond them. - The Cutter Blog » Blog Archive » Understanding the Nature of Self-Organizing Teams.

Posted on: 02-1-2010
Posted in: Other Blog Posts

Project Charter – Agile Project 4

In the spirit of sharing, below is an example of  a Project Charter we use to launch a Agile Projects. Do you use a similar document? In which context? Are there sections that are more critical for the success of your projects?

Vision

The Electronic Balanced Scorecard (EBS) project for Company Y is designed to develop and implement a simple tool to aid the decision making process of all managers and to help them evaluate the impact of their actions and determine if it is in line with corporate strategy.

Objectives of the EBS Project

  • Total transparency of the information for all managers;
  • To generate conversations among managers with regards to the performance indicators;
  • The tool should be easy to use by everyone;
  • To monitor the performance of the organization with respect to the strategic objectives;
  • Supporting the decision making process of all managers;
  • Guide and adjust the strategic discussions.

Success Conditions

To have implemented all the key performance indicators (highlighted in green in the definition document) in time for the strategic meeting that will take place in November 2009.

  • The information must be accessible by everyone;
  • The information must be understandable by everyone;
  • The information must be updated within a pre-defined timeline;
  • The information must be relevant and practical for managers to use;
  • The strategic objectives must be defined, communicated, measurable and measured regularly;
  • The strategic objectives must be communicated to all managers prior to launching the project;
  • The ESC supports the decision making process of the managers on a daily basis.

Priorities and Compromises Matrix

  • Scope: Not Negotiable (priority 1)
  • Schedule: Negotiable (priority 3)
  • Budget: Difficult to Change (priority 2)

Risks

  • Adoption of the new decision-making tool by all managers;
  • Introduction of several new processes;
  • Incomplete and / or erroneous information
  • Availability of key managers;
  • Implementation of a Human Resource Management System;
  • Integration of financial systems from various countries.

Risk Mitigation

Implementation of a change management program.

Role of the various team members

  • Product Owner: Paul Bergeron
  • Scrum Master: Christine Clark
  • Team Members: Patrick Allen, Christopher Green, Anthony Stephanopoulos, Cynthia Martin
  • Ergonomics Expert: Francis Albert
Posted on: 08-12-2009
Posted in: Agile, Agile Business Intelligence, Leadership

Do we really need defined timeboxes? 0

Wikipedia defines time box as “In project management, a timebox is a period of time in which to accomplish some task. (…) If the team exceeds the date, the work is considered a failure and is cancelled or rescheduled“.

When using an Agile approach to software development, this is exactly the dynamic we are looking for. We use time boxes to ensure commitment by the project team to meet the defined time lines. As such, the objective of time boxing is to limit the efforts and activities of the project team to fit to an agreed upon time frame. The longer the time box, the least commitment you will get from the team.

In addition to commitment, time boxing has the amazing effect of creating a sense of urgency. We have all seen development projects
scheduled to be completed in 12 or 18 months with a big time box – a milestone – to deliver the complete application.

When this happens, the project team typically has a more relaxed approach during the early stages of the project only to spend nights and
week-end toward the end of the project to complete their tasks.

Implementing shorter time boxes forces a different team dynamic. If a team only has 2 or 3 weeks to complete their iteration, they cannot delay their activities too much and potential delays will more quickly come to the surface. Time boxing has the benefits of increasing the visibility of such situation.

Short time box also can be used as motivational factor allowing the team to frequently see the result of their work instead of waiting until the
end of the project.

In addition when using Scrum, time boxing also forces the team to work backward to accomplish their objective. In order to deliver working software, the team cannot spend superfluous efforts on the analysis and planning phases and need to start on the development tasks early. Since the development approach is iterative, the team doesn’t have to worry about every single details up front but can address them as they move forward.

Of course, there needs to be control mechanisms to ensure the team delivers working software since meeting time lines with incomplete components would defeat the purpose of time boxing.

In combination with other engineering practices, time boxing is a great way to get the entire team focused and motivated and achieve better results with your software development projects.

Posted on: 03-3-2009
Posted in: Timebox