Scrumptious

EVM is a great tool to assess the project's health in terms of performance and progress. It combines the elements of cost, time and scope to reveal performance issues. At various stages of the project, we can calculate the schedule and cost variance, and more importantly the SPI and CPI to get a very clear picture of how our project is performing.

In traditional projects, most of us are very familiar with cost and time variables to populate our EVM formulas. But what about Scrum projects?  They use story points and iterations which sounds a lot more complicated than what we are familiar with. Can we perform EVM in Scrum and Agile?

The good news is we can. In Scrum we break down the Features of our product into User Stories, and then size them relative to each other. For example, if we have a simple piece of work and the team gives that a "1" value, then by relative estimation, a piece of work twice as large would be given a "2" and so forth. Eventually, we can total up all the points for the iteration, release or project, and that becomes our scope. We can then further break down the work into tasks and estimate there hours and costs. For the purposes of EVM in Scrum, we could use points, completed stories, features and so on. The point is that this becomes our measurement for scope. And remember, only completed points, stories etc. can be used. Uncompleted stories are not counted in any calculations such as Velocity, SPI and CPI. They have to go back into the Product Backlog for future consideration if they are incomplete at the end of the Sprint.

Do you remember our SPI and CPI formulas from the PMBOK?

SPI = EV/PV
CPI = EV/AC

Earned Value is the % of points, stories or features completed so far in terms of their budget allocation. Let's say for example that we have completed 30 stories out of a total 120 stories required to complete the project, but we should have completed 40 stories in the same timeframe (or by a certain iteration or Sprint). Our SPI looks like this:

SPI = 30/40
= 0.75

In other words, our Development Team is performing at 75% of the planned rate. We are behind schedule.

Now let's look at CPI. For those 30 stories completed thus far, the budget allocated was $500,000 (this is our EV or Earned Value), but we only spent $485,000 (this is our AC or Actual Cost). Our CPI will therefore look like this:

CPI = 500,000/485,000
= 1.03

In other words, our Development Team is getting $1.03 of value for each $1.00 spent.

There are many other formulas we can use, but for the purposes of this post, the main message is that EVM is just as useful and applicable in Scrum projects as they are in Waterfall projects.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!


 

There's nothing quite like a bowl of colorful, ripe and fresh fruit to entice the taste buds. They are a heathy source of vitamins and antioxidants to keep us healthy and by extension, happy. While apples are not my favorite fruit of all time, I have been told they do keep the doctor away. However, an unripe or bad apple might just bring the doctor to your front door. They certainly aren't the best option for your health, and probably something you would want to distance yourself from, and in some cases throw away.

In Scrum projects, the Scrum Team is that bowl of fresh fruit vital to the health of the project and the happiness of its stakeholders. The team collaborates and works in harmony toward a common goal which is the delivery of a valuable product. Sometimes however, not everyone is on the same page. There is occasionally a "bad apple" amongst the barrel that can threaten the success of the Sprint, release, and sometimes even the entire project.

Here are some examples of Bad Apples?

Negative - these individuals display bad vibes to the rest of the team for a variety of reasons. Perhaps they don't feel the product is viable, the team is not adequate, or the Product Owner is incompetent. These individuals always seem to find something to complain about and focus on the negatives rather than the positives.

Apathetic - these individuals don't seem to possess any interest, concern or passion for the project. They just do the bare minimum to get away with retaining employment. In some ways apathy can be more detrimental than negativity, as a negative person can still perform or exceed the team's expectations (other than attitude of course).

Dominant - normally a legacy of former glory as a team leader or star developer, these individuals don't respect the collaborative and self-emergent leadership attributes of other team members. They are usually confident, loud, and command the center of attention. Invariably more time is spent on these individuals during face-to-face communication.

What is the cure for these Bad Apples?

Well before we discard the bad apple, there may be a way to save it (or them). That should always be the first approach as a responsible Agile leader.

For the negative individual, firstly we need to understand if what they are being negative about is in fact a serious issue that needs attention. If a team member is being negative about a stakeholder that keeps interrupting them and slowing down work, then that is a real concern. Apart from legitimate concerns such as this, the negative person should be coached on the effects that their negativity is having on other team members. They should understand better ways to voice their feelings that are both constructive and not offensive. Further, they should be made aware that this project is a "happy" place where positivity reigns and negativity has no place. Constructive criticism is fine, but not when it crosses into negative waters.

The apathetic individual is a little trickier. They are doing their job to the bare minimum, but they do not embrace the Agile mindset of continuous improvement and optimizing productivity. For these individuals I find the best antidote is to gain their trust while understanding their motivations; what makes them tick. When you understand that, you can engineer ways to incorporate their interests into the project in ways that make them feel a part of the team. Nearly everyone wants to feel a part of something. You just need to make that thing the project.

Last but not least is the dominant individual. Unless you are scared of confronting issues head on, this is perhaps the easiest one to resolve. These individuals need to be coached privately at first on how their behavior is totally inappropriate and detrimental to the success of the project. When someone is too dominant, we don't get the full flavor of alternative opinions that bring life to stories, features, increments and products. These individuals need to be instructed on team rules and taboos that must be adhered to. However, they also need to save face and not feel embarrassed. I find the best way to handle these individuals is to work on an action plan you both agree to (very important) on some key points at a time. For example: "At the next team meeting, I want you to time yourself and not take more than 3 minutes of the 15-minute Daily Scrum, even if you have a lot more to say."

Failing all attempts to change these destructive attributes, the last resort is to remove the bad apple before they infect the rest of the barrel. No one wants to go there, so we need to identify the first bruise on the apple early so we have time to change the behavior. That way, we have the best chance of getting a healthy, happy, ripe bowl of product features to the market.

"A bruised apple is not all bad. It still has tremendous potential." - Seth Adam Smith

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!


 

One of my armchair passions is astronomy and cosmology. Every time I watch a video about the universe, its galaxies, the stars within those galaxies and the planets that invariably evolve around those stars, I am often reminded of the orbits of lessor celestial beings within our project teams.


 
We know that for a planet to harbor life, it needs to exist within the "habitable zone" around it's solar companion. The sun will give just enough heat and light to make life viable, and the planet itself will need the right chemical mix to make life possible.
 
The same can be said for our Scrum teams. The organization is synonymous with the sun. It gives light (focus and promotion) to Scrum initiatives, and also energy (empowerment and resources) to the Scrum Team. This culture of Agility is synonymous with the habitable zone for successful Scrum teams; autonomous self-organizing teams with individuals specializing and generalizing in a technical soup that produces wonderful creations. They have the right ingredients to get the very best out of Scrum and value for our customers.

Our good friend gravity, a "natural phenomenon by which all things with mass are brought toward each other", has a role to play too. We connect the vision of the project and the goal of the release/iteration with our focus on the work to be "Done". We are constantly reminded and drawn to this vision and goals of the project so that we are not in danger of floating away. Further, we are drawn to each other as individuals through interactive communication, collaboration and common purpose.

One of the things that makes Agile and Scrum projects so enjoyable, is the element of uncertainty, or more succinctly, the unknown. There are many unknowns in our universe, such as whether or not life exists outside our own world, how the universe began, and the stuff that makes up 95% of the universe that we cannot see, hear or touch; dark matter and dark energy.

Not knowing these things doesn't stop us from living, nor from searching for the truth. We are unafraid to venture into the unknown, to make mistakes along the way, and even fail from time to time. And the reason is because we enjoy the journey more than the destination.

Likewise, we embrace the journey of Agile projects as opposed to the destination-only focus of many Waterfall projects. But we go further than this. We convert the intangible to the tangible, the unknown to the known, and turn chaos into order.

"One must still have chaos in oneself to be able to give birth to a dancing star."
- Friedrich Nietzsche
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!


 

Many of us know the hit song "Fame" where memorable lines such as "I'm gonna live forever", "Baby, remember my name" and "You ain't seen the best of me yet" reached millions of listeners. It's a song about a strong inner desire to not only achieve at the pinnacle of our skills, but to also get the fame and recognition from our peers and superiors. One might be forgiven for thinking the driving force behind these lyrics only reside in this dance classic written almost forty years ago. But you would be wrong.

The need for fame doesn't just exist in music or Hollywood, it engulfs the hallways of political power, the Boards of the Fortune 500, and even small Scrum teams inside many organizations.

Scrum Teams generally consist of a handful of developers, and then a Product Owner and Scrum Master to complete the team. The core value of the product increment is produced by the Development Team. They are the ones who commit to the Definition of Done (DoD), work collaboratively to design, code and test features, and finally demonstrate the finished feature/product to stakeholders. They are the nucleus of the Scrum Team.

But quite often it is not the developers who get the recognition of senior management. In most cases it is the Product Owner and sometimes the Scrum Master who get to sing the Fame song.

The Scrum Master Celebrity
  
Scrum Masters who seek the limelight go against everything that is Scrum and anything that resembles a servant-leader. I met one Scrum Master who always praised the Development Team during the Daily Scrums and Retrospectives, but in meetings with the organization and other stakeholders, often mentioned themselves and the Product Owner as the real "champions" of the project. At the very least, when stakeholders praised them during these closed-door meetings, I never saw the Scrum Master object.

Scrum Masters, more than Product Owners in my view, should do everything they can to avoid the limelight. Their focus should be on guiding the Development Team and the organization to adopt the very best Scrum practices, and to ensure the developers are working efficiently and productively by removing roadblocks. They should be humble, selfless and the last to seek praise and recognition, even if it is warranted.

The Product Owner Celebrity
 
Many people equate the Product Owner to the traditional project manager in waterfall projects. This isn't far from the truth since the Product Owner is ultimately accountable for maximizing value of the product or service. Further, they also have the closest relationship to the stakeholders than anyone else in the Scrum Team. Therefore, they are naturally exposed to the spotlight due to these dynamics.

While it is important to have a great Product Owner who can translate stakeholder value into the features and stories that populate the Product Backlog, it is also wise for them to understand that their prime responsibility of maximizing value can only ever be achieved through the product increments produced by the Development Team.
 
Most developers don't crave notoriety, but since I am yet to meet a Product Owner or Scrum Master ask the developers: "Do you want fame?", why even take the risk of shutting out those that need (and in my view should get) the most recognition for the success of the project? Of course I am not advocating asking such a question. I am simply highlighting that the answer should be inferred by their merits, not by their request or intentions.

                                                                * * *

If the Scrum Team is going to be successful long-term, the Development Team needs to be nurtured, acknowledged and rewarded at the appropriate times. Even if they don't ask or want to be recognized, a simple gesture to shine a light on their accomplishments is not only good business, but could mean the difference between Fame and Famine.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!


 

Information is what we use to create knowledge, which drives many of the business and project decisions that keep our corporations afloat. In the Agile and Scrum world, information is shared with all stakeholders and is something that is not coveted but shared with anyone who wants it. We call these Information Radiators, because they involve not only the information required, but a method for sharing this information in a way that maximizes value.

Information Radiators can be defined as large displays of relevant project information located in a highly viable area. The term was coined by Alistair Cockburn in 2001 after he saw many organizations following a pattern of storing information in "information refrigerators". The information was hidden, hard to access, and often in the control of one or few individuals. I recall one project 20 years ago where we needed to gain access to some information for a status report, and the person who created the file (and knew where it was located) was on leave and we had to wait until they came back to create the report. It seems insane now, but you may be surprised to know that this practice still exists today in many organizations.

Some examples of Information Radiators include velocity charts, burndown charts, threats and issues, WIP, features in the current release, and the list goes on. The key is that they are "low tech, high touch" tools that promote collaboration between team members and also transparency with stakeholders.

So why has information been so hard to get to, and for so long before Information Radiators came along? Why haven't we always used Information Radiators? Well the simple answer is, we have!

Information Radiators existed long before Agile, Scrum, XP and Lean every saw the light of day. Many of us used Information Radiators for years before ever hearing about any of these practices. Where? In our schools of course. It seems teachers were smarter than many of our managers today because they saw the true value of Information Radiators in the learning, development and collaboration of school children.
  

 
As you can see from the picture above, information is "radiated" through large, bight and colorful displays. It invites children to explore and interact. I have seen similar schools where children use sticky notes and large pieces of paper to create and display a wide variety of information.

How did we go from that to hiding, coveting and controlling information in the business world? Well, there are many theories why and most of them are probably related to fear and greed. Fear of becoming less relevant if we can't control the information, and greed because having the keys to the kingdom (of information) invariably meant that we were paid more.

I call this practice ICE: Information Coveting Extreme. Instead of radiating information to whom it is best intended, we instead lock it up and freeze its knowledge-sharing powers.

                                                                * * *

So how can we be better custodians of information and not repeat the same mistakes we made in the past? Well, don't keep information on ICE for a start. Let it grow and blossom in the sunlight. Unless it is a matter of national security or corporate competitiveness, information should be relevant, visible and shared.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!