Ron Jeffries and Chet Hendrickson Live from Agile2017 - LeadingAgile Soundnotes

Summary

This video transcript explores key insights on agile project management, focusing on collaboration, self-organization, and the flexibility needed within teams. It critiques rigid practices like the overuse of the 'user story' format, emphasizing the importance of conversations over mechanical structures. The speaker advocates for a balance between planning and flexibility, where teams express needs and solutions emerge organically. It also touches on the role of managers in facilitating communication and consistency without dictating specifics, and the idea that not everything a team does should be included in the backlog. Ultimately, the conversation underscores the need for adaptability and clear communication in agile practices.

Takeaways

• 😀 Tasking and upfront planning are crucial for avoiding inefficiencies, as seen with the collaboration between tile and cabinet installers.
• 😀 User stories should focus on conversation and clarity, not on rigid formats. The checklist approach is more effective than a strict format like 'As a user...'.
• 😀 Overly structured formats for user stories (e.g., 'As a database administrator...') are not always necessary and can lead to confusion or ineffective communication.
• 😀 Agile teams should express needs, not dictate specific solutions. Teams figure out how to address these needs themselves.
• 😀 The principle of self-organization in agile means teams should not be told what to do, but rather what is needed. The team determines how to fulfill those needs.
• 😀 Not everything in an agile environment needs to go onto the backlog. Only tasks related to the product or project should be included, not operational tasks like ordering a server.
• 😀 Backlog refinement should not include trivial tasks like lunch breaks or other non-essential items. The focus should be on product development.
• 😀 A clear distinction should be made between what belongs on the backlog and what is part of normal operational processes, like server purchases.
• 😀 Managers should focus on expressing their needs, not dictating specific details or instructions. The team is responsible for figuring out how to meet those needs.
• 😀 Agile methods aim to reduce unnecessary complexity. A rigid user story format may add more confusion than value, and it's better to focus on the core principles of agile.

Q & A

What is the main issue discussed regarding the coordination of tasks between different workers in the kitchen project?

The main issue is that when the tile and cabinet workers are in the same room at the same time without proper coordination, it leads to inefficiencies, such as requiring additional cuts or adjustments. If they had worked together from the start, they could have avoided these problems.

What is the importance of having a first conversation about design in agile projects?

Having a first conversation about design is important because it helps set the groundwork for understanding the tasks and objectives before diving into execution. It provides an opportunity to identify potential challenges and align on what needs to be done.

What does the speaker think about rigid adherence to upfront planning in agile processes?

The speaker believes that while planning is important, measuring success based on how well the plan was followed can be dysfunctional. They emphasize the need for flexibility and adaptation, as the process of doing the work itself teaches valuable lessons.

What is the issue with forcing every task to be written as a user story in the agile format?

The speaker criticizes the practice of forcing every task to be written as a user story in the rigid format, such as 'As a [user], I want [this] so that [this].' They argue that this format is not useful in every situation, and it can result in unnecessary work and confusion. User stories should focus on needs and outcomes, not on forcing a particular format.

How does the speaker feel about the top-down push to adopt agile practices without proper understanding?

The speaker suggests that a top-down push to implement agile without fully understanding the principles can lead to ineffective practices. They point out that such decisions, especially if poorly executed, can hinder teams and make agile processes feel bureaucratic or overly prescriptive.

What does the speaker believe is a better approach to expressing needs in agile, as opposed to dictating solutions?

The speaker believes that teams should focus on expressing their needs rather than dictating solutions. This allows the team to determine the best approach to meet those needs, promoting self-organization and collaboration. The manager or product owner should communicate 'what' is needed, and the team should decide 'how' to achieve it.

Why does the speaker argue against the practice of including non-development tasks, such as ordering a server, in the backlog?

The speaker argues that non-development tasks, such as ordering a server, do not belong in the backlog because they don't directly relate to the development process or sprint goals. These tasks may be handled outside of the agile framework and should be managed separately to avoid cluttering the development team's backlog.

What is the speaker's view on how to handle administrative or operational tasks in an agile context?

The speaker suggests that administrative tasks, like ordering a server, should be tracked separately from the development backlog. These tasks can be handled through different processes that are more suited to their nature and should not interfere with the agile workflow of the development team.

What is the role of a product owner in the context of writing user stories, according to the speaker?

The product owner's role, according to the speaker, is to express the 'what' and 'why' of the need, rather than dictating the specifics of how to implement it. The team should then figure out the best way to fulfill that need. The product owner should provide high-level direction without micromanaging the solution.

How does the speaker describe the user story format in agile, and what advice do they give regarding it?

The speaker describes the user story format ('As a [user], I want [this] so that [this]') as a rigid template that may not be helpful in all situations. They advise that while the checklist of who, what, and why is useful, the user story should focus on the conversation and the outcome, not on a fixed format that can lead to oversimplification or misunderstanding.