This is a generic Large Solution Train timeline example for organizing an ART launch and/or PI Planning.
One of the more common anti-patterns of Agile adoption is the misconception that simply following methods such as Scrum will lead to development becoming ‘Agile.'”
© Scaled Agile, Inc.
I couldn’t agree more. In nearly every case over my 20+ year career that I’ve been invited to help scale business agility, “to become Agile – in behavior and nature”, in an enterprise the organization was already struggling with achieving agility using just Scrum and Agile. This is the basis of my often repeated statement, “Agile is dead.”
To my dismay, it is also common for the great technical and business practices and concepts from XP to not exist in the lexicon of the organization. Or, only part of XP is used, often incorrectly. It is shameful that Kent Beck’s work is not more prominent in the space. I’m glad to see that he is becoming more active again recently.
A better coaching approach (than simply proposing Scrum and Agile in a CAS) is to understand the market of tools, best practices, frameworks, et cetera and how to apply them appropriately without bias to customer context to drive better outcomes for the business or organization.
As a continuous learner, this is also why I have so much respect Alex Yakyma’s work with OrgMindset. Thinking tools are needed to properly apply and use complex tools in complex organizations. Alex said something very important and interesting during our last discussion/debate about the topics of “Agile” tools and frameworks. Paraphrasing, he said, “I’m just using everything that I know and all of my skills and experience to help businesses make more money.”
This statement is important because often Agile zealots lose sight of the purpose of business – to create wealth – for the shareholders or beneficiaries of the organization. Agile and Scrum are not the goal.
Furthermore, we often forget that Agile and Scrum start out in a state of death. Agile and Scrum are literally just words on a page. They must be given life.
#scaledagile #scrum #agile #scaledagileframework #business #safe
This is a case where leadership completely failed in two major organizations. Some argue for completely flat (eg #gameofnothrones) organizations bereft of a true leadership team. We can’t have it both ways as “agilists.” Leadership is a function necessary in complex organizations. The key in de-scaling is Lean and Systems Thinking, not eliminating critical functions.
The lawsuit states that in early 2016, Hertz began an ambitious project to transform its digital identity. Lacking the internal expertise and resources to carry out the work itself, Hertz picked Accenture from a list of potential candidates to design,…
The impact of software teams using TDD must not be understated. It is critical. Attention to the core technical skills of modern software development are critical elements of the continuous delivery pipeline (DevOps). I’ve been reading uncle Bob’s stuff and Kent Beck’s stuff again. It has been a great refresher from the old days (late 90’s, early 00’s) when I didn’t know jack and discovered XP. Back then I didn’t know enough to realize what I was missing. Less excuses today!
This is not a primer on Test Driven Development. It contains my personal observations of re-starting the discipline and the problem of unit…
Product management is a wholly immersive experience. It simply cannot be done effectively through shortcuts and half baked effort. At scale or for your mom and pop shop… success means hard work and building deep and wide connections with those who buy and those who build as you make the economic decisions on which slice is the highest value and priority.
I recall observing industry competitors wrestling for feature priorities for the OpenDataPlane project (and others) at Linaro Connect. The dynamics of that competition are exactly what your organization needs to build through intrepreneurship. I’m still learning from the past. Are you?
#Scaledagileframework #safe #productmanagement #learning
Here are some patterns to think about the next time you are planning an Agile Release Train (ART) launch. The ART launch should be preceded by a successful value stream identification workshop. Even still, old mental models may prevail that are deeply embedded in the culture of the organization.
Mechanical Scrum is bad for everyone.
You cannot force or assign shared ownership. Management must learn to trust her people and the system. An appropriate quote follows.
Edward Lorenz’s original metaphor for a chaotic system—the world’s weather where the nonlinear nature of forces potentially makes it possible for a butterfly in Beijing to affect the weather a few days later in New York—managers today seem to be living in fear of butterflies.
A potential misstep in launching an ART is allowing management to “assign” team members to teams based off of an overly simplistic view of the value stream or a set of unmanaged assumptions. If the knowledge workers know the work best, then leadership and management should allow the team to be part of the conversation and part of the decision-making process (SAFe Principle #9) for organizing and aligning the ART to the value stream.
This involves a process of self-organization. It is more than just a sequence of steps. If an organizations creation is facilitated mechanically through process steps, then the result will be uncommitted teams and forced misalignment.Continue reading “Team building patterns for SAFe®”
At a Product Owner Community of Practice event a few months ago I had a very interesting conversation with some great folks. We were discussing the topic of testing on an Agile team. During the discussion, someone mentioned a recent coder comment along the lines of, “I was hired as a developer, not a tester.”
Hell, I’ve heard this comment numerous times in my career! Agilists are crying. The DevOps folks are considering a jump! Call the police! Heresy!
I pointed out that as an “evil” Scrum master I would want to comment to this “developer” that, “what I am hearing is that you are a programmer, not a developer.” Now, we shouldn’t let our own emotions drive our behavior in this way so I wouldn’t recommend saying this to anyone. There are constructive ways to address bad philosophy and behavior in the system. Moving on from the shock and awe…Continue reading “Coder Culture – Crazy and Crashing”