” … while it is incumbent on all decent people to do their best to avoid hurting one another, these politically correct language initiatives are misguided and harmful. They create highly entitled professional “victims” who expect to be free from any offense, and they engender a stifling atmosphere where all individuals walk on eggshells lest they might commit a linguistic capital crime (unbeknownst to them in the great majority of instances).”

– “On the Follies of the Politically Correct Language Police“, Psychology Today, Gad Saad Ph.D., December 30, 2013

A colleague of mine who works as an Agile Coach for Ericsson told me she has seen adoption/struggle/rejection repeat in regular three year cycles.  She’s on her third or fourth cycle now.

We appear to be following true to that pattern.  Three years ago senior executives met at a meeting where the good, the bad and the ugly of attempting to adopt any sort of real agile approach was laid out for them so they could make what I term an “informed consent”.  At the end of that meeting I asked them to decide, and if they said no, that was OK, but if they said yes, I expected them to take the steps necessary to help alter the forces in the organization that are at the root of many impediments.  Three years ago they said yes, and since then we have helped hundreds of teams and dozens of products, but most importantly there are many more people who see with clear eyes and can reason in ways we didn’t use to.  One of the interesting side-effects of a journey like this is a significant increase in better middle managers, regardless of what you think of agility (see Management 3.0).

The group of coaches we have built up has effectively been disbanded.  I look forward to the day when someone decides “we need to get our head around this agile stuff” and we try again.

I’m optimistic this resurrection will occur.  The logic behind it is very compelling, and it really is a competitive advantage, one that our competitors are working mighty to master to use against us.  The more we struggle with the ever increasing rate of regulatory changes and requirements changes from our customers, the more we need organizational agility.

We’ve left behind loads of artifacts for any subsequent organization archeologist who may dig through our remnants.  I recognize lots of people still depend on <internal wiki>, so that will remain intact indefinitely.  Perhaps the leaders of the next attempt will be able to leverage some of these materials.

I’m quite proud of the extended team of coaches & colleagues who worked with us across all the lines of business.  They are a generous and knowledgeable bunch, often working against their own self-interest for the greater good, and they are the reason we have gotten as far as we have.

Robin Leopold (HR) pointed out that over half of our workforce are millennials, and that number is growing (“The M-Word”).  I hadn’t made the connection before, but much of what this age bloc is seeking in the way of meaningful work, opportunities for growth and respect are also precisely the constructs we use to build agile teams.  Other articles ^{1, 2, 3} cite retention as a systemic problem with millennials.  Why does this matter?  A normal, healthy age distribution across any company is uniform or perhaps even slightly pyramid, so there are always a pool of people being groomed to step in and replace people above them, and stay long enough to sustain the company until another generation passes and they are replaced.  If we suffer an extended period of retention, we end up with a bimodal distribution – a dumbell – in which the old guard camps at the top, there is a chasm of age with a dearth of experience, and a cluster of largely inexperienced people in the other lobe.  As time and retirements take their toll, the unwritten working knowledge of how things really work will be lost, and younger people may be forced to step into roles for which they are ill prepared.  While that may sound theoretical, I’ve seen it happen, and it is preventable.  It should be no surprise if I suggest that this ticking generational bomb can be at least partially mitigated by the structures we use for building agile, nimble, responsive products.

If you like to read the original research on millennials, here are some studies Robin has shared:

1. Female Millenials in FS.PDF
2. gx-millenial-survey-2016-exec-summary.pdf
3. millennials-at-work.pdf
4. Workforce Mindset Study 2015 .pdf

Footnotes

1. “Millennial Employees Confound Big Banks“, WSJ, April 8, 2016
2. “Goldman Sachs Sweetens Deal for Young Bankers“, WSJ, November 5, 2015
3. “Wall Street’s Playbook for Managing Millennials“, WSJ, April 8, 2016

I almost hesitate to write a blog about ‘failure’ and ‘scrum’, but I think it’s important people are fully aware.

I’ve seen this particular scenario play out enough times that it qualifies as a pattern.

Scrum is adopted by an organization, and it goes through the initial euphoria, followed by a slump with the realization that scrum really doesn’t solve anything, it just exposes weaknesses for us to fix, and that’s work.  If the organization institutionalizes continuous improvement, they get into a rhythm of chipping away at all the systemic, often organizational “rocks” that have been holding them back, and they establish their new normal.  Not perfect, but with an upward slope, precisely because they are cognizant of the rocks and work deliberately and forever to fix the system.

Perhaps the head of the organization is promoted.  Perhaps they are hired away by another company.  Whatever the reason, a new head arrives, without any of the history of how the organization got to where they are now.  The “new broom” is here to sweep out the old, and bring in the new, after all why else would they have brought in this talented person if not to fix all the problems of their predecessor? Making changes is a sure sign of improvement, or at least making their mark on the organization.

Remember: everyone is rational inside the box they find themselves.  The forces at play on this new head tend to steer people this way.  This is a consequence of the system.

And this, my friends, has been the most common failure mode for scrum that I have observed.  It’s almost “death by success”.  I haven’t yet figured out a way to prepare the organization to see this coming and deal effectively with it.

Somehow we need to give the organization an “institutional memory” of some sort so the history is given it’s due and knee-jerk changes are more thoughtfully considered.

Inventors are ordinary people with extraordinary perception.  They see the same things we all see, but they are more observant and very, very curious.  “Why?” pops out of their mouth a lot.

For example, if you have a common coffee carafe you may have noticed that if you pour with any speed (“I need my coffee NOW!”) the fluid runs back down the side of the carafe and spills all over the counter.  Are you one of the folks who just wipes up the mess, or do you, in your caffeine-deprived state, wonder what it is that would cause something as simple as a pour spout to malfunction?

Kudos to those of you with carafes that don’t spill.  I’ll bet they are not made of glass.  Turns out this is a physics problem with glass carafes.  In order to make the glass more robust and not sharp edged, the lip is slightly rounded, which disrupts the fluid flow at the lip.  The slight compression of the fluid makes it more likely to follow the glass than gravity, and the faster you pour, the more you spill.

When you see a “problem” try exploring it for (I know this sounds cliché) opportunities.  The best solutions are ones that completely bypass the problem.  What’s the best way to sail around the Cape of Good Hope?  Don’t do it (ergo the Suez Canal).  Another example is when we see a chain of operations starting with people entering data electronically to then print the form, send it in to get scanned and checked, with all sorts of poor quality 3^rd party form-filling software and people marking on the paper and mishandling the paper.  You could look at that and try to solve all the problems in the chain, or you could see a business opportunity to put those poor quality 3^rd party vendors out of business and completely bypass the print/scan translation steps (our own Suez Canal!).

In our agile training we harp endlessly about the importance of continuous improvement.  The most important lesson is that this is about how to see the world and not some specific, measurable behavior.  The opportunities are endless, if we only dial up our sensitivities.  Try it out the next time you see a problem and ask “why?”  Inventors are not necessary gifted from birth; the curiosity can be developed with deliberate effort.   There is any number of formal brainstorming techniques used by high tech companies for “inventing the future”, but in the end it’s a way of thinking.

An awful (and I do mean awful!) lot of scrum adoptions I have observed are quite shallow.  Shallow in their scope, shallow in their understanding, shallow in their impact.  These are often external trainers or consultants who have a few classes to sell and they approach the engagement at just the team level.  There is a limit to the impact precisely because the scope is limited to the teams and not the larger organization.  This is very appealing to the existing management as the implicit message is: scrum is a technical thingy we apply like a coat of paint on my people.  The smallish dot in the yin yang is representative of such small thinking.

Yin Yang represents harmony and balance, and the eternal play between two forces.  I believe that a proper agile adoption includes a substantial amount of work transforming the larger organization.  Unlike the previous paragraph, scum is most definitely not a technical thingy applied like a coat of paint.  It has implications all the way up the organization, affecting how we think about recruiting, compensation, performance reviews, retention, reward systems, budgeting, org structures and a raft of other organizational issues.  This does indeed include that standard Scrum 101 training for the teams, but that turns out to be a teenie part of the bigger picture.

The other half of our Yin Yang is the orthogonal but oh, so complimentary technical practices.  To be clear: you do not need to be using agile anything to leverage good technical practices, and you should always be trying to apply sound craftsmanship.  That said, there are positive feedback loops that scrum reinforces that amplify solid technical practices.  When you strive to deliver to production every two weeks, then every week, then every day, you take automated testing at all levels, and continuous improvement, continuous integration and continuous delivery (three different concepts) very, very seriously indeed.

If you are starting your journey, keep in mind this balance, and look askance at hucksters with solutions that only address half, or worse just the teams and not the larger organizational issues.  Everything you omit is still there, waiting to bite you.

If you have attended Product Backlog Refinement meetings, you may understand and appreciate the importance of the conversation that occurs between the experts (sometimes referred to as Subject Matter Experts, or SMEs) and the feature teams.  The insight and understanding gained during that conversation far outweighs any artifacts brought in or derived during a PBR.

You may have seen PBRs that appeared quite chaotic, with “experts” who did not seem comfortable in that role.  Skipping over the discomfort of presenting in public for the moment, sometimes you may be looking at someone who is unprepared to answer the myriad of questions.  The topic may be complex, or the expert hasn’t given it much thought recently.  Therefore, one of the forces at play here is a desire for smooth running PBRs and experts that are fully prepared to have a conversation.

This can sometimes go too far, as shown in the image above, where the preparation becomes rigid, perhaps fully documented, and the expert now invested in the artifact to such a degree that they are unwilling to entertain any changes.  The conversation is altered to become the delivery of a fait accompli.  In the worst cases I have seen PBR degenerate into the delivery of a requirements document, with the “expert” withdrawing totally from the conversation.

The answer to the original question of how much preparation is enough is, as always, “it depends”.  You need to understand where your org is on that gradient and be aware not to overshoot the mark in preparation and kill PBR.  Early on I see many more orgs with chaotic PBRs, often due to not inviting the correct experts or not being able to locate experts (now there’s a serious organization impediment that needs addressing!)  For starting out, if writing a requirements document helps structure your thinking so you can fully grasp the requirements, by all means do so.  But don’t confuse that preparation as a substitute for the conversation that PBR brings to the fore.

If you understand all of this, you can probably see why some misunderstand scrum as “not having documentation”, when in fact it’s just the opposite: have just enough documentation.

“We are almost done.  Let’s move the sprint review back a couple of days and wrap this up.”

“We should change our sprint length from two to three weeks so we can get more done.”

If you are a Scrum Master, how do you respond?

Those are two fundamentally different statements, but they have a lot in common.  Let’s look at how one might respond.

“Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.” – Scrum Guide (2013, p. 7)

“Sprints best have consistent durations throughout a development effort.” – Scrum Guide (2013, p. 7)

Textbook response.  Nailed it.  Tick!

If this is all you respond, I’ll give you a C.  Scrum Masters are expected to be masters of scrum (know the scrum guide cold). Appeals to authority (like this), while correct, are very unsatisfying.  If you want to motivate and educate, Start With Why?

Let’s look a little deeper at why scrum has these rules (fixed length sprints) and guidance (best to have consistent durations).

1. Your product Owner wants a release plan, therefore needs a velocity. I can already hear some of you arguing that velocity can be calculated for every sprint length.  Mathematically true, but it overlooks the increasing variability encoded in a longer sprint, which obviates any hope of predictability if sprint length changes.
2. Lengthening sprints is often a sign of weakness.  Teams may need coaching and practice to effectively split items to something small enough that also maintains end-to-end customer visible customer value.  Short, fixed length sprints expose this weakness, giving them an opportunity to correct it.
3. If you stretch the sprint to finish, where do you draw the line?  The same argument can be repeated ad nauseum.  Timebox is a psychological driver for closure.  It is used everywhere in scrum, on purpose.  We want to be able to inspect & adapt, and the points at which we do this are at the timebox boundaries.
4. If you lengthen the sprint, you may inadvertently increase the size of items taken into the sprint by e.g. 50%.  1/3 of a two week sprint is about three days, but 1/3 of a three week sprint is closer to a week.  This should be concerning because 1) there is a non-linear relationship between the complexity of a requirement and the probability of not being able to deliver in a sprint, and 2) the second most significant factor in the success of a software product is small sized requirements [1]  You are climbing out on a nonlinear curve, and it’s really not working in your favor.  You are making things worse, not better.
5. Humans respond well to predictable rhythms.  Sprints give them a predictable rhythm.
6. “if you want to get good at something, do it more often” – Jez Humble.  Basically a restatement of #2, without the guilt trip.
7. Inspect & Adapt is almost a mantra with scrum.  If you lengthen a sprint, you lengthen the feedback loop and reduce opportunities to improve.  Sometimes learning means tossing the work for an item at the end of a sprint.  Short sprints reduce the cost (time invested) before learning occurs.

Those are some of the ‘why?’ that come to mind to motivate why scrum is defined the way it is.  Use some combination of the above and see if that helps.

Extra credit: what other reasons have I overlooked from that list?

[1] COCOMO II

From: Born, Timothy D
Sent: Saturday, July 25, 2015 8:40 AM
To: Abhishek; Agile Community
Subject: RE: Q&A with Jeff Sutherland on Agile Leadership

I cringe when I see such quotes from Sutherland.  Much as I respect Jeff, I wonder if he isn’t doing more of a disservice, raising expectations this high.

The problem with quotes like this is some people will misinterpret this as a *behavior*, such that if we replicate that behavior, we will get great productivity gains.  As written, putting the screws to the scrum master sounds like a great idea.  What is missing is management at Deere actually does something with those impediments.  They have internalized the thinking, and they realize agility is not a “tech thing”, but cultural changes that affects the organization, all the way to the top.

Tim Born | Agile Coach, Corporate & Investment Bank | xxx
(+1) 630-492-0038 | timothy.d.born@xxx.com | http://go/agile

“The ScrumMaster is not at this meeting [retrospective] to provide answers, but to facilitate the team’s search for better ways for the Scrum process to work for it.  Actionable items that can be added to the next Sprint should be devised as high-priority nonfunctional Product Backlog.  Retrospectives that don’t result in change are sterile and frustrating” – Ken Schwaber

From: Abhishek
Sent: Saturday, July 25, 2015 12:36 AM
To: Agile Community
Subject: Q&A with Jeff Sutherland on Agile Leadership

http://www.infoq.com/news/2015/07/sutherland-agile-leadership

Regards,

Abhishek

People often assume pairing means pair programming, but pairing is much more general and powerful than just programming.  One of the best empirical research papers on this topic has to be Arlo Belshee’s “Promiscuous Pairing and Beginner’s Mind“.

The paper is short and well worth the read.  Follow the citations backwards and look forward to some follow up research by Mitch Lacey: “Adventures in Promiscuous Pairing: Seeking Beginner’s Mind“.

I’ve given talks on these papers numerous times.  Here is a video from September 2013 summarizing these and other research on this topic.  This is a webcast, so it’s a lot less dynamic than having a live audience.  At the time this set an attendance record with ~400 people joining from around the world.

This is another technique that, strictly speaking, isn’t so much about agility as good team collaboration.  In other words, this is probably applicable in your environment, whatever that may be.

December 26, 2014

You may have heard the term ‘technical debt’, but what does it really mean? As we explain in our classes, the effect of shortcuts taken now in order to meet a deadline are an IOU in the future. Technical debt has a delayed feedback loop. Heroic efforts in this release make it appear as if “Crash Scrum” was a success, but that IOU comes due in the next and all subsequent releases. This technical debt compounds over time, making the code base increasingly hard to navigate, slowing progress to a point where we declare the product “legacy” and start over with a “next generation” version. We do this because we believe we are smarter than our predecessors, who ‘obviously’ coded like drunken weasels. Or did they? Everyone is rational in the constraints they find themselves in, and technical debt is a manifestation of the system that creates it. We create the system of incentives that creates legacy code by emphasizing short term delivery over robust automated tests, TDD, continuous integration and a myriad of other well known technical practices that mitigate technical debt.

Here is a wonderful article on technical debt that casts the argument in a completely different metaphor:

Bad Code Isn’t Technical Debt, It’s An Unhedged Call Option

Want to see what technical debt looks like?

Technical Debt Visualized