As blog posts in a series are published on a common topic, they are conveniently summarized below.
- Transitioning from Manager to Agile Leader
- Agile Leader Patterns for Building Awesome Teams
- Gain Control by Breaking Dependencies
- Limit What You Start to Go Faster
- Removing Date Driven Behavior
Transitioning from Manager to Agile Leader
Agile teams do not need managers. They need leaders who remove obstacles in their path. This requires management to transition from traditional command and control management to a serving self-organizing teams by removing impediments and waste that teams are unable to remove on their own. These posts provide guidance for managers to make this transition.
- The Management Manifesto: Where are the values and principles to guide managers as they embark on the Agile transformational journey? Managers have been ignored in this journey to Agile. This post proposes a set of values and principles to guide their actions and reshape their behavior.
- Overcoming the Fear of the Incapable Team: The self-organizing team—the powerful force behind any great software endeavor. Agile puts people, human beings, at the core. The problem is that traditional management thinking gets in the way of serving the self-organizing team. This post attempts to remedy this gap in mindset.
- Improvement Versus Delivery: There is always a tension between delivery and continuous improvement. Continuous improvement and delivery must co-exist. In fact, successful delivery depends on it.
- How a Stable Team Grows in Capability: In contrast to Agile leadership values, the basic belief of traditional management is to locally optimize a team to gain efficiency. This tends to create silos of knowledge and bottlenecks. Alternatively, systems thinking and Scrum suggests that we optimize through a stable, long-lived, cross-functional, and increasingly T-Shaped team.
- The Moment of Truth: When the stakes are high and pressure is mounting, how you react is critical to your Agile transformation.
- Coaching and Self-organizing Behavior Co-Exist?: It is easy to make an incorrect observation that coaching seems to go against self-organizing behavior.
- How to Shift Gears to Become and Agile Leader: Agile leadership is about believing in the change, leading your teams towards the new destination, and most importantly, supporting and serving the team along this journey.
- Is Your Agile Coach Out of Touch?: It is normal to feel like a coach is an outsider and can’t possibly know the group or the group norms. While it is understandable to feel this way, the “coach is an outsider” argument is actually a common stall technique that delays or prevents change.
- A Closer Look at Transparency: Transparency is key to continuous improvement. However, it is difficult to embrace due to the uncomfortable nature of inspection.
- Is Half-baked Agile Enough?: Is being good at Agile enough? Making the change to Agile does not happen overnight. It is tempting to stop short of the true potential of Agile. The journey, while long, is worth it.
Agile Leader Patterns for Building Awesome Teams
A change in leadership is key to building Awesome Agile Teams. We have built many misconceptions over time on what makes a stellar team. This series debunks the myths and provides the realities of what ingredients make up an awesome team, illustrating six supportive Agile patterns:
- Encourage Different Perspectives: Contrary to popular belief, teams work best when there are disagreements amongst the members on the best path to solve a problem. In the presence of different opinions and some constructive friction, the solution will be more innovative.
- Stabilize Teams: In contrast to typical beliefs, keeping a team intact for a long period of time will increase the team’s performance. Furthermore, the team will continue to improve the longer they stay together.
- Small is Big: This third post in the series debunks the thinking that larger teams are more effective. Smaller teams promote easy attainment of shared understanding, collaboration, expendient flow to done, and rapid learning.
- Encourage Face-to-Face Interaction: Face-to-face communication is key for enabling optimal team communication and collaboration.
- Enable Self-Organization: Self-organization is not easy to achieve, but it is the best thing you can do to set up a team for success.
- Serve the Team: Serving the team is not a manager’s first instinct. Often a manager feels the best way to serve the team is to direct them and ensure they do not fail. This actually works against the power and capability of a team by shutting down innovation and self-organizing behavior.
Gain Control by Breaking Dependencies
Breaking dependencies is a corrective pattern for gaining control of your concept-to-cash value stream and enabling squad autonomy. This series takes you on a journey from understanding the extreme waste of dependiencies and strategies for breaking free between tasks, teams, and organizational entities.
- Introduction: Managing and coordinating dependencies is a wasteful, expensive endeavor and should, therefore, be minimized. This post presents the case for removing dependencies to support the Agile mindset and drive control into the Agile team.
- Task Level Part 1: Breaking dependencies at the task level within a team removes unnecessary waste. This creates the environment necessary for a hyper-productive, lean delivery team to emerge. This second post in the series focuses on a key aspect of breaking task level dependencies—keeping tasks inside the team.
- Task Level Part 2a: This post continues the analysis on breaking task level dependencies on a Scrum team, providing context for common anti-patterns that impede a team from finishing what they start.
- Task Level Part 2b: Finishing the analysis on task level dependencies, this post outlines how vertically sliced stories and swarming can combat the desire to start something new verses finishing what was started.
- Feature Level: Like other dependencies, feature level dependencies can bring significant waste to your delivery teams, impeding their ability to effectively and efficiently deliver value. This post illustrates how teams can avoid feature specialization by owning end-to-end use cases across features, reducing feature level dependencies.
- Between Organizational Entities: Organization level dependencies occur when a team depends on another team from an external organization in order to deliver a feature to a user. This post discusses one anti-pattern and three corrective patterns for breaking organizational dependencies.
Limiting What you Start to Go Faster
In the rush to show progress, we often feel that the busier we are, the better. We feel that having more things in flight demonstrates some type of higher-order capability. These posts illustrate the perils of multi-tasking and provide key patterns for avoiding it.
- Introduction: Can you get better at multitasking? Research tells us that we cannot; the human brain is actually incapable of multitasking. This first post dives into the perils of multitasking and the benefits of limiting what you start. Future posts will delve into Agile patterns for starting less and finishing more.
- Priorities and Simplicity: Without any priority and without short, frequent validation loops, it is easy for a team to fall prey to starting everything at once or in any order regardless of the relative potential impact of each. In this post, we introduce our first Agile pattern to limiting what we start—Prioritization and Simplicity.
- Swarming and Interrupt Handling: When an Agile team is in sprint, focus is key to achieving the sprint forecast, which is the definition of a successful sprint. Swarming and Interrupt Handling patterns, when used together, are a powerful combination that help ensure a team achieves this goal.
Removing Date Driven Behavior to Achieve Agility
Dates are not evil, but the behavior around them often is detrimental to achieving agility. This series is not advocating dates never exist. Every organization has the occasional true date constraint. However, we tend to manufacture dates when we do not have a constraint under the false belief in a date as a motivator. This series describes how to deal with dates when they exist and eliminate date driven behavior with or without the presence of a date constraint.
- Introduction: This first post illustrates why date driven behavior results in waste and inhibits agility, and why you should, therefore, minimize it.
- Corrective Pattern 1: Learn More By Doing: The fear of failing to meet a due date can cause us to act in overly cautious manner and encourages wasteful date driven behavior. This second post focuses on replacing fear with safety and learning more by doing versus planning and designing.
- Corrective Pattern 2: Achieving “Done” not Dates: Giving a delivery date for software upfront is a bad idea. We must fight against this behavior. Do not give a date up front; rather, involve your users and stakeholders in the creation of your software.
- Corrective Pattern 3: Forecasting Delivery Dates Amidst Uncertainty: Giving a delivery date upfront for software development is a bad idea. However, it is a good practice to continually forecast how long the software delivery will take based on current facts.
- Corrective Pattern 4: Commit to Value, Not Dates: Driving towards value and constantly adapting along the way emerges a successful outcome. Committing to making people great, focusing on value and simplicity, and adapting to change quickly and easily will deliver value.
- Corrective Pattern 5: Dealing with a Legitimate Date Constraint: Legitimate dates in business are inevitable, so we must have rules around how to work with real date constraints.