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?

How to Deal With the Product Owner Coming from Waterfall Background?

How to Deal With Product Owner Coming from Waterfall Background?

Last week, I got this question from one of my ex-colleagues, Victor.

Victor is a ScrumMaster of a newly formed Scrum team. They were on their 3rd sprint. Their sprint length was 3 weeks.

Victor described me his situation:

  • The Product Owner, who happens to be the Product Manager as well, was coming from waterfall background.
  • The Product Owner was senior to all the team members.
  • The fear was that because of the Product Owner’s background in traditional methods, the team would be giving ‘Status Updates’ instead of inspecting and adapting.
  • The Product Owner was open to Scrum, but he seemed to have a lot of baggage of his own accomplishments in other practices though Victor hadn’t experienced it personally.

“I was taught that there is no point of Scrum if each team members don’t self-organize and don’t inspect and adapt – how do I deal with this situation?” Victor asked.

My answer:

No matter the background, no matter the title, the Product Owner is a part of the Scrum team and acts as a team member.

If each team member gives best of her efforts with 100% of ownership of the tasks she owns up, probability of product success, or early failure to learn from and iterate, increases.

Now, if the Product Owner is open to Scrum, then he’d appreciate himself playing the role of the Product Owner and not just playing the conventional Product Manager.

So as the ScrumMaster, you talk to him and inspire him to play that role. If the Product Owner is not playing the Product Owner role – then this is an impediment that needs to be resolved and you need to own that part no matter if he is senior to you or not.

ScrumMaster does not lead any formal authority to resolve the impediments.

Now if I look at your particular case, there is no mention of him not playing the Product Owner role. It might just your perception that because he is so senior you will end up giving status updates and won’t self-organize.

Play your role regardless of who is who in the team. Self-organize. Talk to the Product Owner. Organize a dinner or a tea-party with the whole team. Break the barrier of your perception.

Understand and let every team member understand why you have opted for Scrum.

Is it beneficial to the organization?

Sure.

Is it beneficial to you personally?

Absolutely.

When you just don’t do Scrum but live it, you grow as an individual. You grow because of a simple reason – you unconditionally own up the battle that you have picked. You don’t blame others. You self-organize and lead yourself to get shit done.

Good things come to people who get shit done. When the shit is done, all what remains is good, isn’t it?

Conclusion:
More often than not, new Scrum team members get carried away about their perceptions rather than what are the facts. Instead of thinking about titles and seniority and all such mumbo-jumbo, focus on playing your role and get better at it.

Will you do everything right the first time?

No.

Will you commit mistakes?

Yes. For sure.

Learn from Your Mistakes and make your product, your organization, and your life better.

Daily Standup Vs. Daily Standup

There’s a fundamental difference between participating in daily standup meetings because you want to and attending daily standup meetings because you have to.

You want to attend Daily Standup because you believe you’ll inspect and adapt.
You have to attend Daily Standup because your organization is following Scrum or your boss has asked you.

Former helps the project and the latter does not.

When you do the former, everyone benefits. You. Your project. Your organization. Your customer. Your customer’s customer … everyone.

There’s no “have to” in Scrum. You do it or you do not.

Are you doing Scrum or are you doing Scrum because you have to?

Who Should Be The Product Owner?

Recently, I wrote an article on ScrumAlliance that says that Principle Software Engineer is not a good choice for the role of Product Owner.

In followup, I got an email from a Scrum enthusiast saying he understood the point but then who should be the Product Owner in a Scrum team?

It is a good question.

Unfortunately, it is often misunderstood by even senior management of Scrum-novice organizations.

The Product Owner is someone who builds, shares and establishes the product vision and inspires the team to self-organize and make that vision take form of the product, fast.

The Product owner operates from compass and not just following a map. And that’s why there is no specific set of “processes” that can make a good Product Owner. He is free to do all the activities that stay true to its definition.

Of course the activities that the Product Owner carries out may include collaborating, answering questions, providing answers and so on but at the end of the day, they are just that – activities. Scrum is not about the activities. Scrum is about the results!

To better understand this role, let me use life as metaphor.

Imagine that life is a Scrum Project and you’re the Product Owner of it. Your goal is to build, share and establish the vision for the difference you have dreamt to make and inspire the people on your team (your family members, relatives, friends, colleagues, community fellows and so on) to join the mission to accomplish your goal, fast.

What sort of process you should be following to be a good Product Owner in this case?

The processes that get you closer to your goal!

The same logic applies to the Product Owner role: The Product Owner should be someone who can build, share and establish the product vision and inspire the team to self-organize and make the vision take form of the product, fast!

How Much Documentation Should a Scrum Team Do?

I get this question invariably asked by almost every team that’s new to Scrum.

“Documentation that is just enough,” is the theoretical answer.

Almost always, the next question follows, “What’s just enough documentation?”

just enough documentation

Just enough documentation is what serves the sprint purpose. Imagine the following scenario:

  • Product: A Mobile iOS App in the Travel Niche
  • Pretext: Version 1.0 of the App is already in the market and people are using it. It has generated a user base of about 15000 and many people have requested  different features via App’s support a feature option.
  • Sprint Goal: Build and release version 1.1 of the already successful App. Version 1.1 should have 3 most demanded features by the end users. Out of 3 features, one feature required R&D and hence Scrum is a better choice.
  • Sprint Duration: 2 weeks
  • Team Size: 5
  • Team Details: ScrumMaster (1), Product Owner (1) and Team members (3). Out of 3 team members, one is Graphic Designer, one is Software Developer and the 3rd one is App Support Executive.

Effective documentation in this case could be as follows:

  1. User Stories for the 3 features
  2. Photoshop PSD file with explanatory layer name and optionally a readme.txt file with bullets of specific instructions if any
  3. Readable, modular, commented code that itself is self-explanatory with occasional in-code comments stating why a complex thing is done the way it is done
  4. Updates in the App Support FAQs / Other Support Docs that are affected by introduction of these features

A Scrum team’s goal is to deliver value, fast. Above might act as just enough documentation for the needs. The good thing about Scrum is a specific ceremony called Sprint Retrospective which becomes instrumental in inspecting and adapting to what turns out as the right thing.

When we talk about documentation, often a question comes about the User Manual.

Let’s consider the same in the above scenario: Given it’s an iOS App, it won’t be a good idea to develop a User Manual for the same – The App’s UX should be so natural to the user that they don’t need to refer to the manual.

It is easy to agree to develop a user manual for an iOS app but in fact, that will be a disservice to the end users and the client itself – as you’re disregarding the manual-less experience that is possible to provide to the end user.

Or even better, provide the functionality built in app that enables the user to learn the App by seeing it in action. The need to documentation turned into a functionality!

Many people will say that if client demands, carry out the documentation. However, I do not buy into the idea that if your client requires XYZ documents to be created, you should carry them out without asking questions that provoke her to think – you should explain your client the value a particular activity will bring or the value that it will negatively impact. Sure, typically it is done by the Product Owner but as team members, if you decide to do something in which you don’t believe, you cannot deliver value.

Spirit of Scrum is not to negotiate but to collaborate – when you collaborate towards ONE goal, no one is superior to the other.

Sure in typical Business situations, you might have to do what might look like “anti-scrum” or not “scrum-friendly” – if you choose to do so, do it with awareness.

Is This Your Best Code?

This is the wrong question.

The right question is, “What knowledge, skill, tool, framework or support will enable you to write better code than what you’ve written?”

So what do you mean by better code and why should you care?

Better Code does not always mean well structured, well documented, reusable code. Many a time, Better Code simply means, the code that does what is expected and does it well for most of its consumers.

In past 14 years, I’ve worked with many passionate, crazy and talented software engineers who are fanatical about producing their best code.  Some software engineers, with experiences of different kinds, get it sooner or later what better code means. Many don’t and continue working hard towards producing their best code.

They take great pain in making their code better at the cost of:

=Eval("put whatever highest cost you can pay as a developer").

Willingness to take pain is good but better is to be willing to take right kind of pain.

You write quality code not because you feel “cool” about it, you write quality code because you believe in the indirect value that it will bring in end-users life.

Much rewarding is to take great pain to understand your users world. Even if you are an innovator and you’re going to change the way users behave, take great pain in understanding and communicating how your code will help make that happen.

I have observed many Scrum team members complain that because of iterative way, they cannot produce their BEST code.

It is okay. You’re not in the team to produce “your” best code, you’re in the team to produce the code that will add value to its consumer’s life, even if it is not your best code.

When business leaders ask such question whether this is your best code, Scrum team members get confused. You don’t need to.

Your job is to produce good code, and enable your team to ship fast and ship often, gather feedback and make the whole ecosystem better in the next iteration. I’m not asking to create bad code. It has to be good enough. Shipping fast does not imply shipping crap.

Presuming that you can get better at whatever activity you pick, choose to get better at what you should be get better at. Now that’s a smart choice, not all software engineers make that!

Software Engineers who make such choices are often part of a high performing Scrum team. Perhaps that’s why it is not so easy to locate high performing Scrum teams. A problem worth solving.

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.