Skip to content

Feed aggregator

That's a goatee of a different color

Agile Complexification Inverter - 7 hours 31 min ago
I've made a transition from gray tones to living color - much like Dorothy in The Wizard of Oz (the first color motion picture).

Dog Groomer's have a natural capability to accept a being for what they are and how they present, as well as what their humans may desire.  This is a wonderful ability - we should learn from them.  I had a great conversation with my local groomers at the Blissful Bark Dog Wash, about peoples expectations and inherent biases based upon look, job title, etc.  This capability of acceptance and a deeper level of judgement came to me as they asked about my hair color choices.  They told of the judgements that a dog groomer receives - one even equated the title's status to that of a stripper (good company if you can have friends in low places).

From this and other conversation I've had as a result of a choice to live with more color, I've made some interesting observation about you people.

  • You humans are preoccupied by noticing inconsequential details in your field of view and then fixating upon the possible meaning of such trivial, while being totally oblivious to the important patterns happening all around you.   Dogs do not have this bias.
  • Women are about 8.347 times more accepting of the appearance of someone than men are.
  • Men are generally judgmental - there first question for me has been - Why?
  • White Male Privilege is difficult to comprehend from this state of being.  Having experienced just one fuchsia hair's width of the other side for a fleeting 3 weeks - I can say I understand intellectually - but have no knowledge or understand of it - no experience - no wisdom.
  • Human bias to blend in to the group norm, to look like others, but desire to stand out is ineffable.
Categories: Blogs

Team <-> Group

Agile Complexification Inverter - Fri, 05/26/2017 - 00:46
What makes a team?  Is there a continuum upon which sits the term team?  Some have referred to difficulty comparing apples to oranges - I find it quite easy.

Apple <-> Orange <-> Pomegranate

<- Team ---- Group ->

List of English terms of venery, by animal

Why do we not list HUMAN in the animal column when listing group names?
For example,  horses are know in groups as: teamin harness
haras or harrase
Humans are know in groups as:  mob, group, team, squad, army, click, ....
We have a whole system of dealing with collective nouns.
How do we distinguish between the behaviors of a team and the behaviors of a group?  Have you noticed that manager's refer to people that report to them as a team?  Regardless of the behaviors that the group may exhibit - rarely a team like behavior...  
I've always said just because we all wear the same color jersey doesn't mean we are a team.

Categories: Blogs

Agile Amped Podcast: 10 Essential Scaling Patterns We Can (Probably) All Agree On, and More…

Agile Product Owner - Thu, 05/25/2017 - 20:30

Hi Folks,

A couple of days ago I delivered a keynote at Mile High Agile, “10 Essential Scaling Patterns We Can (Probably) All Agree On.”

Judging from the size of the audience—and from the general buzz throughout the conferences we’ve been attending—there’s no question that the topic of scaling has captured much of the mindshare in the Agile community. Afterall, what enterprise wouldn’t want to enjoy the business and personal benefits of self-organization, higher quality and productivity, and the intrinsic motivation of effective Agile teams?

It is the how that is the question, and on that there are many opinions.

In the spirit of the Mile High conference, ‘Elevating Agile Organizations,’ I wanted to move the discussion beyond a specific method or framework, and instead share the common scaling patterns that we’ve seen perform most effectively when implementing Lean-Agile development at enterprise scale. Thanks to our friends from SolutionsIQ, I was invited to explore the subject in an Agile Amped podcast with Howard Sublett at the conference.

I also had the chance to discuss some of the new things we are working on, because there will always be a next version of SAFe!

You can access the 28-minute podcast here. And if the subject of a ‘essential patterns’ interests you, visit the Essential SAFe guidance article.

Stay SAFe!






Categories: Blogs

Lean-Agile PMO: From Process Police to Adaptive Governance

In this webinar, Sanjiv and Roland share how an evolved PMO can bring discipline to project prioritization, use Lean-Agile techniques to track project portfolios, and provide the support teams need to fully embrace Lean-Agile practices.

The post Lean-Agile PMO: From Process Police to Adaptive Governance appeared first on Blog | LeanKit.

Categories: Companies

3 Questions to Ask During Standup to Keep Speed a Priority

How Kanban Enables Speed
A common theme in workplaces today seems to be “crazy is the new...

The post 3 Questions to Ask During Standup to Keep Speed a Priority appeared first on Blog | LeanKit.

Categories: Companies

4 Patterns for Handling Interruptions

BigVisible Solutions :: An Agile Company - Thu, 05/25/2017 - 17:00


Interruptions are a part of life, even on good Agile teams. You’ve made plans, now they have to change. Again. So, until the sources of interruptions can be plugged indefinitely (which will take some time and work), the team needs a way to handle interruptions while also delivering predictability against the backlog of new features. The goal is maintain predictability in a rapidly changing work environment where interruptions are planned for and can therefore be addressed in a timely manner.

Here are four simple ways to handle interruptions that can actually make a team more resilient to change (with hand-drawn visuals by yours truly).

Pattern 1: Roll With It


We know support and fix requests come in sporadically. Such work comes in every month or two so a special policy for handling it is not needed.


Plan as if there will not be support and fix work. When some comes in, adjust the plan to accommodate it. Drop one or two planned pieces of work to handle the speed bump of fix work, so you can limit your work in progress (WIP) and focus on getting work done. Tell stakeholders immediately what is happening and why. Remind them that, to accommodate this unplanned-for work, you had to remove lesser-priority stories from the Sprint.


Since the interruptions are not that often, we don’t have to change our work process. We simply have to be transparent about the effects of interruptions when they do happen.

Pattern 2: Budget Capacity


The team regularly has support, fix or other interruptive work. It’s expected but the team doesn’t know enough to make a specific plan.


Make an assessment, maybe just a feel or guess based on shared history of how much time is spent each week on such work. Calculate the percent of time spent on such work. Budget that percent of Story Point Velocity (or just hours) for such work. New work is planned for the remaining capacity.


We have a time set aside for the unknown work we know is coming. That way the new work plans can be executed. And, if no interruptions happen, we can do even more than planned!

Pattern 3: Firefighters


The team consistently has “non-new” work to do. Every Sprint or week, without fail, there are enhancements, fixes or service requests that are going to come in.


One or two people on the team each Sprint (or couple of weeks) are designated as “firefighters.” They do not do new work unless there are no interruption requests. The current plan for the next couple of weeks takes into account that these two people are NOT working on new stuff. The firefighter positions rotate every two weeks so the same two people are not stuck doing the fix and support work all the time.


The plan can be met by the people working on the new stories. The firefighters are dedicated to handling interruptions and get to learn new areas of the product. And if there are no interruptions, the firefighters can help get more new work done than planned!

Pattern 4: Special Teams Conditions

Some gnarly problems come in from time to time. These are often so big, so unknown that they are a project all on its own that can threaten to steal everyone away from new work.


Find a spot in your plan where you can stop to re-plan. Finish out the week or two weeks and then re-plan. Peel off a few people who are experts in the problem area and know the technology well. These few people form a Special Team who are 100% dedicated to the big problem. The rest of the team can make plans without them, proceeding with new work.


The current plan for a week or two is not overly disrupted. Then the problem will have the full focus of dedicated people. New work proceeds at a slower pace until the Special Team members come back, but at least it proceeds.

While you’re here, check out my 3 patterns for scheduling Scrum team planning meetings! Also, how do you and your team deal with interruptions? Let me know in the comments!


Subscribe to Agile Eats

Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!

The post 4 Patterns for Handling Interruptions appeared first on SolutionsIQ.

Categories: Companies

The Making Of Servant Leadership - part One

Agile Thinks and Things - Oana Juncu - Thu, 05/25/2017 - 16:51

Servant Leadership is a rising notion in the organisations ecosystem today. The pyramid of classical "Boss Is On The Top Of The World" hierarchy is nevertheless solidly entrenched in our performant organisations culture. So deeply rooted, it lies in our collective blind spot. Because everyone can be a servent leader, this post is the the first in a series that aims to give some guideline on "servant leadership workout", based of 7 elements that matter to a team : Impact, Meaning, Clarity, Structure, Sense of progress, Dependability and Psychological Safety. Let's focus on Impact, Meaning and Clarity.

CreditsI'd like to give credits for my inspiration on the 7 elements to John Le Drew , who hosted an inspiring  at Agile Manchester 2017  "Swearing, Nudity and Other Vulnerable Positions" .  Let's start by being radically authentic.

ImpactChances to acquire intrinsic motivation is greater if the impact of our working together is clear and visible. We might be happy to be compliant with a process, think about the philosophy of being Agile, play collaborative games - including baby foot ;), the feeling of happiness lasts just as much as the time of an enjoyable movie, a spa session or a cool holiday. Then back to the "business as usual" stuff. As long as the impact of the work done together is not clear, there is little chance to long lasting team happiness.
A team, more or less Agile can be very, very unhappy, even if managers are willing to put in place everything that helps empower that team, if they just don't know what purpose what they do serve. Imagine a team who discover, let's say during an exercice of impact and purpose, that what they are building since a number of years is somehow unaligned with their personal ethics? How happy that team you think may be even if they might have the greatest place to work ever?
The impact I'm talking about here, is mainly impact beyond our own selves. That thing that makes us feel contribute at something greater than ourselves.
Philosophers of Cynicism, who often claim it as "pragmatism" by the way, may say that mining his own business in a cool comfy life is the big aim of every one of us. Well...if you think this is true, just imagine yourself in a life where you are very well, thank you and you have no impact to no one's life: no colleagues, no customers, no partner, no children, no parents, no friends, no neighbours,.... Nada. Nope. But you're perfectly happy, right? 'Cause you have everything you need you can think of to be happy and your impact on others is just and wishy-washy concept....

Building for Impact If I was lucky enough until now to convince you that impact matters, how to reveal it? This is the moment when the servant leader enters in the story.  
A servant leader's job is to ask continuously the
Impact Questions:"Why does it matter?" "To whom does it matter?"
A servant leader job will be to hold the space that defines and nurture the impact her team will have on its ecosystem. A servant leader's job will be to make that impact visible by all the members her team : as a target and as an achievement, to collect the metrics that make sense for the impact. Collect frequent feed-back, use visual facilitation to show the impact, and visual management are just some examples.
A servant leader's job is to always remember to all stakeholders what is the impact her team wishes to have on their customers and pairs.

A servant leader's job is to build her team for impact.

Meaning and Clarity
If "impact" is the answer at "why does it matter?", "meaning" is the answer to the "What sense does it make?" What will be doing actually? Exploration of meaning is an exciting exercice on revealing our collective blind spots and our "by default" understanding. Meaning is strongly connected to impact. What we are doing is obviously the result of why we are doing it. Obviously? Maybe a sanity check of this obviousness can be helpful sometimes. Meaning s always aligned around concrete items (or experience). We learn because we experiment, not the other way around. Sorry M. Descartes, neuroscientists don't agree with you. It seems that I rather think because I am instead of being 'cause I think. And of course René Descartes is right about perception replacing reality. As we don't have the same experience of life, we don't give to various things the same meaning. Making a bow to philosophy, time is high to get back to our team. A helpful exercice is to check what we are achieving as a team: does it have a shared meaning? Along with what it means for me, as a member of the team, does that mean the same for the team. Meaning is personal, actions are collective. The gap is ready to operate: the team system moves in a different direction that my own meaning of things tells me to go. Collective activities are complex enough just because they are collective, i.e. it implies more players. Sometimes we go down the line until we achieve a common outcome that nobody wants. This is not magic, it's just non alignment of the meaning of what that outcome should be.

Continuously checking of what is the shared meaning of what we are doing helps teams to have a strong identity and stand up for it. Clarity of meaning is relative. As long as we have a shared understanding (well as shared as possible!) we can achieve a coherent outcome. Like ... deliver a product all stakeholders agree they wanted. I am fascinated by the hidden semantic of almost everything, including plain words. Language is an abstraction and, as a result, it is a source of misunderstandings. Clean Language brilliantly adresses this. Striving for clarity of meaning is a servant leader's key job.

Acting for Clarity of Meaning
A servant leader's job is to listen of her team dynamics and sens the gaps. No leader has the absolute universal definition of things so there is no qualification of the gap to be done. A servant leader's job is to create and nurture the space where team can continuously ask and answer the 
Clarity of Meaning Questions :"What sense does that make to me?""What sense should that make to us?""What are we actually doing?" "How is what we're doing aligned with the impact we want to see?"
Servant leader's job is to keep a "show and tell" state of mind that allows team to present what they are doing. Servant leader's job is create conditions that allow her team to be proud of their outcome. Servant leader's job is to offer the gift of time to team members to check shared meaning. 
A servant's  leaders job is to provide clarity upon a shared meaning
Related postsManage Like A PiratePurposeful AgileOrganisational Design
2 Ways to Embrace a Culture

Categories: Blogs

Why testing in production works.

Agile Complexification Inverter - Thu, 05/25/2017 - 14:21

A video that cannot be unseen.  If you want to truly understand the difference between a unit test and integration tests.
Watch what happens when you write plenty of unit test - but skip the integration test.

Categories: Blogs

The Simple Leader: Just Say No

Evolving Excellence - Thu, 05/25/2017 - 10:27

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen

Clarity about what is essential fuels us with the strength to say no to the nonessentials.
– Greg McKeown

Two years ago, while on my end-of-year reflection trip, I read Greg McKeown’s Essentialism. What a great book! In it, McKeown discusses how to identify your essential projects, activities, and belongings, so that you can then identify (and eliminate) the nonessential ones.

Once you know what is not necessary, you figure out how to get rid of it. Similar to how we eliminated projects that didn’t align with our hoshin plan, we need to get rid of activities and things that are not essential to implement it. One of McKeown’s admonitions is “if it isn’t a ‘hell yes’ then it’s a ‘hell no’.”

I was able to convince several people at my current company to read Essentialism, so we’ve used that last statement on many occasions. When interviewing candidates for a position, we ask ourselves if he or she is a “hell yes.” If we don’t have that level of enthusiasm, then it’s back to the applicant pool. The same goes for potential partnerships, new projects, and equipment. Yes, it’s somewhat subjective, and we do use more quantitative analyses when appropriate, but that last gut call is valuable.

Another key revelation from the book was on how to say no to requests in a way that conveys your time is valuable. If you explain the reasons why you cannot help someone and do so in an authentic manner, requestors will get over their disappointment and you will still have their respect. Perhaps the hardest thing to do, but something that can really improve productivity, is to say “no” to things we want to do—even to good and valuable projects and activities. This forces us to prioritize, thereby focusing our time, resources, and attention on what really matters.

I have used this concept with considerable success over the past year. I’ve turned down speaking engagements I wasn’t interested in, collaborations that I didn’t think would go anywhere (in the past, I might have tried anyway), and meetings where I was invited but didn’t really need to be there. This has freed up a lot of my time and reduced the stress and drudgery of having to do things that didn’t add value, allowing me to invest my limited time more wisely. Sure, I still use a lot of my time to help others, but I now do it more methodically (and, in my opinion, better and more mindfully).

Categories: Blogs

Exploiting Variability: A Principle of Product Development Flow

Agile Complexification Inverter - Wed, 05/24/2017 - 21:44
What do these phrase have in common - what is their inherent consistent meaning?

  • Zero Defects
  • Take the time to do it Right
  • Repeatability and Reliability
  • Process Maturity Model
  • Measure twice, cut once
  • Six Sigma
  • Rework is Waste, Lean processes remove Waste

They are ironically consistent in their purpose to reduce variability.  Don Reinertsen will attempt to convince us that in the domain of product development (unlike other domains) variability may not be the enemy of good.  He will argue that it is the economic payoff-function of this outcome that is of upmost concern in design.

Voltaire's aphorism:  Perfect is the enemy of good.
I'm in a group at work that is reading books on Agile software development topics to what purpose... well to learn I hope.  After Lyssa's book on Coaching Agile Teams we turned the knob up to 11 with Don Reinertsen's Principles of Product Development Flow.  Since it's such a tough read, a dense book with so much knowledge, we have a divide and conquer mind set... we read a chapter and present it to the group (knowing that the group as an aggregate will not read the book).  So my chapter is #4, Exploiting Variability.  This is my plan... to add variability to the typical book report that a group of people might fall into the habit of performing - by adding variability to the format.
"We cannot add value without adding variability, but we can add variability without adding value." -- Don Reinertsen

Agile in 3 Minutes: #23 Vary by Amitai Schlair
...the conclusion "Projects by design and in effect magnify risks."
Ok let's play.  Did you know that play is rooted in variability? (Games and the Human)

"... however different their descriptions and interpretations of play, each rhetoric reveals a quirkiness, redundancy, and flexibility. In light of this, Sutton-Smith suggests that play might provide a model of the variability that allows for “natural” selection. As a form of mental feedback, play might nullify the rigidity that sets in after successful adaption, thus reinforcing animal and human variability. Further, he shows how these discourses, despite their differences, might offer the components for a new social science of play."  
-- The Ambiguity of Play by Brian Sutton-Smith

Fundamental to this discussion is the .... pardon the overuse of the phrase.... various types of domains that humans participate in.  We shall need to distinguish between the creative domains of design and innovation from other domains such as manufacture or agriculture.  In some domains the desire for variability is low, and in these endeavors humans have done well to reduce variance.  However in the more creative endeavors this tendency is harmful.  One doesn't wish for an artist to produce the exact same work of art repeatedly for 20 years.  Now that we agree upon that basic fundamental concept.  Do we agree that software development is a creative act?  If not - you should click on an exit link now...  because we have a fundamental disagreement and I will not be able to sustain the cognitive dissonance required for both of us to continue.

A challenge...  simulate to streams of flow ... one with variability and one without... 1, 2, 3, go....

Conteneo's Ideas into Action(tm) framework
[V1] Principle of Beneficial Variability: do not make the mistake of only paying attention to the probability of success (benefit).  "Paying attention to the payoff-function radically transforms our view of variability."

[V2] Principle of Asymmetric Payoffs:  not all payoffs are the same... we are searching for big payoffs.  In this search, we seek the complicated asymmetric function  (see the 1997 Nobel Prize for Economics: Robert merton & Myron Scholes for Black-Scholes option pricing model).  In this realm live the venture capitalist - start to understand their principles and models.

[V3] Principle of Optimum Variability: It is only via the economic transformation of variability (Payoff Function) that we can judge the goodness of variability.  The notion that all variability is bad (therefore eliminate variability) is to totally misuse the concept.  If one cannot graph the payoff function - one doesn't understand the economies at work.

In the [V4] Principle of Optimum Failure Rate we find the distinction between exploratory testing which should be optimized to generate information and therefore will have high failure rates (close to 50% or you're not doing exploratory testing well).  Versus the design validation tests (strive for 100% success rate) where success looks like green bars.  Noting that most companies do a poor job of communicating their failures - and therefore repeat their failures, thereby produce no new information.  "Only new failures generate information."

There are two approaches to the economics of variability - change the amount of variability or change the economic consequences of that variability.

First attempts to reduce variability.

[V5] Principle of Variability Pooling: overall variation decreases when uncorrelated random tasks are combined.
[V6] Principle of Short-Term Forecasting:  forecasting becomes exponentially easier at short-term horizons.
[V7] Principle of Small Experiments:  many small experiments produce less variation than one big one.
[V8] Repetition Principle:  repetition reduces variation.
[V9] Reuse Principle:  reuse reduces variability.
[V10] Principle of Negative Covariance:  we can reduce variance by applying a counterbalancing effect.
[V11] Buffer Principle:  buffers trade money for variability reduction.

Time for you to participate - give me an example from your place of employment for each of those attempts to reduce variability - this should be easy.

Lastly attempts to reduce the economic consequences.

[V12] Principle of Variability Consequence:  reducing consequences is usually the best way to reduce the cost of variability.
[V13] Nonlinearity Principle:  operate in the linear range of system performance.
[V14] Principle of Variability Substitution:  substitute cheap variability for expensive variability.
[V15] Principle of Iteration Speed:  it is usually better to improve iteration speed than defect rate.
[V16] Principle of Variability Displacement:  move variability to the process stage where its cost is lowest.

Don concludes the chapter by stating: "Variability is not the enemy; it is a tool to create economic value."  Can you weird this powerful tool?

See Also:
Variation: The Root of All Process Evil

Don't confuse Reinertsen's Product Development Flow with the more general psychological term Flow by psychologist Mihaly Csikszentmihalyi's famous investigations of "optimal experience." A discovery that revealed what makes an experience genuinely satisfying is a state of consciousness called flow.

Categories: Blogs

Agile Metrics: A GQM Approach

Leading Agile - Mike Cottmeyer - Wed, 05/24/2017 - 21:22

When undertaking an Agile transformation, there is a need to collect data to demonstrate progress and show improvement, but where does one even start? Common Agile metrics approaches do well at measuring team velocity and throughput but can sometimes overlook the requirements of executive sponsors, product management, and other key stakeholders. This problem is often rooted in a lack of understanding about what business goals are driving decision making throughout the organization and what questions we should be answering with the metrics we collect.

The “Goal-Question-Metric” (GQM) approach is a proven method for driving goal-oriented measures throughout a software organization. With GQM, we start by defining the goals we are trying to achieve, then clarifying the questions we are trying to answer with the data we collect. By mapping business outcomes and goals to data-driven metrics, we can form a holistic picture of the Agile environment and clearly articulate how we are doing across the span of the enterprise.

The GQM Approach to Agile Metrics: John Tanner #AgileDayATL

— LeadingAgile (@leadingagile) May 19, 2017

During this session, we will explore the GQM approach and show its effectiveness in identifying the key information your enterprise needs to know at the Executive, Portfolio, Program, and Delivery tiers. We will provide example metric sets for each tier and explain the goals and questions that drove us to them. At the end of this talk, the audience will understand, not only how to ask the right questions, but specifically what metrics can be used to answer them.

Agile Analytics: A GQM Approach to Enterprise Metrics from LeadingAgile

The post Agile Metrics: A GQM Approach appeared first on LeadingAgile.

Categories: Blogs

Production ready AWS ECS (EC2 Container Service)

Xebia Blog - Wed, 05/24/2017 - 17:59

Are you looking to run Docker containers on AWS? Or are you looking to use AWS ECS (EC2 Container Service)? Does it need to be production ready? If so, then speedup your process and be ready today by looking at my GitHub repository on ECS. It contains infrastructure as code with Terraform for a quick […]

The post Production ready AWS ECS (EC2 Container Service) appeared first on Xebia Blog.

Categories: Companies

Agile at Scale – Outcome Driven (or Broken)

Tyner Blain - Scott Sehlhorst - Wed, 05/24/2017 - 15:42

thousands of monks

Taking agile, a process otherwise optimized for small, cross-functional, collaborative teams and making it work at scale is fascinating. You have to change some elements, and retain others, as you redefine the context. Being outcome driven, is one element you must retain – or even elevate in importance, or you fundamentally break the system of delivery

Getting Faster at Building the Wrong Thing I “went agile” in 2000/2001 – I was writing software and leading teams at an enterprise software company at the time, and we adopted elements of XP and other agile practices in what we branded (internally and externally) as Fast Cycle Time (FCT). It was more than just incremental delivery, we really did incorporate agile principles like pairing and demoing, and engineering practices like automated build and test processes, code-reads, design for testing. It was a brave new world for me at the time and I was hooked forever. Over the next few years my career evolved through people-management, pre-sales, and program management roles into product management. dog doing backflips I spend a lot of time a decade ago as an early agile product manager – testing, learning, applying, and understanding how to be not only a product manager working with agile teams, but also how to be agile as a product manager. Both were then uncommon, and both are still important. I would regularly say – and I still believe it to be true – that when a team or a smaller organization (say 100 developers or fewer) goes agile, if they are not focused also on product management, all they are doing is getting faster at building the wrong thing. To quote Jon Harmer (@jharmer), who I’m fortunate to now call a colleague, “you just crash your car into the wall faster.” I’ve spent the last half-year in the beginning of my journey understanding how agile product management at scale can work. Seeing things in practice. Helping a mid-size organization make the transition from waterfall (at scale) to agile (at scale). Think of a couple dozen teams (a couple hundred people) working to deliver across a couple hundred systems, for a multi-billion dollar organization. Long time readers at Tyner Blain will know that my writing here is driven in large part by the absorption, adoption, extrapolation and generalization of experiences through patterns and into concepts and applicable ideas. For small teams, agile development without a focus on the right outcomes is getting faster at building the wrong thing. As a result you just build more of the wrong stuff. A lack of focus on outcomes is no better than a focus on the wrong outcomes.  Being output-focused is not being outcome-focused. outcome vs output for agile at scale For agile at scale, I don’t believe this is true. At scale, if you are not driving your execution through a focus on outcomes, I don’t believe you are actually faster – you’re only different. At scale, to leverage Jon’s cleverness, “you still crash your car into the wall, but not necessarily faster.” outcome vs output - with selection of outcomes The key difference here is around the opposing system dynamics of encapsulation and coordination.  Smaller organizations have much less need for coordination – “everything” happens within the team.  Why that matters is worth exploring. Scale is Built Necessarily on Orchestration and Planning

You might believe planning to be anathema to agility. The classic war between rationalism and empiricism, which makes me want to re-read Brooks’ The Design of Design. I also suspect another luminary I’m thrilled to be working with, Dave Nicolette (@davenicolette) would even suggest that “agile at scale” may be oxymoronic on principle. He’s probably already written about it too – but I get to hear him talk about it :). At the end of the day, it depends on how you define agility, or more precisely how you define “self-directed.” There’s always a context in which self-determination applies. Since this is a heavy name-dropping post, I will once again thank Andy Polaine (@apolaine) for the visual which is permanently grafted onto the concept of nested contexts for me now.

Agreeing that teams have latitude of operation and autonomy of decision making within the context of working together is a tenet of agile.  Doing this to achieve a shared desired outcome is the key to harnessing agility as a powerful force for achieving business objectives. I would propose  outcome-driven agile teams are the pry-bar we can use to loosen and potentially untie the Gordian knot of agility and scale being logically consistent. So – as long as we are willing to accept a definition of agile where “self-directed” means autonomy within the context of the role of that team, we only need to articulate the rest of the context.
  • Agility at scale requires multiple small teams
  • Each team has autonomy within the context of the role of the team
  • Each team is working in coordination with other teams to deliver
  • Each team is focused on business goals
This focus on the business goals – the “why’s” of investing to build something – is the definition of being outcome driven. dog and owner doing synchronized backflips This coordination requires planning, in an ongoing fashion.  There is a theoretical continuum from no-coordination to pure synchronous action. The fewer highly-coupled systems, and the fewer bottlenecked shared resources, the less coordination is required. As a technologist, I can imagine a situation where all systems are decoupled, and no teams are over-subscribed; through a combination of architectural and training and staffing decisions. As a consultant, I am comfortable there will never be an organization at scale which can avoid coordination and planning. Because things change. Everyone Has a Plan until…

boxer getting punched in the face

“Everyone has a plan, until they get hit.” – Mike Tyson There are many quotable versions of this concept, this is the one that grabbed me years ago. Other fighters would prepare for a fight with Mr. Tyson, crafting a plan to dance around him, tire him out over several rounds, and then use their greater endurance and skill to win the fight. Mr. Tyson would regularly make those plans worthless by doing something like knocking his opponent unconscious in the first half of the first round. As Mr. Tyson said – “Everyone has a plan, until they get hit.” This for me is the touchstone to remember that there are many reasons your plan will change. Another colleague of mine, Jeff Howey (@AgileAlchemy) is fond of asking the room – “the plan is a lie, right?” To which everyone nods yes. This isn’t something unique to agile – the waterfall plan is a lie too. About 5 years ago, I explored several reasons why products fail. Among the reasons are variations which all reflect a need to change the plan. You realize (by gaining new information, outside of the development process) that your team is going to fail, so you need to change. A formal mechanism for doing this is a pre-mortem.
  1. You picked the wrong customer for whom to solve problems.
  2. For the customer you picked, you picked the wrong problem to solve
  3. You made the mistake of declaring success without completely solving the problem
  4. Your solution approach – you discover – will not solve the problem
  5. Your execution / implementation is unable to rise to the needs of your design, and therefore will not solve the problem (even with a viable design)
The last two scenarios, (4) and (5) are actually not examples of selecting the wrong problem, they are examples of failing to solve the selected problem. Usually, these are not problems with the plan (the choice of problem to be solved), although they could be. In the situation where your strategic choices about which problems to solve are both valuable and desirable, it is possible that they are not feasible for your team to solve. It may be that your strategy is one which is beyond the skills of your teams, in which case you need to choose a different problem to solve. I’ve listed them for the sake of thoroughness – although I have only once seen this a driver of failure. Usually, other things are also wrong. You can run a powerful exercise, called a premortem, to help discover in advance what is wrong with your plan.  Proposed by psychologist Gary Klein, it is one of Daniel Kahneman’s favorites.  Here’s a 3 minute explanation Outcomes and Collaboration and Agile When a small (e.g. “as designed”) agile team discovers that they are working on the wrong problem – for any of the reasons listed – they can easily change. They can change because they are directly collaborating with their business stakeholders. They are directly engaged with their customers acquiring the signals which trigger the discovery that the plan needs to change.  From an organizational perspective, you can describe this team as being encapsulated – the ability to change the plan is within their collaborative area of influence. They can change the plan. They can change the plan because they are working together – both the business side (sponsors / customers / stakeholders / users) and the technology side (the team creating the product or solution). They share an understanding of the value/opportunity/desirability and the cost/complexity/time of solving the problem. They share an understanding of the suitability of the design to potentially solving the problem. They share an understanding of their ability to execute against the design.  They can collectively manage technological and market uncertainty about why, what, and how they are doing their work. This team is outcome driven. And when they get metaphorically punched in the face, they can pivot to a new way to solve the problem, to a new definition of “solved” or to a new problem to solve. Because the team is encapsulated the complexity of this change can go unnoticed.  The ripple-effects and new orchestration requirements are resolved “inside” the team. If the team were not outcome driven, their ability to radically change would still be comparable – the team could be tasked with a new set of assignments, and they would discard their previous work, resolve the dependencies and do the new work. From outside of this encapsulated team, the change process would appear to be just as easy. This misapprehension – that change is easy for agile teams, regardless of focus on outcomes – is the root cause of the difficulties organizations struggle to adopt agile practices for large ecosystems / organizations. Agile Without Outcomes

screeching record needle

What happens when this team tries to not be outcome driven?  OK.  Insert the sound of screeching tires (or a phonograph needle dragged across the surface).  I have repeatedly challenged other authors for doing the following:
  1. Describing a bad thing.
  2. Assigning the name of a good thing (like roadmaps) to the bad thing.
  3. Eloquently arguing about why the bad thing is genuinely bad
  4. Declaring the good thing from (2) to be bad, because the bad thing from (1) is actually bad.
I will try and avoid the same mistake.  If the team is not outcome driven,their process is not agile (it is only incremental delivery against a project specification).  What this team can do, as I’ve said in the past, is generate more output.  This is a more efficient process, but only more efficient – not more effective.  It helps you to crash into the wall faster.  And that makes it a bad thing. Effective coordination and execution is irrelevant when you’re solving the wrong problem. Outcomes and Progressive Elaboration An interesting characteristic of agile, for product managers, is how “requirements” are managed.  These days, I really talk about intentionality because what I’m talking about is the organization’s intention to achieve an outcome. The term intentionality resonates with my audiences, and helps me focus. One agile principle (I believe I first heard it from Kent Beck back in 2000) is about doing things at the last responsible moment.  It is also a characteristic of lean manufacturing. In software development, “doing something” is creating work-in-process inventory.  The insights from thinking, designs from designing, code from coding, tests and results from testing are inventory.  Inventory.  Don’t create it until you have to. YAGNI is one way to remember this – “you ain’t gonna need it (so don’t build it).” Just as rolling-wave planning encourages us to sketch out rough time-lines and directionally-correct plans into the future, with detailed planning reserved for the immediate future, intentionality is progressively articulated relative to time and scope.  We avoid investing to create something likely to be discarded – specific details about the distant future. There is a long-term goal or outcome you are trying to achieve. In support of that long term goal you may define a handful of strategic initiatives. To advance those initiatives you may also identify a set of deliverable, valuable products or product capabilities.  These are steps along the path to the long term goal.  The first of those capabilities may get progressively elaborated into features and stories – which are what the team works to deliver in releases and sprints, getting feedback along the way.  You do not build out all of the stories which span the entirety of every initiative designed to realize the goal.  You progressively elaborate, as needed.  At the last responsible moment. A scannable list of one way to progressively articulate intentionality:
  • Strategy – a long term goal, multi-year in scale and organizational in scope
  • Opportunity – an initiative supporting the strategy, easily a year or longer, maybe divisional in scope
  • Epic – a key component or capability as part of the opportunity, market-positionable, product or service scoped
  • Feature – a collection of outcomes from a user’s point of view, atomically deliverable or testable for customers
  • Story – one scenario of value delivery for at least one customer in at least one context
With a small team, all of this progressive elaboration does two things.  First, it establishes context – the big picture.  Second, it drives focus – what the team works to achieve right now.  However, it comes at the cost of inextricably coupling requirements and design elements at multiple levels. Drost effect image Progressive elaboration of intent incorporates elements of design and planning.  
  • The stories make sense, given the selected feature.
  • The feature reflects a set of design decisions (in terms of both interaction and implementation) to realize the intentionality of the epic.
  • The epic manifests some hypotheses and assumptions about how best to realize an opportunity.
  • The opportunity represents one aspect of one way to succeed with a strategy.
This is more than intentionality, it is also design and planning.  They are inextricably linked. As you cross multiple contexts – progressively getting deeper into the problem space – you are grafting planning elements and design decisions into what the team will do. As you engage with the market over time – you will discover you need to adapt the plan.  As a small agile team, you easily do this.  You revisit decisions up and down the elaboration ladder and you adapt.  Operating at scale is about orchestrating and coordinating.  Planning.  This is why an outcome focus is required for agile to work at scale.  As desired outcomes change, plans change Outcomes and Planning at Scale

bridge under construction

When you’re orchestrating a large organization working together, there are necessarily elements of decomposition and allocation of responsibility for executing parts of a plan.  This is true for waterfall and agile organizations.  They both do it, but they both do it differently – an aspect which makes transformation from one to the other difficult. In the waterfall world, areas of the organization, and then divisions, and teams, will each be “assigned part of the plan” to execute.  Someone coordinates that execution and allocation of responsibility across teams.  This is how large projects have always been done. When a not-agile large organization is calling itself “agile” but orchestrating a plan across teams, instead of progressively elaborated intentionality, the system behaves similarly to a large waterfall organization. When the plan changes, things get interesting – the may we live in interesting times kind of “interesting.” One of the teams will discover that their particular portion of the plan won’t work.  Perhaps they get negative customer feedback on a prototype or the deliverables of the current sprint. The team wants to change the plan, to incorporate this feedback. The problem is that the team only knows the plan and not the intent; they lack the context to effectively deviate from (or modify) the plan to address the very real problem.  They have to bureaucratically go “up the chain” with their findings, and initiate discussions around how to adapt the plan.  In the meantime, nothing gets done.  This is “at scale” but it is not “agile.”  It is the same for waterfall and not-agile teams. For a team to be able to adapt the plan they need to understand the intent.  With insight into intent, they can be self-organizing within the context of how they approach delivering their portion of intentionality.  They can assess if whatever they learned invalidated the framing of intentionality one-level up as well.  And that team can determine how they will adapt, without having to escalate all the way up through the progressive elaboration – except when that is what is required. The following distinction is key.  When each team is working a portion of a plan, they have no insight into cross-team dependencies and must always escalate before changing.  There is not autonomy with respect to adapting to changing circumstances.  When each team is working to deliver a portion of intent, they have autonomy and flexibility to change what they build to deliver.  They only escalate when what they learn invalidates intentionality – and then escalation only goes as far as it needs to. What is unique is that with a focus on intentionality, at each stage of progressive elaboration, the teams can adapt within their context, without disrupting or invalidating the greater context of intentionality. This is the secret sauce of agility at scale.  Without it, you only have waterfall, agile-in-name-only, at scale Agile at scale cannot work without intentionality. Speed of Change Requires Intentionality Near the start of this article, I asserted that without intentionality, at-scale “agile” organizations are not faster.  If there were no changes to the plan, they would be faster than a waterfall organization – avoiding death marches and being generally more efficient is an outcome of a frequent delivery cadence.  However, every team will get punched in the face and every plan will have to change. The need to change the plan – and all of the cross-team dependencies – is what slows down not-agile at scale teams, making them no faster than waterfall teams. Working against progressively elaborated intentionality is what allows agility and adaptation by small teams working in concert as part of a larger organization.  Without delays.
Categories: Blogs

Scrum Day Europe, Amsterdam, Netherlands, July 6 2017

Scrum Expert - Wed, 05/24/2017 - 10:00
Scrum Day Europe is a one-day conference dedicated to Scrum. This conference dedicated to Agile project management and Scrum takes place in Amsterdam and will features local and international expert...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Agile Cymru, Cardiff Bay, UK, June 19-20 2017 (cancelled)

Scrum Expert - Wed, 05/24/2017 - 09:30
Agile Cymru is a two-days Agile conference organized by Agile Wales. Agile Cymru offers practical advice, techniques and lessons from practitioners, experts and beginners in the field of Agile...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Agile Open Spain, Segovia, Spain, June 23-24 2017

Scrum Expert - Wed, 05/24/2017 - 09:00
Agile Open Spain is a two-day event focused on Agile software development approaches like Scrum and XP. The Agile Spain community organizes this conference and all discussions will be in Spanish. The...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Communities

Vending Machine of Values & Principles

Agile Complexification Inverter - Wed, 05/24/2017 - 05:54
Have you seen the new automobile vending machines.  It appears we could put anything in a vending machine.  So what would you put into the vending machine?

Categories: Blogs

Dealing With Optimistic Concurrency Control Collisions

Jimmy Bogard - Wed, 05/24/2017 - 00:06

Optimistic Concurrency Control (OCC) is a well-established solution for a rather old problem - handling two (or more) concurrent writes to a single object/resource/entity without losing writes. OCC works (typically) by including a timestamp as part of the record, and during a write, we read the timestamp:

  1. Begin: Record timestamp
  2. Modify: Read data and make tentative changes
  3. Validate: Check to see if the timestamp has changed
  4. Commit/Rollback: Atomically commit or rollback transaction

Ideally, step 3 and 4 happen together to avoid a dirty read. Most applications don't need to implement OCC by hand, and you can rely either on the database (through snapshot isolation) or through an ORM (Entity Framework's concurrency control). In either case, we're dealing with concurrent writes to a single record, by chucking one of the writes out the window.

But OCC doesn't tell us what to do when we encounter a collision. Typically this is surfaced through an error (from the database) or an exception (from infrastructure). If we simply do nothing, the easiest option, we return the error to the client. Done!

However, in systems where OCC collisions are more likely, we'll likely need some sort of strategy to provide a better experience to end users. In this area, we have a number of options available (and some we can combine):

  • Locking
  • Retry
  • Error out (with a targeted message)

My least favorite is the first option - locking, but it can be valuable at times.

Locking to avoid collisions

In this pattern, we'll have the user explicitly "check out" an object for editing. You've probably seen this with older CMS's, where you'll look at a list of documents and some might say "Checked out by Jane Doe", preventing you from editing. You might be able to view, but that's about it.

While this flow can work, it's a bit hostile for the user, as how do we know when the original user is done editing? Typically we'd implement some sort of timeout. You see this in cases of finite resources, like buying a movie ticket or sporting event. When you "check out" a seat, the browser tells you "You have 15:00 to complete the transaction". And the timer ticks down while you scramble to enter your payment information.

This kind of flow makes better sense in this scenario, when our payment is dependent on choosing the seat we want. We're also explicit to the user who is locking the item with a timeout message counter, and explicit to other users by simply not showing those seats as available. That's a good UX.

I've also had the OTHER kind of UX, where I yell across the cube farm "Roger are you done editing that presentation yet?!?"


Another popular option is to retry the transaction, steps 1-4 above. If someone has edited the record from under us, we just re-read the record including the timestamp, and try again. If we can detect this kind of exception, from a broad category of transient faults, we can safely retry. If it's a more permanent exception, validation error or the like, we can fall back to our normal error handling logic.

But how much should we retry? One time? Twice? Ten times? Until the eventual heat death of the universe? Well, probably not that last one. And will an immediate retry result in a higher likelihood of success? And in the meantime, what is the user doing? Waiting?

With an immediate error returned to the user, we leave it up to them to decide what to do. Ideally we've combined this with option number 3, and give them a "please try again" message.

That still leaves the question - if we retry, what should be our strategy?

It should probably be no surprise here that we have a lot of options on retries, and also a lot of literature on how to handle them.

Before we look at retry options, we should go back to our user - a retry should be transparent to them, but we do need to set some bounds here. Assuming that this retry is happening as the result of a direct user interaction where they're expecting a success or failure as the result of the interaction, we can't just retry forever.

Regardless of our retry decision, we must return some sort of result to our user. A logical timeout makes sense here - how about we just make sure that the user gets something back within time T. Maybe that's 2 seconds, 5 seconds, 10 seconds, this will be highly dependent on your end user's expectation. If they're already dealing with a highly contentious resource, waiting might be okay for them.

The elephant

One option I won't discuss, but is worth considering, is to design your entity so that you don't need concurrency control. This could include looking at eventually consistent data structures like CRDTs, naturally idempotent structures like ledgers, and more. For my purposes, I'm going to assume that you've exhausted these options and really just need OCC.

In the next post, I'll take a look at a few retry patterns and some ways we can incorporate them into a simple web app.

Categories: Blogs

Defining “Scaling” Agile, Part 2: Program Management for Product Development

Johanna Rothman - Tue, 05/23/2017 - 23:36

The first post was about scaling functions to working as collaborative agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program.

The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a program, a collection of several projects with one business objective.

Programs come in a wide variety of shapes and sizes. Here are some kinds of programs:

  • You might have just one feature team and need people from Marketing or Legal to release the product. You need to bring those people into the program somehow, so they can accomplish their deliverables so the organization can release the product.
  • The project is larger than one or two feature teams. You may have several feature sets and need people from Marketing, or Legal, or Finance (or someone else) to be able to release the product.
  • You might be managing the software program, and have several feature teams or programs within the larger program. You might have the Engine program, and the Admin and Diagnostics programs. Each feature set has several teams collaborating on the code in their feature set(s). And, you probably need people across the organization to finish the work for the product. Those are the people from Marketing, Legal, Finance or others that I keep talking about.

Programs exist when you need a little structure to organize the feature teams and/or organize the deliverables across the organization. Agile programs especially don’t need too much structure. The key is to create something that helps the people collaborate and visualize the work they need to complete.

Here’s a way to think about scaling to a program:

Scale the collaboration across product development to release products. 

 Scaling Collaboration Across the OrganizationYes, I wrote a book about that:  Agile and Lean Program Management: Scaling Collaboration Across the Organization.

Here’s how I think about scaling collaboration across product development:

  • Each team thinks about how fast they can release their work to the rest of the program. (BTW, fast isn’t useful unless the work is great.)
  • Each team manages its WIP (Work in Progress) so they aren’t bottlenecking themselves or anyone else.
  • The POs work as a team so the feature teams always work on the most valuable work for the program. Sometimes, feature teams move from one feature set to another because that work is more valuable. If you’re worried about interdependencies, you might not have feature teams. Or, the POs aren’t working together. See Understand Your Project Interdependencies.
  • Teams use the power of their small-world networks (and possibly Communities of Practice) to solve problems at the team level. Teams often don’t need help from anyone with “manager” or “master” in their titles.

Aside from trusting the teams to deliver and asking them to let you know if they can’t, I also suggest these ideas:

  • Scale the visualization of the work. How do people see what other teams or people are doing?  (I have plenty of images of kanban boards so you can see if any of those work for you.)
  • Keep the hierarchy as flat as possible so problems don’t have to go up a hierarchy, over and down, and then follow their path back before someone gets the answer they need.
  • Consider a cadence of meetings that solve problems. These meetings are not standups. Standups might expose problems but they don’t solve them.

I recommend teams decide if they need to organize as small programs (such as above with the Engine, Admin, and Diagnostics programs). That allows a cadence of limited-participation program team meetings to solve problems the teams can’t solve.

In addition, measure at the program level. Sure, the teams need to measure their cycle time and velocity, whatever they choose. In addition, measure the features complete at the program level, program level WIP, and any other program measures that make sense to you. (See Velocity is Not Acceleration for two of these charts.)

Agile program management helps product development use agile approaches to release products. Next up is how to scale agile from product development to other parts of the organization.

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.