What is an acceptable pace of change for your organization? The root of all improvement lies in change. Should we go all out with unmanaged chaos, or manage change as part of a strategy through extensive controls? How does your enterprise identify and engage what the appropriate pace of change is? How do you balance change to affect positive business outcomes?
How fast does your company need to innovate to stay competitive?
Remember the wisdom of Jack Welch, “If the rate of change on the outside exceeds the rate of change on the inside, the end is near.”
The answer lies in the balance of new and/or improved thinking tools, ways of working, and even ways of feeling as an organization. Every organization is unique and therefore requires a unique approach to managing change. We can always start with existing ideas and tooling and fit to purpose. Choose wisely, and actively engage and match the pace of change to the needs of innovation.
I am particularly fascinated by Rimac and their explosive growth and ability to continuously and relentlessly improve and match the external markets demand for innovation.
“We need to change everything. The whole company changes pretty much every year. – Mate Rimac”
Company founder and CEO Mate Rimac takes you deeper behind the scenes than most journalists have ever been. And this is only the first episode of the four they’ve produced.
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,…
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.Read the rest of this entry »
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…Read the rest of this entry »
It has been said that “Value is in the eye of the beholder.” Our perceptions drive our understanding of value, according to psychologists, and perhaps marketers. What makes great marketing at a company and positive sales can also have a negative effect on the product development organization itself. A double-edged sword of sorts, as humans and our perceptions, assumptions, and emotions travel with us to work. Long after that impulse purchase of the latest iPhone or other gadgets we are still creatures of habit.
The same behaviors that make us vulnerable to marketing manipulation also make product development companies vulnerable to diminished truth and performance in execution. The reality is that we are navigating complex adaptive systems (CAS) within systems. The system (organization) we work within, the product (a system), our team (a system), and ourselves (a system). The causes and effects of movement or change in and around the systems are where we must build discipline, manage assumptions, and rationalize, validate (/in-) through experiments. These validations become part of our imprint, our perceptions, or mental models (schemas). But what if our rationalization or validation was incorrect? Our experiment flawed. How would you know?
This is an organizational aspect too. The organization is the symbiosis of its people and their behavior and mental models.
For example, what is the value of a spare tire when you are purchasing a new car?
Does the spare tire affect the decision-making process of buying the car? What about the price of an average spare tire ($30-$100) and its effect on the decision-making process to buy a car? Read the rest of this entry »
I read several articles on the subject after having a short discussion during class this week with a fellow student (and amazing person!).
#noestimates does not seem to address the rather common difficulty in achieving a consistent, homogenous backlog with deterministic job durations and delay costs in a CAS. The #noestimates solution fails in the same ways that story points can fail. Yin/Yang. Red vs. Blue. Black & White. Whoopee.