Tag: life

Democracy in America

Leave a comment

The religionists are the enemies of liberty, and the friends of liberty attack religion; the high- minded and the noble advocate subjection, and the meanest and most servile minds preach independence; honest and enlightened citizens are opposed to all progress, whilst men without patriotism and without principles are the apostles of civilization and of intelligence. Has such been the fate of the centuries which have preceded our own? and has man always inhabited a world like the present, where nothing is linked together, where virtue is without genius, and genius without honor; where the love of order is confounded with a taste for oppression, and the holy rites of freedom with a contempt of law; where the light thrown by conscience on human actions is dim, and where nothing seems to be any longer forbidden or allowed, honorable or shameful, false or true?

– Alexis de Tocqueville

Death

Leave a comment

“Someone who has given up the idea of living life will surely never be able to embrace death.”

– Guy Dubord, Society of the Spectacle

Measuring Success

Leave a comment

I don’t measure my days
In hours I work
In songs that I stream
In tweets or likes or characters
Or words I’ve put to paper
I measure my days
By the gardening dirt
Washed off in the shower
And the bugs I catch
With my kids at dusk
For science lessons at bedtime
And how sore my muscles are
The morning after
I measure my days
In the flowers I’ve met
And sandcastle refuges built
And Lego towers
I measure the day in love
With smiles of hope and joy
And the number of dresses
My daughter twirls, singing
Between tickle-monster giggles

I don’t measure the steps I take
Or the miles I drives
I measure my warmth and stillness
In much-requested snuggles
Sheltering a child from morning
On peaceful weekends

I don’t measure my weeks
In billable time
Or proscriptive pages
And decisions made
I share and give and hope
Alongside dreamers
Who need to see their spark
I don’t worry about
Being taken seriously
Or the advice that I’ve provided
Ignored or followed as I try to help
No, I measure my weeks
In twinkling eyes
As I walk in the door each evening
In bonfires lit for marshmallows
And Summer’s splashing water
I measure my weeks in hiking trips
And Autumn leaves we crunch
In snowball fights and lightning bugs
Spring showers danced in
Early summer sunburns
And ice cream headache kisses
I measure my weeks in smiles
In water sloshed out the tub
In sand tracked onto hardwood
And the drowsy bedtime tales
In nights I look up at my sky
And track the conversion rate
Of sunsets I find peace in

I don’t measure my years
In money I’ve made
Or parties I’ve thrown
And destinations I’ve seen
I measure my years
In the people I’ve served
By the callouses on my hands
The art hung on the fridge
And my joy in the moment

You do NOT want Transparency

Leave a comment

Disruption and Transparency

As a custom app dev consultant I constantly get inserted into the space between organization silos – between marketing and accounting, between sales and operations, between IT and product management.  The agency life makes you a fly on the wall in meetings where groups who avoid each other are forced to work together directly for the first time. Maybe it is the nature of disruption, whether it is a lean, agile, or digital “transformation” – but it creates immense hoopla about and demands for “transparency”.

Transparency is promised all around, named as a priority in meetings, and complained about when people feel like they’re out of the loop. As the old bard said, “Ay, there lies the rub.”

Transparency is not what anyone wants.

Requesting transparency, instead, represents the desire for visibility and proper prioritization of important information as it flows to the people who will be impacted by it.  If someone doesn’t have an understanding of what information they want prioritized, “transparency” is really just an expression of distrust.

Transparency is saying “I don’t know what information is important, I don’t trust you to prioritize it for me, so give me access to all of it.”

Now don’t get me wrong, this post is not about how to allow or restrict access to data. Instead, if you are part of a disruption-in-progress, keep an eye out for communication anti-patterns.  When a complex system is creating new cultural repertoire, adapting to disruption, new information flows must be created.  New decision patterns emerge.  Some people like the change and others are oblivious to it until the day it hurts them because they personally failed to adapt. 

Examples of Communication Anti-Patterns:

  • Email notifications that are really just internal company spam.
  • Managers who request to be added to meeting invites “just in case” they want to pop in.
  • Sending someone a raw (and sort of meaningless) export of data in spreadsheet form as an “answer” to their question.
  • Stakeholders who demand access to the agile tool (JIRA, Rally, Trello) but never look at it.
  • You get a casual question about status and answer by forwarding several email chains.
  • Making up new KPIs and performance metrics that don’t matter.
  • Virtually every version of reports on “utilization” that I’ve seen.
  • Anonymous complaints to executive leadership about secrecy around financial status.
  • Weekly meetings that review numbers that only change quarterly.

I’m sure you have another hundred examples, just like I do.

So whether you adopting a new tool, some kind of “enablement” software, in your aspirations for lean scalability, changing your agile or DevOps processes to encourage innovation, or embracing digital transformation as a path to new business models and potential revenue: be human.  When nonsensical requests for transparency happen, let it inspire a dialogue (or several) about what information is most important to each person and the best way to present it.  If you didn’t see the future and have all those conversations up-front, guess what?  No one does. Start driving human dialogue as soon as you notice there is a communication anti-pattern.

Visualize Your Work – and Show it off!

And, if these aren’t problems you’re having right now, you should still think about the best ways to visualize your work in progress. You will benefit psychologically, someday you’ll be able to answer new but important questions to a manager or colleague more appropriately, and you’ll discover what you can teach to other who are earlier in their professional journey.

Why? Why? Why? Why? Why? (5 of them)

Leave a comment

As I described this weekend on Snapchat using the example of my house, Root Cause analysis – or asking the 5 why’s – is essential to lean scalability and a thriving culture of relentless improvement. In complex systems thinking, you must see problems (lack of quality, decreasing sales) as a symptom of the system as a whole.

I bought my first home in November in a north suburb of Chicago. Naturally, that means finding little issues here and there as I go. It was originally built in the 1950’s and I knew it was in a neighborhood that had flooded a bit a few years back. I was excited from the first tour to see a fantastic dual sump pump system in the finished basement.

Unfortunately: The previous homeowner had treated the symptom, not the problem.

A house (like a software product or tool in its context) is part of a complex adaptive system. It is inserted into a biological ecosystem, and integrated with multiple networks (cable, electrical, plumbing, roads). What the previous homeowner did is a mistake many of us make when it comes to eCommerce, marketing campaigns, enterprise software, you name it – the symptom was treated in the context of a system in homeostasis without changing the ability of the system to adapt to deal with a chaotic event.

SO – my basement has flooded, just a little, three times this spring.

Enter the “5 Why’s” Analysis:

1- Why is the carpet wet in the basement?  The sump pump didn’t pump out the water quickly enough. If I were to continue to treat the symptom, I might upgrade the sump pump, which is expensive and might not work (and what we tend to do in the workplace).

2- Why didn’t the sump pump handle it?  There was too much water around the house, building up hydrostatic pressure. The second time we had flooding, I noticed that the water appeared to have come in from all sides, not from the sump pump reservoir overflowing. (i.e. without “going to the place” I might have continued to blame the sump pump)

3- Why was there too much water around the foundation? I have a negative grade, meaning my lawn on one side slopes slightly toward the house. Again, easy to blame that and spend a fortune on a re-grading (legacy system migration anyone?) but I had the joy of really, really “going to the place” and spent an 1hr flash-flood storm OUTSIDE, managing the flow of water in non-normal conditions. After all, the yard may slope slightly, but there are 4 basement egresses with drains in the bottom that run to the sump pump…

4- Why did so much water flow to the basement window wells that the drains couldn’t get the water to the sump pump quickly enough? (notice that we are finally getting somewhere in our root cause analysis!) Once I was out in the storm, it was clear that the rain on its own was not the issue: despite having cleaned out my gutters hours before the storm, the winds that blew the storm in kicked lots of new leaves onto my roof, blocked the gutter, and a waterfall of water came off the gutter onto the negative grade instead of going down the downspout system that drains the water in a safer direction. What I also noticed was that the sidewalk gradually filled with water from the downspout nicely – meaning there was a certain amount of in-yard flooding that could occur before the water would pour unchecked into my window wells. (note, I could invest in LeafGuard or something as part of a total replacement of my gutters, but have we really found the root cause?)
5- Why doesn’t the system (my house in its context) handle a the flow of water in that quantity? Now we’re down to business. The soil has a high clay content and hasn’t been aerated recently. The previous homeowner removed bushes on that side of the house but not the roots and stumps. The downspouts eject water 3 feet from the house, but into an area of the lawn that can be easily filled with water that will then flow back to the egresses.

Root cause – The system is not prepared to handle the flow of unwanted inputs under non-normal conditions.

Oops, I slipped into discussing emergent leadership in complex adaptive systems.  What I meant was, nobody had bothered to look at what happens to the flow of excess water in flash-flood conditions.  Just like I frequently see no one planning for “storms” in their agile or devops culture, their social media presence, or omnichannel efforts.

To round out the story, now that we have a ROOT CAUSE.  I can come up with a….

Solution – Create a sub-system that encourage adaptation to non-normal systemic conditions.

Sorry, I did it again.  But you really can’t tack on a new tool or process if you have underlying cultural factors that need to be addressed.  For my house, the answer is simple, add a French Drain system that will handle excess water during a flash flood.

Now, with my years in custom app development consulting, the parallel is really quite striking. Investment in a bigger pump, a total re-grading, or new and improved gutters would have been an expensive way to deal with emergent properties of the system without helping it adapt properly to non-normal stress. The french drain and dry well implementation I have started will require some hard work (i’m digging it by hand!) but potentially no cash (I already have more river stones than I know what to do with).

  • I’ve discussed how this applies to agile or DevOps transformations that don’t address cultural problems.
  • I’ve shown how bad investments in software happen due to a lack of understanding of the root cause.
  • Look for more on how this applies to eCommerce and Marketing on the way!

The Leader I Am

Leave a comment

The foundation of the leader I am today isn’t listed on my resume. Those formative moments don’t really belong in the official documentation of pursuing autonomy, mastery, and purpose through software product innovation.

My training in leadership did not begin during my MBA or any of my agile certifications. It began by watching my father’s servant-leadership as a minister and the mentorship of my high school English literature and composition teacher.

There was a day that came when Mrs. Bernsen, my high school English Lit teacher, gave the disengaged classroom an admonition to inspire our focus as we read and discussed selections from Ralph Waldo Emerson’s “Self Reliance”. Who we choose to be today sets us on a path for who we will become in 5 years. I took that idea very seriously. I studied “Self Reliance” several times and began teaching its ideas to anyone who would listen. I had decided I was a philosopher who loved teaching people to strive for introspection and self-ownership of their journey in life. My career has been expanding on that theme ever since.

As 1st chair trumpet in band, I learned the power of servant leadership and inspiring people to the prestige they wanted. I played third part because I was naturally the loudest and it made the whole band richer. I made sure everyone who wanted one got a chance at a solo that they would succeed at. Senior year we had a particularly challenging piece and not enough trumpet players to effectively make it beautiful, so I noted out with my second chair how he and I would trade off between 1st and 3rd part, ensuring the high notes were never missed while the low notes were the right strength.

As a Youth Minister in college I found the power of Accountability Partnership in learning plans. There is truly to many virtues and too much knowledge in life to tackle at once. Whether a mentor, teacher, or friend, finding someone to share your personal development goals with, and being someone who can ask about progress, is essential. Saying it out loud makes goals more realistic and personally expressing them to someone simplifies the ability to prioritize your priorities.

As an assistant manager in retail and in a restaurant after completing my philosophy degree, I learned the importance of being the janitor. Clean up the messes, socially and physically, that your team can’t get to so that their flow isn’t interrupted and the customer is happy. You show up at 2am to unload the new stock so someone else won’t have to and you run the reports and call the customers no one else wants to call.

Yesterday I was asked to share a story that exemplifies my leadership style. I shared a simple story – I recently noticed a group looking a little lost because there were no meeting rooms were available and they had a conference call. I gave them my office. Their work and that customer were important than my comfort. I worked in the lobby.

All of these moments stay vibrant in my mind, as the milestones of how I became a leader today. Most important though is the example of my dad, which laid the foundation for how I view people in need of guidance, listening more than teaching, and serving where no one else wants to go.

So when you ask me about the leader I am today in the software space, it centers around four goals, built off the foundation described above, and countless other tiny moments along the way.

I use workshops and one on ones to build the confidence and vision of my team so they can pursue their own sense of meaning and purpose at work – I can only help build the bridge between company goals and values to personal sense of prestige and love of your work.

I use learning plans and information sessions to help my team members pursue their sense of mastery in their craft. I am constantly learning what they want to learn so they have someone to meaningfully converse with, while playing the role of accountability partner much more then mentor. I don’t lecture or train so much as play the role of knowledge janitor, cleaning up the chaos of possible theories, tactics, and practices, finding answers for people and resources and thinking a few extra steps ahead about how we can grow.

I am an advocate on their behalf when political games are in the way of their autonomy, while challenging them to become more cross-functional, more collaborative, and better at self-advocacy. I want my people to be leaders who are better at defining their own processes and taking pride in their work because they trust I can challenge them. The most important trait of a leader is gaining trust by proving that I have their back.

Strength to Compete

2 Comments

Excess of strength is the only proof of strength.  

We must strive, fight, and harden ourselves, continuously improve and overcome, to outstrip and outpace our rivals.  We must brace ourselves, proud and resilient, against risk – and even welcome loss when justified – because even in a wound there is the power to heal.  It is a first-principle from the military school of life:  

What does not kill me makes me stronger.

As warriors we expose our weakness happily, welcome vulnerability, fail often, delighted, and inspect, adapt, evolve, and innovate – hard and fast.  We make pain our truth, we make learning our competitive strategy, we make ourselves immune to the setbacks that ruin the weak around us.  In the face of tragedy the warrior in our soul celebrates, and even honors life as the most worth adversary we will ever face; because, more consistently than any other rival, “life” brings its most formidable weapons against us.  Every artist needs his torture, even more the disrupter and creator of values.

The warrior-champion is born out of, and evermore accustomed to, suffering, and extols his existence by means of tragedy and hardship, because he knows the value of a thing often lies not in what one attains with it, but in what one pays for it; what it truly costs him. Liberated by perseverance, gritting our teeth against pain and loss, war becomes a training in freedom – after all, what is freedom?

Freedom is the will to self-responsibility.

Freedom is a state of spirit; that one embodies the will to self-responsibility.  That one preserves the distance that divides us, even in an embrace.  That one is ready to sacrifice men to one’s cause, oneself not excepted.  Freedom means that the instincts that delight in war and victory within us have gained mastery over all other instincts.  The truly free man is a creator, destroying the past and disrupting the present, a warrior constantly overcoming resistance, five steps from becoming a tyrant while standing on the threshold of servitude.  He combats the tyranny of the pitiless, dreadful instincts with maximum authority and discipline toward himself.  After all, what is strength?

Strength is the will to self-discipline.

It is great danger, our thorough and deliberate exposure to risk, and winning against it, that makes us deserving of reverence.  It is only the real danger of losing everything that first teaches us to know our resources, our virtues, our shield and spear, our very spirit; it is danger that compels us to be strong.  Thus the first-principle:

One must need strength; otherwise one will never have it.

The strongest among us, champions respected throughout history, have felt precisely this way – freedom is something a man attains but can never own, something one always pursues, something for which we must fight, a state one continuously conquers.

Stay strong, rise to the fight!

– An adaptation, extension, paraphrasing from the works of Friedrich Neitzsche

Photo Attribution:  Rob Weir‘s photo of “Atlas (1937) Statue” by Lee Lawrie, Rockefeller Center, NYC

What Westside Barbell has taught me about Scaling Agile

Leave a comment

Agile Portfolio Management:

There is a new way of doing things in delivering a complex product portfolio.  It focuses on delivering value both incrementally and iteratively.  It utilizes empirical process control and hypothesis-driven planning.  It utilizes test-driven development in both convergent and emergent delivery, even when budget and scope are fixed.  It utilizes a Lean kaizen approach to maximize velocity.

This philosophy is by nature, object-oriented and modular.  No one framework is right for every product, so it is highly customizable.  It may sound new to you, but it has been around for quite awhile.  But wait – I’m not talking about Agile, Scrum, or Lean software principles – I’m talking about Westside Barbell’s approach to powerlifting.

Waterfall Weightlifting:

Powerlifting is a sport in which the lifter competes for the highest single-repetition maximum in the Squat, Deadlift, and Bench Press for their weight class.  The traditional approach to training powerlifters relied on linear periodization – a method still very valuable for beginning athletes because each phase builds on the last while progressing toward competition-specific strength.

At a basic level, here is a 12-week competition plan:

3 Week Hypertrophy Phase (muscle size, stamina): Sets of 12 to 15
3 Week Strength Phase (movement form, ability to move weight): Sets of 5 to 7
3 Week Power Phase (Explosive speed, maximum weight at progressively higher volume): Sets of 1 to 3
3 Week Peak & Rest (Highest weight, lowest volume): Sets of 1 to 3, tapering off to a few rest days
Competition: Three chances to get three lifts correct, competing against others who are doing the same

As agilists, this correlates perfectly with the “waterfall” approach we try to leave behind:

Hypertrophy phase: Business planning, creative design, and thorough documentation
Strength phase: Database layer, middle-tier
Power phase: Client-side logic, front end development
Peaking phase: Testing, beta release, focus group and stakeholder reviews
Rest days: Code freeze and marketing
Competition: Release to the market, in which you may not recover from failure

Then the lifter starts over.  If there was a big loss (e.g. an injury) pre-competition, the weight lifter might not compete at all – just like software project that gets cancelled after key engineers leave or technical debt gets too high to meet the release date.  More problematically, if there is a big loss or injury at the competition, the lifter may never compete again- just like the software team with a botched release that gets “reassigned” or laid off.

Repeating the Cycle:

The weightlifter who perseveres, win or lose, still has big “waterfall” problems.  The lifter rests a little and repeats the linear progression cycle, an exercise in bodily context-switching.  When the next hypertrophy phase starts post competition, most of what was developed in the previous cycle is gone!  The same is true of each phase.  When the lifter resumes focus on 3-rep max, some hypertrophy and stamina is lost.  As the lifter peaks for competition, the 1-rep max may increase but the 5-7 rep range decreases.  Studies show that after a few weeks in the subsequent hypertrophy phase, up to 15% of single-repetition strength is lost.  The disconnect between foundational planning (by increasing stamina and size) sacrifices a considerable amount of value captured (ability to perform the same single-rep max).

What does this specificity-switching cost the lifter?  As a beginner, not very much – any work will improve size, conditioning, and maximal strength, and fantastic progress can occur.  The discipline of repeating the movement pattern likewise increases maximal strength even with little planning.  However, once the lifter goes from a beginning athlete – a time when nearly anything will improve the lifts – to an intermediate athlete – subsequent peaking phases will see little or no increase.

The process requires disruption if total stagnation is to be avoided.

If this sounds like delivering software in waterfall, it is!  As you read this quote from a strength coach describing the “waterfall” lifting approach, think about the Waterfall PMO:

Having now gotten away from this type of training and looking back as an outsider, I can see where the program is lacking and why I had so many problems. I used to feel it was the only way to train (mostly because it was all I ever knew). It was also the only type of program for which I could find a lot of research. Some of the limitations to this linear style of periodization include:

  • It’s a percentage-based program
  • It starts with a high volume
  • It only has one peak
  • Your abilities aren’t maintained
  • The program has no direction to the future

– Dave Tate via T-Nation.com

Here are the parallel problems we see with waterfall:

  • “It’s a percentage-based program” – accounting-based statistical process controls are applied to an emergent system
  • “It starts with a high volume” – a significant portion of the budget is spent planning, designing, and fighting about features that no user wants (and if the project is cancelled, 100% of this sunk cost never drives user- or owner- value capture)
  • “It only has one peak” – A major release attempts to market itself to all segments simultaneously and a flop may kill the product line completely
  • “Your abilities aren’t maintained” – once the waterfall project plan is set in motion, market evaluation, user feedback, and stakeholder review is non-existent
  • “The program has no direction to the future” – a waterfall project plan is delivered based on the knowledge available at the beginning of the project when the least is known and has no intrinsic method of looking to the future relationship between the user market that might exist and the software that could be produced.

Westside Barbell’s “Conjugate Method”

The Conjugate Method attempts to balance all phases across preparation for competition. At the “enterprise level” three movement patterns are continuously tested as the measure of the process. At the “business level” a new variation of a similar movement may become the focus for 3 to 5 weeks (e.g. training rack pulls instead of full deadlifts when “lock out”, the upper portion of the movement, is the weak link). At the “team level” (the lifter + coach), the two-week sprint has a consistent set of ceremonies and artifacts (workout plan, workout log, the workout, etc).

Here is an example:

Week 1
Monday – Max effort lower body day (squat + low back + hamstrings), focus on strength and power
Wednesday – Max effort upper body (bench press), focuses on strength and power
Friday – Dynamic effort lower body (squat, deadlift), focuses on speed and hypertrophy
Sunday – Dynamic effort upper body (bench press), focuses on speed and hypertrophy
Week 2
Monday – Max effort lower body day (deadlift + low back + hamstrings), focus on strength and power
Wednesday – Max effort upper body (bench press), focuses on strength and power
Friday – Dynamic effort lower body (squat, deadlift), focuses on speed and hypertrophy
Sunday – Dynamic effort upper body (bench press), focuses on speed and hypertrophy

This correlates nicely with “core” Scrum concepts:

  1. Maximal strength is tested every week – working software every sprint
  2. The metric (1-rep max / story points delivered), is improved (strength / velocity over time), through hypothesis and experiments (empirical process control)
  3. The entire body is trained for size, stamina, strength, and power per every week – vertical slicing and user stories
  4. The lifter gets to experiment with new exercises without fear of wrecking a 15-week cycle – sprint retrospective, sprint planning
  5. The coach focuses exercise planning on addressing weak points – a ScrumMaster, removing impediments
  6. The Power Lifting competition is not a unique event with a long lead time – working software every sprint, TDD, XP, continuous integration and release

Now the lifter, like our Scrum team, gets to plan, experiment, and deliver often.  The overall roadmap (Lean + Scrum) might have a basic end-game or vision (increasing 1-rep competition max performed on 3 lifts the same day is equivalent to convergent product delivery), but planning only looks forward up to 5 weeks, commitment at 1 to 2 weeks.  Likewise, the lifter and coach is always looking at the most recent data, the newest lessons learned, and quickly reacts to whether a behavior, practice, or process should be continued or not – just like the Product Owner, ScrumMaster, and Team are always planning and executing based on the most recent market and team data.

Applications to the SDLC:

Now we can extend the metaphor and draw conclusions.  The powerlifter’s body equates to a complex large-scale digital portfolio.  The lifter needs to increase value three programs that focus on convergent product delivery while also developing several programs that utilize emergent product delivery.  In waterfall these two program methods are separated by functional division and project lifecycle, in conjugate (Scrum) these two are handled in tandem.

For the powerlifter, the three convergent products are squat, deadlift, and bench press.  Quality must stay constant or the increase in value does not qualify.  The same is true in software products – adding a high-value feature while allowing a 50% increase in crash on launch is absolutely unacceptable.  Your users will disqualify you!  Whether your have a three-application enterprise CRM program or a three-iOS app consumer program (see LinkedIn or Facebook as examples), adding an exciting feature to an app that causes mass user drop out is a risk no business can tolerate in today’s market.  The competition is too fierce, barrier to entry too low; someone will blow you away.

At the same time, the powerlifter needs to maintain several emergent delivery programs, some for function (increasing grip strength), some for fun (increasing bicep size).  Ongoing workout plans, building size, stamina, and maintaining joint health, addressing weak points by focusing on a new accessory exercise for 5 weeks – all of these priorities must be balanced and evolved.  Keeping a workout log is the only way to be sure that exercise volume, intensity, and density are increasing.  The relationship between the convergent product value and the emergent product investment is the only metric rationally applicable.  The same is true in software delivery.  Emergent-delivery programs like R&D, marketing, UX, product planning are all critical to the health and success of the portfolio as a whole – but the end goal must be clear.

  • Over-planning and under-delivering is not acceptable.
  • Over-researching and under-user-pleasing is not acceptable.
  • Over-designing and under-testing is not acceptable.
  • Over-marketing and and under-releasing is not acceptable.

Conclusion:

The Conjugate Method as an analogy for Agile, Scrum, XP, and Lean at scale works for me because I love lifting.  I realize it may not be right for you, especially if neither agile or weightlifting are familiar territory.  So, like everything, find how this applies to your life so that you can find inspiration in ordinary – then start a conversation about it.  I’m happy to discuss anytime:  224.223.5248

Mike Cohn’s Opening Keynote: “Let go of Knowing”

Leave a comment

Special thanks to Mike Cohn, who did a great job kicking off the Global Scrum Gathering in Phoenix, AZ with his opening keynote, Let go of Knowing: How Holding onto Views May Be Holding You Back.  It set the tone for the week and opened up my mind for gathering new perspectives!

Overcoming biases, challenging the assumptions we bring into conversations and new opportunities, and admitting when our beliefs are proven wrong – this is the Intellectual Humility at the core of being agile rather than doing agile.  Scrum is not a best practice in itself, it is an empirical method for finding better “next” practices.  Cohn quoted one of my favorite philosophers on the virtue of intellectual humility:

“In the case of any person whose judgment is really deserving of confidence, how has it become so? Because he has kept his mind open to criticism of his opinions and conduct. Because it has been his practice to listen to all that could be said against him; to profit by as much of it as was just, and expound to himself, and upon occasion to others, the fallacy of what was fallacious. Because he has felt, that the only way in which a human being can make some approach to knowing the whole of a subject, is by hearing what can be said about it by persons of every variety of opinion, and studying all modes in which it can be looked at by every character of mind.”

– John Stuart Mill

The rapid feedback loops we strive for in Scrum are meaningless if we are unwilling to revisit our assumptions and beliefs.  The agile frameworks and philosophies we explore and promote – with the goal of building a complex product more efficiently and effectively – are intended to create a safe-to-fail environment, not a fail-safe system.  Not only do we need to encourage this mindset in our organizations so that our teams are free to experiment, we must be the example in this and admit when our assumptions were incorrect.  Process stability allows us to effectively measure data, but process rigidity is likely to ignore metadata.  Cohn gave some great examples of ideas held by agile thought leaders that did not stand up to to the test of time:

  • Ron Jeffries has abandoned estimating completely after doing it for many years as part 

  • Ken Rueben once argued the ScrumMaster should NOT be a team member, but now believes it can work

  • Robert Martin was a complete skeptic of TDD when he first heard of it until he tried pair programming

While we joke about “Scrum, but” companies (e.g. “We do Scrum – but we only test every third sprint”).  Mike put things nicely into perspective, setting a great tone for the week:  Scrum was born through companies that were essentially “waterfall, but…” companies.  As in Art and Literature, it took a new era to name the previous era, but Agile, Scrum, XP, and Lean all evolved over time.

“In science it often happens that scientists say, ‘You know that’s a really good argument; my position is mistaken,’ and then they would actually change their minds and you never hear that old view from them again. They really do it. It doesn’t happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion.”

It was fantastic to start my week with this mindset, looking for new perspectives and challenging my beliefs along the way.  I picked up a few non-core-Scrum tactics along the way.  The only way to stay innovative and keep improving is to risk the possibility of proving yourself wrong along the way.