How to Decide Budget on an Agile Project?

Recently, I was asked these two questions by an Agile enthusiast who works with a services organization and have recently started practicing Scrum.

How do I know the budget without having to analyze all the features, especially when the feature list is too long and can’t fit in a sprint of 2 weeks?

The answer I gave was well received. Not because it was right from the process perspective but it was effective from the business perspective.

My simple point was: Who would disagree with the fact that processes and frameworks are created to serve the businesses and not otherwise?

Read on for the answers.

There is no way to know the budget without analyzing all the features. If the project is big and feature list is long then it gets even more challenging.

How to Deal With the Budget Problem When the Project is Big and Feature List is Long

  1. Analyze all your features
  2. Estimate the project as you’d normally do (using any conventional, non-agile methods that you’re comfortable with)
  3. Calculate one-month time-boxed cost of iteration. Refer to this excellent article by Jesse Fewell on the subject: How to Calculate Budgets for Agile Teams (Disclaimer: My entry in agile world is thanks to Jesse so I might be biased but his words of wisdom are way beyond any biases. Any Agile practitioner would vouch for his contribution in the world of Agile Software Development.)
  4. Now you have calculated your budget using two different methods. Use a variable factor to deal with uncertainty, that will come up
  5. This way you’d know how much margin you’re going to keep – now, you can make an offer that makes the business sense to your service company

When we execute a project using Scrum, the opportunity is to retrospect at the end of each sprint and ask ourselves:

  • Are we going in the right direction?
  • Did whatever we do in the past sprint is of any value from the business perspective?
  • … and take corrective actions.

In theory, taking corrective actions means that you can stop developing further or pivot if the business value is not found in the delivered increment. Practically, many people (and companies) fear that practice. Which is normal because in business we need predictability although we know that life itself is not predictable. It’s agile!

So, business-people want predictability and budget is one such practical problem so rather than dealing with that problem using agile techniques, we can choose to deal with it using any technique that works.

Sure, since we’re considering Agile, we’d get the cost of iteration and add a variable factor to make some changes but it is, at its best, a kind of guesstimation.

This is not a perfect way. This is not where you will get optimum value from Scrum. Scrum framework is effective when the focus is on delivering value, not on finishing something by the budget.

If you can, avoid Scrum – or other agile practices – for these kinds of projects. If not, then you can tweak but in that case you’re not using Scrum – or agile.

Also in some cases, the clients of a service provider company would not much care which development framework the service provider uses. All what matters to them is how you will deliver the value. So make an offer to them that they cannot refuse.

  • Is this Scrum? No.
  • Is this Agile? No.
  • Is this business? You know it better 🙂

In my opinion, when not to use Scrum is a distinction that every practitioner must have because then Scrum remains a tool, not a magic wand.

The war has to be won; does it matter if you win it using Swords or Guns?

Scrum Teams and The “F” Word

What’s the “F” word in Scrum?

Not [F]un. Not [F]ire. Not [F]ailure.

What is it?

Most scrum teams deal with software engineers so they are concerned more about engineering challenges than anything else in all what they do.

In Daily Scrums. In Review Meetings. In Retrospectives.

Often, they don’t pay active attention to important “F” word.

Scrum Teams and The F word

Don’t get surprised when I say that the “F” word is their “FEELINGS!”

Don’t get surprised.

Techie guys don’t tend to speak more about their feelings. Essentially, they are left brainers so they seek logic in what they do. Feelings come as a second thought to most.

But what they feel while being a part of Scrum team is important for a Scrum team to succeed.

“People who feel good about themselves produce good results”

~ Ken Blanchard, Spencer Johnson, The One Minute Manager

(Read more about my experience with The One Minute Management Learning)

Cannot agree more: People who do not feel good about their work, cannot produce good results!

And, Scrum – or any other Agile framework for that matter – exist to produce great results; not for any other objectives.

Scrum Masters need to figure out ways to understand the feelings part of their team members and create situations where the team is motivated to assume the ownership of the tasks they undertake.

So, ask your team member directly how she feels if you have a great rapport with her. If not yet, there are other ways figure that out. Some example questions:

1. What excites you to do X, Y and Z?
2. What situations make your low point?
3. What situations make your high point?
4. How did you find working with other team mates on this sprint?
…and so on.

Choose the questions that open up your team members and share their experiences.

Experiences express feelings.

Understand what makes them feel good; what makes them feel uncomfortable and create situations that are motivating for the team members to perform.

A small but important soft skill that every ScrumMaster should have.

3 Tips for Product Owners to Survive the Chicken Test

As a Product Owner, why should you even think about the Chicken Test?

For a simple reason: You are accountable for ensuring that the product you’re working on achieves its goals.

The chicken and pig metaphor suggests that the difference between ham and eggs is this: the hen is involved, but the pig is committed. While Chickens may have other priorities, pigs have only one goal – make the project successful.

When it comes to Scrum, surviving the Chicken Test means that the Product Owner is not treated as someone who is not a member of the team.

Theory says that the Product Owner is a pig, committed to the project and judged on the results. However, the role of Product Owner is the most critical one in terms of conflicting priorities.

In practical world, often the Product Owner role is assumed by someone whose primary job is to directly face customers or interact with other critical stakeholders and in such situations, the scrum team may feel that they are interacting with a Chicken when they are communicating with the Product Owner.

When the Product Owner is treated as someone outside the team, there is a high probability that not the Product Owner’s other responsibilities but his behaviors are making the team uncomfortable.

It is obvious that most people don’t like to be with people who make them uncomfortable. Scrum teams are no different.

Team being uncomfortable with Product Owner is an impediment as it can impact their ability to deliver.

The team will react using more or less predictable behavior. You will be treated like a Chicken. Your inputs won’t be appreciated in daily scrums or retrospectives and the level of comfort will be less amongst the team members when you are around.

The result? Conflict among team members. Demotivated team.  Ineffective sprints. Delayed release cycles…

No Product Owner wants that, do you?

Here are my three Tips for Product Owners to Survive the Chicken Test

1. Honor your agreements:

Product Owners often get situations where they have to obey other commitment at a cost of the commitment they have made to the team.

Particular instances could be as small as promising and not meeting daily scrum or as critical as delegating the huge part of Product Owner’s responsibilities to a team member but the point is – the agreement is dishonored.

Don’t do that. Always honor your agreements.

The team cannot trust a Product Owner who does not keep his promises.

If the team cannot trust the Product Owner, the very essence of Scrum is compromised.

Don’t make agreements that you cannot honor. Period.

2. Exhibit unconditional commitment:

Let us face it. Almost all Product Owners are committed but not unconditionally. At least not always.

They may attend all the Daily Scrums as agreed but may not always pay attention to the junior most team member’s point of view.

Even if the junior most team member is not adding much value at the very moment, she at least deserves all the team members’ attention.

That is very basic but often not practiced as it should. Now, that’s an example of lack of commitment.

So how do you deal with that? Don’t choose to be the Product Owner if you cannot offer unconditional commitment for the project.

You may be an important stakeholder or the core Project Sponsor but you cannot be the Product Owner if you have any other priorities than making the project successful.

Have unconditional commitment if you take the Product Owner Role.

3. Make yourself available:

If you are NOT available when needed, it is often perceived as lack of commitment. When it comes to be part of a team that has ONE goal, managed perceptions are much better than assumed conclusions. None other than Product Owner can own that fact.

For any clarification or insight the team might need, Product Owner has to be available for the team.

There is an another aspect of making yourself available. You make yourself available to the team when you develop a personal rapport with team members such that they don’t hesitate to ask you questions. If team members do not feel closeness, changes are very high that they won’t consider that the product owner is available.

At the end of the day, as a Product Owner, you have to deliver the results. You’re rewarded if you do, you’re fired if you don’t.  If you don’t pass the Chicken Test, you need to work on yourself. If that’s the case, don’t wait, go fix it.

The Problem With Preparing User Stories In Advance

is that it lacks the “ownership” part.

Some Product Owners invest a lot of time creating user stories and provide them to the team in the sprint planning meeting.

It is an opportunity lost to explore team’s point of views and knowledge.

Stories created through such activities often serve as meaningless piece of document in the greater whole.

A good user story is complemented by the team talk. It is more on target when it is written collaboratively. A user story should be able to convey the essence of the story, not every single detail that can be imagined around the story.

The lean concept, “just enough” applies while creating user stories as well.

When it comes to grooming your backlog and envisioning the future of your product and organization at large, user story, when done as a team activity, has potential to produce wonderful results.

Don’t engage in an Agile activity just because it is a ceremony. Get the essence of it and practice it in the right way.

Great user stories are user stories that are owned by the team. If your user story has not got 100% ownership, something is wrong that needs to be fixed sooner than later.

How Every ScrumMaster Should Deal With Attention Issues?

Ever been part of a team where team members didn’t pay attention to what was being communicated?

Yes, in Scrum teams also that happens. Especially in the Daily Stand-ups.

Team members don’t always pay attention to what other team member is saying.

Most people get this habit from their daily lives. They go to doctor and while talking to them, they’re checking their BlackBerry. The same people go to restaurant with their spouse and spend more time with their mobile device than their spouse.

They are just like that. Involved in something else when they’re with someone else.

No wonder that kind of people would want to do the same even when they are part of a scrum team.

That’s not acceptable.

As ScrumMaster, you must coach every team member about importance of attention.

Conversations are most important tools in agile frameworks. They get your work done. And you can’t have a conversation without your team members listening to one another with 100% of their attention.

Listening with intent and with 100% attention is what makes Scrum team successful. That becomes and impediment if not resolved early.

Non-listening frustrates people and they tend to lose interest in the project.

Scrum team members are also human beings with their strengths and weaknesses. Scrum team is a committed team and commitment works when every team member trusts and respects one another.

If that does not happen then Scrum processes might still be there but there won’t be a Scrum team.

As a ScrumMaster, coach your team members to listen. Re-state and coach again and again so that they get why it is important.

Your conversations show who you are. Let your conversations say you’re committed. Let the whole team get it sooner than later. If not, then you’re not doing the right job of a ScrumMaster.

The Most Important Trait of an Effective ScrumMaster

When it comes about being an effective ScrumMaster, I often give an example of orchestra. I conclude by saying, “If even one team member is out of sync, the produced software feature might be out-of-order. That’s an impediment the ScrumMaster must remove.”

(If you want to read about the orchestra example, please have a look at my ScrumAlliance Article and read point #6.)

A couple of days ago, I got an interesting counter argument on my above mention.

The argument was: The ScrumMaster herself may not have required skills to bring the team member back in sync so she needs to empower the team and otherwise it may take more time etc.

My point of view: ScrumMaster does not have required technical skills? So What?

The Most Important Trait of an Effective ScrumMaster

Sure, the ScrumMaster may not have all the required skills to solve the problem but the most important trait of an effective ScrumMaster is to lead without a title and cause the right change.

ScrumMaster would have many impediments to deal with. Not enough technical skills…not enough authority…no access to needed resources. ScrumMaster would have tons of constraints.

Nonetheless, the ScrumMaster needs to presume the responsibility of the situation and influence respective persons to make things happen.

For example, consider this impediment: Because of a system failure, payroll will be processed 4 days later and hence salaries would be delayed by 4 days. A key team member has house loan installment to pay. Since the key team member is stressed fearing what will happen if he would miss the installment date, he’s not able to concentrate. Now in this situation, ScrumMaster has almost no expertise or authority to resolve the problem with Payroll department.

Regardless, the ScrumMaster may choose to communicate with respective persons and figure out the alternative ways by which the key team member’s loan installment issue can be resolved. Whenever anything is going wrong with the team members – either directly related with work or otherwise – ScrumMaster has to take the right actions and help the team member to focus on the work the team member has committed.

Obviously there could be more than one way to solve this problem but the bottom line remains the same – The ScrumMaster has to facilitate the team, remove the impediments and help the team focus to carry out the work they have committed.

That’s what effective ScrumMasters choose to do. They do it by presuming the responsibility and causing the right actions. Their ways may vary, though.


Trying Vs. Seeking Permission

Sometimes back, I facilitated a team with the objective to eliminate a couple of bottlenecks in the process to ensure early delivery.

To begin with, I proposed several directives for all of us to own. Upon completion of second sprint and observing only ordinary benefits, one of the team members asked, “Can we alter directive #3 so that we can get…”

He got an uncomfortable reply from me: “Trying is much better than asking for permission when you’re part of an agile project.”

The team tried it, altered the directive #3 and within couple more iterations they observed better results.

“Try and fail, but don't fail to try.” ~ Stephen Kaggwa

It was a learning experience for the team members. They learned that getting out of their comfort zone, doing what is right and being responsible for what you they done is much better than asking permissions.

It could have been failed as well. But that’s not much of a point here.

Point is to get out of your comfort zone and take actions. Over the course of a few sprints, team would figure out what would work and what wouldn’t.

Constraints such as directive #3, even though listed, may not always apply to a particular situation. Don’t assume that it will.

When you’re part of a true agile project, you’re limited only by your self-imposed constraints. Work on that part and organize yourself to do what is right without being afraid.

Perhaps that’s why Agile Manifesto values Individuals and Interactions more than Processes and Tools.

Now, that’s something so basic but important like hell to execute Agile Projects well.