The essence in PO role is to manage ROI - Return on Investment. While you are doing projects for clients, there is contract in between and ROI involves both sides, which makes who taking PO role more complicated than it is in product organization. We are going to look at
During the recent Advanced ScrumMaster course, two guidelines for performance metrics emerged. Continuous Improvement over Performance Evaluation "Measuring and Managing Performance in Organizations" by Robert D. Austin is a great source for the topic of metrics. He made the distinction in terms of the purpose of using the
You have more work in one area than what the people in that area can do. You also have available people in the organization, but their skill does not match the work. Will this happen? Believe me, it will always happen at some point, either at team level or at
What's appropriate to put into Product backlog? In order to answer this question, we first look at different views on Scrum. Two views of Scrum One is viewing Scrum as planning framework, then, PBI (Product Backlog Item) is the unit for work planning. The other is viewing Scrum
How to split work (from big to small) and how to split people (into multiple teams) are two essential and very related topics in the context of scaling Agile. In these two dimensions (work and people), there are two common splitting strategies, through component or through feature. This leads to
Contract game is the traditional way that Business and R&D work together. At the beginning of the project, Business asks R&D to commit a big batch of work and holds R&D accountable for execution. The mindset behind is "plan then execute". Clearly
Specialization is about being good at something, while responsibility is about having a duty to deal with something. While they are related, it may not be good idea to couple them together. Component specialization and Feature responsibility Conway's law states, "organizations which design systems ... are constrained to
I'd like to revisit the rationale behind moving fixed scope to fixed time in Agile development. By understanding what is essential, we may get back to the thinking of fixed scope. Fixed scope in traditional development In traditional development, we often start by fixing the scope (of the
In my recent CSPO course, I got a question about when we should focus on the whole team (team, PO and SM), and when we should highlight different roles. Some people are somewhat confused because on one hand we define different roles and responsibilities, on the other hand we talk
I realize that LeSS is a natural way to scale. And let me illustrate. LeSS is still Scrum LeSS provides two different large-scale frameworks: LeSS for 2-8 teams and LeSS huge for 8+ teams. We focus on LeSS here. LeSS is trying to reach the same purpose as one-team Scrum
While discussing some struggles of Scrum team with my friend He Mian during his Kanban course recently, i realize that Scrum team can benefit from many Kanban practices. There are 6 core practices defined in Kanban method. They are: 1. Visualize 2. Limit Work-in-progress 3. Manage Flow 4. Make Policies
Acceptance criteria vs. Acceptance tests Recently, i had an interesting discussion with my good friend Xu Yi. We discovered an interesting difference in our way of thinking about acceptance criteria and acceptance tests. In his thinking, acceptance criteria and acceptance tests have one-to-many relationship; while in my thinking, acceptance criteria
As to this topic, I am only talking about project managers in software industry. Same thoughts may not apply in other industries. Traditional project managers There is traditionally contract game between business (or product or customer) and R&D (or IT or technology or vendor). In the beginning of
Scrum framework is based on empirical process control, i.e. you inspect and adapt to achieve the goal. In my CSM course, we do an exercise to relate empirical process control with events defined in Scrum framework. The below table is one typical outcome. Event Goal Who Information for Inspection
PO (Product Owner) is defined as single person in Scrum. However, for various reasons, in practice a team may be formed to fulfill the role of PO. I am using the term of team rather freely, strictly speaking, some of them are only working groups. I'd like to
In my recent CSPO (Certified Scrum Product Owner) course, we had a discussion exercise about how PO breaks and/or gains trust from team. I'd like to share some points so that any PO can keep those in mind while working with the team. How does PO break