Actions Speak Louder Than Words

I met a friend on the train recently. We used work together in a team. He was the Scrum Master and I was the Agile coach. During that time, in order to help everyone to have better visibilities about the team’s work, I created a spreadsheet to generate a release burnup chart what was according to the team’s actual velocity and the total estimated work in the backlog. The chart would also generate two trend lines based on the overall average velocity and the latest 3 Sprints’ average velocity. With these two trends, everyone can predict the possible range of the release end Sprint, as shown in Figure 1.

release burnup chart sample.png

Figure 1: Release burnup chart sample

This tool was trying to help the stakeholders and the team to identify the potential risks according to the team’s actual data, and, it was NOT a measurement of the team’s performance. But, unfortunately, my friend told me that the management team is using it in an opposite way now. They started to put the pressure on the team to increase the velocity if the trends are behind the expected schedule. And the team started to game the data and try to make the chat looks good. I felt so bad when I heard about it. It is another example of how a tool can be used in a wrong way to kill the team’s energy.

Any tool like this one can have different impacts on the team. It depends on how it is used. When the organization uses it to discuss with the team about the impediments, it will enable and empower the team to improve continuously. But if the organization uses it to force the team to work faster and more, it will constrain and weaken the team. For example, instead of asking the team “how can we deliver faster and more?”, the leadership team can ask “what are slowing us down and how can we help you?”. These two different questions will show the different images to the team, one is a commander, and another one is a helper.

When I think about this story more, I start wondering that, maybe the way of how an organization uses a tool could be a good indicator of the organization’s real culture, e.g, are they truly believing in trust and autonomy? Like we always said, actions speak louder than words!


The feature image of this blog is from Picture Quotes.

Why big-bang budgeting model should change – part 2

In my previous article, I discussed two reasons of why the big-bang budgeting model should change. This blog, I like to have further discussion about it from another view.

Before getting into details, I like to share a simulation what I created in InsightMaker.

Figure 1 – Simulation Setup

This simulation is trying to see the difference between funding business initiatives based on small size and big size. Like the Figure 1 is showing:

  • The estimated budget depends on the estimated size and the unit price of the work.
  • The total budget will reduce if the estimated budget is divided.
  • If the budget is approved, then the total size of the backlog will increase with the estimated size.
  • And the total size of the backlog will also decrease the size of the completed work what is the velocity.

To simulate the way of the different funding model, I set the estimated size as 500 to simulate the big initiative and 100 to simulate the small initiative. The simulation time period is 12 months. And the velocity is always 40. The results are shown in Figure 2 & 3.

Figure 2 – Simulation Result (Estimated size = 500)
Figure 3 – Simulation Result (Estimated size = 100)

Compare the results:

Estimate Size = 500 Estimate Size = 100
When are there no enough budget to support more initiative? The 9th month Still have about $7,500 left in the budget stock
The total undone work in the backlog 4060 760
The total done work 440 440

So, as the comparison of results discovered, the big-bang budgeting model will lead to more undone work what is the WIP. And also it will run out of money much quicker. Imaging there is a very important business initiative needs to implement after the 9th month, what can the organization do? They need to add more money. Also, because all the development teams are busy on the previous initiatives, there are no enough people to work on the new one. So, the organization may need to hire more people, or, they need to ask the existing teams to work on multiple products. This is exactly what is happening in many organizations. You can see how many potential wastes can generate by this model.

How to escape? Try to sponsor the initiatives with small size in short cycle. Rather than set up budget plan annually, try to set it up quarterly, monthly, etc. Try to change the mindset from funding the projects to the teams. There are many alternative ways to support business activities from the financial perspective. Try to be more innovative and to focus on the whole system optimization!

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”


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.”


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
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