check out this awesome book of anti patterns.
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.Continue reading “Planning Defects into the system”
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? Continue reading “Perception of Value in a CAS”
If you are a change agent, SAFe® Program Consultant, SAFe® Product Manager, STE, RTE, or practitioner you may find the Blogagility.com™ Feature Progress Chart Template a useful tool for kick-starting your product management (PM) implementation and Lean-Agile reporting. Continue reading “Feature Progress Chart Template”
Awesome experience with a great group of students eager to learn about Scrum mastering within a SAFe portfolio. I really love teaching this course. 28 folks were in the class and thirteen agreed to take the picture to be posted here on LI. Thank you, team! My co-instructor, Giuseppe B. (left), was also amazing, as usual, as expected for such a great guy! The team chose (self-managed) to use the “Build a house” simulation rather than stock context sim so it was great fun to learn about and experience the awesomeness of PI Planning and the enterprise backlog model while planning a $1.5M mansion.
The teams also experienced self-organization and self-management in this course as they aligned to a common mission, vision, and strategy for their “construction company ART.” They learned how to write and decompose great features and stories.
The students also get near constant teaching and reference back to the value systems of the Agile Manifesto, SAFe, Scrum, Lean, and Systems Thinking. We spend lots of time talking about cognitive empathy, Human Factors, CAS, and culture transformation using the AM goal of “We are uncovering better ways of developing software by doing it and helping others do it” as a foundation.
#SAFe #Scrum #Scrummaster
The fourth tool created to date by blogagility.com for the community!
This handy starter kit is for Scrum masters that are using the Shu Ha Ri paradigm for team development. Good coaches help new teams avoid the pitfalls of added complexity involved in “Agile Lifecycle Management Tools” and instead push for good old-fashioned manual BVIR’s, Kanbans, Scrum boards, et cetera. Change is hard enough in a CAS without adding to the problem by also complicating the way of working. Continue reading “Lean-Agile Team Metrics Starter Kit”
Artificial Limitations are not controls
Don’t limit your team to using just Scrum or Kanban. Don’t even limit yourself to using watered down versions of a combination of Scrum and Kanban. High-performance teams master both the empirical process framework and controls called Scrum, and the use of Kanban (system; Lean).
Continuous Learning (The Three Ways) & Empiricism
Continuous learning teams know how to scale these frameworks and systems using the SAFe and other scaling frameworks to suit the needs of the business and customer solution context (value). Learning teams know how to drive DEVOPS culture and practices through self-organization and self-management.
Scrumming it, the next step
If you are practicing Scrum, and using a Kanban to support the process framework it is helpful to walk the board during the Daily Stand-up (Scrum). Do this a few times a week rather than asking the three questions every day.
#Scrum #Kanban #Agile #Lean #SAFe #scalingframeworks