#agilefails - Firefighting is never easy!
Dealing with tough situations in product delivery is always a challenge!

There are usually multiple ways of dousing flames and fixing situations. Unfortunately for us, when we are in the thick of things, we often get carried away and adopt the first solution that comes to mind. They say that the road to hell is paved with good intentions!

Over the last few years, I have come to believe that best solutions are ones that balance our short term needs with our long term view.

I present #agilefails. These are examples of partial fixes that do not address the root cause of our problems. While each #agilefail may help relieve an immediate pain, it is insufficient in the long run. Click To Tweet

This list will likely grow and evolve as I continue to learn and discover.

A long-running project is getting delayed. We are struggling to deliver based on our estimates. #agilefail – Lets add new team members!

#2: A senior leader wants something new immediately. #agilefail – No conversation needed. Some of us must immediately start working on this new “opportunity”.

#3: Team is getting too big to manage. #agilefail – Let us create multiple component teams (with multiple dependencies) to manage them better.

#4: Too many meetings are eating up our productive time. #agilefail – First get rid of the retrospectives, then grooming, and eventually reduce stand-ups to few days a week.

#5: Testers only want to test, developers only want to develop. #agilefail – That makes sense, it is their career path after all. It’s our duty to encourage that behavior.

#6: Rock-star team member hoards knowledge and we are afraid of losing him/her. #agilefail – Ensure that our rock-star is happy and promoted, so that person does not leave.

#7: Too many stakeholders want something delivered. #agilefail – Stop the conversation, do not commit anything as we are too busy. -OR- Commit to everything and still make everyone wait.

#8: Not everyone understands the value of collaboration. #agilefail – Make our most expensive tech people as Scrum Masters.

#9: There is shortage of people with a particular skill-set in town. #agilefail – Training our teams will take too much time. Let us hire remote employees who will be experts. We will make them work like hell with multiple teams.

#10: We have a tough delivery date for a big new project. #agilefail – There is no time!! Get coding ASAP and work weekends if needed! We can understand customer needs as long as each team knows its own part. There is no time to spend on process either. Teams can do whatever they want.

My disclaimer: There is something to be said about what we can change and what we can’t in our situation. We may find that a partial fix may be a step in the right direction and enable us to have a deeper conversation about fixing the root cause.

What do you think? Have you faced any of these situations? What did you do, and what did you learn? What other #agilefails have you come across?


Firefighters image courtesy: https://pixabay.com/en/firefighters-training-live-fire-1147795/

Things can get desperate!

Imagine things are going completely out of control; ownership and accountability are minimal; there is little willingness to collaborate and not enough leadership to make it happen. You are down with dismay and disbelief at how things are going… feeling blue and nothing seems to move despite your best effort? Imagine yourself stuck in the moment unable to get out!

Damn.. we wish never to be confronted with a situation like that. Nevertheless stuff happens, at times all we can do is think, and think hard what we should do but answers don’t come easy or fast. How can we help change the situation for the better? That is the agile mindset isn’t it – inspect and adapt until we find an answer?

Hope and despair, both usually exist!


What to do?

Should you stay hopeful or quit in despair!?

I hate to say it, quitting could be an option if you are desperate. It could work in the short term and give you relief, but what would you achieve, what would you solve by quitting? Why not let someone else deal with the mess? Quitting is usually the easy way out, though not always the best.

Why should you care? Before you decide whether to quit or to persevere, try answering these questions:

  • Would you learn something new that would prepare you for even greater challenges if you continued to persist instead of quitting?
  • Would you get a similar opportunity again… an opportunity to be a part of the solution to a very big or complex problem?
  • Could this be an avenue for you develop and practicing your skills in a particular area that you really want to learn?
  • How will the decision impact the organization that you work for, and your colleagues?
  • What will make you happy? What about your family and your friends?

I think:

  • If you are a kind of person who gets a kick out of bringing positive changes, you will likely enjoy persisting. Things usually change, and although they sometimes change for the worse, but they usually (eventually) change for the better.
  • If you enjoy learning, you will likely want to try and persist longer. You will also try to experiment with options you have not tried before and there is god chance you will succeed when others see value.. and they eventually will.
  • If you are very competitive (and perhaps driven by how fast you rise in your career charts!), you will likely calculate the risk/reward possibility around your situation and decide accordingly.

 In short…

Whatever you do depends a lot on your situation, and the kind of challenges you are built for as a person – your strengths, weaknesses, values and motivations. Give it a thought, introspect a little and make your choice. Good luck!

Image sources:

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.

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