Stop Drinking From the Fire Hose. Tips From an agile Coach
Christian Antoine, Agile coach and instructor in Minneapolis, MN, is often asked how to stop the ‘drinking from the fire hose’ feeling at work. Do you feel as though you are trying to keep 20 plates spinning at work? How does it feel to juggle so many things? Do you feel productive?
Christian Antoine, Agile coach and instructor in Minneapolis, MN, is often asked how to stop the ‘drinking from the fire hose’ feeling at work.
Do you feel as though you are trying to keep 20 plates spinning at work? How does it feel to juggle so many things? Do you feel productive? Do you feel you add value? Do you think your employer values you for the number of plates you can spin at once?
What if your employer was looking for you to add value by providing information about those 20 plates? This could be determining which plates should be stopped and which plates to double–down. This could enable you to focus and delight your customers.
The best way to stop the insanity is to ask leaders to order their top priorities. Priority alone does not work. Everyone will tell you their priority is #1, top priority. When there are 20 number one priorities, it is impossible to address all 20 at the same time, at least not effectively. Ask “What order should I work on these 20 items?” or “What is the most valuable thing to work on first? Next? And Then?” etc.
Good leaders provide value by deciding the order of our priorities. Good teams provide value by making their leader’s decision work.
This is where those delivering look to leadership. They want to know they are working on valued items and do not have to worry about switching plates mid effort.
Delivery teams are great problem solvers … but terrible at predicting problems. Here is a good test. Ask your teams: “Has there been a problem where we have not solved it and we had to shut down the company?” If the answer is no, could it be the problems the company has encountered have been solved by those working in it?
The next time you feel you are drinking from the fire hose, the best remedy is to get an ordered list of priorities from your leader(s). This allows you to address them in order, focusing one at a time until completion, and showing progress at regular intervals.
You may even have more conversations with your leaders to provide data on what is working and what is not, in turn helping your leaders to make better decisions on the order of their priorities going forward. This reoccurring conversation between you and your leaders will build trust and help going forward.
Want to learn more?
Are you Suffering in Product Development?
Craig Larman is dedicated to reduce suffering in product development. This video introduces Craig Larman and how he is serving the people in product development and incorporating Agile and Scrum. Over the last 10 years Craig Larman and his partner Bas Vodde have worked with a variety of companies and organizations by helping them adopt.
Craig Larman is dedicated to reduce suffering in product development.
This video introduces Craig Larman and how he is serving the people in product development and incorporating Agile and Scrum. Over the last 10 years Craig Larman and his partner Bas Vodde have worked with a variety of companies and organizations by helping them adopt LeSS and Scrum with their large scale Product Development.
Learn more about how Craig Larman can help your organization with this video:
Ready to dive in? Check out the upcoming course on March 28.
What is LeSS and How Can it Help Your Organization?
LeSS (Large-Scale Scrum) is the simple high-impact framework for scaling lean and agile development designed to optimize the whole system. It’s based on over a decade of adoptions in many big groups worldwide (e.g., see case studies).
LeSS (Large-Scale Scrum) is the simple high-impact framework for scaling lean and agile development designed to optimize the whole system.
It’s based on over a decade of adoptions in many big groups worldwide (e.g., see case studies). In addition to learning about it atless.works, it’s described in the three books on LeSS that come from that decade of experience:
(1) Scaling Lean & Agile Development: Thinking & Organizational Tools with LeSS
(2) Practices for Scaling Lean & Agile Development: Large, Multisite, & Offshore Development with LeSS
(3) the upcoming third book, More with LeSS.
Although LeSS is described as for scaling, a key purpose of LeSS — the implication of its name — is actually descaling through organizational simplification. Descaling the number of roles, organizational structures, dependencies, architectural complexity, management positions, sites, and number of people. LeSS is not about ‘enabling’ an existing big and clumsy organization to “do agile” by painting agile labels on top, it is about scaling up the simple Scrum framework itself to achieve organizational descaling.
In a way, LeSS is simple because there’s only a small set of elements, whose purpose is transparency and empirical process control. It’s ‘hard’ because transparency reveals weakness, and empiricism requires learning and change rather than following a recipe.
Unlike some other scaling frameworks, LeSS does not define a one-size-fits-all detailed recipe, and like Scrum, is based on recognizing that development is too complex and situational for a prescriptive detailed recipe that a group can just “buy and install.” Rather, it will require creating a learning organization, and lots of situational adaptation.
There are no fancy titles, no trains, no layers of management, but when you simplify and descale, you ought to be able to achieve more impact and flexibility with LeSS.
Click here to learn more about scaling learning opportunites!
ScrumMaster File: Positively Neutral
You are a ScrumMaster for a personal care products company. You and the other ScrumMasters have formed a Community of Practice, getting together periodically to share coaching tips to improve how you serve your Development Teams, your Product Owners and the Organization at large.
You are a ScrumMaster for a personal care products company. You and the other ScrumMasters have formed a Community of Practice, getting together periodically to share coaching tips to improve how you serve your Development Teams, your Product Owners and the Organization at large.
One of the other Scrum Masters, Sheila, has asked you to sit in on a Sprint Planning session. You have been asked to observe and then provide feedback to Sheila after the session.
Part One of Sprint Planning seems to go pretty well with the Development Team and the Product Owner using their Velocity and upcoming Capacity to agree upon a Sprint Goal. Product Backlog Items (PBIs) are committed to the Development Team’s Sprint Backlog and there is good collaboration about Definition of Done.
Part Two of Sprint Planning begins and Development Team members start discussing how to achieve a number of the PBIs as they identify those Tasks. Two team members disagree over a solution approach and the tension starts to build.
Sheila, the ScrumMaster, is listening intently to as Scott and Rob banter back and forth – each advocating for their own solution. Both gentlemen’s faces are red, their fists are clenched and you believe they may actually start fist-fighting.
Nobody else is speaking. The remaining Development Team members and Product Owner all have fearful looks on their faces or are staring down at the table.
You lean over to Sheila and whisper “Scrum Master, get in there…”
Sheila turns to you and says “No. I am remaining neutral.”
What do you do in this situation?
Do you think that Sheila’s behavior, or lack of behavior is what is meant by the neutral quality of the ScrumMaster?
If you were the ScrumMaster for this team, what are some questions you would ask?
Scaling Agile & Scrum
Angela Johnson, Certified Scrum Trainer and Coach asks “what’s all the fuss about scaling Agile & Scrum”? Is it just me or has the word “scaling” become a buzz word in the Agile community in the last 5 years?
Scaling Agile and Scrum
Angela Johnson, Certified Scrum Trainer and Coach asks “what’s all the fuss about scaling Agile & Scrum”?
Is it just me or has the word “scaling” become a buzz word in the Agile community in the last 5 years? Thinking back to the mid-2000s, I don’t recall this being talked about at User Groups, Conferences, in Certified ScrumMaster courses, etc.
Today scaling frameworks appear overnight and promise a one-size-fits-all solution to using Agile approaches “at a larger scale”. Let’s look at the first challenge with that:
- What do you mean by “scaling”? When someone talks about Scaling Agile or Scaling Scrum, I ask them what they mean more specifically as there are a lot of loaded terms in that phrase.
- Do you mean Scaling Agile or Scrum across a large Product?
- Do you mean Scaling Agile or Scrum across an enter organization?
- Do you mean Scaling Agile or Scrum across distributed geographies?
- Do you mean all of the above? (Yikes!)
In my experience, many of these organizations cannot answer what is meant by “Agile”. Some mean using the Scrum framework, yet others mean eXtreme Programming or just adhering to the values and principles in the Agile Manifesto. Many also cannot answer what they hope to gain by adopting Agile to do work versus the status quo. So how are these organizations going to know that they have achieved their goals? Firstly if they do not understand what the goal is. Secondly, if they do not agree on what is meant by “Agile” or do not have this working successfully (whatever that definition for them is) at small scale. What do they plan to do? Scale something that has not been proven to work at small scale and hope that it somehow delivers better results?
2. One Size Fits All. Some scaling approaches offer a prescriptive solution regardless of the size of the company or the type of work being done. Many assume the work is technology based so a number of information technology specific references exist that may not universally apply in every organization.
Some may read this and think “well, isn’t Scrum or Agile one size fits all”? This gets to the heart of the misunderstanding. They are not intended to be “methodologies”. They are frameworks. The Scrum framework asks anyone adopting it to identify who the Customer is and what the Product that will be built for that Customer is. The framework offers a set of “guidelines” to keep the people building the Product for the Customer accountable and adaptive to the Customer’s feedback. By definition the Development Team, the Product Owner, the ScrumMaster and the Organization are meant to do what makes sense for their company, industry etc. The values and guidelines are there to help.
Other Agile approaches, such as eXtreme Programming, assume a technology Product so are slightly more prescriptive in the technology practices but still start by asking “who is the Customer?” A Customer view is adopted as opposed to a System-only view.
If companies have not worked through these questions, chances are the rush to Scale Scrum, or other Agile approaches, may slightly optimize the status quo, but will not achieve the full benefits from using Scrum or Agile at scale.
Click here to learn about opportunities to learn about scaling.