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

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!

Are Robots Stealing Our Jobs???

I interview people at all levels of an organization during a Digital Transformation. Since the business case for transformation assumes lean process improvements, I have two goals:
– Make the information that runs the business into data a computer can “understand”
– Replace the non-human, monotonous tasks related to information with computers

To give away the ending here – the robots aren’t taking over. When I am done, all the social context, human relationships, and important judgement calls are still human-made. What we change is how quickly the mundane data-massaging, tiring research, and waiting between email chains that delay all of those human decisions. So I have a goal when I start interviewing: remove inefficiencies and make existing workflows more scalable. This implies automation.

One key thing here: nothing your business does is just chaos. I absolutely spend more time convincing people that an algorithm can capture the complexity of what drives decisions than I do formulating the algorithm. No matter how loosely controlled or gut-feel driven the decisions are, once a business grows into the 100s of employees, I can represent most of your processes with an algorithm. I could even replace the important human decisions with another algorithm that would succeed within a reasonable margin of the average employee, but that’s too risky. Instead, we make notifications and intuitive user interfaces to let one person make the same important decisions 10x or 100x as efficiently, making everyone more scalable. Don’t lay people off. Make it easy for them to increase their value-add.

Interestingly, there is a powerful cultural influence in these conversations due to the mistaken belief that “automation” somehow equals “artificial intelligence” – when what it really means is “fairly basic math equations tied together into one big powerful formula”. The intelligence is completely human-created, human-programmed, and human-managed. So I inevitably but happily show it works prior to convincing someone it works, because depending on their place in the company, the idea of automation replacing humans can be an ideal direction loaded with false optimism or a terrifying slippery slope where unrealistic pessimism prevails.

Both cultural perspectives ultimately distort the conversation.

In its really old roots in the Toyota Production System, the introduction of an “ejector” was a huge benefit to the safety, well-being, and efficiency of a machine worker. Before the ejector, a worker would carry a part to a machine that had just finished its task on a previous part. The employee would put down the part they were carrying, take out the previous part, pick up the next part to put it in the machine, then pick up the previous part. With an ejector system, the machine gets the previous part out of the way so that the worker just walks up and loads the next part, then takes the previous one, checks it for quality, moves it along the line.

Think of all your manual spreadsheet updates, paperwork, phone calls, and email chains just like that. You’ll still check the output for quality before passing along information or making a decision, but automation, notifications, workflow rules, and algorithms can save you a fair amount of your pain by pushing or ejecting what you need when you need it (keeping it out of your way the rest of the time).

This makes the value-add or revenue potential of every existing Customer Service or Sales or Marketing employee scalable beyond what additional hiring can accomplish. Lean Process automation doesn’t mean replacing all operations with an AI. This is the foundation of “Autonomation” – where a worker no longer manually labors at one machine, but becomes a manager of multiple “machines” – multiplying the value-add per employee. Replace the painful, slow, or unnecessary steps with a computer, while keeping the human element – the important decisions, the social context, the gut feel, human.

My First MVP.

Notice the blank spaces.  Notice the technological wonders that – despite my imaginative artist-engineering mind, you’d never actually see.

Tentatively Entitled – ShareLighter

Product Vision

Do you love reading physical books, but wish it were easier to share the insights you’ve gained and quotes you love via social media?  

Value Assumption

People want to share quotes from physical book pages with virtual highlights, blackout, or underlines as a form of expression. Someone – somewhere – in the fantastic conversations that grow from this narrative of noting, quoting, and sharing, wants to pay to be a patron for this game of reader-response, learn it and share it, cultural-criticism-gone-viral.

Growth Engine

Viral. People will love the app enough to share it with two or more friends. 

Success Metric

Viral coefficient, tracked by release version cohort analysis. If the viral coefficient is increasing, the cohort is correlated with the newest features, indicating they have tentatively proven their success hypothesis. 

Minimum Viable Product

To establish our baseline, we need the core functionality of taking a photo, highlighting text virtually, and sharing the photo with a caption to a social network.  To track our success, we will need an “invite friend” feature and the ability to correlate the act of inviting to the version of the app. 

“Blue Sky” Potential Features

You’ll have to see the Trello board…

Do you care?

You have other ideas, because you want this app too, right?  @mention me on Twitter for glory or shoot me an email. andrewthomaskeenermba@gmail.com 

How to Lose the Innovation Game

How to Fail at Agile, Ruin Your Culture, and Lose the Innovation Game

Cover photo via Andrew E Weber

There is one major issue that – if not properly addressed – is going to kill your company.  In fact, many companies FAIL MISERABLY when trying to break down silos, increase collaboration, and begin competing as a culture of innovators.  Every company must innovate or die.  Every product will face competition from a connected variant supported by a mobile app.  Mature enterprises who have never competed on innovation before are now suddenly competing with innovative tech companies!

Tearing down functional silos so that solution-oriented, self-contained, fully-functional and ultra-innovative collaborative teams is now THE biggest overarching challenge that will make or break enterprises that are struggling to maintain their decades-old success and strategic position.  Moving to agile in maturing industries, that are now being utterly disrupted, has become unavoidable for most companies.

The most common label for repositioning to compete on innovation is “agile” and breaking down silos is labeled “agile transformation”. 

There is a major failure that is gradually breaking many companies as their agile and high-tech endeavors fail miserably.  This is issue is caused by executive leadership’s denial and insecurity to face the terrifying reality that to truly “break down silos” is NOT (exclusively) a process transformation or change management issue.

Ready?

Here it is:  Breaking silos REQUIRES organization restructuring.

This major issue is two-fold and occurs simultaneously:

1. Failing to have “tech” report to “business”

2. Failing to have “business” people report to “tech”

There is an unwillingness to break apart and completely restructure the separation of “tech” disciplines and “business” disciplines, despite the growing number of roles that are impossible to clearly classify as one or the other.  In the sad but traditional approach massive enterprises take in the face of a major strategic decision, many companies are attempting a straddle-the-fence strategic position by attempting to leave their existing antiquated structure intact while building entirely new divisions modeled on the structure of successful tech companies.  This is likewise problematic – to succeed at this, revenue growth must accelerate enough to both maintain the old organization while building the new division(s) and the corporate efficiency gains of sharing administrative and brand resources means the new groups will adopt many of the dysfunctions of the old organization.  To the extent this is a Zero Sum Game played out against other competitors and multiple competitors are attempting this simultaneously, no one is likely to “win” the game.

What is the problem?

Let’s look at the first hard lesson facing companies attempting to compete against innovation-base startups and high tech for the first time.  They bring in consultants to help them break down silos, communicate cross-functionally for the first time, and establish a shared vision.  They bring together teams across various business functions, bring in agile coaches, and try to get everyone to collaborate.  They bring in vendors who seem to be better than them and try to “copy their homework” so to speak.  With enough cash, they may even implement widespread training and certification and bring in new employees who are from flat, agile, startups.

The problem that companies introduce when they do this, at any given level of the organization:  without restructuring, there is a “business” and “tech” person set together in equal standing.  If they get it down to two, that is an accidentally triumph.  It is more likely a three to four person group representing a) marketing/sales b) technical leadership c) requirements and project management d) creative design.  There is no clear empowerment for any of them, because mentoring, performance review, and promotion or disciplinary power are all linked to other pieces of the organization.

This diffusion of responsibility was the failure of waterfall in the first place!

Attempting to preserve a forced distinction between “business” and “tech” as well as the hierarchical position of leaders, then forcing “equals” into a nightmare arranged marriage on a per-project basis is a recipe for a slow but unmitigated disaster.

Taking a step back to “Core” Scrum

In software development today, virtually every high tech, innovation-based company is delivering products with some mix of agile values, Scrum ceremonies, Lean improvement efforts, and XP best practices.  While companies may call their process Agile, Scrum, Scrumban, Kanban, etc – let’s talk generically about “core” Scrum and why it succeeded where “waterfall” failed.

Our imaginary “Core” Scrum team is a small startup with a visionary leader who is a fantastic mix of technical proficiency, business acumen, and management skills.  We’ll call this person the Product Owner but in remember, this is the CEO, product manager, and sales-plus-marketing all at once.  For simplicity, everyone else in this company of about 12 is part of the software delivery team (all other roles like accounting are outsourced).  They are The Team, and one of them is the Scrum Master who keeps the process of delivery rolling smoothly, constantly challenging everyone to collaborate more.

That’s “Core” Scrum in a nutshell:  The Product Owner is roughly 50/50 split-focus between the Team and stakeholders, the Team only needs to converse with one voice of prioritization, and the Scrum Master keeps this one small group on-time, ever-learning, and un-impeded.  The CEO owns the company, its only product, and all stakeholder relationships (investors, customers, end users).  This is “pure” Product Ownership – the entrepreneur “lives and dies” by the sword of her decisions because the power, responsibility, and accountability for every promise and decision is firmly on her shoulders.

The purity achieved here is simple to understand:

the company role and its associated place in the superorganism’s Prestige Economy is perfectly aligned with the project role.

The Scrum Master manages no employees and builds culture, collaboration, and keeps the Product Owner’s relationship with The Team healthy and strong.  If this were a highly technically complex product, the ScrumMaster could be a very experienced architect who is can assist in code quality decisions, pair-programming to overcome tough coding challenges, and resolving any risks to the long-term sustainability of the code.  In an extremely technically complex engineering environment, it would make sense that this (dare I say) Architect is a thought-leader but not a people leader.  This Architect knows all of the code and is on speed dial for production issues.  The strength and trust it takes to successfully push the CEO to prioritize refactoring over new features, hardware investments versus new hires means the Scrum Master must be a right-hand-man to the CEO but have no agency dilemma or conflict of interest in making certain the CEO (Product Owner), the Team, and derivatively (via total process quality) the Product are at any given time healthy.

Naturally, we can assume a different but very valuable breed of Scrum Master is also possible.  If we imagine a software product where technical uncertainty is easily handled by an experienced team of engineers but the business rules are extremely complex, a business analyst may be the perfect Scrum Master insofar as Backlog Decomposition and the precise details of User Stories will require a business person with the Product Owner on speed dial who can resolve every business rule uncertainty.

Just like our anecdotal Product Owner, we see in each anecdotal Scrum Master, due to the nature of the product, the company role and the project role are perfectly aligned.

Scaling vs Scaled

This simple paradigm is compelling due to the clear accountability and laser-sharp focus  that makes it successful.  With the single, properly-sized team described above, it is easy to understand why it works and how emulate it.  Confusion tends to set in as the number of contributors and teams grow.

There is an important distinction to make between scaling this pattern and implementing the pattern at scale. 

Continuing our narrative about this successful “core” Scrum team, we can imagine the company grows organically as the product becomes increasingly successful.  Revenue is great, margins are fantastic, and more engineers join.  It becomes clear to the CEO (and Product Owner) that second product would be a perfect strategic fit.  The product, focused on different niche in a similar industry will leverage the skill set of the engineers, design patterns, and the libraries and APIs that have been built over time.  Stakeholders are excited, ready sign on the dotted line.  The engineers are thrilled.  As a group, they decide to split into two teams, each focused on their product.

This Scrum implementation has begun scaling.

The shared code and strong culture combined with the mature agility and engineering best practices allow the ScrumMaster to happily work with two teams.  Unfortunately, the CEO is now  splitting time roughly 20% stakeholders and 10% team on product #1 while 40% stakeholders and 30% team on product #2.  Days get longer and attention to the backlog is suffering.

The CEO is no longer effectively owning either product.

Her trusted colleague, the ScrumMaster talks through the risk of “Hero Scrum” and the need to delegate, and the risk of poor feedback or lack of actionable backlog when more engineers and another designer will be joining in the summer.  There is demand to have the APIs and an SDK consumed B2B.  The decision becomes clear – two experienced Product Owners are hired, one to manage the consumer apps Scrum Team and one to manage the B2B cloud platform. 

The CEO sees that leading the company’s strategy, defining new products, and the need to build a brand, while mentoring the Product Owners on great management of their categories and teams is her new “job role” and “project role” – it evolved organically, and the two still align perfectly. 

This is a happy company.  More products follow, and while not all of them are an instant success, the values, vision, and identity stay strong.  Camaraderie, disruptiveness, and culture of innovation keeps this company profitable at-scale, through a constant assurance that the job role and project role, whether a Jr. Developer or a Marketing Specialist, are always properly aligned.  People are asked to own “one big thing”, empowered to succeed, and held accountable.

Paternalism and Guild-based Hierarchies

If you work at a large company and this happy anecdote sounds ludicrously fictional, it is because implementing agile in a scaled environment – whether due to the success of an isolated team or a management decision to copy Silicon Valley – rarely looks like this.  Large enterprises in mature industries were born out of organization and management practices dating back to the British Empire and the industrial revolution, and function-based guild preservation that began in the Dark Ages. 

Blacksmith best practices evolved, certainly, but not so fast an entire practice community couldn’t keep up.  The capitalists in the industrial revolution could invest in a few big innovations, paternalistically demand new behavior from a new “guild”, and reap benefits for decades. 

Marketing, even as the internet bubbled, consumer product research and development despite the worldwide adoption of desktop computers, and a whole guild built around Information Technologies did not disrupt this proud history of dividing the troops into functional units held together by rules, history, and strong paternalistic leaders.

Transforming Project Roles While Preserving Job Roles

The United States Military is realizing, unit-based combat in an urban setting full of emerging demands and uncertain risk.  Cross-functional teams are being built tactically insert their blend of skills into situations that require empowerment and responsiveness.  The days of marching pikemen and flanking with cavalry are gone.

Enterprises are realizing the same is true of innovation-based product markets.  A level of guided group-think is needed to courageously build an innovative product for a still-emerging market segment.  The capacity to “lock everyone in a room” that you need, and risk market and technical uncertainty requires executive mandate and tenacious teams.  Limiting investment to two weeks of team effort at a time, fierce concentration, no politics, and freedom to experiment are essential.  This is a creative process that requires adventurousness and tenacity.  Let adults succeed and celebrate or fail and learn.  Otherwise management is simply holding back the potential of their most brilliant engineers.

To do this, one thing must happen above all else.  The job role must perfectly align with the project role.  If job descriptions align to guilds, as a talent “pool” of human “resources” to get allocated like widgets in a managerial accountant’s spreadsheet, the project – which is intrinsically finite will always suffer.  The job is linked to performance and salary. 

Predictably, people behave like a faceless number on a spreadsheet when you manage them (and pay them) that way.

The move to “agile” is in large organizations is nothing more than an attempt to move to a company that has established a culture of innovation as its sustainable competitive advantage.  The four cultural choices are simple to understand, but they inevitably fail without a strategic mandate from executive leadership, and the “blessing” to fail when overcompensation in the effort to change occurs.  As a leader, tell your people these four virtues are the key to success and back it up in your daily actions:

Collaboration Focus  Put all the right people in seats next to each other, tell them they have one goal: unlock your full potential by learning from and investing in your team as you solve tough problems.

Product Focus – A project is finite, a product is a living platform for an ongoing conversation.  Build a dialogue, tell a story, and leave a legacy.  Do you really want to control your budget and schedule, or do you want to change the world?

User Focus – The ideal information symmetry cycle:  The user Tweets a feature they want, the team codes it, knowing exactly what the Story means to the User, and the user has it in-hand within a month.  The further you alienate the producers from the consumers, the more wasteful and less innovative your organization will be.

Innovation Focus – Taking risks and learning from mistakes is mandatory.  Encourage it and live it. There is infinite content available and your well-formed team’s natural curiosity are their default state.  If they aren’t innovating, you’ve burned them and overburdened them.  Give them some slack and encourage their interests – you’ll be amazed what the unbridled human accomplishes.

Issues At-Scale:  Agency Dilemma

At scale, reorganization – not just redecorating – is going to be critical.  There will be politics to deal with.  It will take immense courage and backbone as a leader.  Middle managers will be your biggest problem until you change the seating chart and pick the right people for those seats.  Agency dilemma from the guild-based job hierarchy will ALWAYS impede the success of cross-functional teams.  Functional managers encourage non-collaborative activity.  Over-documentation.  CYA.  A lack of focus on the team and product. 

Why is this so prevalent? 

It is not simply the change management of restructuring, changing number of direct reports, flattening the organization – that is all incredibly well-known turf for large, established enterprises in mature industries.  The new political problem is two-fold and pragmatically simple:

1. Failing to have “tech” report to “business”

2. Failing to have “business” people report to “tech”

Unfortunately, the politics of putting previously separated guilds in charge one another is  not the root cause here.  You could put an abstract painter in a direct management position over a cross-functional software team so long as they had the skills to lead them to success and prestige.  Instead, it is a symptom of leadership not understanding the team-product-user relationship.  In “core” scrum described above, this was simple.  The start-up was built around it.

How you should restructure, once you “get” it, would be fairly simple: If the user has needs that are solved by a product that will need a team that must overcome technical uncertainty first and foremost – a more technical manager for that product team makes sense.  If the user has needs that are solved by a product that will need a team that must overcome market uncertainty first and foremost – a more business-savvy manager for that product team makes sense. 

In other words, when an old business problem can be solved by new technical innovation, let an engineer lead the cross-functional team.  When an old (enough) problem can be solved by technology by changing the complex business problem (think finance) – put a subject matter expert as the team manager. 

If the multiple products fit into a “category” where the users are likely to consume multiple products, scale to a director who can set strategy, build a brand, and ensure cohesion.  This person will likely be a mix of skills so significant that designating them “business” or “tech” simply makes no sense. 

Diffusion of Responsibility

This brings us full-circle back to the reason why organization restructuring needs to occur at all – multi-bossed employees are easily distracted.  Too many leaders goes hand-in-hand with sharing resources.  No one knows what any given employee is doing while no employee is terribly confident which leader to follow.  In a guild-based system, they fall back on their functional allegiances and their job description.

When you make an engineer (with experience taking new products to market) the direct manager of a cross-functional, self-contained product team that can collaboratively handle business+tech roles needed for a highly technical product – planning, design, engineering, quality, and marketing – that manager has a pulse on what everyone is doing and everyone knows who to go to when their workload gets too light.  The same is true if this manager is from a business background.  The end user is well-known, the backlog is simple to build, and the product is the professional focus of everyone in the room. 

This independence and focus is the building block of a culture of innovation.

Shared resources and functional guilds perpetuate agency dilemma, information asymmetry, and diffusion of responsibility.  Kill it by restructuring before it kills you.

Scaling Issues: Copying Enterprise Dysfunctions

To be thorough, this is not exclusively an issue faced by enterprises shifting to innovation and high-tech at-scale.  Growing from a startup to a mid-size company and beyond means personnel growth and collective skill-set via true talent acquisition.  However successful a small company was at innovation through collaborative, cross-functional problem-solving, pulling in new people is incredibly dangerous.  The temptation is fill in the top and middle with highly experienced managers and individual contributors.  Enough new hires with more than a few years experience inevitably bring with them the “baggage” of their guild-based past and the political self-protection of the toxic culture they left behind. 

If you are currently scaling, learn from the issues facing scaled transformation and protect your culture, mission, and values from the threat of new and toxic influences.  Grow teams into categories, categories into industries.  Agency dilemma, information asymmetry, and diffusion of responsibility are the inevitable dysfunctions of a company that loses its sense of identity by growing too fast through acquisitions. 

First of all, grow from your bench.  Being a small company is no excuse for constantly showing employees they will never progress in their career by hiring knowledge and leadership from the outside.  Second, when a subject matter expert can only be acquired, it makes no sense to put them in a leadership position as well – they need to spend their time educating the organization. 

To succeed in scaling a small culture of innovation, keeping every person at every level fully focused on their end user, their team, and their product is the only path. 

5 Reasons I Would Fire You

Originally posted April 2016. 

Disclaimer: I currently work solo on this blog and could only fire myself – so this isn’t veiled threat.  I have done my best to mentor individuals and lead teams aways from these dysfunctions; and disrupt processes that perpetuate them.  These are also part of my personal introspection process.  This is not an accusation of anyone  in particular.  Instead, these are traits we can all continuously work to improve.  On the other hand – “You’re so vain, I bet you think this song is about you.”  

The Top 5 Reasons I Would Fire You

Tech professionals on teams trying to innovate:  Speaking on behalf of managers, your peers, and individual contributors everywhere, these are the top five reasons you aren’t just a poor performer, you’re bringing down the people around you as well.


Reason #1 – You Default to One-Way Communication

Collaborative problem solving cannot happen without meaningful and timely feedback.  There is a time for group chat and a time for well-argued prose (email).  To avoid death-by-chat and long CYA email chains, you need to set clear expectations about when you need to focus and when you can discuss issues – and respect that prerogative in others. 

Whining about documentation, instructions, or a process as document brings you no closer to a better workplace experience for yourself, improved team health, or a product you can feel a lasting pride, prestige, or sense of legacy about.  Bring a solution to the table, own your responsibility for following up, and escalate to a scheduled meeting if needed.  Folding your arms and leaving work unfinished is childish.  You know you can do better – do it.

Mantra – There are no documentation problems, only communication problems.


Reason #2 – You Repeat the Same Words When I Say I Don’t Understand 

Speaking of childish, self-advocacy is an important milestone.  It requires enough vocabulary, understanding of abstract concepts, and recognition of similarities and differences to allow a child to not only imagine a future state that is desirable, but also solve the most likely path to attain it, and make a rational statement to an adult who can permit, empower, or provide.  My three-year-old daughter, forgivably, needs an enormous amount of assistance, and patience, when she attempt this.  As an adult, you should not.

As a leader, I will do my best to bridge the gap between your words and my words.  I will cue you when I am unable to build that bridge, repeat back to you what I understood you to say, and ask you to demonstrate or show me where and what you mean so that I have the context I need for a deliberate and logical decision.  I will do all of this without patronizing you, even when it is mentally exhausting for me.

Not everyone has learned to lead this way, and I admit I can be imperfect at it as well, so you absolutely need to learn to self-advocate.

That said, I cannot heroically be an adult on your behalf.  The real dysfunction that brings down team performance through your own sub-par performance is the continued repetition of the same words when I (or others) explicitly ask you to re-word the request, argument, or question.  You are obstinately anti-try-something-else.  You refuse to paraphrase, assist my incorrect understanding, or demonstrate the meaning of your words.  It is only through my strong personality and insistence that I convince you to show me exactly what the problem is so that I solve it rather than answering a question that sounds like utter nonsense out of context.  Unfortunately, even that is not always effective.  I can carry my pre-school daughter to the cabinet and let her pick the exact afternoon snack she wants.  I cannot “carry” you as an engineer into a realm of creative solutions where emerging technology and emerging market segments meet.

Mantra – Communication is the responsibility of the communicator.


Reason #3 – You Feel No Pride of Ownership Over Your Work

Having coached, worked with, or heard the complaints of hundreds of tech-focused professionals in various, I have found this can often be more a symptom of the dysfunction of an organization than the root cause of poor performance.  The tech industry today is too mentally demanding and excitingly disruptive to attract genuinely lazy people, looking for a free ride.  So when you start giving into distraction, procrastination, or laziness, my leadership spidey-sense goes off.  I will tell you the secret to motivating innovation-based technical teams – empower them to know the impact a line of code will have on an end user. 

Karl Marx’ philosophy describes this exact phenomenon in its examination of the individual worker’s separation and alienation from the product.  Superficially, the question seems quite simple:  Which is more rewarding, a carpenter who makes custom-installed wooden shutters, getting to know the customer, their home, and tastes in the process, or working in a factory running a machine that produces millions of shutters for a big-box store’s generic one-size-fits-all product line?

If you have lost pride of ownership over your work as a software professional, though, shame on you.  You have no excuse for complacence, apathy, or becoming disengaged.  Your skills are a premium product in a seller’s market.  Companies of every size will fight to win you to their side. With one idea and a few colleagues, you could start a company of your own in a heartbeat.

Now, let’s be adults here.  We all have to collaborate and negotiate.  When the majority or a manager makes a call that goes against your individual dissenting opinion, don’t stomp away and pout.  Losing pride of ownership over work, and settling into a free-rider paradigm brings down the team, the product, the end user, and your career.  You better woman-up or man-up and either do a great job that you can be proud of, work to change the organization that is stifling you and your peers, or move on.

Change takes courage, but our virtue is the outcome of our habits.  When you accept and justify your childish, dysfunctional, lazy, sub-par effort and excusing yourself through an external locus of control hurts no one more than you.

Mantra – Anything worth doing is worth doing well.


Reason #4 – You Hide Behind Uncertainty

Deconstructionism is a dangerous game, especially when you are part of a team that is teetering on the edge of a cliff overlooking the seas of chaos, moments from falling into market risk or technical risk that could engulf you.  Since I coach teams on how to become a room full of adults solving the pains of a real person through a collaborative, unified, inspired collective brilliance and sheer power of will, I have a radar for someone  who is hiding. 

You are playing a dangerous game.  You signed up for this, after all.  You wanted to be brilliant, in the thick of it, defining emergent market segments using emerging technologies – but the minute you lost faith in the cause, lost hope for your job security, or lost belief in yourself as a builder and creator of new tech that can change the user’s world… that was the moment the inherent uncertainty of our goals became apparent.  You shut down.  You got stuck.  You became intolerant of technical risk AND market risk and looked to your leaders to spoon-feed you.

At first, a good leader can give a big speech, host a team-building event, or roll up the proverbial sleeves to help.  When the team as a whole needs some slack but they still have their eye on the prize, I have a long list of tools and tricks to re-energize the whole team.  When an individual begins the process of deconstructionism, and moves every conversation into an infinite regress in which the certainty of any word or any intention or any risk is now more important than the product discovery process, that’s when a tough love heart-to-heart happens.  Agile demands small increments.  Innovation requires trial and error.  You must remain infinitely curious.  You must self-advocate for the size of the risks you take.  Escalate when time-to-feedback is hurting you.  Sturdy yourself and your tenacious attitude about the “failure” intrinsic to empirical discovery – otherwise you don’t belong in this work space.

Mantra – Fail fast to succeed sooner.


Reason #5 – You Give Up Before Attempting to Solve a Problem 

This issue if often comes hand-in-hand with insecurity toward uncertainty.  When it comes to coaching a product visionary in agile, this means whipping them with the importance of setting goals for the product, an end user to empathize with, and a pain to solve in the target user’s particular context.  Once that is in place, a team – as a whole – may need some encouragement that a 100% success rate is not the goal.  Innovative, defect-free software that fits the user’s needs is the goal.  As it turns out, some people fear failure too much to risk it.  If that’s you, make sure you are in the least innovative technical space possible.  Sink your teeth into a legacy system and never complain about the spaghetti code you manage again.  That slow-moving space is perfect if you prefer to play it safe.

Innovation may not be important to SOME people, but it is VERY important to the REST of US.  The courage to risk failure is essential to experimentation. 

The real issue, of course, is not the fear or the failure.  It is a lack of proper perspective that puts your short-term ego ahead of long-term viability.  It is a base rate logical fallacy in which you are ignoring the most important variables.  Pretend for a moment that we have a product for which any given User Story – which we’ll restrict to less than two weeks of effort to get from planning to production – has a 70% chance of success (completion in two weeks) due to technical uncertainty and 20% chance of success due to market uncertainty (i.e. “is it really what the end users need?”).  If you take the risk of a false-positive – succeeding in releasing a working product increment that the market doesn’t demand – as the only indication of your own failure, you are sure to be unhappy. 

Now, imagine a breathalyzer has a 5% probability of a false-positive.  A police officer pulls over drivers truly at random at a random time of day.  What is the probability that a driver who tests positive is actually drunk?  Guess what!  A dreadful 2% chance.  Luckily, officers are trained not to play the odds like that.  The time of day, the day of the week, the location selected, and driving behavior all weed out the risk of a truly random selection.  Then recognition of symptoms, through human interaction must give probably cause. 

When you stop trying to overcome technical risk or market uncertainty prior to even attempt to solve a problem, you’re like a cop who stops pulling over anyone due to the statistical uncertainty of a false positive.  If you attempt to solve 0% of the problems you face, you’ll come away with a 100% lack of solved problems. 

Tackle 100% of the tough challenges tenaciously, courageously, and look for an assist as needed.  Anything else makes success incredibly unlikely.  The market risk of success is hard enough.  Don’t ruin the odds further by quitting in the face of technical risk.

Mantra – You miss 100% of the shots you don’t take.


Grow Up or Move On

If these sound like you, work to grow as an individual or you are likely already on your way out the door.  If you, your peers, and even your manager exhibit these traits and the organization seems unlikely to change despite a heroic group effort – it’s time to move on.  Complacence, apathy, and passive aggression is terrible for your career.

I’ve taken to saying, “Some people just want to watch the world burn – the rest of us build it anyway.”  If you aren’t a builder, at least stop burning down what the rest of us will happily accomplish with you.

Metrics: The Good, The Bad, and The Ugly

Metrics and the Superorganism

“A foolish consistency is the hobgoblin of the small-minded.”

– Ralph Waldo Emerson

Metrics are frequently the greatest challenge managers and executives face. The vast majority of companies are so bad at defining metrics below the highest possible level (e.g. standard accounting KPIs) that they would be better off with no metrics at all.

The worst possible approach to performance metrics is constantly changing them. However, when executives lose their sense of company “proprioception” they look for easy to digest numbers they can be provided as a substitute for regaining an understanding of the organization.

“Managers who don’t know how to measure what they want settle for wanting what they can measure.” – Russell Ackoff

In my next few posts I’ll build off the idea that metrics can be the mental “cue” that compliments the proprioception of the executives of a superorganism (the company). In weightlifting, maximizing force and controlling process function often requires “cues” – proprioception is a complex system to interpret and control and the Central Nervous System doesn’t take direct orders from the lifter’s mind. On the squat this means a coach may say “Back on the heels!” or “Screw your feet into the floor.”

Metrics are just like this when used correctly. Naturally, my focus will be on agile software development in an environment with scaling issues – but the relationship between employee motivation and company outcomes holds true across every for-profit superorganism.


 

Process Control Methods

Six Sigma is a Statistical Process Control methodology. Using a Statistical Process Control methodology is perfect when the process environment is stable and the goal is static and repeatable and known before the opportunity occurs.  As a rule of thumb, if planning is done up-front and the same product is built repeatedly, statistical process control will have meaningful metrics for throughput. Imagine one automated drill in a factory that produces billions of parts per year. The holes drilled are one step in an easy-to-view process and performance is simple to judge – the holes must be within less than a .02mm of variance or other steps in production may fail and the overall product will be unacceptable.

However, software development is not like this at all.  The business context, market expectations, tools, and process environment are in a state of constant evolution, so an Empirical Process Control methodology (some combination of agile, Scrum, Kanban, and XP typically ) is needed such that that the process gathers and inspects short-term results after they have occurred to inform the next set of short-term adaptive goals. A single engineer writing code, due to the unlimited number of possible demands and her/his nearly unlimited paths to supply each demand has a virtually infinite potential to succeed or fail and the throughput process has zero visibility.


 

Control Metrics vs Performance Indicators:

While the visibility and the tangible nature of throughput makes it possible determine the relationship between statistical process control metrics and company Key Performance Indicators, the continual change inherent in innovation-based software makes empirical process control metrics more difficult to tie out to KPIs. This is because accounting metrics are statistical in nature based on the consistency or predictability of the value of the currency being used and stability of the institutions assuring the long-term meaningfulness of the accounting measurements.

In other words, the success of statistical process control against a variance of .02mm requires a shared understanding and valuation of the unit of measure “millimeter” just like accounting measures are all built on a shared valuation of the monetary unit of the company. Just like companies can choose to measure in inches or centimeters, most countries currently value exchange rates for currencies relative to the dollar. Currently, the world economy is a faceless superorganism that is cohesive to the exact extent that every individually is mutually self-interested in the shared valuation of the U.S. dollar. Even those who deny the right of the U.S. dollar to play this role live in a world in which their continued engagement in the global economy requires them to interact with rationally self-interested entities that will ultimately compare the non-USD valuation of their currency with the USD-based practices of others.

On that foundation, when you are an executive leading a brick-and-mortar retail chain, managerial accounting statistics are relatively simple to choose.  As an example, retail stores create semi-homogenous shopping environments across sufficiently similar demographic regions, train and compensate based on similar sales techniques, then track revenue precursor metrics: Traffic (customers through the door, Conversion (sales per customer), Items per ticket, dollars per ticket, etc.  Daily statistics give a clear indication of the trend toward longer-term goals.

Similar metrics can be applied to an e-commerce solution to the extent that a high sample rate can give insight into the conversion funnel.  The empirical tuning of these KPI’s has a long feedback loop based on the assumption that missing the target statistic is a failure for which managers can be held accountable and the process can be corrected.  To restate – when a sales team or web site fail to hit a target, the KPI is not immediately put under review because they are based on benchmarks consistent across an industry.  Instead, the sales organization is expected to improve to meet the benchmark.

Note that the KPIs are valuable to the owner of each company (whether a sole proprietor or millions of shareholders) only insofar as they are comparable between two groups or time periods, stable over time, simple (enough for your audience) to understand, and honest in origin (whether trusted or proven). If you analyze enough Annual 10K reports to shareholders, you will note that in addition to the metrics that “everyone” reports you can also report virtually any measure you believe gives a positive and accurate portrayal of the current and future potential value of shares.   A carefully written explanation for each of these is required both in law and in practice. If it is too difficult for shareholders to understand it will likely be ignored. If it misrepresents the value of shares, there are grounds for action by governing institutions and lawsuits by those with a fiduciary interest in the value of the company.


 

What about innovation?

In companies that pursue innovation as a competitive advantage, any “benchmark” is by definition emergent.  The learning organization is constantly seeking out new tools, processes, practices, and behaviors that will lead to a unique product offering, ideally with significant learning curve advantage over competitors.  Unlike the retail company’s use of weekly conversion as a leading indicator for quarterly profit, most innovation-based companies are unable to find a leading indicator for “successful innovation” because the success being pursued has not yet been discovered!

While managerial accounting can trace the market risk of an investor based on quarterly earnings, the innovation-based startup company is often creating supply for a product prior to also creating the demand AND the market for what it will supply!

So, if you do not know your price, your market, your product, or your demand, how can you possibly guide the process of product creation to ensure successful innovation? The executive must:

  • Ensure cohesion around a shared vision and values
  • Ensure the identity and evaluation of a company is consistent enough for isolation of variable in experiments
  • Strip every risk down to its smallest possible impact

This is where empirical process control for agile software development starts to look more effective the innovation-based company.  The emerging next practices are monitored using hypotheses and experiments such that metrics are selected as appropriate to a given learning opportunity.  The problem is tying the Scrum metrics that are meaningful to a team understanding itself now may have no meaning later after they have evolved. Because these metrics are not comparable across teams and not meaningful when compared at one time versus another, they cannot be used as an indication of performance for individuals or the company!

Metrics and KPI’s are still possible, but executive leadership must be careful not to lead the learning organization into non-learning behaviors constrain the innovating company into anti-innovating practices. Note that in the retail store example, the validity of performance indicators tying into accounting metrics down to the store level and the Store Manager is meaningful to the manager. If the associates staffing the store are wage-only earners, comparing conversion by employee is pretty nonsensical. However, if a new initiative like a Loyalty Card is rolled out, incenting employees at Point of Sale for sign-ups can be effective at driving change.

This is an important distinction. The length of time a fast food chain cook keeps the French Fries in the hopper is not a performance metric – it is a minimum requirement. Behaving in a way that encourages sales is a minimum requirement for the store associate. It the manager’s duty and power to be engaged enough to whether minimum requirements are being met and reward, correct, or discipline accordingly. The Store Manager therefore manages toward a company-wide performance indicator while the employee manages their own behavior in a way that ensures continued employment.

H.T Johnson wrote a terrific analysis of the tension between Lean principles and Accounting metrics and supplies this terrific summary:

Quantum physicists have suggested that undisturbed systems in the universe naturally stay in multiple states simultaneously, unless someone intervenes with a measurement device. Then all states collapse, except the one being measured. Perhaps what you measure is what you get. More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.  – H. T. Johnson, “Lean Dilemma”

 

This is commonly called Hawthorne Effect in organization psychology – the moment an organization knows a behavior is being observed, the behavior will change from its natural state (typically to match the state the members of an organization believe to be desirable).  Because time and energy are finite per resource, shifting to a new behavior is always at the expense of another behavior.  This does not mean by necessity that observation should never occur at the enterprise level, it means that every metric must be extremely strategic.

 Moreover, the undisturbed natural state of the system includes the organic self-maintenance of the minimum requirements for membership.   This self-maintaining state is the emergent Prestige Economy of the company as a superorganism.

Metrics that have an impact on the relative value of individuals within the superorganism must be selected as a way to purposefully protect behaviors against change or to drive new adaptation.   In a company where what outcome means success, executives must be that much more careful with metrics because organizational energy will be expended in response to the metric – potentially at the expense of behaviors that will result in future but unknown success.

We can break metrics into three simple categories:

  1. The Good – Metrics that reinforce known successful behaviors – or less-certain but expected to drive success and judged by executive leadership as worth the risk – thereby reinforcing organization attention, energy, and output in the direction of strategic goals; with the known trade-off of less energy being expended on less-important processes.
  2. The Bad – Metrics that reinforce non-priority behaviors often due to leadership not possessing a sufficient understanding of strategic goals and what drives their achievement.
  3. The Ugly – Metrics that shift attention directly into bad behaviors, leaving the process that was being tracked worse rather than better.  These are typically a symptom of systemic co-dependency – the members of the organization see that there is a parent-child relationship, they are misunderstood, and they act out or lie in order to avoid punishment or gain attention from leadership.

 

Measure Strategically

Good metrics can only come from leadership, because only leadership is empowered and accountable for strategic trade-offs.  Know what you want for your organization, what you must prioritize, and what you are willing to sacrifice.  Measure the few key numbers you are certain positively reinforce what you want.  If you find yourself relying on consensus, or measuring in aggregate anything organization members are already measuring for their own purposes, slap your own wrist.  You have failed at leading.

A pilot has dozens of metrics available to her.  In context, many of them are important to a safe and comfortable flight.  You may have noticed that – while Average Aggregate Flight Altitude could be meaningful for scientific research – it is meaningless on an airline Annual 10K.  Many organizations do the equivalent of asking a pilot – “What is the most important metric in your cockpit?”  Don’t be that leader.

This is part of a series!

Part 1 – Metrics: The Good, The Bad, and The Ugly

Part 2 – How to Fail at Performance Metrics

Part 3 – Rules For Measuring Success

Part 4 – Measuring What Matters to Innovation

Throughout the series I tie together ideas from two great resources:

Kevin Simler’s Minimum Viable Superorganism

Steven Borg’s From Vanity to Value, Metrics That Matter: Improving Lean and Agile, Kanban, and Scrum

Strength to Compete

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

FREEDOM: How using Scrum un-impedes our full potential!

Scrum frees teams from the tyranny of the urgent:

A key goal of the Scrum transformation is breaking the parent-child relationship between “business” and “development”.  Technical planning, implementation, commitment, and delivery is in the hands of the team while the Product Owner provides a single priority-order backlog of consolidated items from stakeholders, users, and the developers, for the team to plan around.  Once a well-formed-team finds the right mix of XP and Lean practices (especially continuous integration and frequent releases) the pressure of “we have to do this now” is easy to manage.  If major items frequently pop up mid-week on a “release train” that deploys weekly:

  • The team leaves room in their commitment for these items
  • The Product Owner sets realistic expectations with stakeholders on which release will include the request

This is part of the power of Lean planning for making strategic product and release decisions – once the Minimum Viable Product is in the open market, data from the users can determine urgency of backlog items.  Frequently, this is a point where a pivot is desirable.  Through frequent releases, the users, stakeholders, and the team can relax and look at the big picture, free from the fear arbitrary deadlines and urgent scope “creep”.

Scrum frees teams from the fear of making mistakes:

While the extreme co-dependency that drives the tyranny of the urgent is overcome by putting an end to arbitrary deadlines and poor scope decisions, the fear of making mistakes is overcome through the key roles defined by Scrum.  Note, these are roles and this label is intentional – these are NOT by necessity positions or titles.  As I describe in Why Product Owners? a role is the confluence of empowerment, responsibility, and accountability for One Big Thing that rests on the shoulders of a single person.  Teams are free to voice ideas because the Scrum framework encourages collaborative implementation planning, cross-functional brainstorming, and constant discovery of best practices.  With XP Pair Programming, this becomes even easier as a single screen and keyboard gets two minds and four eyes that can converse on best practices, mitigate against knowledge silos, and build team relationships.  In the end, all of these adults acting brilliant and mature, huddled around a problem still have the Product Owner as the proxy to the users and stakeholders.  The team is free to determine one small solution at a time, just-in-time, and just-enough – then iterate or pivot.  When tough decisions need to be made, the Product Owner makes the call, relying on the expertise of the team, sets expectations, and maintains accountability.  Moreover, the user story – as the building block of incremental product delivery – isolates risk of mistakes to the smallest valuable user interaction and continuous integration ensures that when a new increment is not “potentially shippable” it can be easily taken out until additional iteration is completed.

Scrum frees organizations from business as usual:

When things go wrong in a large Waterfall project, multiple helpless Project Managers ask for updates but are unable to check boxes, development teams are powerless to drive the direction of the product, and stakeholders become progressively frustrated by the unfinished pit into which money is being thrown.  Then they cancel the project!  What is missing here?  JOY!  Menlo Innovation’s Richard Sheridan and author Joy, Inc. describes the importance of team joy in an interview with InfoQ:

There is in fact tangible business value to joy. But understand this: our focus is external to the organization. What we want more than anything else is that the work of our hearts, our hands, and our minds gets out into the world and delights people. That’s our definition of joy. We want somebody to stop us on the sidewalk and say, “That thing you built, I love it. Thank you. You made my life better.”

When I build a new Scrum team, guiding them with the help of my Scrum Master through the process of forming, storming, norming, this is the number one fear I must guide them through:  I say “Yes, the requirements will change.  Yes, what you build today will be modified tomorrow.  What matters is that you are a creator, people will actually use what emerges, and it will make a difference to them.”

The move from cancelled projects to meaningful user feedback has an incredible impact on an organization.  The drive to constantly improve, tighten feedback loops, and evolve through empirical process control will make disruption the norm and remove the fear of inevitable change and new ideas.

Scrum frees organizations from process rigidity:

There are three overarching goals driven by the roles, ceremonies, and artifacts in Scrum:

  1. Notice ineffective processes, workflows, or behaviors quickly and cease them.
  2. Notice effective processes, workflows, or behaviors communicate this knowledge
  3. Recommending new processes or practices that can be tested for the length of a sprint

At the organization level, the same process should occur.  While the empirical methodology monitoring “the process” – a mix of lean, XP, and other function-specific practices – is held constant, the practices that are monitored within “the process” are under constant review at the team and organization levels.

At this year’s ScrumAlliance Global Scrum Gathering in Phoenix, Arizona, I attended a terrific session  “Scrum at Scale – Free yourself from the myth of one-size-fits-all scaling led by Scrum Inc.’s Alexander Brown.  Look for an upcoming post on his argument that Scrum is by definition modular and object-oriented, such that organizations scaling Agile, Scrum, Lean, and XP can utilize empirical process control and a mix-and-match approach to the various frameworks most appropriate to the unique needs of each team.

Ralph Waldo Emerson

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day. — ‘Ah, so you shall be sure to be misunderstood.’ — Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood.

Enterprise Mobility – You and your team need more green time!

As a consultant and delivery owner for custom mobile application development, discussing with people outside the industry regarding the various ways in which people think about “enterprise mobility” is always a great conversation. There are three basic ways the terminology is used:

  1. Mobile Device Management:  Devices and data security management in enterprises environment that COPE (corporate-owned, personally enabled) versus BYOD (bring your own device)
  2. Consumer Marketplace Apps: Consumer facing solutions created custom by an independent contractor (I would typically point out this is not what I consider enterprise mobility)
  3. Internal Enterprise Apps:  Proprietary solutions used exclusively by a single enterprise, in which the operational effectiveness gained with on-the-go, on-demand employee activity that is supported by one or more mobile applications

Let’s talk about #3.  I love enterprise mobility and being a member of the mobile workforce.  I love to build and manage employee solutions for enterprises.  Every day is a good day when I am consulting, planning, and delivering on-the-go, on-demand, notification-driven enterprise user experiences – that is my specialty.  Part of how I stay “in touch” with the users these solutions serve is by finding and using the marketplace and proprietary apps they use, getting out of the office and off wifi, making every effort to be an ultra-mobile worker – and I love doing it!

Worker Mobility

Talking Stick Resort – Scottsdale, AZ

Why do I love being an on-the-go, on-demand employee?  Less screen time, more green time.  As valuable as note-taking can be when it truly captures the full context of what is discussed, I find conference calls and meetings where I have a computer in front of me are consistently sub-par.  So when I have several calls in a row (with no screen sharing), I plan to spend that time at a park or forest preserve.  I love walking meetings – not the indoor kind on treadmills (though I support that option too) – so when I need a one-on-one “meeting of the minds” with a mentor or mentee, we take it outside and walk around.  I go to the gym at lunch most days to give my eyes a break and get my body awake.  After all, I can chat, text, and email as easily by mobile between sets as I can between bites at a desk.  When there is a tough problem to solve, a couple beers and a whiteboard can help a small group hash out a solution better than a chat group.

We are part of an increasingly mobile workforce.  Take advantage of that freedom, encourage it with your peers, empower your employees.  You will see immediate benefits!

Walking Meeting

Illinois Forest Preserve – Chicago, IL


Connect With Me:

LinkedIn       Twitter