Here are the audience notes from the GoldTaking Exercise done at Agile India 2012 during the session on “Slowing down to speed up: Encouraging sustainable pace in teams” on 19-Feb-2012.

Final slides are here.

Video from the session:

Group 1: How to motivate team to deliver at sustainable pace

  1. Acknowledge the achievements
  2. Environment, open culture, celebrate success
  3. When things go wrong, personal attacks should be avoided. Learn to internalize and change
  4. Celebrate with connection to purpose of work
  5. Try adn figure out why team is demoralized and plug the issues
  6. Understand the mindset of individuals to understand their de-motivators or motivators. It is possible that coaching will vary from person to person
  7. Make team members feel safe and secure to out of demotivation
  8. It is good to make mistakes but learn from them. Difference between personal and professional.
  9. Over-pampering should be avoided. Put up facts, and be straight-forward
  10. Like volleyball, coach should ask for timeouts if required
  11.  Practice and preach respect between team members, gain trust
  12. Challenge team on collective ownership
  13. Team building

Group 2: Tackling Management Interference at Sprint Planning

  1. Do not over-commit
  2. Rely on velocity and capacity for committing work
  3. Scrum Master should facilitate planning and protect team
  4. There can be client interference causing pressure on management
  5. There is need to adopt new work culture of Agile
  6. Lack of clear acceptance criteria upfront during planning
  7. Make sure all the stakeholders attend the sprint planning meeting
  8. Re-prioritizing of Product backlog by PMs causes disruptions
  9. Lack of trust: PM should not commit on behalf of the team at/outside Sprint Planning
  10. Development overflows beyond one sprint
    1. Plan in a way that this does not happen
    2. Estimate for less, specially when team members are shared
  11. (Only as much as possible) Accurately estimate/predict the team velocity to know the number of points to take this current sprint
  12. Under-commit but over-achieve
  13. What should happen if more points need to be delivered to client than what the team can deliver?
    1. If the team cannot deliver the points, then team should say “no”

Group 3: Motivation

  1. Leaders have to trust. Sustainable pace is a good way of building trust
  2. Dan Pink -> Motivation
  3. Do you buy into the company objective -> Helps motivate people
  4. Behavior that is appreciated, gets respected
  5. Stretch goals can help people grow fast
  6. Individuals knowing how they are contributing to the bigger picture
  7. Exposure to customers: Know about Customer’s needs and vision
  8. If team values opinion you feel you matter, need to be noticed
  9. Appreciation of individuals from external sources over appreciation of teams may demotivate others on the team
    1. If the recipient appreciates the team that may help
  10. Team finds ways to appreciate/motivate high performers so perhaps no external appreciations needed!?
  11. Transparency at all levels is a pre-requisite for motivation
  12. Recognize team contribution

Group 4: Ad-Hoc to sustainable pace

  1. Experience: Last minute checkins, Slack and work inflow reduction after release
  2. Burned down before release, then next sprint gets off to slow-start
  3. Why this big-effort before the release? May be things were not really done!
  4. Expectations to go faster than you really can go, causes the problem
  5. Management push
    1. Educate Manager? No, that addresses just one problem
    2. You are actually not done if that happens
    3. Provide dates to managers that shows the real pace and use that as a basis for planning
  6. Improve effectiveness
    1. Non-value added requirements, for example paperwork. Have someone else do it – hire a clerk!
    2. Identify activities that are taking time and see if they can be reduced to save time
    3. Use CI and increased automation to release more often
  7. Use scrum prioritization to make hard and real prioritization
  8. Avoid “Goldplating” – over-engineering
  9. Zero defects to make sure it is really done
  10. Piling up work to test at the end of sprint is risky
  11. Argument about ability to swarm around stories. Some have seen it happen, some have not
  12. Positive experience with testers collaborating with developers (pair) from start. Done=> All test cases targeted => Done
  13. How much time to finish a story? 3 days on average, some have minimum 3 days of dev. effort.
  14. Tester writes test cases. Developers start developing at the same time they get the test cases

Agile India 2012: Slowing down to Speed up: Encouraging sustainable pace in teams

Find the final presentation here.

Here is the description:

We would like solutions delivered fast without compromising quality, user experience, implicit requirements and non-functional aspects such as scalability and performance. This would have been easier, if we had all the time in the universe. Doing this in a sustainable manner becomes a huge challenge for teams as there are multiple competing forces at play and because software development is very complex.
Coaches & Practitioners, participate in this workshop and leave with thoughts that will help your teams adopt and practice sustainable pace, and delight your customers over and over again.

Process/Mechanics
Introduction to the topic, understanding participant expectations – 10 minutes
Achieving sustainable pace – 20 minutes
Workshop briefing and topic selection – 10 minutes : Participants will propose and select topics for deeper discussions Workshop – 30 minutes : Goldtaking (The “Goldtaking” format was introduced by Jan-Erik Sandberg and Lars Skaar at Agile2008 and is a variation of the open space format)
Workshop debrief and discussion – 20 minutes
Learning outcomes
In a highly competitive world, delighting customers is no longer optional. Steve Denning, in his book “The Leader’s Guide to Radical Management”), mentions that the goal of an organization is “Customer Delight”, as opposed to making money for its shareholders. Going by this goal in mind, we will examine how we can use Agile as a means to make our teams and organizations successful.
During this workshop, we will explore:

  • Sustainable pace – Importance and challenges:
  • How does it result in customer delight?
  • How agile values are challenged without sustainable pace?
  • What prevents us in delivering at a sustainable pace? (such as competitive surroundings, culture, organization structure, conflicting priorities, old habits, antiquated tools, technical debt)
  • How can we coach teams towards sustainable pace?:
  • Self realization
  • Importance of contextual information
  • Understanding and responding to Force fields
  • Challenging status quo: Stakeholder alignment and participation
  • Building your team into Agile craftsmen, and not Agile mechanics
  • Using Data as a vehicle for change
  • Inspecting and adapting
  • Continued engagement

This article was published on Scrum Alliance in Feb 2010.

How to Sustain Adaptive Planning

Scrum and other agile methods recognize that responsiveness to change is an important aspect of delivering projects. They also recognize that software development is evolutionary and creative. By managing changes through Adaptive planning, Scrum provides a simple yet effective method of planning and tracking project progress. In this article, we will examine what is needed to sustain Adaptive planning and improve Team’s responsiveness towards customer needs. We will examine the following factors:

  • Just-enough planning
  • Evolving plan, scope driven by budget and/or time
  • Grooming the scope
  • Trust, involvement and collaboration
  • Management support

Consider a scenario where the project is progressing as per plan, and in the middle of the project the customer approaches project manager with a request:

Customer: “I really need this functionality delivered in the project. But it is not part of the current scope. Can we make it happen as part of this project?”
Possible response #1: Project Manager: “Unless you are okay with budget overflow and/or schedule delay. Alternatively, we can revisit the project scope but it will require us to drop certain other functionality from the scope of this project. As the effort already spent on estimation and analysis of that functionality will be wasted, please be aware that it will impact productivity.”
Possible response #2: Project Manager: “Well, I am afraid the change control board (CCB) needs to decide this. The CCB meets in two weeks and once they approve that an investigation is needed, we can investigate and inform them about the impact on our plan. The CCB can then decide whether or not this functionality can be implemented.”
Possible response #3: Project Manager/Product Owner: “I do not see a problem as long as you are okay with dropping certain low priority items from current scope of the project and getting this functionality at the end of next Sprint, assuming it fits. Let’s get together and discuss.”

Although many responses are possible depending on the context, if the project is using Adaptive planning then a response similar to response #3 is more likely. Such a response demonstrates that the Team is well prepared to respond to change.

Making Adaptive planning work

– Just-enough planning

To begin with, requirements are understood at a very high level and thereafter, the rest of the planning is driven by priority. As a rule, lesser time is spent on figuring out the details of those requirements that do not have a very high priority. High priority bigger requirements are split into smaller ones so that details can be explored. Only relative size estimates (at a high level) are done at this point to get an idea of how “big” the work is. Once the work is quantified, tasks and effort are estimated for the highest priority requirements. That gives an idea of how much the Team can deliver in a Sprint. This idea is tested in the first Sprint and gives the Team a better understanding of its Velocity (or the size it can deliver in one Sprint). Using the Velocity, the Team is now in a better position to give commitments for later sprints.

– Evolving plan, scope driven by budget and/or time

As the project gets underway and the Team executes multiple sprints, the Team has better visibility on the customer needs. Likewise, the customer also understands the requirements better. This understanding results in evolution of the Product Backlog (e.g. changes in functionality and scope, priority). As the Product Backlog evolves, the size estimates are done for newly added requirements. The Product burndown chart shows how much work is remaining based on the revised scope in the Product Backlog. The work remaining is controlled usually by removing some low priority requirements (of size equal to the added requirements) from the scope. This ensures that scope is managed continuously based on highest priority requirements. Adapting the plan in this manner helps in providing better visibility to all stakeholders by tackling many important issues, such as:

  • How do we deliver what is most important for the customers?
  • How do we address customer feedback on what has been already delivered?
  • What are the key changes that we need to make?
  • Have we addressed all the key risks for the project?
  • How much work is remaining for the project? Do we need to adjust the project scope?

– Grooming the scope

At the beginning of each Sprint, the Team makes a commitment on the functionality it can deliver. In order to make a commitment, the Team may need some time to investigate certain aspects and risks in the preceding Sprint itself. In other words, sometimes it makes sense to look-ahead and reserve some time for investigation on risky items in the backlog that may be part of the next Sprint. Better insight into risky items in the Product Backlog helps the Product Owner make conscious decision on the item’s priority, makes the Sprint planning exercise easier and the Team more confident. Additionally, new functionality requests by Customers can be expected at any point during the project. Sometimes, especially when the functionality is complex or due to other reasons, identifying enough details for quickly giving commitments on these new items at the beginning of the Sprint can be difficult. Grooming the scope during a previous Sprint makes sense.

– Trust, involvement and collaboration

Working with an adaptive plan requires a lot of trust, involvement and collaboration between the Team, the Product Owner and other key stakeholders of the project. Unfortunately this is much easier said than done. Individual stakeholders have different motivating factors and it requires time to build the trust. Things may become extremely difficult and unsustainable if the trust is lost. The effect of losing trust could result in failures such as poor quality, dramatically reduced velocity, inability to meet commitments for multiple Sprints, arguments over small stuff, high team attrition and loss of face in front of the customers. Building trust requires a lot of commitment and collaboration. The Product Owner and management should give the Team freedom to decide how much it can deliver in a Sprint. The Product Owner needs to set the right expectations between the customers and the Team. Setting unreasonable expectations can misfire in the long term. The Team may succumb to pressure of delivering more functionality and may succeed in doing so by cutting quality, or by introducing too much technical debt that becomes difficult to handle later. The ScrumMaster needs to support the Team by guarding the scope and the practices of Scrum. The Team needs to understand the needsof the Product Owner and help in achieving that goal. The Team can help in several ways, such as improving its engineering practices, making the most out of feedback, ensuring that it acts on its retrospective actions and highlights issues that are beyond control. The mechanism of “inspect and adapt” should not be interpreted as a “self-repairing system.” The system will not fix the problems unless everyone involved in the process devotes the time needed and is committed to the process. The Team members (ScrumMaster, developers, testers etc.) need to work with each other to achieve the Team’s sprint goal and continuously improve their ways of working. They need to work with the Product Owner to groom the scope and understand what is needed. Likewise, the Product Owner needs to collaborate with the Team throughout. If the Product Owner becomes complacent in engaging with the Team after a few Sprints then the visibility of the Team can reduce drastically, benefits achieved can be quickly erased and situation can deteriorate. The Product Owner needs to ensure that the business users and customers are appropriately engaged in the process. Without an appropriate level of engagement, there is a risk of misunderstanding the business and customer needs.

– Management support

In order to sustain Adaptive planning with Scrum, it becomes important that the culture of the organization understands and respects change. Organizations, where teams go agile but the management thinking does not, run a risk of quickly losing all the benefits from Agile and becoming worse than they were before. Some of the things that managements need to do include

  • Provide long term vision, direction and priorities
  • Trust and motivate their Teams
  • Focus on addition of business value
  • Encourage Teams to deliver quality, act on technical debt, enhance engineering practices
  • Ensure continuous flow of work
  • Minimize non-work related disruptions
  • Facilitate removal of impediments outside the control of Teams
  • Support the process of learning, inspecting and adapting
  • Communicate

Conclusion

Adaptive planning helps Teams handle changes to scope in a continuous manner but may become unsustainable when practiced in isolation. Other practices of Scrum, along with critical management support and understanding are critical for sustain Scrum in an organization.