Author: Marshall Guillory - Blogagility.com

Information Technology professional, transformation leader, agile evangelist & coach, change agent, scrum master, servant leader and more...

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”

Advertisements

Self-Organization with Children

Have you ever been self-managed/organized at a pick-up game at the schoolyard when you were a kid? Basketball? Baseball? Football? Soccer? Dungeons and Dragons (j/k)?

We train our kids to do this…and they are really good at it, and they accomplish it mostly in an objective manner. e.g. – I’m a big guy, 6’3″, and so I was always picked right after the really fast smaller guys depending on the sport.

Yet somehow when we become adults…we need other adults to tell us which team to play on?

#agile #scrum #SAFe #selforganization #selfmanagement #sensemaking

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”

Sticker Face

Certifications and Sticker Face. This is an important topic for our industry. My intent is to deliver this respectfully with a goal of driving more robust solutions in the marketplace. Continue reading “Sticker Face”

Lean-Agile Team Metrics Starter Kit

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”

Michael Küsters : Things that never meant what we understood

Reblogged with permission from , the original author of
 this content. Originally published on his blog Fail Fast, Move On, June 2, 2018.

We throw around a lot of terminology – yet we may not even know what we’re saying. Here are three terms that you may have understood differently from how the original author’s intention:

1. Technical debt

Technical debt has been used by many to denote willfully taken shortcuts on quality.
Many developers use the term to imply that code has been developed with poor craftsmanship – for instance, lack of tests or overly complicated structure. Continue reading “Michael Küsters : Things that never meant what we understood”