Skip to content

Feed aggregator

Psychometric Assessments - a peek inside the person

What do you think & feel about personality and behavioral assessments?  Are they useful to you?  Can you share them with others to help improve your relationships?  Do you have the courage to put your personality on display for your collaborators to inspect?

Well I thought I'd try to open the kimono to see if it helps me...

I've studied Psychometric assessments and some I find useful, some I feel are just a step to the left from astrology charting.  Yet might not be harmful for self reflection.  I've also found that it takes an expert to explain the tools and reports such that a layperson can understand and make positive use of the assessment and it's report.  And while I've been "certified" is some of these tools/technique I do not practice them enough to be competent - and my pitch is akin to a snake-oil salesman.

Here is my DiSC Classic profile:

DiSC Classic by WileyHere is my Trimetric assessment (DiSC, EQ, Motivation) by Abelson Group

DiSC WheelMotivators Wheel
Emotional Quotient Wheel

Here is my Myers Briggs Type Indicator - Level II assessment:
MBTI Level OneMBTI Level II reports

Here is my EQ 2.0 - Emotional Intelligence:

EQ 2.0 by

TalentSmart, Inc. Here is my Action & Influence report:

Here is my Personalysis assessment:
Personalysis assessment

See Also:Authentic Happiness - resources in Positive Physiology - 20 assessmentsMartin Seligman TED talk on Positive Physiology
Personalisis assessment ReviewedMBTI Level II assessment Reviewed
Psychometric testing resources

British Psychological Society’s Psychological Testing Centre (PTC) provides information and services relating to standards in tests and testing for test takers, test users, test developers and members of the public.

National Cultural Studies - assessments at the meta level - the personality and behaviors of nations.

Categories: Blogs

A Light Bulb Moment

A few months ago Michele of Sliger Consulting, Inc. asked about my first Agile Light Bulb moment, I've had a few of them but one that easily came to mind was this one with the Washington State Appellate Clerk court case management systems people back in 2005.

In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful.
"My light bulb moment was during the product demo in the Sprint Review Meeting, when the state of Washington Appellate Clerk of Court told me he and the courts had been waiting 20 years for the feature that our team had just delivered. In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful. He later sent me the requirement spec for the 20-year-old feature and it read just like our epic story and its children we discovered. Yes, this was a completely different system than the previous retired system - yet it had the same customer needs. We had transitioned from a deadlocked in analysis paralysis development group to a Scrum team in under 3 months, delivering into production every month new features, bug fixes, and tested working software."  -- David Koontz
See other Light Bulb Moments at Sliger Consulting Light Bulb Moments

Have you seen in other collections of Light Bulb Moments?  Please comment below.

Categories: Blogs

Q: What is an Agile Transition Guide?

David Koontz guiding a canoeI was at the Dallas Tech Fest last week and was asked several times what an Agile Transition Guide was (it was a title on my name tag)... it's surprising to me how many people assume they know what an Agile Coach is, yet there is no good definition or professional organization (with a possible exception coming: Agile Coaching Institute).

So naturally the conversation went something like this:

Inquisitive person:  "Hi David, what's an Agile Transition Guide?  Is that like a coach?"

David:  "Hi, glad you asked.  What does a coach do in your experience?"

Inquisitive person: "They help people and teams improve their software practices."

David:  "Yes, I do that also."

Inquisitive person: "Oh, well then why don't you call yourself a coach?"

David:  "Great question:  Let's see...  well one of the foundational principles of coaching (ICF) is that the coached asks for and desires an interaction with the coach, there is no authority assigning the relationship, or the tasks of coaching.  So do you see why I don't call myself a coach?"

Inquisitive person: "Well no, not really.  That's just semantics.  So you're not a coach... OK, but what's is a guide?"

David:  "Have you ever been fishing with a guide, or been whitewater rafting with a guide, or been on a tour with a guide?  What do they do differently than a coach?  Did you get to choose your guide, or were they assigned to your group?"

Inquisitive person: "Oh, yeah.  I've been trout fishing with a guide, they were very helpful, we caught a lot of fish, and had more fun than going on our own.  They also had some great gear and lots of local knowledge of where to find the trout."

David:  "Well, there you have it... that's a guide - an expert, a person that has years of experience, has techniques to share and increase your JOY with a new experience."

Inquisitive person: "Yes, I'm starting to see that difference, but can't a coach do this also?"

David:  "No, not unless the coach is willing to switch to a different modality - to one of mentoring, teaching, consulting, or protecting.  Some times a guide must take over for the participant and keep the person/group within the bounds of safety - think about a whitewater river guide.  A coach - by strict interpretation of the ethics, is not allowed to protect the person from their own decisions (even if there are foreseen consequence of this action."

Richard FeynmanAnd now the conversation start to get very interesting, the Whys start to flow and we can go down the various paths to understanding.  See Richard Feynman's dialogue about "Why questions"

So, I'm not a Coach

I've been hired as a coach (largely because the organization didn't truly understand the label, role, and the ethics of coaching).  This relationship was typically dysfunctional from the standpoint of being a coach.  So I decide to study the role of coaching. I've done a few classes, seminars, personal one of one coach, read a lot and drawn some conclusions from my study - I'm not good a coaching within the environment and situation that Agile Coaches are hired. I've learned that regardless of the title that an organization uses (Agile Coach, Scrum Master, etc.) it doesn't mean coaching.  It intends the relationship to be vastly different.  Since I'm very techie, I appreciate using the correct words, and phrase for a concept.  (Paraphrasing Phil Karlton: In software there are two major challenges: cache invalidation and naming things.  Two Hard Things)

So to stop the confusing and the absurd use of the terms, I quit referring to my role and skills as coaching.  Then I needed a new term.  And having lots of friends that have been Outward Bound instructors and understanding their roles, the concept of a river guide appeals to me in this Agile transformational role.  Therefore I coin the term Agile Transformation Guide.  But many organization do not wish to transform their organization, but they do wish for some type of transition, perhaps from tradition development to a more agile or lean mindset.  So a transition guide is more generic, capable of the situational awareness of the desire of the organization.

What does a guide really do?  
This question may best be answered by David Kelley in his TED talk, "How to build your creative confidence."  In this talk David points out his desire to teach parents that there are not two types of children - the creative and the non-creative.  There are, however, children that lost their desire to express their unique talents early in their lives.  He helps people regain this capability.

It is much like how Dr Bandura has developed his treatment for phobias.  David will tell you about this basic guided mastery technique that restores self efficacy.

How to build your creative confidence. TED Talk by David Kelley
This is what an Agile Transition Guide does... they guide you on a journey toward self efficacy via many techniques in mastery of your domain skills and capabilities.

See Also:
Six Kinds of Agile Coaches by Ravi Verma Describes the HUGeB coach, the one to be.
So what is a Coach and What is a Trainer - Agile 102
Where Agile goes to Die - Dave Nicolette - about those companies that are late adopters or laggards in the innovation curve and the challenges that "coaches" have when engaging with them.
The Difference Between Coaching & Mentoring

Scrum Master vs Scrum Coach by Charles Bradley

Agile Coach -or- Transition Guide to Agility by David Koontz; the whitewater guide analogy to agile coaching.

Academic paper:  Coaching in an Agile Context by David Koontz

What is the ROI of Agile Coaching - Payton Consulting

Interesting Twitter conversation about the nature of "coaching" with Agile42 group.

Categories: Blogs

GitKraken vs the CLI

About SCRUM - Hamid Shojaee Axosoft - Fri, 03/03/2017 - 00:28

There are quite a few things that I do every day in GitKraken that make my work easier. When I just worked with my repos using the command line, these tasks were always a hassle. Maybe, sometimes, the hassle is worth it. Imagine you’re Tom Hanks and you bring an old, manual typewriter to a baseball game to keep score. Now, admittedly, that is really cool, but it’s not something I’d want to do all the time, and the idea of typewriter-like permanence in Git operations makes me shudder a shiver of pure fear. So, in honor of Hanx, I thought I’d share 6 reasons why I prefer GitKraken over the hassle of just banging away on the keyboard.

Click image to download this infographic as PDF 1. User Friendly

The CLI has a steep learning curve because you have to memorize commands and understand what those commands actually do. GitKraken, on the other hand, is a great tool for learning and teaching Git. GitKraken allows you to simply make a few clicks to perform commands and then provides a visual representation of the commands so you can see their effects.

See that big Undo button up top? That means that if you make a mistake, there’s also a good chance you can undo that mistake.

2. Speed

With GitKraken, you can drag and drop to quickly merge, rebase, reset, push, and more. If you need to undo a commit, simply give the Undo button one quick click.

I also love being able to easily see all of my work in progress; I can stage, discard, or stash any changes as I wish, so I don’t accidentally commit small mistakes. It makes me feel fabulous and powerful like I’m on the Bachelorette, and I can see which hunks I want to keep and which can be discarded.

3. Performance

Ok, look, it’s a GUI, and with a GUI there’s always some trade-off between the convenience of the UI and the demands on your CPU. I’ll admit that the CLI will be less taxing on your machine than any GUI out there, but you’re still getting bang for your buck when using a client.

The background processes that often run on a GUI, though they affect your CPU usage, are often also a great convenience to the end user, keeping up-to-date with file changes, for example.

4. Remote Control

If you’re tracking multiple remotes from your team, it can often be difficult to differentiate your local work from changes on other forks. With GitKraken, you can always see the avatar of the user on GitHub or Bitbucket, to know whose branch you’re viewing, or you’ll see a computer icon for your local changes.

Creating and viewing pull requests is something I do all the time, and I really couldn’t do them in the command line. With GitKraken, I can create new PRs, view my existing PRs in the repo, and even add the remotes attached to the PR if I don’t already have it pulled down.

5. Preference

I hate Git Spaghetti.

An actual Git commit graph from 1918

We’ve all witnessed a commit graph that is a mess of merges and branches that people forgot about. In many cases, this mess can accumulate because people have pushed without being able to visualize what’s going on. My history has been much friendlier and cleaner since switching to GitKraken. Now it’s more of a nice tidy riGitoni instead of a messy Git spaghetti.

Bonus: GitKraken Frees up my terminal

Just because I’m using GitKraken, doesn’t mean I am ending my relationship with the terminal. In fact, GitKraken allows me to use terminal for other essential tasks like updating npm packages, starting/stopping processes, using vim to edit a file, or even to play a game of Zork without having 8 different terminals open.

What’s more, GitKraken can augment the way you work with your repos and, if you still want to launch the command line to scour the reflogs or to play some nostalgia 80’s text based games, just use the keyboard shortcut alt + T (Windows/Linux) or option + T (MacOS).

Categories: Companies

Targetprocess Mobile for iOS Release 3.3: Notifications tab, view setup, follow entities

TargetProcess - Edge of Chaos Blog - Thu, 03/02/2017 - 20:10
List of notifications inside the application

Previously, you could get push notifications sent to your device, but you couldn't view a list of them inside the application. We've now put all notifications into one place, so they are much easier to find.

You can find notifications for:

  • State changes for entities assigned to you
  • New comments where you are mentioned
  • When you are assigned or unassigned to an item


View setup

For those who aren't sure what's going on with their board, such as why certain cards or lanes are not displayed, we’ve added the possibility to see the view configuration. This includes:

  • Cards selected on the board and filters applied to them
  • Horizontal and vertical lanes and filters applied to them
  • Projects and Teams and selection that is applied to the displayed cards and lanes

You can see it all in read-only mode plus and also choose to reset your personal filter applied to cards:


Some other useful improvements include
  • Copy the link to an entity
  • Follow an entity
  • Save Attachments


If you have anything you want to share with us, use the Feedback form in the app's 'Me' tab, or shoot us a message at

Click here to download the iOS app.

Categories: Companies

Agile and Beyond, Ypsilanti, USA, May 4-5 2017

Scrum Expert - Thu, 03/02/2017 - 10:00
Agile and Beyond is a two-day conference focused on Agile software development and Scrum project management that takes place near Detroit in Ypsilanti, Michigan. It aimed at taking together software...

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

6 Popular Atom Packages

About SCRUM - Hamid Shojaee Axosoft - Wed, 03/01/2017 - 21:40

Here at Axosoft, one of the most-used tools, unsurprisingly, is the humble text editor. No matter what kind of developer you are, you likely have your own setup for the editor you use: theme, keyboard shortcuts, add-ons; everything configured just the way you like it.

At Axosoft, the most popular editor of choice—by far—is Atom: GitHub’s functional, flexible, open-source, cross-platform editor. Out of the box, Atom is a very capable app that doesn’t take long to feel familiar. But its real strength lies in its extensibility and hackability. This is a real boon to developers with their own unique requirements, languages, preferences and habits. Should you need to, you can tweak config files, or create entire plugins to extend Atom’s base functionality.

These days, there are lots of packages available for Atom, and they’re easy to browse and install from within the app. Here’s a roundup of some of the most-used packages around the Axosoft office.

Our 6 Most-Used Atom Packages 1. linter/linter-eslint

The most popular plugin with our devs, is a combination of two plugins for linting code. A linter is a program that assesses code for probable errors and for enforcing a consistent coding style. The base linter, combined with a JavaScript linter installed on top of the base, is the combo of choice with developers at Axosoft. Syntax typos begone!

2. highlight-selected

As you may have guessed, the “Highlight Selected” package highlights your selection; in fact, it highlights all instances of that selection in the document. Simple, but effective if you need a quick reference to all visible instances of a string.

3. pigments

Pigments is an indispensable package if you’re working with colors and variables. Pigments highlights all color values (hex, rgb, rgba) with the color that value represents. Among other settings, you can choose the “marker type,” opting for, say, a color dot next to the color value rather than highlighting it in that color.

Pigments supports precompilers, too, so you can use Stylus, Less, Sass, or Scss and it’ll highlight functions and variables that represent colors. Need examples? Well, we all know that Chuck Norris’s hex value is #bada55, but here are a few Stylus suggestions for you:

rocky                  = #ba1b0a
ringo-starr            = alpha(#bea71e, 0.5)
whats-that-smell       = #badc0d
whats-that-other-smell = #faece5
4. minimap

Minimap offers an at-a-glance graphical preview of the current document’s entire source code. The package’s home page shows the copious configuration options, but even without setting those, Minimap offers a really easy way to work out where you are in your code, and quickly get to where you need to be.

Combine this package with the minimap-highlight-selected package to see all your selections in the map!

5. regex-railroad-diagram

Do regular expressions fill you with the kind of dread otherwise reserved for dental surgery, high school reunions, going to the DMV, or, actually having dental surgery at your local DMV performed by one of your old high school friends? If so, Regex Railroad Diagrams might be the answer to your prayers. This package offers a visual view of your regular expressions so it’s easier to debug their behavior.

6. rulerz

Where did my cursor go? Where am I in this row? I’m frightened! If only there was a little vertical bar that followed my cursor on the screen, subtly giving me a visual reference for where I am!

Ah, there’s a package for that. Rulerz gives you a simple vertical rule to help you know where you are. What’s more, it’s customizable, thanks to Atom’s stylesheet. Here’s a modest example: {
    ruler-view.rulerz {
        border: 10px solid #5234d4;
        width: 500px;
        box-shadow: 0px 0px 10px 10px #ff0, 0px 0px 100px 10px #f00;
        background-image: url('');
        background-size: contain;

Gives you:

Ah, that’s better. And you are most welcome.

Categories: Companies

Agile Alliance Board 2017 Officers Elected

Scrum Expert - Wed, 03/01/2017 - 19:18
The Agile Alliance has announced that the Agile Alliance Board of Directors has elected officers for the 2017 term. The board — comprised of Agile thought leaders from a variety of backgrounds and...

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

Lisa Hershman Will Serve a Interim CEO of the Scrum Alliance

Scrum Expert - Wed, 03/01/2017 - 18:24
The Scrum Alliance has announced that Lisa Hershman will serve as interim CEO. Hershman joined the Scrum Alliance Board of Directors in 2015 and will step away from her newly elected position as...

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

Succeeding with Large Scale Agile

Scrum Expert - Wed, 03/01/2017 - 17:52
Learn how to succeed with large scale Agile. Implementing Agile in small, short lived projects is easy. The real challenge comes when the project becomes long-running, and it gets even harder when...

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

Empower - an action; not a command

You have not empowered a person by telling them "you are empowered."  This is a classic mistake in communication.  When one does this, they misinterpret their message, "I'm empowering you..." with the action that a verb such as empowerment requires to happen.  This person is taking a short cut, by giving the platitude of empowerment in place of any action that would be view by the other as empowering.

"When told that they are empowered to do something; this message is actually interrupted to dis-empower the persons agency."How does this misinterpretation occur?  Why do we humans mess up this simple act of communication?

Let's look at an example:

For a few months I had been working with a new team of software developers at a large organization.  Like many organizations they had already done the agile/scrum thing and it didn't work for them.  Recently the leadership had built a satellite office and started from a very small pool of tenured people to grow it's new "resource" of technical people.  This time the leadership decided that hiring some experienced people that had "done Agile" and "knew how to Scrum" might give them the needed energy to actually get somewhere with the initiative.  At least these experts could teach the new people how to do agile right.  I guess I was one of these "experts" (another term for a has-been drip under pressure).

Observing the new team for a few weeks I noticed they referred to their process by the label "kanban," yet they never appeared to move any sticky notes on their board, never made new ones or retired any old stickies.  Mostly they just pointed at them and talked about something not written on the note.  It was very difficult for the outsider (me) to follow the process they were using -- or maybe they were not using any process; and I was following them -- to nowhere.  This will take a bit more observation.

Although that was several months ago, and my memory is not the best at recovering details when there is no emotion overlaying the details, believe me there was little emotion at their stand up meetings, I'd call them boring (the meetings, not the people).  I don't remember in the 4 weeks I was observing that they ever shipped any software, never spoke about a customer visit, or discussing a solution with a customer - I don't think anything they talked about ever got done.

So, I some how convinced their manager that what they were calling a process, could not be named - and that wasn't a good thing (sorry Alexander that attribute is not the same as your "quality without a name" ).  It didn't reflect any known process.  He didn't know much about the process either.  It was labeled "kanban." Yet they didn't exhibit any of the behaviors of a team practicing the Kanban process, they didn't even know what steps the process might involve.  They had also tried scrum, but "it didn't work" either.  It was very difficult to discuss these failures with the team or the manager, they were reluctant to discuss what about the process had failed, nor what actions they implemented when these failures occurred.

I made a bold assumption - they didn't know anything about the processes they were espousing they were using.  They had been to training classes, therefore they knew ... something.  They could use the new lexicon in a sentence (90% of the time the sentences made sense).  But how do you tell someone they are ignorant (with the full meaning - that they no nothing about a subject and it's not their fault for having never been exposed properly to the knowledge).  That's a crucial conversation.  I rarely handle these well - I got lucky this time perhaps.  I suggested the team join me in a workshop to talk about the practices they are using and how these map to the Agile Manifesto.  We did this exercise and branched off into many valuable conversations.  During this exercise we decided they were already being Agile, so many of their practices supported the principles of the manifesto.  So the question was not if they were Agile, but how much was enough... could they improve their agility - did they want to try something different?  Along the way of this conversation we might have arrived at an understanding of a difference of opinion, when I used words in the lexicon I had intended to imply certain meanings that they did not intend when they used the words.  We often seemed to use similar phrases but rarely meant the same things actually happened.  That level of miscommunication can be tedious to overcome, while still keeping an open mind that the other person has something valuable to offer.

For example: they had been using the word "kanban" to describe the process they were using because that was the term applied to the Rational Team Concert (RTC) - template work flow the company created.  They had chosen that workflow because it was easier to use than the complicated scrum workflow the organization's PMO created.  Turns out it had nothing to do with the development process they were using.  They finally agreed that they were not doing Scrum, and didn't really know how to do it... they hadn't learned much from the powerpoint presentation (imagine that).

I got extremely lucky with one of the leaders of this team. She said to the team, that she thought the
team should give the scrum master (me) a chance, just go along with whatever I said, regardless of how stupid it sounded. Try it for a few weeks, it wouldn't hurt, and then in a few weeks decide if it was working for the team, or not.  I learned of this leader's suggestion to her teammates only months later.  It was without a doubt the turning point in the relationship.  After this détente, the team members began to implement with ease suggestions on how they could implement Scrum.  One might say that this leader empowered me, but never said a word about it to me.

We did more workshops in a scrumy fashion, we had a board of items to complete.  We tracked these items on a board right there in the workshop space.  Sometimes we split the topics up more.

Sometimes the topic didn't get finished in the time allotted and we had to decide if it was good enough to continue with other topics and come back later to finish the discovered aspects.  We used the rate at which we were progressing day after day to predict that we wouldn't get all of the topics covered by the end of the week.  But that was good enough, because each day the team selected the most important, most valuable topics and we put off the lease valuable.  Sometimes a topic was dependent upon another item on the board and we had to cover some of a less valuable item so that the dependency was resolved.  In these workshops we covered many Agile principles, the Scrum process framework (3 roles, 3 meetings, 3 artifacts, and a lot more), engineering  practices (many originally defined by Extreme Programming gurus), local organization customs, terms, policies, and procedures.  Much of what was suggested by some agile or scrum nutjob was in contradiction with the customs and policies of the organization - at least on the surface.  Great conversations were developed where the team joined into filling the shared pool of knowledge.  This pool of knowledge now with company and agile/scrum knowledge was easily sorted into new understanding of how both systems could co-exist and interrelate.  It wasn't easy but it generally worked.

The team started understanding the process of Scrum and working toward getting stories in the backlog to done.  Slicing stories that had proven too large in the past and delivering working software to the business each sprint.  They developed the ability to easily estimate a story or an epic set of stories within minutes.  Their ability to read their task board and predict which stories (if any) were not going to get completed within their sprint time-box that they quit wasting time tracking a sprint task burndown.  They understood that if they got into a new domain that ability might be diminished and they could easily revert to tracking task aspirin (a unit of effort; not time) on a chart in the future. The team knew their velocity and could accomplish a sprint planning session in about an hour.  They could predict when they needed to spend more time in refining tough stories before planning and they learned how to slice stories for value and leave the fluff on the cutting room floor.

But all was not well with a performing team...  (cue the scary music - set up a scene with dramatic lighting) ... the manager was looking for a way to measure the team.  And as people are wonting to do... without any thought they look for a dashboard to tell them how well the "team is being run."  They want to know if the "team is being driven at their top performance", and they need some numbers to prove it.  Generally this is a warning indication that many conversations were wasted and no learning occurred,  in hindsight the wrong person was doing too much of the talking and the other didn't draw from the pool of shared knowledge but instead just admired the pool from the shore, never bothering to enter.  The team's manager wanted me to build a dashboard tool using the company's tool of record (RTC) that would give him all the numbers that prove his team is performing well.

I've made a strategic decision over the years to not become the tooling expert - especially with the bountiful assortment of tools the software project management industry offers.  Needless to say I didn't want to become an expert in RTC (a tool rumored to be on it's way out for this organization that was in their 3rd Agile adoptions curve).  I asked what this dashboard would have on it, what it would display, etc.?  The answer fit on a sticky note, because that's what I had with me... something like velocity, the backlog, and what the team is currently working on was the manager's response.

Here's my Nth mistake.... I hoped the request would dissipate as many thing in a transition tend to do, so I wasn't motivated to create a dashboard for the manager that would reproduce the team's well maintained Scrum task board.  I offered to work with him in reading the board, he attended many of the team's Scrum sessions at the board, rarely engaged but appeared attentive.

[this story will continue ...  as I've lost my round-toit --  wonder if it's with my marbles?]

See Also:

The Rise of Emergent Organizations  by Beth Comstock

The ScrumMaster - How to develop a team - by Marcel van Hove

Categories: Blogs

Groundhog Day at the Agile Transition Initiative

Now that everyone knows about Bill Murray's movie Groundhog Day - I love February 2nd.  It's my favorite, most enjoyable, beloved, cherished, esteemed day of the year.  And I don't need to tell you again how many LIKES I give this redundant day... so on to the story.

Bill & Groundhog
Well this happened about ten years ago, and about 6 years ago, or maybe it was 4 years past, and seems like we did this about 24 months ago...  or it could be today!

The Agile Transition Initiative at the company has come upon an inflection point (do ya' know what that is...  have you read Tipping Point?).  I'm not exactly sure of it's very precise date... but Feb. 2nd would be the perfect timing.   The inflection has to do with which direction your Agile Transition Initiative takes from this point into the future.   Will it continue on it's stated mission to "transform" the organization?  Or will it stall out and revert slowly to the status quo?

How do I recognize this perilous point in the agile trajectory?  Well there are several indications.  But first we must digress.

[We must Digress.]
Punxsutawney Phil Says more Winter in 2017In this story we will use the germ theory as a metaphor.  Germ theory came about in about ... (wait - you guess - go ahead ...  I'll give you a hundred year window... guess...). That's right! "The germ theory was proposed by Girolamo Fracastoro in 1546, and expanded upon by Marcus von Plenciz in 1762."  Wow, we've know about these little buggers for a long time.  And we started washing our hands ... (when...  correct -again).  "The year was 1846, and our would-be hero was a Hungarian doctor named Ignaz Semmelweis."  So right away business (society) started using a new discovery - a better way to treat patients.... or well it took a while maybe a few months, or maybe  more than 300 years.

But back to the metaphor - in this metaphor the organization will be like a human body and the change initiative will take the roll of a germ.  The germ is a change introduced to the body by some mechanism we are not very concerned with - maybe the body rubbed up against another body.  I hear that's a good way to spread knowledge.

We are interested in the body's natural process when a new factor is introduced.  What does a body do?  Well at first it just ignores this new thing - heck it's only one or two little germs, can't hurt anything - (there are a shit load of germs in your body right now).  But the germs are there to make a home - they consume energy and reproduce (at this point lets call it a virus - meh - what the difference?).  So the virus reproduces rapidly and starts to cause ripples... the body notices this and starts to react.  It sends in the white-blood cells - with anti-bodies.  Now I don't understand the biological responses - but I could learn all about it... but this is a metaphor and the creator of a metaphor may have artistic license to bend the truth a bit to make the point.  Point - WHAT IS THE POINT?

The point is the body (or organization) will have a natural reaction to the virus (change initiative) and when the body recognizes this change it's reaction (natural - maybe call it subconscious - involuntary).  Well let's just say it's been observed multiple times - the body tries very hard to rid itself of the unwanted bug (change).  It may go to unbelievable acts to get rid of it - like tossing all it's cookies back up - or squirting all it's incoming energy into the waste pit.  It could even launch a complete shutdown of all communication to a limb and allow it to fester and die, hopefully to fall off and not kill the complete organism.  Regaining the status quo is in the fundamental wiring of the human body.  Anything that challenges that stasis requires great energy to overcome this fundamental defense mechanism.

[Pop the stack.]
So back to the indicators of the tipping point in agile transitions.  Let's see if our metaphor helps us to see these indications.  The tossing of cookies - check.  That could be new people hired to help with the change are just tossed back out of the organization.  The squirts - check.  That is tenured people that have gotten on board with the change being challenged by others to just water it down... make it look like the things we use to do.  Heck let's even re-brand some of those new terms with our meanings - customized for our unique situation - that only we have ever seen, and therefore only we can know the solutions.  Folks, this is called the Bull Shit Reaction.

Now imagine a limb of the organization that has adopted the new way - they have caught the virus.  There is a high likely hood that someone in the organization is looking at them a "special".  A bit jealous of their new status and will start hoarding information flow from that successful group.  Now true that group was special - they attempted early transition and have had (in this organizations realm)  success.  Yet there was some exception to normal business process that made that success possible.  How could we possibly reproduce that special circumstance across the whole org-chart?  Maybe we just spin them off and let them go it alone - good luck, now back to business.

What's a MIND to do with this virus ridden body and all these natural reactions?

Well we are at an inflection point... what will you do?
Which curve do you want to be on?  - by Trail Ridge Consulting
[What Should You Do?]
Say you are in the office of VP of some such important silo, and they are introducing themselves to you (they are new at the Org.).  They ask you how it's going.  You reply, well, very well.  [That was the appropriate social response wasn't it?] Then they say, no - how's the agile transformation going?  BOOM!  That is a bit of a shocking first question in a get to know each other session - or is it that type of session - what should you do?

I will skip to the option I chose ...  because the other options are for crap - unless you have a different motive than I do... and that is a very real possibility, if so defiantly DON'T DO THIS:

Ask the VP if this is a safe space where you can tell the truth?  Be sincere and concerned - then listen.  There response is the direction you must now take, you have ceded control of your action to them, listen and listen to what is not said - decide if they want the truth or do they want to be placated.  Then give them what the desire.  For example (an obviously easy example - perhaps); imagine that the VP said:  I want the truth, you should always tell the truth.

Don't jump to fast to telling the truth... how can you ascertain how much of the truth they can handle?  You should defiantly have an image of Nicholson as Colonel Nathan R. Jessep as he addresses the Court on "Code Red".

You might ask about their style is it bold and blunt or soft and relationship focused.  You could study their DiSC profile to see what their nature may tell you about how to deliver the truth.

Imagine you determine that they want it blunt (I've found that given a choice must people say this, and only 75% are fibbing). So you suggest that it's not going well.  The transformation has come to an inflection point (pause to see if they understand that term).  You give some archeology - the organization has tried to do an agile transformation X times before.  VP is right with you, "and we wouldn't be trying again if those had succeeded."  Now that was a nice hors d'oeuvre, savory.  The main course is served - VP ask why?

Now you could offer you opinion, deliver some fun anecdote or two or 17, refer to some data, write a white paper, give them a Let Me Google That For You link. Or you could propose that they find the answer themselves.

Here's how that might go down:  Ask them to round up between 8.75 and 19.33 of the most open minded tenured (5 - 20 yrs) people up and down the hierarchy; testers, developers, delivery managers, directors, administrators (always include them - they are key to this process - cause they know every thing that has happened for the last 20 years).  Invite them to join the VP in a half day discovery task - to find out why this Agile thing get's ejected before it takes hold of our organization. If you come away from this workshop with anything other than - culture at the root of the issue, then congratulations your organization is unique.  Try the Journey Line technique with the group.  It's a respective of the organizations multi-year, multi-attempts to do ONE THING, multiple times.  Yes, kinda like Groundhog Day.

See Also:

The Fleas in the Jar Experiment. Who Kills Innovation? The Jar, The Fleas or Both? by WHATSTHEPONT

Categories: Blogs

10 years of Agile @ Crisp. Next challenge: Global Warming!

Henrik Kniberg's blog - Wed, 03/01/2017 - 09:30

10 years ago, 2007, me and a few Crisp colleagues embarked on a mission: be best in Sweden at helping companies become agile. We had experienced first-hand the power of agile development, and wanted to use this newfound super-power to help both Crisp and our clients improve. Others joined us and – tadaa!  – Agile Crisplet was born (and the concept of crisplets)! That was the year I taught my first Certified ScrumMaster course together with Jeff Sutherland, co-creator of Scrum. Since then we’ve co-trained almost 30 courses! About 2-3 times per year. In fact, May 22-23 is our 10 year anniversary (join us at the course in Stockholm!).

Now 10 years has passed since our Agile Crisplet was formed, and I’m happy to see we have achieved more than we ever could have dreamed!

Dispensing with false humility here, we’ve somehow managed to become one of the world leaders in this field! Famous agile and lean experts partner with us. Super well-known product companies, large telecoms and banks, even government organizations, turn to us as first choice for agile guidance and training. Our videos and articles and books have racked up millions of hits, and we are basically overwhelmed with requests to do coaching, write book forewords, do conference talks and workshops, and run training courses. I’ve done almost 30 keynotes in 20+ countries. I’m amazed (and overwhelmed) every time I look at my inbox, I’ve had to hire an assistant just to turn down the 95% of all requests that we simply don’t have capacity to handle.

OK, so now what?

10 years is a long time, and now it’s time for a new focus! At least for me (Crisp is a no-CEO company where people are free to do whatever they want).

My personal mission has been “Help companies improve”, then it shifted to “Help the Good Guys Win”. I’ve been focusing on companies that have a good culture and build products that make the world a better place – companies like Spotify and LEGO. “Good Guys” in my book.

But I’ve gotten a little bit too comfortable in my role as “Agile Guru” (I don’t really like the term, but so many people call me that so I’ve decided to just accept it). My work started feeling repetitive, like I was doing things out of habit rather than out of passion. And at the same time, I was getting increasingly worried about global warming, especially after a climate change denier took the helm of one of the most powerful countries in the world.

And then it hit me. Shit! I’m solving the wrong problem! Here I am, feeling good about myself for helping cool, successful companies become even more cool and successful. And at the same time, the world is facing an unprecedented disaster, the sixth mass extinction event over the past 500 million years, caused by humans, and I’m doing nothing at all about it (in fact, making it worse by flying all over the place)! We like to take our existence for granted, but the dinosaurs ruled the earth for 160 million years (800 times longer than the human era so far!), and they were wiped in the last extinction event 65 million years ago. How can I look my children in the eyes, while we screw up the planet they are inheriting?

Over the years I’ve built up this wonderful arsenal of problem solving skills, so how about I use it to help solve the right problem instead? I started studying up on global warming, and realized that this really is the world’s biggest and most important problem, anything else seems tiny and insignificant in comparison. Kind of depressing, because what the heck can I do about it, I’m just one guy and a totally newbie on climate stuff.

But then I realized – wait! 10 years ago, I started off as a newbie (well… not an expert at least) on agile, and now my colleagues and I have managed to make a major world-wide impact on how companies work, helped them create more humane work environments, helped them succeed with their projects, helped them build awesome products and organizations. I’ve lost count of the number of people that have said “You changed my life” (for the positive… I think…)! What if we can pull off the same stunt again? A bit optimistic, yes, but worth a try!

We’ve developed a big arsenal of really useful skills – software development, system architecture, viral communication, teaching, facilitation, structured problem solving, community building, and more! AND we’re lucky enough to have some discretionary time and money – most of us don’t have to work full-time just to make a living. So let’s put it to use!

I started looking for solutions. The past two months I’ve been busy. Partnered with experts. Joined a solar energy startup and formed an electricity company. Formed a community – Climate Crisplet (half of Crisp, 20 people, joined almost immediately!). Studied up on CO2 emissions, started blogging about it. Found awesome tools like Invested in solar panels in Africa via Trine, an awesome startup that is trying to eliminate energy poverty (and reducing global warming as a side effect). Supported development of aviation biofuel. I’m basically exploring the solution space!

My biggest insight is that there is hope! The solutions are out there. Electric cars. Solar and wind energy. Mainly, we just have to stop burning oil and coal. And there is no reason for us to do so anymore, not for energy at least, and not from an economic standpoint either (even if we ignore climate impact, which is massive). A lot of very passionate smart people are at work saving the world. Lots of really cool stuff is happening! But it needs to happen faster, A LOT faster.

So that’s my new mission and focus: Help reduce global warming.

And that really translates to help find ways to reduce global CO2 emissions, which right now translates to help promote solar and wind energy and electric cars! And make oil & coal energy obsolete as fast as possible.

I’m definitely not an expert on this, so I’m trying to learn as much as I can. Exploring ways to make a difference, partnering with others who know more, spreading knowledge, and inspiring others to help out. People like Elon Musk, Bill Gates, and Al Gore are already making a huge difference, but the more people that pitch in the better.

My mantra is every ton counts, because one ton of CO2 is one ton, regardless of where in the world it is reduced. That’s my driving KPI.

Climate Crisplet is a starting point, so join if you are interested! I can’t promise strong leadership, just a gathering point for people that share this interest and are looking for ways to help out and inspire each other.

I have no idea where the journey will lead, but I’m enjoying it so far! After 10 years of being an “expert” it’s very refreshing to get to be a newbie again

Categories: Blogs

How to introduce Agile to non-IT teams

TargetProcess - Edge of Chaos Blog - Wed, 03/01/2017 - 00:00

It’s clear that the Agile Methodology is not restricted to software development teams. Countless organizations have improved their flexibility and delivery speed with an Agile mindset, and many have successfully scaled Agile through every department. Agile is already widely used in marketing, education, and even auto manufacturing.

If you’re a non-IT team that wants to adopt the Agile mindset, you will likely encounter some resistance to change. This is good. Criticism of Agile can help your application of its values to improve.  To encourage non-IT teams to embrace Agile, you should first demonstrate the value that an Agile mindset can deliver. 

Don’t prescribe; encourage

The Agile methodology has (unfortunately) been fairly well-saturated with buzzwords and prescriptive practices. As Dipanjan Munshi puts it, “The process whose manifesto declared ‘People over Processes’ has now became a standardized prescriptive process in itself.”

To avoid putting anyone off unduly, don’t introduce Agile as a set of prescriptive processes. Instead, frame it as a cultural practice and a mindset for approaching work. Note that a successful Agile culture will help to increase employee independence, trust, and personal responsibility. In a traditional environment, management ends up being responsible for both failures and successes. In an Agile environment, responsible individuals shoulder this responsibility.  

It’s important for Agile transformations to happen more-or-less organically. Nobody wants to put up with another vague strategy change that’s been mandated by management. This is the the sort of thing that an Agile mindset is supposed to eliminate.

Don't transform; iterate

There are a lot of practices that have formed around Agile; introduce them iteratively, and you’ll be able to the avoid the culture-shock that has stagnated many transformationsTo get started, research Scrum and Kanban. Try to understand which practices might work for you, and why:

Kanban - Kanban uses a board with cards that represent work items. As a work item progresses from idea to completion, it is moved forward through the board's swimlanes. It's great for helping teams adjust to frequently changing priorities. Setting WIP (work in progress) limits helps teams to reduce context switching and avoid getting bogged down by an ever-expanding scope of work.

Scrum - Scrum is great for organizing teams and for making continuous improvements to your work process using Retrospectives. It's fairly heavy on planning (compared to Kanban), and uses fixed iterations to help teams understand and improve their velocity. Most teams utilize a Scrum Master - an individual whose job it is to facilitate meetings, remove impediments, and generally help the team get their work done.

If you're aiming for a large scale shift to Agile, take extra care when planning change. Peter Merel, a long-time Agile consultant and founder of the XSCALE Alliance, advocates the use of steel-thread squads: A small number of progressive people adopt Agile practices and measure their metrics to prove the productivity benefits. The team then divides like a cell and spreads to other teams. This allows for a natural change that doesn’t disrupt the established organization. The transformation is iterative rather than sudden; Agile is adopted using Agile.  

Bridge the gaps between software development and the domain of your teams

Some Agile coaches have noted that it is difficult to link the idea of “delivering working software” to other fields of work. Opposition tends to come in the form of rebuttals such as “We’re too quality-focused to adopt this practice.”  This line of thinking comes from a lack of understanding about the core principles of Agile.  Keep in mind that Agile does not mean sacrificing quality for speed. Rather, it means you should deliver the highest quality you can, without getting bogged down by process or bureaucracy.

The concept of developing “Working software” can easily translate to any field. It simply means the first point where you can deliver real value to your customers. Define the variables of what "working software" and "end user" means to your team. Figure out what what could be considered as one of the basic building blocks of your final deliverable so that you can get feedback at an early stage. 

You also shouldn't feel obligated to use the vernacular of Agile. It was created in an IT world, and might be irrelevant or confusing for your teams. Consider changing the terminology of your tool or process to reflect the vernacular your team already feels comfortable with. For example, a marketing team might rename Features as Campaigns, a sales team might rename User Stories as Leads, etc.  

Synchronize, but don’t get bogged down by ceremony

When you have multiple teams practicing Agile, you run the risk of creating what has come to be called "Agile silos." These are teams which are practicing Agile internally, but lack cross-team or cross-departmental coordination. This is not a good recipe. There needs to be some sort of unifying vision to help turn these different teams into a collaborative ecosystem. There are multiple frameworks to help you plan this out, including SAFe, DaDLeSS, and LeadingAgile

So, it's important to synchronize your teams, but you also have to be careful to not get bogged by ceremony and bureaucracy. A central pillar of Agile is replacing processes with interactions. Adopting the ceremonies of Agile without understanding their purpose is a huge red flag. Don't constrain your teams by trying to over-synchronize them with processes that they don't need. 

“Humans are of very low value as cogs in a machine doing identical things in interchangeable ways. That's for robots. Humans are most valuable when they have high autonomy, and able to play to their unique strengths and histories, particular sensitivities, op-tempos, and patterns of privileged information. The idea of "wisdom of the crowds" in fact rests on humans having diverse, unique private knowledge bases. The madness of crowds kicks in with synchronization and imitation.”  -Premature Synchronization is the Root of All Evil

Final thoughts

One of the biggest pitfalls you can fall into is looking at Agile as a cure-all panacea that will help you do more work in less time. This is not what Agile is about. It's about breaking out of the rigid structures that constrain individuals from completing their work in the best possible way. 

Dilbert on Agile

Learn the various techniques and strategies that Agilists have accumulated over the years, and pick the mixture that works best for you. Above all, don't lose sight of the values in the original Agile Manifesto.

Categories: Companies

Cross Functional Doesn’t Mean Everyone Can Do Everything

Perhaps the most prevalent and persistent myth in agile is that a cross-functional team is one on which each person possesses every skill necessary to complete the work.

This is simply not true.

A cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills.

Specialists Are Acceptable on Agile Teams

It is perfectly acceptable to have specialists on an agile team. And I suspect a lot of productivity has been lost by teams pursuing some false holy grail of having each team member able to do everything.

If my team includes the world’s greatest database developer, I want that person doing amazing things with our database. I don’t need the world’s greatest database developer to learn JavaScript.

Specialists Make It Hard to Balance Work

However, specialists can cause problems on any team using an iterative and incremental approach such as agile. Specialists make it hard to balance the types of work done by a team. If your team does have the world’s greatest database developer, how do you ensure your team always brings into an iteration the right amount of work for that person without bringing in too much for the programmers, the testers, or others?

To better see the impact of specialists, let’s look at a few examples. In Figure 1, we see a four-person team where each person is a specialist. Persons 1 and 2 are programmers and can only program. This is indicated by the red squares and the coding prompt icon within them. Persons 3 and 4 are testers who do nothing but test. They are indicated by the green square and the pencil and ruler icons within those. You can imagine any skills you’d like, but for these examples I’ll use programmers (red) and testers (green).

The four-person team in Figure 1 is capable of completing four red tasks in an iteration and four green tasks in an iteration. They cannot do five red tasks or five green tasks.

But if their work is distributed across two product backlog items as shown in Figure 2, this team will be able to finish that work in an iteration.

But, any allocation of work that is not evenly split between blue and green work will be impossible for this team to complete. This means the specialist team of Figure 1 could not complete the work in any of the allocations shown in Figure 3.

The Impact of Multi-Skilled Team Members

Next, let’s consider how the situation is changed if two of the specialist team members of Figure 1 are now each able to do both red and green work. I refer to such team members as multi-skilled individuals. Such team members are sometimes called generalists, but I find that misleading. We don’t need someone to be able to do everything. It is often enough to have a team member or two who has a couple of the skills a team needs rather than all of the skills.

Figure 4 shows this team. Persons 1 and 2 remain specialists, only able to do one type of work each. But now, Persons 3 and 4 are multi-skilled and each can do either red or green work.

This team can complete many more allocations of work than could the specialist team of Figure 1. Figure 5 shows all the possible allocations that become possible when two multi-skilled members are added to the team.

By replacing just a couple of specialists with multi-skilled members, the team is able to complete any allocation of work except work that would require 0 or 1 unit of either skill. In most cases, a team can avoid planning an iteration that is so heavily skewed simply through careful selection of the product backlog items to be worked on. In this example, if the first product backlog item selected was heavily green, the team would not select a second item that was also heavily green.

The Role of Specialists on an Agile Team

From this, we can see that specialists can exist on high-performing agile teams. But, it is the multi-skilled team members who allow that to be possible. There is nothing wrong with having a very talented specialist on a team--and there are actually many good reasons to value such experts.

But a good agile team will also include multi-skilled individuals. These individuals can smooth out the workload when a team needs to do more or less of a particular type of work in an iteration. Such individuals may also benefit a team in bringing more balanced perspectives to design discussions.

Evidence from My Local Grocery Store

As evidence that specialists are acceptable as long as they are balanced by multi-skilled team members, consider your local grocery store. A typical store will have cashiers who scan items and accept payment. The store will also have people who bag the groceries for you. If the bagger gets behind, the cashier shifts and helps bag items. The multi-skilled cashier/bagger allows the store to use fewer specialist baggers per shift.

What Role Do Specialists Play on Your Team?

What role do specialists play on your team? What techniques do you use to allow specialists to specialize? Please share your thoughts in the comments below.

Categories: Blogs

Agile Trends, Sao Paolo, Brazil, April 12-13 2017

Scrum Expert - Tue, 02/28/2017 - 10:00
Agile Trends is a two-day conference focused on Agile software development and Scrum project management that takes place in Sao Paolo in Brazil. All the talks are in Portuguese. In the agenda of the...

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

Agile Games, Cambridge, USA, April 3-5 2017

Scrum Expert - Tue, 02/28/2017 - 09:00
The Agile Games Conference is three-day annual event organized by Agile New England that focuses teaching, demonstrating, and improving Agile and organizational effectiveness using game theory. In...

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

We’ve moved from UserVoice to Service Desk for Idea Management

TargetProcess - Edge of Chaos Blog - Mon, 02/27/2017 - 18:13

Our new Service Desk application can be used to manage almost any kind of Request. One of its most common use cases is Idea Management, which allows you to gather feedback and prioritize features in your product based on your customers’ needs.

For the past several years, we’ve been using UserVoice for Idea Management. Now that our own Service Desk provides the same functionality and more, it’s time to move on. Last week we carefully moved about 10,000 users and 2,800 ideas to to make sure your feedback is not lost.

This means that the forum at is now deprecated. You are welcome to share your ideas at

The other thing we want to highlight is that you can also use the Service Desk + Targetprocess combo to collect and manage ideas for your own projects. Service Desk has all the usual features such as voting and comments, it allows you to easily link ideas to particular work items in Targetprocess, and it’s free. Also, as our own Product Owner observed, it's much more convenient to manage incoming ideas when you have all the power of Targetprocess to back you up.

Service Desk can be enabled from the Settings page in Targetprocess. Take a look at our guide if you need help getting started, or send us a message at

Tip: You can create Custom Request Types to expand your use of the Service Desk for almost any kind of application. If you’re not using Service Desk for customer support, just remove the Issue and Question request types and rename them to something that corresponds to your needs.


In addition to all that, we have just released a widget that can be handy if you have your own system and don’t need the full Service Desk application, or if you just want users to submit requests without leaving your website.


We understand that you might need some flexibility from the default settings, so we made the widget customizable. You can hide elements like top requests, description, and attachments, define default request types and privacy, and change the form's subject text. It is already available for you and you can embed it anywhere – all you need to do is to provide a link to your Service Desk with the correspondent parameters. See our guide for more information.

Categories: Companies

The Costs of Non-Delivery and Non-Conformance

Scrum Expert - Mon, 02/27/2017 - 17:16
Like the notion of technical debt, the concept of management debt relates to the leadership issues that prevent a successful Agile transformation. This article from Agile transformation expert Sriram...

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

Self-Alignment in Organisational Design

from torbenrick.euThe 1st step to organisational change is the abiliy of leaders to align their actions with their own honest intentions. Often, the installed culture they are part of don’t let them see the misalignment between their true intentions and how they are responding in day-to-day decision making. Narrative theory says  all story starts with heroe's tension between the status quo and her aspirations. One day, a trigger event gets the story going: the hero decides to leave the status quo. Organisation's Agile and the like transformation stories follow very much the same path. People (leaders, teams, etc.) decide to work differently. We want a better place of work , so that work becomes inspiring. We want a working place, where we are proud of what we deliver to our delighted customers. These wishes are genuine. When they meet organisation's current eco-system and culture, unpercieved misalignment between intentions and actions sneaks in.  From Reason To Purpose The trigger of any story, including a new organisational design one, is its "why".  "Why" question is time related. The answer is depended on how the question is connected to the "now" moment. It  can head both ways: it may search an answer backward to the root reasons of the tension:"Why the current status quo is not for me/us?" AND it may aim forward to the purpose of the story :"Why (what for) should I/we change the status quo?"
I think both questions are valuable as long as they are loaded with good will, and answers provided helps people in the room (well, I mean organisation). What is the answer has its importance, but what is the most important is remembering to ask the question. To all the people in the room ( well, I mean organisation). If you are tempted to ask it only in some workshops with selected managers and a bunch of consultants, resist! If ever you didn't notice it yet, at this moment, I'm giving you the trivial advice, you've  went through in another billion of blogs: "start with why".
I hava had some very interesting conversations Sylvaine Pascual , who's a professional coach, and  says that we have different needs, therefore for each of us one of the questions might be more important : some people need to know the "why" to move forward, but others need the "what", and others the "how". She says that saying that "why" is the most important is considering only the needs of the "why" people. I'm absolutely fascinated by her approach, because it is inclusive, supports diversity and allows us to step-down from  main stream thinking.
Nevertheless, I still recommend to start any transformation/new design of organisation... initiative with the why question.  Regardless of our personal needs,  making gathering some insights on the "purpose of (our organisation) life" is rich.  Most important, every story starts with "why the hero has stepped into this particular story".  Regardless of our personal needs,  our brain is story wired. We need a story to make sense of anything.
Culture In Organisations' Trenches 
 We start with "why", we acknowledge a dream, we state a purpose. But wait, there is more! We may invest a lot of time to create or even co-create the visible part of a common purpose and fill the room with energy and hope. Unfortunately, if  we have little courage to dive and inspect the invisible rules, beliefs and underling assumptions, the vision, strategy and structures are airy. Or they turn into dust.  If our collaboratively co-created initiatives are not aligned with the invisible culture, more inspiring our initiatives will be, greater the delusion when they will  last no longer that the time of an workshop or a pilote project. Once again, invisible culture have swalllowed  strategy along with our "change forum" breakfast.
Ok, what can be done to avoid that the only transformation that happens is that of delusion turning in perpetual resignation? The tricky thing about invisible culture is that it is of course ... invisible.  You may notice that there is no vision accuracy, chemistry or microscopic technology that will help us here. So what does this  invisible really mean? It means filters of or mind.  Our brain makes invisible, things that it decided it already knows, and you don't have to bother about any more.  Our brain thrives for learning. It's its main activity. As it is VERY smart, it also optimise learning. So what you've "learned" becomes a habit. Or a belief. It becomes "the way we do things here". It becomes blind to our awareness. It became "invisible culture".
What's the magic potion we can throw on invisible culture and make it glitter?  Question everything. I'm giving just some examples, you can feel free to find a lot more that fit your eco-system:
Why are you doing it? Who will benefit from it? What benefit will that be? How did something improved because you've done? If you don't think useful to do it, why do you do it?
And one more thing: regardless of the questions you ask, if the answer is "it's just the way we do thing here", BINGO! You've hit one element of invisible culture. While looking at it, how do you like it?

System Thinking To Help Leaders Self-alignmentNowadays, many transformation and change are supported or initiated by organisational leaders. They are visionary people want want to make organisations they lead the best place to be for the  people who are part of.  I'm a fan of the Principe of "retrospectives prime directive" and rule believe that anyone does her best. Nevertheless, even if leaders are very supportive to create a learning collaborative organisation, it might end-up in preoccupied confusion. Why does that happen?
Noooo, it's NOT because people need, at the end of the day to be told what to do. This belief, by the way a crunchy piece of "invisible culture".
There are a couple of things leaders are often not aware of. One is they are part of the transformation they make: they are participants, not only "advocates".  The second is that culture is "invisible" to them also. They are part of it.
The invisible culture is how an organisational system reacts when we are in the system.
I believe one of the reasons of failure of  organisational change are leader's misalignment with themselves, as they reflect well the culture iceberg. I also believe they are pretty unaware of this. I believe acquiring awareness about that I not easy, and I believe the best help comes from system thinking.   To overcome  the unwise side of "the invisible culture", leaders may try to be system listeners, who observe their organisation at their limits without judgment.
Organisations need time to change sustainably and resiliently.
"Invisible Culture" always have all the time in the world. It's the system itself, it's stable. Leader who will successfully contribute to change the organisation,  have time. The time belongs to us. Only ourselves decide what to do with it.
"Invisible culture" is the stable system. A world who goes fast does not make any sense to it. To change isn a system that pushes back any change, people need a safe place to  experiment those changes.  Leaders will successfully contribute to change the system will simply take part of the experiments. And get credit of their outcome, just like any other participant: It went well.It went wrong. We have learned. We are continuing to experiment.

Invisible is also Wonderful  We often address the "Invisible Culture" as something evil to be fought with. While, there are surely some bits we, as part of an organisation, will not be proud to look at, if a mirror of truth will be shown to us. "Invisible" is a word that gets our best friend, our brain ( yep, once again!) VEEERY preoccupied, because unknown means  danger around the corner!
But revealing something invisible is also a moment of grace. Revealing what makes us great together, what actually keeps me coming to work each day have a long lasting wow effect. Just like an Aurora Borealis in a frozen landscape, our invisible culture has its breathtaking characteristics.
WOW!from Travelminds.frRelated Posts 
Manage like A PirateFrom Listening To AwarenessThe Cost Of Fear Why I Am Not A Change Agent
The answer to Why is Ahead 

Categories: Blogs

Scrum Knowledge Sharing

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