Skip to content

Blogs

That's a goatee of a different color

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

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
herd
stable
string
stud
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

The Making Of Servant Leadership - part One


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.





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

Exploiting Variability: A Principle of Product Development Flow

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 -iSixSigma.com

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 - 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 https://t.co/k0G3jWDSC4

— 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

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

Vending Machine of Values & Principles

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

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

Info Radiation vs Info Refrigeration - a metaphor

Is a metaphor a form of lightweight model?


"All models are wrong, some models are useful."
-- George Box





The metaphor of information radiation is quite well know to many in the software industry.  Did you ask why?  Maybe because much of our work is very hidden from view, until we run the program and the computer interprets the code to produce some desired outcome.  Even that outcome may be obscured from view, and we must produce reports upon the data that the program produced.  So in a world where smoke and mirrors are common, one antidote to the common problem of not knowing where one is along the path toward product completion, a visualization is a powerful tool.

Generally speaking the information radiator has similar properties to the old fashion building heat radiator that used a steam media source to heat heavy iron and radiate the heat from the iron into the room.  It feels great to be standing next to a radiator when you've just come in from the cold.

What is the refrigeration process - what's required to cool some air?  Currently we use the 200 year old Carnot cycle to produce the cooling effect that your summers are known for.  I doubt that my home of Dallas Texas would be the Mecca of IT if not for Mr. Nicolas Carnot and his research into what would become air-conditions environments.  A comfortable 70 degrees indoors while the Texas sun is 95 in the shade.

Pressure-Volume diagram of Carnot cycleI will leave the internal working of the AC unit to your study (I did it back in college - fascinating stuff).

When we put information is some systems we encode or compress it in such a way that the storage is efficient.  Think of a data base, significant work is done upon the data to store it.

When we pull it out of those systems we also must now do work to make the data into information, and then do more work to make the information understandable by the people that have little knowledge of where the data came from, the purpose of storing the data and the context from which that data/info may have resulted.  Someone will interpret that context, information and purpose and try to convey all this in a summary of the meaning behind larger data sets that the important people reviewing the information have time for.  This expansion of the information and subsequent summarization or generalization takes energy from the system as a whole.

pondering the connections - AC to info refrigeration metaphor....  what do you see in this metaphor?

is there a useful model to play with?


Categories: Blogs

Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams

Johanna Rothman - Mon, 05/22/2017 - 18:34

I keep encountering confusion about what scaling agile is. I’m writing what I think is a 4-part series to define it so we all talk about the same thing.

When I ask people to define what they mean by scaling agile, they talk about these possibilities:

  1. They have agile developers. They want agile testers. This is creating cross-functional agile teams for projects.
  2. They have had successful one- or two-team agile projects. Now, they’re ready for an agile program.
  3. They have agile product development (it might be called IT or Engineering or R&D or something else), and they want to share agile approaches across Marketing, Finance, HR.
  4. They want to build an entirely agile business.

Each of these is different. Each solves a different problem for the organization. This post is about #1: the developers have been agile in their single function team. They want to bring the testers along and create cross-functional teams. (It could be the other way around where the testers are agile, but I haven’t seen that. I have seen testers using iterative and incremental approaches, but often that’s a reaction to the developers.)

I wrote about the problem of staggered iterations in How Long Are Your Iterations, Part 1. When the developers are on a different cadence than the testers, they don’t act like a cross-functional feature team. The “team” isn’t delivering a finished feature. They’re not solving problems like a team. They often have a ton of WIP (Work in Progress). Using iterations does not make a team agile.

On the other hand, if this is where you can start, do start there. The next part in your “scaling” of agile is to move to cross-functional feature teams. That’s where the team works together, in a collaborative fashion, to create finished features. You might do this in iterations, especially if you’ve only heard of Scrum. You might use a kanban board to see all the flow of work through your team and your bottlenecks.

I keep talking about “your team.” Agile approaches use cross-functional teams who focus on delivering features. I’m not big on component teams. That’s because they postpone delivery of finished features. I also hate the idea (and name) of “shared services.” I’ll blog about that later.

You might think, “The developers are agile. We’ll scale agile to the testers.” If that’s the way people think about agile in your organization, maybe that’s the best you can do. Here’s a possible reframe for you:

Scale agile from one function to a cross-functional team.

When you (and your managers) start to think about cross-functional teams rather than functions, you start to realize the benefits of agile.

If you think scaling agile is sharing agile between functional teams, consider reading my upcoming book, Create Your Successful Agile Project. I’m still in editing and then it goes out for review. We expect it will be available in July.

I do have reviewers, but if you are struggling with your agile approach, let me know if you would like to be a reviewer. We might have room for another couple of reviewers.

Categories: Blogs

Cycle Time and Lead Time

Our organization is starting to talk about measuring Cycle Time and Lead Time on our software engineering stories.  It's just an observation, but few people seem to understand these measurement concepts, but everyone is talking about them.  This is a bad omen...  wish I could help illustrate these terms.  Because I doubt the measurements will be very accurate if the community doesn't understand when to start the clock, and just as important - when to stop it.

[For the nature of confusion around this terms compare and contrast these:  Agile Alliance Glossary; Six Sigma; KanbanTool.com; Lean Glossary.]

The team I'm working with had a toy basket ball goal over their Scrum board...  like many cheep toys the rim broke.  Someone bought a superior mini goal, it's a nice heavy quarter inch plastic board with a spring loaded rim - not a cheep toy.  The team used "Command Strips" to mount it but they didn't hold for long.

The team convinced me there was a correlation between their basketball points on the charts and the teams sprint burndown chart.  Not cause and effect, but correlation; have you ever stopped to think what that really means?  Could it mean that something in the environment beyond your ability to measure is an actual cause to the effect you desire?

I asked the head person at the site for advice, how could we get the goal mounted in our area?  He suggested that we didn't need permission, that the walls of the building were not national treasures - we should just mount it... maybe try some Command Strips.  Yes, great minds...  but what about getting fired after putting holes in the walls scares one from doing the right thing?  How hard is it to explain to the Texas Work Force Commission when they ask why you were fired?

The leader understood that if I asked the building facilities manager that I might get denied - but if he asked for a favor... it would get done.  That very day, Mike had the facilities manager looking at the board and the wall (a 15-20 minute conversation).  Are you starting the clock?  It's Dec 7th, lead time starts when Mike agreed to the team's request.

The team was excited, it looked like their desire was going to be granted.  Productive would flourish again.

Over the next few days I would see various people looking up at the wall and down at the basketball goal on the floor.  There were about 4 of these meetings each very short and not always the same people.  Team members would come up to me afterwards and ask...  "are we still getting the goal?"... "when are they going to bring a drill?"...  "what's taking so long?"

Running the calendar forward a bit... Today the facilities guy showed up with a ladder and drill.  It took about 20 minutes.  Basketball goal mounted (Dec 13th) - which clock did you stop?  All of the clocks stop when the customer (team) has their product (basketball goal) in production (a game commences).

I choose to think of lead time as the time it takes an agreed upon product or service order to be delivered.  In this example that starts when Mike, the dude, agreed to help the team get their goal mounted.

In this situation I want to think of cycle time as the time that people worked to produce the product (mounted goal) - other's might call this process time (see Lean Glossary).  And so I estimated the time that each meeting on the court looking at the unmounted goal took, plus the actual time to mount  the goal (100 minutes).  Technically cycle time is per unit of product - since in the software world we typically measure per story and each story is some what unique - it's not uncommon to drop the per unit aspect of cycle time.

Lead time:  Dec 13th minus Dec 7th = 5 work days
Cycle time:  hash marks //// (4)  one for each meeting at the board to discuss mounting techniques (assume 20 m. each); and about 20 minutes with ladder and drill;  total 100 minutes

Lead Time 5 days; Cycle Time 100 minutes
This lead to a conversation on the court - under the new goal with a few team members about what we could do with these measurements.  How if one's job was to go around and install basketball goals for every team in the building that a cycle time of 100 minutes with a lead time of 5 days might make the customers a bit unhappy.   Yet for a one off, unusual once a year sort of request that ratio of 100 minutes to 5 days was not such a bad response time.  The customer's were very happy in the end, although waiting for 5 days did make them a bit edgy.

But now what would happen if we measured our software development cycle time and lead time - would our (business) customers be happy?  Do we produce a once in a year product? (Well yes - we've yet to do a release.) Do our lead times have similar ratios to cycle time, with very little value add time (process time)?

Pondering...

Well it's January 5th and this example came up in a Scrum Master's Forum meeting.  After telling the tale we still did not agree on when to start and stop the two watches for Lead Time and Cycle Time.  Maybe this is much harder than I thought.  Turns out I'm in the minority of opinions - I'm doing it wrong!

Could you help me figure out why my view point is wrong?  Comment below, please.

LeanKit just published an article on this topic - it's very good but might also misinterpret cycle time.  I see no 'per unit' in their definition of cycle time.  The Lead Time and Cycle Time Debate: When Does the Clock Start? by Tommy Norman.

An Experiment in measuring the team's cycle time:
After a bit of time reflecting, debating, arguing with colleagues and other agilitst online I've decided to publish a little experiment in measuring cycle-time on a scrum team.  Here's the data... what does it say?  How do you think the team should react?  What action should be next?  What should the team's leadership feel/think/do?

The Story:  This team has been working together for a while.  The sprints are numbered from the start of the year... an interesting practice, this team uses 2 week sprints, is practicing Scrum.  Took a nice holiday and required some priming to get back in the swing of things after the first of the year (you see this in the trend of stories completed each sprint).  Cycle Time for a story on trend is longer than the sprint, this correlates with typical story "carry-over" (a story started is not finished in one sprint and is carried over to the next sprint).  Generally a story is finished in the sprint but not in sequence or priority - they all take at least the full sprint to get to done.  There is no correlation of story size to cycle time.

Now those are the facts more or less -- let us see what insights we might create from this cycle time info.  With no correlation of story size to cycle time AND little consistency of number of stories finished in a sprint (trend of # of stories: 1, 6, 7, 2, 2). The question arrises - what is the controlling variable that is not being measured that effects the time it takes to get from start to finish with a story?  Now that the team can see that the simplest things we could track do not have a strong effect on the length of time (or the through-put) a story requires... and that means the process is not under good control - we can start to look around for some of the uncontrolled (invisible factors) -- if we a courageous enough!

We reflected that many of the stories that carry over and are virtually unpredictable in size/time/effort appear to have large delays or multiple delays within their implementation phase.  So we devised a quick and dirty way to track this delay.  The assumption that this delay inherent in the work will perhaps be the unmeasured / uncontrolled variable that throws the correlation of story size with cycle-time out of kilter.

Our devised technique for tracking delay per story - a yellow dot on the task with a tick mark for every day the task is stuck in-process (delayed).




If this article spawns another article which references this one that references that one... does the internet cause a singularity?  I'd ask you to click this link, but you may implode:  Derek Wade - On Time.

See Also:

LeanKit published this excellent explanation of their choices in calculating cycle time within their tool:  Kanban Calculations: How to Calculate Cycle Time by Daniel Vacanti.
LeanKit Lead Time Metrics: Why Weekends Matter
Elon Musk turns a tweet into reality in 6 days by Loic Le Meur
The ROI of Multiple Small Releaseshttps://en.wikipedia.org/wiki/Frank_Bunker_Gilbreth_Sr.
https://en.wikipedia.org/wiki/Cheaper_by_the_Dozen


The Hummingbird Effect: How Galileo Invented Timekeeping and Forever Changed Modern Life
by Maria Popova.  How the invisible hand of the clock powered the Industrial Revolution and sparked the Information Age.

Categories: Blogs

They are “Lessons to be Learned”, not “Lessons Learned”

Leading Answers - Mike Griffiths - Thu, 05/18/2017 - 18:10
The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the... Mike Griffiths
Categories: Blogs

Staying on Course With Agile

Leading Agile - Wed, 05/17/2017 - 23:22

You may have heard that agile is just a bunch of cowboy programmers doing whatever they want; there is no rigor or discipline and best of all…NO more documentation. You may have heard about the agile zealots and that teams are full of these so called “agilistas” just spewing out code with no concern for quality and that you never know when anything is going to get done. You may have heard that others have tried some form of ‘agile’ and that “it” doesn’t work. Well fake news is everywhere these days, and misinformation about what agile is, and the notion that agile doesn’t work is a prime example.

The emotional reactions to agile can range from ‘meh’ to a vitriolic ‘it’ll never work here’. But, for organizations that are enthusiastic about making a transition and infusing more agility into their businesses, it is important to filter out the hyperbole. The facts can set you free. Becoming more agile is a journey rather than a destination, and in many ways, the path can be non-intuitive and overgrown with detritus.

Clear requirements have traditionally been an important first step to understanding the solution space and, just as importantly, an idea of how long it will take to implement it. There is a bit of hubris in this approach. Experience has shown that trying to nail down requirements at the beginning of a project—when we know the least about it—is the worst time to do so. What teams need instead is the ability to learn what a customer is trying to take care of throughout the project and make course corrections based on that emerging knowledge as it grows. Engendering the skill of making course corrections is one of the keys to the agile kingdom.

Experiments, and designing for discovery helps teams stay on course and produce better outcomes than big requirements documents and a lot of up front design. A well-groomed backlog is essential, but it does not mean that every detail is understood and articulated up front. Determining how to implement the details of a solution at the last responsible moment is encouraged because great solutions are based on the most up to date information about what is really needed rather than what we thought was needed at the outset of the project. Balancing when that information is captured and converted into team knowledge is a big differentiator between “doing Agile” and being agile.

That does not mean we don’t do any up front planning and certainly does not mean “No Documentation”. Themes, Initiatives, Epics and Stories all need elaboration and some form of memorialization so that teams can gain some collective knowledge around the outcomes that are going to be most important to customer. That documentation may be concise, and it may continue to be elaborated throughout delivery, but it should be captured in some way that communicates both the what and the why of the effort. The outcomes a customer is after is more valuable to understand than features or functionality. Requirements documents historically focus on the latter.

Far from the misperception that agile lacks discipline, done well, it is actually more rigorous than traditional approaches. Prioritization around value is not just the first step to a series of predetermined steps, but rather an ongoing guiding force as we continually refine our course toward the ultimate destination. Like an airplane navigating to Tokyo, pushed off course by winds and sometimes circumnavigating around bad weather, constant course correction produces a better result than setting a direction and hoping nothing changes along the way.

In a way, IT Leadership reminds me of my flying days. From checklists to navigation charts, pilots need documentation too. They need to know the radio frequencies with which to communicate and the protocols for doing so. And the good pilots are rigorous; they are disciplined. Now, there are some cowboy pilots out there who eschew the rules. Sometimes, unfortunately, they end up serving as a cautionary tale for others. There is an old saying about pilots, and I think it applies to IT leaders as well.

There are old pilots and there are bold pilots, but there aren’t any old, bold pilots!

So, rigor, communication and even documentation really are necessary. The best pilots have a lot of airtime and experience. They are most likely to get you safely to your destination. Indeed, for IT leaders, with large IT projects, there are similarities to flying a plane. Communication as well as both the skill of navigating and course correcting—are essential.

There are both cowboy pilots and cowboy agilistas out there. IT projects and flying can be inherently dangerous, and like so many failed IT projects, there are a plethora of failed agile experiments too. My recommendation in both cases is to look for experience. If you are considering agile, don’t listen to the “fake news”. Find a seasoned agile guide; someone with an approach that considers your environment, your business model and your customers and flexes to help you make the most of your transformation. Experience matters and the success of your journey may just ride on who you’ve chosen to help you navigate the course.

The post Staying on Course With Agile appeared first on LeadingAgile.

Categories: Blogs

Agile Movement's parallels to Lincoln's Gettysburg Address

What parallels are there between Lincoln's Gettysburg Address and the state of the Agile movement's union?

Lincoln was a primary figure at the dedication of Soldiers' National Cemetery, in Gettysburg. He did not wish to upstage the keynote speaker, Edward Everett, and so summarized in 2 minutes the principle of human equality as defined by the Declaration of Independence and the Civil War.  Do you remember, the keynote speech?  Few people do.


Lincoln's Gettysburg Address:
Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But, in a larger sense, we can not dedicate—we can not consecrate—we can not hallow—this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth. - - U.S. President Abraham Lincoln
I heard an NPR story about a person that give their grandkids twenty dollars to recite the Address.  It sounded like a wonderful way to engage kids in history and the founding reasons of the existence of this nation.  I'm assuming that it would take the children some time to memorize the short speech and in so doing they would have questions, about what the words meant.  How many of your colleagues know what unit of quantity a score represents?  Do you know what happened four-score and seven years before 1863?

The foundational document of this new nation is the Declaration of Independence - signed in the summer of 1776 by a group of wealth white men.  They are now described as our founding fathers, yet some were quite young at the time (Hamilton, 21; Jefferson, 33; Washington, 44).  These free thinking people (and some were women - they just didn't sign the document) were called radicals by their government and traders by their neighbors.


Does any of this sound like a fractal of the Agile Manifesto and the movement that was started back in the 1990s with lightweight frameworks for organizing software product creation.  The desire to increase the good aspects and there by overcome the poor habits (appreciative inquiry or extreme programming - is there a difference?).

Is there a revisionist movement some 15-20 years beyond the 2001 manifesto creation?  Yes, there appears to be a constant yearning for the next wave, the next wagon to hitch your cart onto.

Are there amendments that need to be added to the manifesto much like the Bill of Rights?  Or is that a fringe movement on the periphery?



Modern agile  defining four guiding principles:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment and learn rapidly
  • Deliver value continuously

Alistair Cockburn observer his communication style in beginner and advanced classes, he said: "[I] found that when I was encouraging getting back to the center/heart/spirit of agile, I kept emphasizing these four things, and drew them in a diamond:"



Could the newest technique Mob Programming be anything more than an incremental addition to eXtreme Programming (XP)?  Some 30 years in the making.








I've found a next movement in the Agile Symphony. [Do you see what I just did there? Yeah, changed the metaphor but pivoted upon the term movement. Crafty right?]  I believe the next movement that so many people are looking for are just a jump to the left.  Look to the left of the typical process flow of value through the company, just left of what the current Agile process addresses (software development).  It's the creative process that is just up stream of software development.  The product ideation phase, the place where all those creative people are trying to get a seat at the table and be engaged with the software product design.  The User Interface and User eXperience people are wanting to engage with the whole process. Not just be consulted at the end of the process when the user acceptance test has proven that no one wants to use our product.

Could it be that the UX group is searching for a way to improve the development process?  Are they sensing the need to find a better process?  One that results in similar outcomes but with shorter timelines, a process that allows them to maximize the value in their portion of the stream.  I think this group is in the same place as the lightweight software development group was in the 1990s.  Before a few of them got together to coin the term Agile and write a manifesto to protect their small market share from the large 800 pound gorillas in the software consultancy market space.

Well the gorillas have exerted their power and the industry has consolidated into the safer methods that allow the late adopters to feel good about their failing transformations.  Your OK, and I'm OK; let's just call the whole thing off.  And that folks, is how we arrive back at the trend in business lifecycles becoming shorter, while innovation continues to accelerate.

So maybe this new movement in the symphony will allow me to come into their community.  I feel I have something to offer, I love learning, and building (which I think of as design).  I have a bit of experience with these new methods of designing and building and learning as we discover what the customer truly desire.  I'd like to help the creative people get that seat at the whole development table.

Maybe you could think of this period of software development as the reconstruction.

See Also:

Reshaping our View of Agile Transformation - Jason Little

Categories: Blogs

The Career Path of a Scrum Master

I blogged recently on the question of whether a Scrum team can ever get so good that they no longer need a Scrum Master. In this post, I’ll address a closely related topic: Assuming that the role of Scrum Master does not go away, what is the career path for a Scrum Master?

In my experience, a Scrum Master’s career will usually evolve in one of four directions.

Multiple and More Challenging Teams

A typical career path for a Scrum Master will start with serving one team. After a while that team becomes less time-consuming to work with, as issues are resolved and the team takes on more responsibilities itself.

At that point, a good Scrum Master will seek additional challenges. Often the logical next step is to begin working with multiple teams concurrently or from working with more demanding teams or products.

When developing new Scrum Masters, I prefer to put the person in a position to most likely succeed. That will means working with a team that has neither any difficult personalities nor unrealistic delivery expectations. But, to go from good to great, the Scrum Master will need to learn to work under more complex conditions.

This leads to the philosophy that success is often rewarded with additional challenges.

Mentor

A Scrum Master who has been successful in a variety of different contexts and teams, might choose to move into a role as a mentor to other Scrum Masters. This will especially be true and feasible as the Scrum Master gains skills and experience.

In many organizations, this role would be called an Agile Coach, with the most common job description being that an agile coach coaches Scrum Masters (and their teams).

Personally, I’m partial to such individuals mentoring rather than just coaching. Much of the benefit these experienced individuals provide comes through them offering guidance (“I suggest you do it this way”). Because of this, I think of these individuals as having become agile mentors.

This is an appropriate path for Scrum Masters who have learned that their true passion is the creative act of developing a product--largely independent of whatever the product may be. Some Scrum Masters enjoy the process of enabling creativity among development teams so much that it almost doesn’t matter what the product is.

Think about the radio DJ who just loves being a DJ and doesn’t care if he’s playing classic rock, the current top 40, or classical music.

The Scrum Master who loves the process more than the product is a likely candidate to follow a career path into becoming an agile coach or mentor.

The Scrum Master Becomes a Product Owner

Other Scrum Masters, however, learn that they love what their team is building more than the act of creating it. Those Scrum Masters become good candidates to become product owners.

I don’t want to imply that a product owner role is above the Scrum Master role in an organization. I consider the roles equivalent in a typical organizational hierarchy.

But some Scrum Masters learn that they care deeply about the thing being built rather than the process of building the thing. And from having worked with a team long enough, some of these Scrum Masters learn enough about the product, industry, users and such to become good product owners.

The Scrum Master Becomes a Manager

Scrum Masters are most assuredly not managers themselves. But through their Scrum Masters duties, Scrum Masters often work closely with those who are. And some will find that work intriguing.

Scrum Masters become adept at guiding teams without much authority to say, “Do it because I say so.” Because of this, many can move into management roles where they could demand compliance but because of what they’ve learned from being Scrum Masters, know it usually is best not to.

Especially if a Scrum Master has retained technical proficiency, moving into a role like QA director or development manager can be a fulfilling, logical step.


Scrum Masters often become coaches, mentors, product owners, managers or continue as Scrum Masters in more challenging situations.

A Scrum Master Has Options

There are many paths a Scrum Master may pursue. The skills learned in becoming a great Scrum Master will serve that person well whether they choose to become a mentor, manager, product owner or just work with more challenging teams.

In some ways, asking what is the career path for a Scrum Master is like asking what is the career path of a professional athlete.

Some professional athletes use their former careers as springboards to move into broadcasting. Others use the money they’ve made to start businesses--where I live in Colorado, car dealerships and pizza restaurants seem popular with retired athletes. Some athletes use their fame to enter politics.

Still other professional athletes would find the topic of a career path preposterous. They didn’t become athletes as a path to something else. Becoming a professional athlete was the goal itself.

And so it will be for many Scrum Masters. The role of Scrum Master can be an end itself. Doing it more and better can remain the goal. A professional athlete cannot perfect his or her sport. A Scrum Master cannot perfect that skill either. There is always room to improve. And so, for many Scrum Masters, there may be no career path other than the continuous improvement in themselves that Scrum Masters demand of their teams.

Where Are You Headed?

If you’re currently a Scrum Master, what do you think is next for you? If you were formerly a Scrum Master, what you done since leaving that role? Please share your thoughts in the comments below.

Categories: Blogs

Version R6#14.13

IceScrum - Fri, 05/12/2017 - 17:58
R6#14.13 Here is the new and probably the last version of iceScrum R6. Its only purpose is providing iceScrum Standalone R6 users with the ability to migrate their projects to iceScrum v7. If you use iceScrum Cloud, you will have to wait a little longer before the migration is available but don’t worry it’s our…
Categories: Blogs

Design Your Competition's Support Department

You are presented with a common business problem.  One technique that has always helped me to define the problem space is to invert the problem, take it to an extreme to explore the continuum of your domain.  Let's imagine that we want to redesign our software support department at MegaSoft Corporation.  Applying our inversion principle we will leave our MegaSoft support as is, and instead we will design the competitors support group. It's going to stink, people are going to hate to even call them, their people will be arrogant techies with no human compassion - they will actually hire with those skills required.  Let's pause and give this company a name...  TechHard sounds great.

Who's time is most valuable?  At TechHard the support engineers time is very valuable, so we will have process that time how long a support tech. is on the call with a customer so that our process gurus can optimize for the use of this most valuable resource.  A typical call from a director or VP in our internal support operation should be logged by an administrative receptionist (maybe even automated system) and then the support techs time can be queued up with return call tickets.  We will return the VPs call when it is convenient for our tech.  The tech can validate that the VP is authorized to access the system, and will confirm that they are still experiencing the problem by walking through a standard checklist.  Being efficiently minded the tech may skip over some simple question like power plug, on/off, reset/reboot, logout/in again if they feel the user is competent.


Answering the basic question of who's time is most valuable via the design of the competition's process is enlightening.  Which is it?  The support person's time - or the customer's time.

How are support systems designed?  Has anyone ever heard of a company that used Design Thinking or High-Tech Anthropology to create a customer centered support group?

Is this Conway's Law at work - are we truly designing the support function of our products/services - or are we just reacting?

Give me an example of great design for support:  Nest Thermostat and Fire Alarm Installation
Have you installed a Nest product?  Their installation and configuration process is well designed.  I don't know about their support department - but my expectations are set very high, if I have a problem.


History will repeat
In the 1980s universities started teaching about design for manufacturing (robots would make the parts).

Are you designing your business departments for it's function?

Speaking of support tools - your going to want a great issue tracking system.  Why not look to a market leader that has all the features your people can put on a check list?  Let's buy Jira - or should we look at the competition's product?



See Also:

Cable Internet provider Frontier's support group struggles with the corporate infrastructure that can not resolve customer problems.







Categories: Blogs