Skip to content

Feed aggregator

A Personal Manifesto

NetObjectives - 19 hours 7 min ago
Background and the Agile Manifesto. I have been asked several times to help in the rewrite of an Agile Manifesto.  After having been involved in Snowbird 10 (the reunion of some of the original Agile Manifesto authors along with some others from the Lean/Kanban community) I realized there is no “Agile” community. Rather we have many sub-communities that are so diverse it is hard to think of them...

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

Private and pinned comments for Requests

TargetProcess - Edge of Chaos Blog - Fri, 05/26/2017 - 22:55

In the upcoming version of Targetprocess (v.3.11.4), there will be two changes related to comments: the long awaited “private” comments, and the ability to pin comments. These will only be available for Requests, and are mostly designed to improve the Service Desk experience.

Private comments

We fully support openness, transparency and all that, but when dealing with requests from external users, you often have to exchange some internal comments with developers or fellow support folks. Previously, this was tricky because all comments were available to customers in Service Desk. Now you can mark the comment as private so that it stays hidden for requesters.

Don’t go too far though; other people with a Targetprocess license will still be able to see the comment in both Targetprocess and Service Desk, so please don’t upload photos from your last party, or something like that.

private-comment

Pinned comments

If you're doing Idea Management and have some popular ideas, you might get dozens of comments from both customers and your own team. No one likes scrolling through through text to see whether or when an idea is going to be implemented, so what will people often do? That's right, post another question. Now you can “pin” a comment to a Request to give it its own "Last Official Comment" section in Service Desk. This way, customers will see current status at a glance.

last_official_comment

Categories: Companies

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

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

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

GitKraken v2.6

About SCRUM - Hamid Shojaee Axosoft - Tue, 05/23/2017 - 21:26

“You know my methods, Watson,” said Sherlock. “There was not one finder command which I did not apply to the inquiry.”

Okay, so maaaaaybe that’s not quite what Sir Arthur Conan Doyle wrote, but Sherlock’s detective skills surely inspired the new and improved Fuzzy Finder in GitKraken version 2.6.

With this release, we’re trying something a little bit different. We’ve put together a video—and this article—to cover what’s new. Watch the video or keep reading, the choice is yours! Let us know which you prefer.

Fuzzy Finder

To bring up the improved Fuzzy Finder, use the keyboard shortcut Cmd+P for Mac or Ctrl+P for Windows and Linux.

GitKraken Fuzzy Finder

After you’re done looking into the curious incident of the dog in the night-time, you can use the Fuzzy Finder to perform any of the following actions:

Repo:
  • Init
  • Open
  • Open in file manager
  • Clone
Settings:
  • General
  • Git Config
  • Authentication
  • GitFlow
  • UI Preferences
View:
  • Toggle Left Panel
  • Increase Zoom
  • Decrease Zoom
  • Reset Zoom
  • Keyboard Shortcuts
History:
  • History + filename

The Fuzzy Finder has replaced the Command Palette; however, the old keyboard shortcuts Cmd+Shift+P for Mac and Ctrl+Shift+P for Windows and Linux, will still bring up the Fuzzy Finder.

gitkraken fuzzy finder keyboard shortcut

The actions listed below were previously performed through the Command Palette, but can now be performed using the Fuzzy Finder:

Core:
  • Undo
  • Redo
File:
  • Stage all changes
  • Unstage all changes
  • Discard all changes
Stash:
  • Create
  • Pop
  • Apply
Branch:
  • Create
  • Fetch
Checkout:
  • Checkout + branch name

Additionally, if you click the search box in the upper right corner—or use the keyboard short Cmd+F for Mac / Ctrl+F for Windows and Linux—it will search through commits by default.

Fuzzy Finder Shortcut

#GitKrakenTip: Use the Cmd+backspace / Ctrl+backspace shortcut to quickly clear out any searches or filters.

Other Updates

GitKraken will now politely inform you when you have an external rebase in progress. GitKraken will show this message and temporarily lock parts of the application until the external rebase has finished. You can still resolve conflicts from inside GitKraken at each step of the external rebase.

gitkraken external rebase message

Lastly, we updated the macOS title bar color for both dark and light themes.

gitkraken macOS title bar

As Sherlock once sarcastically put it, “The world is full of obvious things which nobody by any chance ever observes.” We hope our Fuzzy Finder helps put things in plain sight so that you need not have Holmes’ mind to perform actions that are quite elementary. To see what else is new and improved in GitKraken v2.6, continue your investigation over in our release notes.

Categories: Companies

Product Owner Assessment

Scrum Expert - Tue, 05/23/2017 - 16:26
The product owner role is responsible that the production of the Scrum team meets the requirements of the customers and deliver value for the organization. This is an important role that requires...

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

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

LAST Conference, Melbourne, Australia, June 29-30 2017

Scrum Expert - Fri, 05/19/2017 - 12:00
The LAST conference is a one-day conference about Lean, Agile, Systems Thinking that takes place in Melbourne, Australia. It is a event for practitioners that encourages participation and interaction...

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

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.