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 »
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
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.
Adventures in slicing features.
Teams need to learn the artful skill of slicing features into stories a related to their business context and domain purpose. A typical anti-pattern is for teams to waterfall their iterations, as described in the next two scenarios.
The first iteration we will gather all the requirements, the second iteration we will design, the third and fourth iterations we will build, and the fifth iteration we will test…and so on…
Another derivation of this anti-pattern is to order up another form of phony business agility and/or Scrum.
In this iteration we will pull “requirements gathering” stories first. When those are all finished, we will pull the “design stories”, and then “build” stories…
The next common anti-pattern related to intra-waterfall is for dev team members to pull stories and work on them independently. This is a siloing ant-pattern, indicating the team is not cross-functional and is simply a collection of silos and individual waterfalls. Read the rest of this entry »