Why big-bang budgeting model should change – part 1

Many organizations set up the budgeting model for the big project. Each business initiative will need to apply for the budget with the estimate before they can organize a team to work on it. This may be the most common budgeting model across many organizations. And, it’s also the root cause of many organizational problems.

First, it may cause huge waste to the organization.To estimate the budget for a large initiative, the team must get more details about the requirements. This will lead to the big upfront requirement analysis work. It will take a couple of weeks or months and involve many people. But because the idea is still at the early stage, the details actually include many assumptions what are highly possible to change in the future. So, it’s risky to make a big decision on those assumptions without further validation. That’s why many projects wasted large amount of money and failed to deliver the real value to the customers.

Second, this budgeting model may set wrong expectations to the team what will be harmful to the team’s morale. The below diagram provides a systematic view of how that could happen.

cld for funding model.png

The diagram shows that:

  • Large project-based funding model will drive the business to expect to realize everything in one project. It will potentially require a large amount of budget what will increase the difficulties to get approval.
  • When the project’s big estimate has been challenged, the team’s pressure of changing estimate will increase and the team may feel untrusted what will damage the team’s morale.
  • If the smaller estimate is approved, the expectation of the team’s velocity will also set up implicitly. When the actual velocity is slower than that expectation, the team’s pressure of being faster will increase. If the pressure increases continuously, to the point, the team will struggle to survive rather than to succeed. The quality will be sacrificed. And it will finally impact the business value what will cause many wastes.

Those are all common behaviors in different organizations. Everyone who has been involved in that situation will feel suffer and stressful. Everyone will just want get out it. It’s harmful to the long-term development.

Besides the above two reasons of why the big-project-based budgeting model is unhelpful to the organization’s business agility, there’s another financial reason. I will continue to explain it in the next blog.

One question being asked frequently

When I participated some discussion within Agile communities, one question has often been asked:

“Which is best tool for Agile team? Physical board or JIRA or Rally or …”

Although every time we would like to answer it from Agile value and principle perspective, but when it has been asked so frequently, I start to ask WHY?

The first possible reason based on my experience, is that the organization tries to set up standard Agile process include tools. Most of cases, in those organizations, the Agile transformation is top-down driven by senior leadership team. They like to have a consistent view of the performance. So to have a standard tool seems easier to achieve it. It is an organizational needs of Alignment.

The second possible reason might be because the team players are not co-located. And in order to help team to be able to have good collaboration across different location, set up a tool to be available easily for everyone from different place sounds a great idea.

The third possible reason is that the team just start Agile journey and they don’t know how to start it properly. So they are thinking to have a great tool will help them to set it up.

All of these may have good intentions but also missed some key points.

In the first case, in order to achieve that alignment, teams’ autonomy has been sacrificed. Team has no authority to select proper tools by themselves but they are expected to use them on daily base to deliver great results. It looks like a chef can’t select his best tools to cook the best dishes. Sounds not reasonable anymore, right? So how to balance alignment and autonomy? The organization leadership team can explicitly explain to the team what are expected from business operation perspective instead of giving a one-option solution. And give the authority to the team to decide which tool can match the needs for both sides. For example, leadership team like to have visibility of the quality and they may tell what kinds of measurements are expected, and allowed teams to decide whatever the tools they like to use but match this criteria.

The second case is also very common. Team players are distributed and need something to help them to collaborate. So for that, I would suggest to start from a very simple and free tool, e.g., google sheets what is very good to collaboration and easy to change the setup. The key thing is the same as I mentioned above, to let the team to decide which tool to use. I saw a team had started to use Trello and they really like it because of its simplicity. But the organisation forced the team to change to JIRA. And also there were many access limitations that team had to go through a long process to set it up. And it caused unnecessary wastes and demotivated team’s collaboration instead of enable it.

The third reason is also quite usual for a new team. It is because of some misunderstanding about Agile. A common one is treat Agile as just another process with some defined activities or meetings. So set up a tool to force the process to be followed sounds a good idea. This needs to be improved through coaching and education to help the team to understand Agile correctly. To assist that learning process, I found it is always really good to start from using physical board rather than any electronic tools what will drive the team to focus on collaboration rather than how to use a tool. When team start to understand it, then they may decide to choose a proper tool for themselves.

Last thing I like to emphasize is, although almost all of the Agile practitioners prefer to use non-tech tools, like physical board and post-it and pens, the team’s capability is really depends on how team use the tool not what the tool has been used. I saw one team used physical board but the one person dominated the whole idea about how to set it up. No one else would like to touch the board. I also saw one team was using JIRA and had very good collaboration.

So, if I can ask questions, I would like to ask

  • How does the team select the tool?
  • How is that tool used on daily base?

Why is team waiting?

Super Evil team has waited for 3 days for Product Owner’s decision if the layout should be changed or not. Product Owner is still working with different stakeholders and trying to find the best answer so that everyone will be happy.

Product Owner feels sorry that he is slowing down the whole team and team feels frustrated because the Sprint goal seems not be able to achieved.

It looks like the user stories are not ready when team decided to implement them within the Sprint. But when I discussed this with Product Owner, he told me that he is not sure which is the right option for that question. And there are many those ideas in the backlog now. And it will be very hard to make them be ready quickly so that team can implement it. He told me that the current situation is team can implement stories fast but he cannot feed the team continuously. The flow is not smooth.

With further discussion, I realized that the real reasons are

  1. The team is only focusing on delivery. They haven’t been engaged in the whole learning cycle which is from idea to product.
  2. Everyone expect the requirements to be confirmed (what means fixed) before team start to implement it.

But the reality is, when a new idea has been raised, most of cases, we don’t really know what the best solution is. There might be many different options with lots of hypothesis and assumptions. So, it will be very hard also very danger to fix the solution before we test those hypotheses. We need to organize diverse people to work together collaboratively and creatively and experiment different options quickly.

That means, we need to engage team from very beginning. They may provide different viewing angles. They can create prototypes and collect feedback from users quickly so that we can compare different options with actual data.

So, it is not because Product Owner hasn’t done a good job. It is because that decision is very difficult and at the same time team has been excluded from the learning cycle. Hence, they have to wait until something is ready (many times it means confirmed or signed-off)  to deliver. But if we engage them in the whole cycle, they won’t wait. They will contribute their expertise and knowledge and help to experiment different solutions quickly. That will help Product Owner to make critical decisions earlier.

What is Agile? Exactly

I joined a Agile practitioners WeChat group and today one friend raised a question to everyone – “What is Agile?”. There are many different responses:

  • Agile is a kind of spirit
  • Agile is to keep the required needs but get rid of unnecessary wants
  • Agile is a kind of ideology
  • Agile is a dynamic standard what consolidated team’s intelligence
  • Agile is just a word
  • Agile is a kind of practice
  • Agile is a kind of intelligence what makes the procedure of building software to be efficient and interest and also be possible to reduce the cost
  • Agile is to optimize process, be people-oriented, eliminate waste, deliver value and pursue for technical excellent

From these responses, I can see that the definition of Agile is still not clear in the community. Those answers are all correct, in some degree, but also missed something from my view of point. So I tried to find other answers from internet. Here are some of what I found.

Agile Alliance

The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”

Bas Vodde 

“Create the organizational ability to respond to changes by being able to deliver or change direction at any time without additional cost”

Martin Fowler

“Agile Development

  • is adaptive rather than predictive
  • is people-oriented rather than process-oriented”

Wikipedia

Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.”

There are also many others what are more trying to give the definition in the context of software development, e.g.

Agile in a Nutshell

Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.”

cPrime

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams”

From what I found, I personally like Agile Alliance and Bas Vodde’s definition more. Because

  1. It beyonds the software development
  2. It gives the definition from Agile’s vision and value

For any organizations, not only software development, the number one priority is to survive and grow. It is even harder today because of the continuously increasing uncertainty. Agile, like the meaning of the word, help the organization to build the ability to be more nimble and more adaptive and be able to change the direction faster and cheaper. This is the true value of Agile to organization and this is why Agile received more and more attention today.

It is important to define it from vision and value perspective rather than from particular practice perspective. Because the practice may change with new technologies and also the practices will be different in different environment. But the value and vision will not be changed.  

So, if I’ve been asked the same question, my answer will be, by using elevator pitch format,

For any organizations
Who need to succeed in an uncertain and turbulent environment
Agile
is organizational ability
That enable the organization to respond to changes faster and cheaper
Unlike many other methodologies
That usually are predictive, process-oriented and often lead to sub optimization
This is adaptive, people-oriented and focusing on the whole system optimization

What is the critieria for qualified PO

Today I had a discussion with my colleagues (Jeremie, Dave and others) about how to evaluate product owner’s capability. How to define a qualified product owner? We gradually achieved an agreement, like this.

  • Enabled – have required knowledge
  • Business knowledge
  • Product knowledge
  • Agile knowledge
  • Marketing knowledge
  • Etc.
  • ·         Empowered – be able to make decision for product direction
  • Set up vision and roadmap
  • Prioritize backlog to maximize business value
  • ·         Engaged – be in the journey
  • Always accessible to the team
  • Commit time to participate ceremonies
  • Work closely with business stakeholders

Why is estimate based on story point much BIGGER?

Many times, we need to provide estimate the cost of a project/feature. For many Agile teams, it will be done by using relative estimate, e.g., story point and convert it to cost based on team’s velocity, like the following formula.

Total # of Sprints =Total Points / Average Velocity
Total Cost ($) =Total # of Sprints * Team’s cost per Sprint

Recently, one project team’s manager asked me why the cost estimate based on story point and velocity was 3 times bigger than the estimate based on effort (man day). When I checked the two estimates, I realized that the project manager convert effort estimate to cost directly, like

Total Cost ($) =Total Efforts of Many Day * Cost per person per day

The problem of this formula is, usually the cost model of a project is based on duration rather than effort. That means team may spend 3 days to finish 1 man day work so that the cost will be 3 days’ cost but not 1 day’s cost.

It is a common problem that people will convert effort estimate based on man day to the estimate of duration and schedule directly. That’s why I don’t like effort estimate because it is so easy to cause confusion about it.

With my experiences, I found story point estimate is actually quite accurate and easy to apply. Because it is relative estimate based on comparison. And according to the research of scientist, human’s brain is really good to compare rather than measure. That means when team considers that one story is roughly 2~3 times bigger than another one, the relative size does make sense most of time.

And the effort estimate (man day) is trying to estimate the effort of each activity, e.g., analysis, development and test. This kind of estimate usually requires more details about the requirements and the solution in order to improve the confidence. It will take longer time and also the deviation will be often big.

When the estimate needs to be converted to duration and cost, the conversion rate for story point is team’s velocity what is the actual data represent the team’s capability at the moment.

And the conversion rate for man day effort is based on general experience rather than team’s capability (except team measure it which is quite difficult and usually will create too much overhead to the team according to my experiences). With that, I believe the estimate based on story point and team’s velocity will provide more accurate forecast about the project.

So when you already have the estimate points and team’s actual velocity, it will be quite easy to estimate the duration and cost. If you find the figure is quite big, usually it is because team’s capability, what is velocity, is not as good as you expected rather than the size of the work has been overestimated. So to reduce the cost, you need to think about what can help the team to improve capability rather than ask team to reestimate again and again.

Stop talking, start doing

enter image description here
I used to be involved in the project what was a very challenged project because neither business needs nor technical possibilities were clear.
According to the organizational project initiation process, the business stakeholder asked for estimate about the potential requirements so they could apply for the budget. So, we tried to help the team to do the relative estimate using story points. But after 4 workshops, the business stakeholder still thought the cost was too high and couldn’t accept it. And the project manager would like to organize more workshops to investigate further and hope it would help the team to come out more “reasonable” estimate.
This scenario might sounds very familiar to you. The business probably has already had an acceptable range of budget figure in his mind for his very vague requirements. And team normally will provide a bigger number because of very limit information. Then it will be the dead loop of conversation. Business expect s smaller estimate and team always give even bigger one. And in the most of cases, it will end when team feels tired of this game and surrender themselves to give whatever the number the business expected. But, of cause, the business will pay back when they spent more money and received a crap software at the end.
So, how to escape from this trap? In this case, I asked project manager, if it was possible for the business to sponsor team for 1~2 iterations to start to work on something what were relatively clear and feasible. So everyone would have better understanding about the complexity of the project and then business could decide if it was worth to continue accordingly. I also mentioned that, with total about more than 8 hours workshops what involved many experienced team members, we already spent a lot of money on estimate but couldn’t got any confidences.
At the beginning the project manager was not quite sure if it was a good idea but he agreed to give it a try. And, guess what? The business accepted it and we stopped to provide further estimate but started to plan for the first iteration. During the iteration planning session, we worked with business stakeholders together to decide the possible delivery of the first two weeks and they were very happy about it. At the end of the planning, one of the business stakeholders said: “I am very happy that we finally start to discuss about some detail instead of all those big epics. And thanks to everyone to make this happen!”.
This is a quite common scenario in my experiences. Customers expect the lowest risk for their investment and, at the same time, maximized return. Both of them are fair. The question is how to do it. The traditional way is trying to do lots of analysis at the beginning and expect that will reduce the uncertainties so that we may put everything under control. But the reality is, most of time, through those early stage investigation, we probably can only find the answers of what we know, but, like the following diagram,
enter image description here
There are other 3 areas where the most of uncertainties stay, we need to Explore, Experiment and Expose. We won’t be able to find the questions’ answers in those 3 areas until we start to try. The earlier we start to try, the earlier we start to learn and reduce the uncertainties. That is the only way to reduce the risk and maximize the return (or minimize the waste).
Stop talking and start doing. Start to deliver values to customer and learn from it earlier. The customer will appreciate it.