Agile


Prioritization is a form of control over work entry. Tony Timbol (SPamCAST columnist, CEO of Agile Ready, and consultant) would call prioritization a guardrail for the work entry process. Unfortunately, work entry is not always a controlled process which highlights two of the few absolute truths about the world we live in.  

(more…)

In this week’s podcast, we speak with Mike Potter, CEO of Rewind.  Mike and I talk about the need to backup SaaS applications, remote and hybrid working, and entrepreneurship. This interview opened my eyes to the risks we all face by trusting SaaS application companies to back up our data. Mike also highlights in his answers how humanity in the workplace can help create special results.  

(more…)

There are three common scenarios that generate prioritization decisions outside of an individual or team’s span of control.

(more…)

Over the past few months, I have been in traffic jams on the highway several times when traveling to our weekly hike.  In more than one instance someone has decided to pull over and drive on the berm.  In more than a few cases the outcome of this technique for getting things done ends poorly. Despite the unpredictable outcome, jumping the queue is practiced by many in traffic and even more when funneling work to teams. The consequences when working on information technology products are far more predictable than driving, and they are ALWAYS bad. Let’s fix some of the problems leading to queue jumping.

We also have a visit from Susan Parente, who brings her I Am Not A Scrumdamentalist column to the cast.  We discuss risk management when using hybrid agile approaches. 

Contact Susan on LinkedIn linkedin.com/in/susanparente or at Parente@s3-tec.com

(more…)
Jumping the queue breaks the pipes!

Work Entry: Jumping the Queue

Over the past few months, I have been in traffic jams on the highway several times when traveling to our weekly hike.  In more than one instance someone has decided to pull over and drive on the berm.  In more than a few cases the outcome of this technique for getting things done ends poorly. Despite the unpredictable outcome, jumping the queue is practiced by many in traffic and even more when funneling work to teams. The consequences in information technology are far more predictable than driving, and they are ALWAYS bad.

(more…)

The second category of prioritization problems is risk tolerance mismatches. This category focuses on how organizations and teams balance the exposure of having people and resources in the wrong place or accepting work that fails to meet expectations. The process of work entry and prioritization matches the value and the risk of a piece of work to the needs of an organization. Every organization has a risk profile. Some organizations chase projects with very uncertain outcomes for high rewards.  SpaceX and Blue Origin are examples.  In the same industry, United Launch Alliance is far more risk-averse. The risk profile of the organization will impact the projects each firm takes. Accepting work that is outside of the risk tolerance yields stress and increases the likelihood of work that either does not meet the expected return or outright failure. Leading these types of projects can also be career limiting.  Three leading causes of mismatches are:

(more…)

Prioritization is a topic as old as time. Jon M Quigley pointed me at old Spanish and German sayings about prioritization.  The one that struck me was:

“Who grasps at too much loses everything” (unknown)

In today’s world, losing everything translates into higher technical debt, defects, or problem tickets. None of which sound quite the same, but are all painful. One chronic area that generates prioritization problems is timing. Here are some examples: 

Too long of a planning horizon. Prioritization often requires a lot of time and effort which means prioritization becomes an event held at major calendar demarcations (annual, semi-annual, or quarterly — these are often driven by reporting and financial needs). The real world is usually more dynamic, which means people prioritize work outside of the major events using less rigorous approaches. Long planning horizons can generate other bad practices including:

  1. Urgent work is being prioritized over important work. The person that is yelling the loudest commands attention. The classic Eisenhower Box is useful as a framework to sort through how urgent and important a piece of work is. Importance should trump urgency – easily said, but hard to do without an approach.
  2. Queue jumping. The longer the time between prioritization sessions, the harder it is to assure stakeholders that their needs will be addressed on time. This creates an incentive for stakeholders to try to get someone to start on their work outside of normal channels. Queue jumping disrupts the flow of work and makes EVERYTHING later than it should be.
  3. Team level priority drift. Teams prioritize on a more finite schedule which means they can drift away from the top priority without the involvement of their product owners (or whoever is playing that role – someone always is).

Too short of a planning horizon interacting with a longer work cycle. Continual reprioritization which leads to changes in direction or starting or stopping work at any level is demoralizing or is at odds with rules or principles of iteration-based methods. For example, Scrum resists changing priorities at a team level during a sprint.  Short time horizons lead to anti-patterns including:

  1. Re-prioritization fatigue – Teams get tired of being redirected and either strike out on their own (facilitating queue jumping) or ignore changes in priorities. This is a leadership issue; nip either problem in the bud.
  2. Turnover – Demoralized team members leave or create toxic work environments. Ensuring that there is a match between the planning/prioritization cadence and how teams and groups work is not an esoteric discussion. Mismatches can have huge impacts in the way throwing a pebble in a pond causes ripples that seem to go on forever.

The nursery rhyme about the three bears provides a good metaphor for too-long and too-short scenarios; the goal is to match work cycles, business dynamics, and organizational requirements (not too hot, not too cold, but getting it just right). One solution is to understand what part of the organization needs to have an asynchronous approach to prioritization is value stream mapping.  A value stream is a set of activities that are intended to create and deliver a consistent set of deliverables that are of value to customers.

Next: Risk tolerance mismatches — a people and process problem.

In this podcast, I talk with Søren Pedersen.  We talk about teams, value streams, and leveraging agile to improve how teams deliver value.  We started with the definition of a team and then got into the practical nitty-gritty of defining value streams and coaching teams. 

Bio:

SØREN PEDERSEN is a co-founder of BuildingBetterSoftware, a strategic leadership consultant, and an international speaker. With more than fifteen years of software development experience, Søren knows how to help businesses meet their digital transformation goals. Using Agile methodologies, he helps leaders achieve organizational

(more…)

This week we focus on Chapter One of Monotasking by Staffan Nöteberg, which is titled Monotasking In A Nutshell. This chapter lays the foundation for translating the Five Axioms of Monotasking into a simple and straightforward approach. 

(more…)

This week is a doubleheader (baseball term for two games played by the same teams on the same day against each other). We begin our re-read of  Monotasking by Staffan Nöteberg and we have my interview with Staffan. Several years ago I read Staffan’s book on Pomodoro which changed how I work.  Monotasking might be even more useful and impactful.  We discussed how to apply the ideas in the book to improve focus, productivity, and quality of life.

(more…)

Next Page »