Category: Scrum

Coder Culture – Crazy and Crashing

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”
Advertisements

Planning Defects into the system

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”

Learning how to Scrum master in SAFe

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

SSM2018SEP6_Guillory

 

RE: #noestimates sidebar in #SAFe #RTE course.

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.

260px-Yin_yang.svg Continue reading “RE: #noestimates sidebar in #SAFe #RTE course.”

Paradigm shift: Slicing Features

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…

interwaterfall
This is an inter-waterfall anti-pattern. It is essentially a pure waterfall approach chopped up into smaller time boxes.

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…

intrawaterfall.png
In this case, it is an intra-waterfall anti-pattern.

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. Continue reading “Paradigm shift: Slicing Features”

The Knowledge Worker Factory

Does it really exist?

Or are we still working in the blacksmith shop? Will it take AI to bridge the gap?

In Lean manufacturing companies that build physical things have been able to improve quality consistently and dramatically since the dawn of the industrial age.

Here many of us are in the post-industrial, Information Technology or Digital Age.

When we change the channel to knowledge work, companies struggle mightily to match the pace of quality and outcomes of physical manufacturers, even to this day. Why?

XP, Agile, Scrum, DEVOPS, Kanban for Software, Scaling Frameworks

Are these practices, methods, frameworks, and guidance really helping the knowledge worker factory catch up with companies that make physical things? Perhaps there is some evidence to support the claim. Continue reading “The Knowledge Worker Factory”