Rules of Disorder

Measuring Effectiveness

Using an effective methodology should be like listening to a great piece of music. You should only notice the music, not the craft. Any tension and release in the process should exist as merely "part of the song" rather than discord.

Kevin's Rules Of Disorder

Here's my "Rules of Disorder" list, an outline of ways to sabotage your own workflow:

• Oversimplify the degree of planning and thought that should go into a project. Don't bother with a roadmap or a plan, just get to work and say out loud "now that's Agile".
• While following the skateboard, bike, car analogy to the "T", jam the entire process into the development phase (only) instead of across all the phases. Don't be surprised when your car has skateboard wheels.
• Have a subjective and nebulous way of describing, prioritizing and estimating stories so there are some nice LOE data roll ups that give everybody a nice sense of false security.
• Use a big visually cluttered Kanban board where you can't see sh*t and make everything a priority. Compound the problem by using "as a customer I want" titles for your stories.
• Manage the team as if all members have equal skills and responsibilities and FORCE all stories to be expressed as "business requirements." This approach hides team dependencies, workload imbalances and tech debt by encouraging "hero work".
• Make sure nobody on the team learns anything from anybody else so the same hero's are needed time and time again.

Kevin's Rules Of Order

In a similar vein, I've crafted a "Rules of Order" list, detailing various odds and ends I feel generally lead to successful outcomes. This isn't exhaustive, just a few things I've had success with.

• Follow a bike, moped, motorbike, car analogy. Checkout my diagram. The diagram illustrates that "iteration" is often considered something that only happens in the development phase of the project. Wrong! You should be iterating the Product, not a phase of the project. Do a MMMVP V1 of the product, then a v2 and so and before you know it you'll have a V4 or V5 of the product that looks like your original V1 but runs like a top, has fewer problems and was completed SOONER!
• Turn the task board into a table where you can see everything. It's a lot easier to say "I'm working on number 15 and I'm next going to do number 21". Everyone will know what you're talking about immediately. If the table is too big, your team is too big.
• With your clean board, make the lead dev be the Scrum Master and let them name the stories however they want. The board will reflect what's actually going on and devs will actually know what to do. Stories will read "build the porch" instead of "as a customer I need a place to rest after a long days work".
• Use the Eisenhower Matrix to sort and prioritize work. This gives the product owner realtime feedback and tuning controls. POs don't need to spend time writing stories, they can just tell the team what they want, the board can be tweaked in realtime and it's immediately clear what's going to get done and what's not.
• The end of each sprint (weekly preferred) should involve the following: A demo (if needed), sharing credit where credit is due. Have breakout sessions for backlog-refinement, maintenance and overall cleanup on all the "little things" we don't need to clutter up the task board with. Ditch retrospectives, they cause more problems then they solve. Gather any requirements that may be needed for the next sprint.
• The start of each sprint should involve the following: A sprint planning meeting where the product owner can set a theme and the scrum master can fill the board with tasks. If new tasks need to be defined, so be it. Only be as granular as you need to be and delegate the details to the people who will be doing the work.
• Make sure everybody knows what they are supposed to be doing and have what they need to do it. If they don't, they need to speak up.

A Note On Humans

In the intricate web of workplace dynamics, it is vital to acknowledge that employees are not automatons; they are influenced by emotions and interpersonal relationships. When an individual harbors animosity towards a colleague, this negativity tends to surface in the form of counterproductive behaviors, with efforts often directed at undermining one another. While a robust methodology can streamline communication and minimize petty disputes, it is not a panacea for the human condition.

Final Comments

If your Agile methodology is more complex then mine and working then I applaud you, you have reached unicorn status in my book. Most things come down to people problems anyhow. If people get along and trust each other, they communicate and it's good communication that makes things work. That and being flexible and reasonable.