Someone who claims expertise in and loves to play the agile game of thrones recently posted an article on Forbes.com about the Scaled Agile Framework for Lean Enterprises (SAFe). Of particular interest the author took the time to denigrate the SAFe by knocking it for not having a focus on the customer. In fact, the author, Denning, specifically states that he is worried because, “the customer is almost absent.” Denning even went through the effort to point out that the SAFe “only” has the customer represented by this little icon in the Large Solution space.Read the rest of this entry »
A remarkable pattern is occurring right now. And for many years. We thought the agile war was over? Experts that are supposedly focused on improving organizations around the world have given in to a state of confusion, or perhaps pure jealousy and selfishness, that leads them down a path of destruction of people and things. And we all thought the Agile revolution was about “helping others do it, better.” On face value, the Agile Manifesto is about BUILDING and CONSTRUCTING a better culture. Through building new habits based on the four core values and twelve principles.Read the rest of this entry »
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
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 »
Why on earth do we do that?
Team A, an Agile Release Train (ART), or the mythical Scrum team, has a lot of technical debt. In an effort to reduce the technical debt, management decides to create a bunch of new “container” “FEATURES” in the product backlog to address batches of defects. Because they want to understand the value of the (fixing) defects.
Except there is a problem. Defects are not new features. Well, in a sane software world we hope not? Defects are typically created while coding or configuring a new feature, right? Is it a defect yet? Not really. Fix it NOW, not later. If it makes it to production? What is the cause of defects making it to production? Poor coding, standards, quality and automation, et cetera? No DevOps? or do defects occur magically in existing features (real ones)? (not my code!!) We all know how computers have minds of their own…
I’ve seen that oddly familiar pattern of desire to package up defect fix/technical debt effort into a feature or story or a suite before. I call these “projects”, “probably to be implemented with waterfall.” That type needs project managers and factory workers, not Lean-Agile practitioners, creative knowledge workers driven by autonomy, mastery, and purpose.Read the rest of this entry »
The newest VersionOne (13th) Annual State of Agile Report was recently released. Last year the report was published on April 9, 2018. This year the report was published on May 7, 2019. As I had reported earlier I will compare and contrast the various scaling frameworks growth and shrinkage and also discuss the missing elements for organizational transformation and whether or not the industry at large is addressing those challenges.
The newest VersionOne 13th Annual State of Agile Report was released on May 7, 2019. Over the past few years I have been comparing interesting trends in the State of Agile Report where I have compared the growth of scaling frameworks and methods to each other year over year.Read the rest of this entry »