Stop talking, start doing

enter image description here
Recently I am involved in the project what is to help customer experience team to find out the correlation between the feedback of customers with business results. It is a very challenged project because neither business needs nor technical possibilities is clear.

According to the organizational process of project initiation, the business stakeholder required for estimate for the essential scope so they could apply for the budget. As one of the Agile coaches in this organization, I actually have worked with other coaches together to minimize the initiation activities to get rough estimate based on story points. Usually it will be 1~2 couple of hours workshops to brain storming the user stories and have story point estimate. So the overhead and cost were reasonably small. But this project, after 4 workshops, although we have narrowed down the focus to be one specific area according to business priority, the understanding about the business needs and possible solution were still very vague and the estimate number was still very big. The business stakeholder couldn’t accept it. And the project manager would like to organize more workshop 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 an acceptable range of budget figure in his mind for his very vague requirements. And team normally will provide a bigger number because they have to consider more contingencies to deal with the uncertainties. Then it will be the dead loop of conversation. Business asks for less estimate and team will provide bigger one. And in most of cases, it will finally be finished 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 1 year later.

So, how to escape from this trap? This is my way. I asked the above project’s manager, if it was possible to the business to sponsor a team for 1~2 iterations to start to work on something what were relatively more clear and feasible. So everyone would have better understanding about the complexity of the project after this period and business could decide if it was worth to continue accordingly. I also mentioned that, after about 8 hours workshops have involved many experienced team members, we already spent a lot of money on estimate but couldn’t come out any confidence.

Initially 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 planning session of first iteration, 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!”.

Sometimes we will be stick in the situation like this. But the way of Agile thinking will inspire you how to escape from it. We may learn very fast by doing if we may get quick feedback. And the customer won’t lose the investment because they will also be involved in this learning experience and have better understanding about what their real needs are. The risk will be managed much better with this approach because the customer will evaluate the return on invest frequently and can stop it immediately if there is no value any more.

Stop talking and start doing. Start to deliver values to customer and learn from it earlier. The customer will appreciate it.

Learning from latest coaching experiences

enter image description here

Last week, I have completed the contract in a banking organization as an Agile coach (or say, ScrumMaster). There were lots of learning from this experiences.

Background

This role was to coach a BAU(Business As Usual) team to adopt Agile principles and Scrum framework. The team, include about 15+ members, is supporting multiple applications include CORE banking system, online banking system and etc. The function roles include architect, developer, tester, BA and project manager. And the major technologies include Java, IBM MQ and T24 (a commercial system for CORE banking system).

They have worked with waterfall-like process for many years and have no any experiences about Agile.

Each team member has some degree solo focus to support different systems as well as technology. For example, some of them are very experienced for T24 system but have very few experiences about online banking. And they are experts for T24 and jBASE but cannot write Java code and IBM MQ.

For testers, they are all manual tester and there were no automation tests except some for MQ what are developed by MQ developers.

For BA, they are very familiar with business and used to to have a upfront big requirement analysis before implementation.

Challenges

There were lots of challenges for facilitate and coach this team to start the journey of Agile transformation.

From Agile transformation aspect:

  1. As support team, they have to deal with outstanding issues on daily base. So it is very difficult for them to have a iteration plan;
  2. They have used to work in a respond way for many years so it was difficult for them to have some degree focus;
  3. From team’s culture perspective, most of team members are quite comfortable to focus on their own area only. So it is difficult to change the mindset to set up a cross-functional team;
  4. The CORE system is using a kind of old technology and difficult to write automation tests against the codes
  5. The CORE system support team hasn’t set up the process to use any SCM to manage the source code versions because of some technical limit and habits;
  6. “Yes But” attitude among the team to stop them to learn something new;
  7. Like to have quick answer

From personal aspect:

  1. Different language is quite challenge at the beginning
  2. To adapt the different culture
  3. To earn the trust from the team

Strategy

At the beginning, I didn’t start to change something immediately. Instead I spent about 1 week to observe team’s work and discussed with team members and to understand the team’s situation. After that, I decided to help the team to start to adopt Agile principles and Scrum framework from two major aspects.
1. Iteration planning
2. Source code control

In order to improve them, I tried to focus on the following practices.
1. Set up definition of DONE
2. Set up more discipline daily Scrum and retrospective so to have improving mechanism.
3. SVN usage
4. Have transparency about team’s priority of focus

The reasons of these were that, according to my study, the major issues of the team are

  1. There are many business requests have been raised for long time but no priority plan to resolve them.
  2. Because of no agreed priority, team will tend to pay more attention to new outstanding issues or issues that could be fixed quickly.
  3. There are typical invisible walls between each function team (e.g. dev & test). Especially dev team won’t care about testing like many other organizations. The collaboration among the team needs to be improved
  4. It will be a long way from current situation to CI and CD. And the first thing needs to set is about source code version control
  5. I hope the team to own the improvement and their process but not me. The retrospective is the best chance to try to make it happen.

Achievements

For achievement as a coach, I really want to figure out what kind of good changes happened in the team. For this team, the things changed are (you may find that they are all small changes :) ),

  • Team got used to the process which was set up on Scrum framework
  • Set up a roadmap for team’s Agile transformation
  • Some of earlier adopters of the team are understood that Agile is not only about set up some different processes but about continuous improving
  • Team has set up the definition of DONE so to have an initial standard of the quality
  • Team has refined the triage process for outstanding issues so to have better focus on daily work
  • Team started to have Sprint plan to focus on high priority work items
  • Team started to have more focus on high priority work items in one Sprint
  • Team started to have monthly discussion with business team about backlog priority
  • Team has started to have better collaboration and more transparency of team’s status. Like to customize JIRA so to highlight block issues, use issue burndown chart to have more focus on getting things DONE, track efforts for outstanding issues so to understand the team’s capacity and etc.
  • Team started to realize the value of Sprint planning, daily Scrum and retrospective and is able to run these activities by themselves
  • Team has started to share knowledges and experiences on Confluence
  • The whole team started to use SVN for their source code version control
  • Team has been aware of different ways to deliver software and started to realize the importance of automation testing. They actually started to try to figure out the possible solutions for their CORE system test automation
  • Test team started to learn how to create automation test for IBM MQ application based on the commercial tool – SoapUI
  • Team have started to study how to have CI for IBM MQ application (use Maven to execute SoapUI test and integrate it into build process)

Haven’t Achieved

  • Haven’t be able to help the team to understand the whole picture of the value of Agile practices – Why all of those different practices and how to apply them together as a whole solution;
  • Haven’t help to set up a cross-functional team successfully. Most of team members are still only focusing on their own area;
  • Haven’t help the team to set up team learning environment and culture successfully. There are still lack of motivation of the team to learn something new;
  • Haven’t help the manager of the team to shift the focus from each individual’s utilization rate to real business value delivery;
  • Haven’t set up the pull system. Team members are still taking the task according to assignment;
  • Haven’t help the team to have more collaborative Sprint planning. Most of team members only paid attention to the items assigned to them;
  • Haven’t be able to to help the team to learn how to split big work item into smaller deliverable items. Right now, lots of big item will be split into multiple tasks, like developing and testing;
  • Haven’t be able to help team, especially BA, to practice about how to use user story to communicate the requirements instead of up-front big requirement analysis;

Learning

After listed out what I have achieved and what haven’t, I realized that the most achievements are about the practices and most of the things that haven’t achieved are about culture and mindset. Why?

What I have failed

  • Failed to help the team to understand why they need to be Agile except their manager required them to do it at the beginning
    • Haven’t organized efficient workshop/discussion about it at the beginning
    • Haven’t involved the team to discuss the roadmap of Agile transformation
    • Haven’t communicated with major sponsor of the transformation efficiently
  • Failed to help the team to get confidence to change
    • Lack of small wins for team’s improvement to get more trust from the sponsor
  • Haven’t worked with earlier adopter closely to help team to change
  • Spent too many efforts to find the solution for the team instead of facilitating the team to figure out the answer.
    • Team asked for quick answer
    • Team has lack of motivation to try something new
      • Lack of time to do it
      • The organization is caring about how busy a member is rather than how many real values have been delivered

What I have done right

  • Trust the team. Believe that the team can improve by themselves with proper coach and facilitate
  • Be patient enough. Although there were resistances from the team, I was keeping on trying to help the team to find improvements by the end of each Sprint.
  • Provided demos to the team about different practices to help them to be aware of something different
  • Let the team to run the Agile activities gradually, like planning and daily Scrum, and then to own the process by themselves

What need to do different

  1. Need to be more confident to share my experiences and opinion
  2. Have better communication with the team about why Agile in the context of the team’s environment
  3. Set up transformation roadmap with the team together
  4. Have regular communication with sponsor about the status and roadmap
  5. Have small wins continously so to help the team to gain confidence as well as the team’s trust
  6. Need to set up fundament knowledge base at the beginning
  7. Find out earlier adopter and work with them closely

Lots of learningn in Agiletour Sydney 2013

It was the second time I participated the Agile community event – Agiletour Sydney. And the experience was just great like last time. There were more people to join and sharing (about 130 attendees). Actually it could be more if there were more sponsors (hope it can be even bigger event next year).

What I learned from this event? It was a whole day event on working day and if I say it was just a great, relax time then it sounds like a little bit wasteful :) . No, I do learned a lot from this conference.

This time I paid more attention to sessions about Lean and Kanban. So the first one I chosen to join was the workshop of Renee’s Suduku Kanban workshop. It was a very good exercise to use Suduku puzzles to simulate a kind of BAU environment and let each of participant to experience the Kanban principles: WIP limit, flow, value-driven, done and etc. Suduku is very good to simulate the software development because it can introduce different level of complexities and participants may experience bottleneck of the flow. The interesting things I experienced was that, although I understood the principle of Agile and Kanban, but when I started to work on a Suduku puzzle card, it was very diffcult for me to think how we could do it better as a team. Everyone just put all of their focus on the puzzle on the hand. The a regular reflection, like sprint restrospective in Scrum, is very important to let people to leave away the work for a while and think about what they can improve, where the wastes are, where the bottleneck is and etc.

Another session about Lean was run by Juan Barberis who is a Lean expert. In the session, we tried to create a value stream for a shoe shop and figure out where the wastes were. What impressed me was that, before we started to figure out the value stream, Juan introduced a persona analysis to figure out the most important type of user of this shoe shop and then let us to set up value stream for this particular user type. The point here I learned is that, before we start to create the value stream of the organization, we need first think about what the most value is.

Recently I am focusing more about how to facilitate and coach individual/team/organization. So when Lynne Cazaly, a very professional facilitator, set up a session during the open space, I was so exciting about it. Lynne is so good to set the environment up to attract everyone to be engaged, through her humor senses, body language, eye contact, drawing and etc. It seems so easy to her to pull everyone’s attention and active everyone’s energies. When I asked her how to prepare a workshop and how to facilitate the session smoothly and engage everyone. She suggested a model to prepare whatever the session we were going to run.

  1. You: as a facilitator, what I want to learn/improve from this session
  2. Environment: what kind of environment I need to set up to help the session running.
  3. Process: what kind of process I am going to use to achieve the expected results
  4. Response: how to response to any questions, conflicts, challenges and etc during the session. This might be most difficult part because it needs lots of practices to accumulate experiences.

And, of cause, to be a master of professional facilitator, you need practice, practice and practice, also have the reflection after each workshop to see where you may improve. This is very familiar, right?

Dave, a very experienced Agile coach, has brought a new Game about Scrum. It is poker game that you will play with other participants together and try to earn money as much as possible by delivering values to the market. So you may invest to improve your performance. All the other players are your competitors. It is a match about strategy and value-delivering speed. We have been told that it was Version 0.7 and they will refine it continuously. I like the whole concept to simulate the business competition in a poker game to inspire the players to experience the way of Agile thinking. The only thing is that, the rule of the game might need to be refined to make it be simpler :) .

Uninstall Agile

I joined today’s Sydney Lean Coffee Meetup and had some interesting discussion with community friends. Martyn shared an idea of a kind of workshop to help the organization to recognize the pediments that stop the organization to be Agile – Uninstall Agile.

The workshop basically can be divided into two parts.

  • Everyone brainstorm the elements of the idea Agile organization. That will define a perfect world
  • Then figure out how to UNINSTALL this perfect Agile from the organization. That means if we decide to go back to the old way, how to remove all of those Agile elements

This morning, we had a very quick run for this workshop (only about 10 minutes included the discussion). For the idea Agile organization elements, the results are

Team

  • Shared understanding of the goals (project, organization, personal)
  • Self-organized team
  • High professionalism
  • Shared responsibility and shared support
  • Teams organize dependencies themselves
  • 100% business involvement
  • Collocated with business closely
  • Having FUN

Culture

  • Zero defect tolerance
  • Open communication
  • Transparent and trust environment
  • People choose their own learn
  • Time for innovation

Engineering

  • Excellent engineering practices
  • Daily deploy

Organization

  • Very successful organization
  • Continuous improve
  • Passionate product owners galore
  • Delivering values to customer regularly
  • Almost no project, just product
  • Deliver value fast

We didn’t had much time about to discuss about how to uninstall those elements. A few points are

  • Change top level leadership
  • Six Sigma, CFO in control
  • Put a micro-management command-and-control manager
  • Isolate each functional team
  • Individual performance appraisal based on utilization

This workshop is similar with some others like Future Perfect. But the idea I really like is the question of “How to uninstall Agile”. It might be able to help people to find out the impediments from very different angels. I like to give it a try in team’s retrospective and see what will happen :)

What am I going to test?

I am developing a small web application using RoR. During the implementation, I am writing acceptance tests with Cucumber+RSpec+Capybara. Recently I am testing a page that will post a AJAX HTTP request to change the status of the data and refresh the page with the latest status value. Initially I created the test with Selenium Web Driver which can invoke javascript what would be able to send AJAX http request (although it is slow). But the issue was that when I tried to validate the status value on page had been refreshed by the returned JSON data, it was failed because the asynchronize request. Although I tried to wait for couple of seconds, I still didn’t figured out how to resolve it.

Yes, it is a technical issue and I believe I should be able to find the solution after google the internet. But, what pomped up in my head is, am I doing the right thing to create this test? I mean, my test script is trying to simulate the user operations on the page to click a button and invoke the AJAX request sending. But what am I really going to test? I actually want to test the http request can send to the backend and trigger the status change successfully. So, to test it, I may not need to simulate the whole steps of UI interaction but just simply post the HTTP request and then visit the page to see if the status has been set correctly as expected. Then I needn’t to deal with the painful asynchronize request anymore (yes, it might be still value to test asynchronized request but it can be coved by other pure javascript test through e.g. jasmin). It sounds like a good idea to help me to be out of this tricky situation and move forward.

What I learnt from this is that, although many times, it looks very straight forward to simulate the interaction steps to create the acceptance tests, but, as mentioned in the book of “Specification by Example“, we need to focus on the question of WHAT but not HOW. The approach to simulate the steps is more like about HOW. It will be difficult to maintain (if the workflow is keeping on changing at the early stage of the project, it will be very pain). And shift the focus to WHAT will make our life easier in many of the cases.

 

 

 

Great Day – Sydney Agile Coach Camp

The Saturday of September 7 2013, I participated a Australia Agile community event – Sydney Agile Coach Camp. Thanks a lot to the organizers, it was a so great day and I learnt a lot.

The event was hold in Atlassian’s office building in Sydney and was a whole day Open Space. I really like this kind of un-conference style personally. There were totally about 30 timeslots for us to raise the topics. And finally we had to work together to merge some similar topics in order to have more spaces for1378592420381 more topics.

Many of the topics were about how to drive the change in an organization, how to influent people.

The first session I joined was about life coaching in Agile. The topic was raised by a professional life coach who was from Melbourne. The discussion attracted many people with different opinions. One major opinion is that the coach should not provide answer directly because, like life coach, we believe the best answer exist only in the mind of people. Another opinion is that, in some cases, the coach needs to give answer, like some special skills (TDD for example). DSC_0443

To me, I like the way of life coaching what actually I am practicing  now. But, according to my recent experiences, I think the coach also need to play the teacher’s role sometimes especially when people have no idea about the things we are going to coach. Refer to the theory of situational leadership, we need to assess the people’s competencies first. If it is very low, then we may need to put more efforts on teaching to set up the fundamentals.

Another session I really enjoyed was about how to transfer new knowledge/skill in first 20 hours. The major question it tried to discussed was, when people likes to learn something totally new what means that they have zero experiences/knowledge about it, there will be always a period, before they start to shot up, they will feel frustrated and want to give up. How we, as a coach, to help them over come it in first “20 hours”. Like teaching a people how to play guitar, a simple chords what can let people to play a song might be a very good experiences to help him to build confidence and interests to move forward. So, my understanding is, it is critical in this period, to help the people to establish confidences and the vision of mastery. And we need to focus on bring small win from coaching’s perspective.

Coaching Dojo was a kind of workshop that all participants could practice together about coaching skills. The structure was that, one people played as a coachee and tried to raise any questions to ask for help from coach. Two people would be coaching together as pair to help the coachee by asking powerful questions. Another two would be observers. After the exercise, observers and coachee provided feedback to two coaches. And then rotate the roles. I heard this kind of workshop before but it was the first time I had the opportunity to experience it. It was really good and I hope there will be more such kinds of activities in the future.

My biggest gains was to be able to discuss with Dave, a very experienced Agile coach, about my current coaching experiences. He helped me to understand that the coach should be able to manage the pressure and be patient. The most powerful questions he asked what helped me to have deep insights about myself were

  1. What is your current feeling?
  2. How does your feeling impact your behaviors?

These two questions let me immediately realized where the pressure came from and how should I handle it properly.

At the end closure session, many friends shared their good experiences within the day and appreciated for the organizers great efforts as well as the open and good sharing of this community. And it is true. The Agile community is very open and everyone is willing to help. From China to Australia, the spirit, what is based on the values of Agile, is the same.

Dairy of Agile coaching – Day 8

The team is struggling on planned work and unplanned incidents. By the end of Sprint, there were just few planned items had been closed. I collected the data about spent time on planned work and unplanned work of the team and shared them with the team in the retrospective meeting. I asked everyone how about their feeling. Each team member felt it was just the reality and not good not bad.

I tried to let everyone share what the team did good and not good and write the ideas on Post-it. But one team member asked “Can we just talk? I don’t want to write because I just want to ask a question.” I said “Sure if everyone like to have this discussion”. All the other members were good for that. So I asked her “What do you want to discuss?”. She then said “Why we do this? Why we try Agile in BAU team? Currently there are not big differences. Except we set up a Sprint.”

This is actually the question has been discussed with their manager last time. But seems the question mark is still there. I looked arround the other members. One of them said “Because we want to continuous improving”. Then they asked me what my answer is. I said the major business motivation was to close those most valuable issues in the backlog for ages. The BAU team has to deal with incidents on daily base. If we could fix all of the incidents everyday, then there won’t be any legacy issues. But we actually can’t so the number of existing issues is growing. And many of them have high business value. So the planned work is to resolve those issues. 

I felt that my answer was accepted by the team. But, during the discussion, another project’s project manager enterred the meeting room and asked one member’s help for some urgent issues. And because it was almost times up, then discussion has been stopped. 

When all the other members left, the girl who raised the question at the begining stayed and continued the discussion with me. She metioned that, in order to deal with old issues, her approach was trying to fix some new tickets, then switch to planned work and switch back when necessary. She couldn’t see any better way to deal with the situation.

The retrospective didn’t figure out any actions for improvements finally. The major outcome was the sharing about why we adopted Agile practices.

Self-retrospective

  • It is good that team really care about the value of the change. 
  • This kind of questions should be addressed before we start to change. This needs to be improved in the future.
  • I still haven’t shared the whole idea in my mind about WHY. Do I need to have a separate session to discuss about it? What is the best way to do it?
  • It is really BAD the retrospective meeting has been interrupted by some urgent issue of another project. I used want to resist on the time box. But I knew some of team members would like to leave soon. The problem I have now is that, because of the last two sprints’ results were not good, the team started to doubt if Scrum was proper for them or not. 

Dairy of Agile coaching – Day 7

During today’s morning session

  • the team updated to each other very quickly and completed it within 10 minutes
  • one developer said he was working on one product issue what had some uncertainties. One BA said she could send him a form template what might be helpful. the developer said that would be awsome
  • the only tester in the team had too many things need to test and she was under high pressure. she said she would try to focus on all of the issues that had been deployed on pre production environment and take them as priority
  • the team’s burndown chart has been bunded down and total spent planned efforts were exteed the total unplanned efforts
  • there were two key team members couldn’t join today’s daily meeting because there was another meeting with business team and their manager
  • I shared the existing open incidents after the daily meeting since the start of this sprint to the team because those incidents were supposed to be fixed ASAP from product support perspective. team members quickly went through the list and without providing many feedback. 

I felt something good and some challengies of the team today

  • the daily session is more smooth and it is much more easier to keep the time box now
  • the team started to have more proactive collaboration during the daily meeting. the values started to be visible
  • some team members start to have some degree of mindset about priority
  • the team is still struggling on the focus shift between planned items and unplanned outstanding issues since they are product support team. the conflict hasn’t been resolved yet
  • the only tester is working very hard but the constrainse of her capacity is the bottleneck now

I decided to keep on staying back at this moment to see what would happen. I planned to facilitate the team to discuss about our sprint planning and commitment issue during the retrospective. Actually the only tester of the team discussed with me last day and suggested to have the sprint plan like that developers would work on new tasks and she would test the issues of last sprint. A kind of waterfall-like Scrum. It is not strange to me that the team will have this kind of consideration based on my experiences. The question behind of this suggestion is that the team doesn’t see the whole picture and understand the root causes. The suggestion is a kind of local optimization. Right now, the major questions in my mind are

  • What doesn’t work for us and what are the root causes
  • What can we do to improve it

Maybe I can faciliate the team to have a root cause analysis through the tool of fish-bone diagram.

Dairy of Agile coaching – Day 6

The team needs to support multiple bank systems. And there are different environments to support the different implementation stages what include several development environment, SIT, UAT and Pre production. Because of the legacy issue, the codes of CORE bank system haven’t been managed by a SCM yet. Although the SVN server has been setup. This caused the issue of version synchronization among different environments. It is rely on a kind of manual process and there is no visibility about what kinds of system have been deployed on which environement with which version. It is usual that the team needs to keep on asking which system has been refreshed with which version on which environment. Or, the system patch of a bug fixing has been deployed on which test environment so tester can start to test it. It is really a wast of the team.

So today I tried to raise a discussion with the team about how to have better visibility of the environment situation. My intention was to help the team to figure out some improvements about it. 

When we just started the discussion, some team members asked what we were going to discussed. I shared what my obersavation about the environment visibility issues was and asked the team what kind of things we could do to improve it. Then two developers said they needn’t to be involved in this discussion because from their perspective, there were no issue. They had a track document to log each deployment information for the system they supported. Then I asked if they noticed that the environment usage information actually caused some issues for testing efficiency. Then they said it only needed testers and managers to be involved. They didn’t care about it because they had no any issues from their own perspective. Then one tester asked them if they felt OK that she would ask them about the environment usage information everytime. They didn’t answer that question but emphasized again that it should be the problem of the manager’s but not theirs. I could felt that the tester became a little bit emotional at that moment. I also realized that the discussion couldn’t be continued. So I stop the meeting and said let’s find another time to discuss about it.

What my feeling in my mind is that I can see there are invisible walls between developer and tester and between different domain experts who solely focus on one particular system support but don’t care about others. The change wouldn’t happen if we couldn’t remove all of those invisible walls. And also, based on current situation, it is a little bit difficult to help the team from majorly coaching perspective. I need to provide some cases to the team to open their eyes and see some different ways. So to raise their interests to try something new. I should provide more teaching and mentoring to the team at this stage – the Shu stage.

Dairy of Agile coaching – Day 5

the daily scrum, the team members didn’t started the session until I invited them. Some of them were working on some urgent issues and felt a little bit frustrated to have to join the 10 minutes team meeting. 

I could felt a kind of resistance from some team members. The questions I want to ask team is “What are the values of this meeting to us?”

 

One team member have completed all of her planned items in the sprint

 

This was really good achievement to a product support team. “What kinds of experiences may you share with the team?” 

I tried to keep on reminding myself to listen and without trying to make judgement or say something. It made me to be more focus and able to what the questions/issues the team had more clearly

It was difficult to insist on this practices but the experiences was good. Need to continue practicing

After review the burndown chart, I aksed team that, it seemed that we couldn’t complete our planned items what were the high priority requirements from business people, what their suggestions were? Although the team didn’t raised any adaptive actions, but I could felt that some of team members cared about the business team’s feeling

It could be discussed during the retrospective if the team raised the issue. And it could be the opportunity to help the team to find better way to satisfy the cutomers.