Monday, September 17, 2018

Estimation is not an alibi for failure.

Estimation is not a quotation of work.
I spend plenty of time working with people who are just learning about agile and scrum.  The agile reformation has spread worldwide; what it has not done is penetrated deeply into organizations.  Elite information technology teams quickly accept the new paradigm and start to deliver.  Executives and leadership notice and they want to replicate these effects in the organization.  It is when this happens the life of a scrum master gets complicated.  If agile is going to succeed at scale in large organizations leadership must change how it views work.  It begins with accepting all estimations are not quotations for labor. 

Ryan Ripley, a coach, and trainer I respect is an advocate of the “no estimates,” camp of agile.  I have blogged about this school of thought, and I consider myself a skeptic.  I think it is easy for a team to operate without estimating but executives who are paying the bills are horrified when highly paid professionals say they do not have an educated guess about when they will finish work. 

The reality is executives are craving certainty in an uncertain business world.  An executive wants to know the budget is not getting wasted.  Most executives do not understand the technology which keeps their organization workings, so this creates an additional level of anxiety.  Finally, technology is changing so quickly a course of action which made sense at the start of the project can backfire at the end of the project. 

Agile and scrum attempt to solve this by using rapid iterations to build a shippable product which business professionals can then inspect and adapt. It works like a charm, but for larger projects with multiple handoffs between systems, it can create a sense of apoplexy.  Teams are on schedule but with different cadences of work.  Software code on one team does not work correctly with a different team.  Meanwhile, time continues to move forward, and deadlines made without any feedback from the people doing the work begin to slip. 

Estimates are treated like quotes because when deadlines slip executives can point to the faulty projections as an alibi for failure.  Activities such as construction and automotive repairs are easy to estimate because the rules which govern those activities are reasonably constant.  Concrete dries at a particular speed.  A repair shop can replace a tire in about an hour.  The laws of gravity have been steady for eons.  The nature of software development makes it nearly impossible for smart people to provide accurate estimates. 

Multiply this reality over numerous projects which have to work together with tight deadlines and tighter budgets you have a recipe for madness.  The software teams are groping in darkness, and the executive team is demanding some light and direction.  What can be done to break this pattern of insanity?

The first thing which needs to change is executives should understand estimates are not quotes of work.  An estimate is an educated guess at best and a cruel lie at worst.  Software working in production is the only credible sign of progress.  Based on what is working in production a leader can make more informed decisions about what to do next. 

Next leadership needs to fund cross-functional teams.  Often projects are supported, and they have a beginning, middle, and end.  When a project ends the team is disbanded and with it the knowledge to maintain or improve the system just created.  High functioning teams should stay together and given different projects.  A marketing team like this will develop logarithmic expertise and use it to defeat the competition.  If you watch Netflix, I recommend the story of Barbie and the “pink berets,” who worked in Mattel’s marketing department.  

Finally, leadership should accept software development and other complicated projects should resemble the commute to work.  Somedays the traffic is heavy and others it is light.  Construction can cause backups, and occasionally a car fire will create a gaper's delay.  Accept variability of work and try to avoid forcing unreliable estimates into schedules not grounded in reality. 

If executives and business leaders can understand these principles estimates will no longer be an alibi used to forgive failure.

Until next time.

Monday, September 10, 2018

Each Scrum Master and Agile Coach Should Embrace the Weird.

Be Weird!
Being a scrum master in a large organization is filled with contradictions.  The scrum master is a servant leader for development teams with zero authority unless earned.  A scrum master removes impediments to progress and leads to continuous improvement.  It is a mission which often puts the scrum master in conflict with the organization they work.  People in the business see you as a misfit and weirdo.  I firmly believe this is a good thing and coaches and scrum masters should embrace their inner weirdo.

I kept thinking about how change is often promoted by the eccentric, weird, and outcast among us.  Allan Turning and Ludwig Wittgenstein are intellectual giants of the twentieth century.  One invents the concept of software development and computer science.  The other gave us the “Tractatus- Logico Philosophicus.” Our understanding of computing and language would never be the same thanks to these two people.

Both people were also profoundly weird.  Turning was a closeted gay man with a penchant for wearing a gas mask to ward off allergies.  He was also overly protective of his tea mug chaining it to a radiator.  Wittgenstein was weirder than Turning;  he quit university teaching to build a house for his sisters.  He claimed his book “Tractatus- Logico Philosophicus,” was the last book of philosophy anyone will ever need, and he also liked to pick fights with his contemporaries like Karl Popper. 

Today people like Turning and Wittgenstein would not make it out a Ph.D. program at a big ten college let alone be tenured faculty at a major university like Cambridge of the 1930’s.  The world of business has similar stories.  Bill Gates was a college dropout who could not complete his eagle scout when he was in high school.  By every definition he was a nerd, breaking into computer labs to get more time on mainframes.

I doubt a computer company or venture capitalist would give someone like Gates the time of day.  His elevator pitch would be too bland, his sweat-stained oxford shirts would not look professional, and what does a college dropout know about business.  The truth is Bill Gates is one of the countless oddballs, misfits, and weirdos who have moved business, technology, and society forward.

It is why when I saw this tweet from the Muppets I had a revelation.
Being weird is amazing.  Not living in the box others live in is fantastic.  Being able to speak truth to power because they do not take you seriously is fantastic.  Making changes which are crazy enough to work is terrific.  Being weird is a lonely path, but the friends you do make are amazing.

As a scrum master or agile coach, you are in a weird role doing weird things which the rest of the organization consider weird.  The truth is what you are doing is amazing, and you are going to be remembered with more fondness than the boring CEO who speaks in accounting jargon.

Go forth, be weird and be amazing!

Until next time.

Monday, September 3, 2018

Time to call out bad agile before its too late.

Do you want this person coaching your agile efforts?
Agile is not a revolution in business.  You do not see technology professionals and agilists with pitchforks and torches wanting to burn down global capitalism.  It is a reformation where smart and conscientious people are attempting to reform business.   It creates a backlash against people who are happy with or benefit from the status quo.  Backlash is a natural reaction to change.  What I have discovered this week are developers I have known and respected for years heckling an introductory agile training course in their company.  Via social media, I had a front-row seat.  It was deeply troubling, and I wanted to blog about it.

Plenty of technology leaders have criticized Agile and Scrum.  I have written two blogs directly addressing these concerns. What struck me, recently, was the contempt I was experiencing from quality developers about the basics of agile.  I witnessed a series of vomit GIFS and videos of people attempting to self-harm while the presentation was in process.  One commenter said, “Reading these to my team (we all hate agile) and we are LOL” and the thread continued with someone else saying, “…I have a passion for hating agile so yeah I’m LMAO.”  Making matters worse the slides showing agile principles were mislabeled and out of sequence.  Combine this with an instructor who looked like they never had to deliver working software it was brutal and disappointing.

After some back and forth with the hecklers, someone I deeply respected got to the meat of the why there was so much contempt.  The agile manifesto and principles of agile were “insulting,” and further elaborated, “if your leadership is buying into agile, it works.  However, that is not a case at most companies.  This is much harder to install at something that isn’t a startup.”

The contempt is a product of poor leadership support of agile.  The ridicule comes from skilled and experienced developers who want to ship software without getting bogged down in process.  The laughter comes from poorly coached and led efforts to guide agile at the firm.  The cynicism is a product of “dark scrum” and the creation of a software sweatshop mentality.

It was upsetting to experience this kind of pushback.  I do not discount this experience.  People with PMP certification and limited exposure to agile feel threatened by the reformation of business.  Some of the unscrupulous put on the title of “Agile Coach” without the experience or the mindset of a coach.  These individuals peddle their services as consultants or thought leaders.  Often people like this are about a helpful as butchers in an emergency room and just as dangerous.

Poor agile leadership, coaching, and education deserve contempt.  Those of us who bring a sense of artisanship and care to agile need to point out bad actors and improve the field.  Often, we are brought in to clean up the wreckage created by these people. We should also extend help to the bad actors to improve their ability to do the job.

I firmly believe a terrible agile application to a company is worse than no use of agile at all.  Based on the contempt some of my developer friends heaped on the agile trainer; it is clear they feel the same way.  Coaches and scrum masters like myself will be around to help guide others.  It also looks like we are going to clean up this mess left by others.

Until next time.

Monday, August 27, 2018

Talk to People Instead of E-Mailing Them!

Instead of sending an e-mail pick up the phone.
I have been a business professional for a long time.  I have been working in technology for two decades.  In that time, the world has changed radically for good and ill.  What has not changed is the time suck which is e-mail and how it is cancer for many organizations.

E-mail is as old as the internet.  Before the creation of the World Wide Web, the most common use of the internet was swapping files and sending e-mail.  Business organizations saw the utility of the application and used it as a means to create a way to cut down on the number of business memos.  What happened is the creation of a flurry of messages through companies as people used the tool to improve communication.  With the advent of e-mail and voice mail systems, managers hoped the worker bees in the cubicles would not ignore important information.  According to my experience, the cobra effect raised its venomous head.

The information did move more smoothly, but it created an incredible amount of noise which drowned out the necessary information. Instead of business goals; office gossip, invitations to lunch and memes began to clutter up inboxes.  The torrent of information became a tsunami as network systems were tuned to send SMTP messages.  Today, every file dropped into an FTP folder, or work item changed in JIRA or help desk ticket created generates an e-mail to provide you with a friendly reminder.  Today, a business professional has to act on hundreds and thousands of e-mails – daily.

The ocean of e-mail both trivial and critical is overwhelming.  It has created the inbox zero phenomena and a perfect storm of professional apathy.  All e-mail has the same relative importance, so it is easy to ignore messages equally.  Managers have used the folder routing features of Outlook and GMail to ignore inquiries and information from subordinates skillfully.  Help desk people with a particular form of sloth will ignore complaints for days.  The ability to use email as a tool of deflection seems, to me a credible reason why productivity has been relatively stagnant over the last decade.

What makes e-mail so insidious is that it is a written record of the conscious and unconscious mind of an organization.  An e-mail gives an employee an alibi creating the impression they spoke up about important issues even if management ignores that information.  Sexual harassment and gossip exist in the company e-mail database like an improvised explosive device waiting to dismember.  Finally, criminal and unethical behavior are spelled out for prosecutors and the journalists to expose.  It is why the e-mail database for Enron is still used by software companies to test e-mail products.  The criminal conduct and general idiocy of the Enron organization live forever.  Technology, human resources, and public relations professionals use the Enron e-mail database as a simulation of what might happen in an actual corporation.

To me, e-mail is not a tool for clear communication but a device for obfuscation.  It is the written equivalent of snowflakes coming together to create a blizzard of awfulness.  Individuals compensate with text messages sent between private phones, executives and other essential people having multiple phones to have conversations.  It is critical information being harder to share and keeping secrets for personal gain.  Finally, business professionals spend three to five hours each business day according to Forbes monitoring and authoring e-mails.  I think this is crazy.  Instead of helping customers, innovating the business or solving problems we are doing ticky-tacky work monitoring e-mail.

One of the agile principles says that face to face communication is preferable to other forms of interaction.  So my warning to any scrum master or agile coach is to pick up the damn phone, call people, and speak to them.  Get up from your desk and walk over and talk to people rather than hide in your office.  Use video conferences and insist that everyone turn on their camera so that we can read body language and know they are paying attention.  A lousy organization is not going to change if we insist on doing the same thing redundantly.  It is time to reconsider e-mail and how we use it.  It cannot hurt to try.

Until next time.

Monday, August 20, 2018

Product Owners deserve Healthy Ownership.

Spending quality time with Alex Sloley
I have been working as a scrum master for the last five years.  What I have discovered over that period of my practice as a coach and scrum master is that product ownership is the weak leg of the triad of Scrum roles.  We spend plenty of time making scrum masters and developers better, but we still struggle with the purpose of the product owner.  I suspect this is because as a former technical professionals scrum masters and developers speak a similar language.  Product ownership is different in experience and expectations.  It is why it is the weak leg because it is so radically different to slinging code.  It is why I want to talk about “healthy ownership” on my blog this week. 

The notion of “Healthy Ownership,” was constructed when I attended the Agile Coaches Retreat in London this summer.  I had just finished a contentious sprint planning session before getting on a plane to England where a product owner questioned the estimates of the development team.  It was a gross breach of the social compact of agile.  The product owner protested, “They did something similar last sprint, I thought they would be faster this sprint.” Typically, I do not want to drink bourbon at the office, but at that moment I was sorely tested. 

I brought this and other examples of bad behavior to the other coaches.  I pleaded with them for help. Others had similar challenges and solutions.  The truth was they did, but no one had come up with coaching techniques that would help them rectify the situation.  Like any other self-organizing group of individuals, we came up with a team to address this situation.  We had numerous people with different perspectives from former developers to project management professionals who were attempting to instill professional practices in their organizations. 

We had three goals: 1) open dialog between team members, 2) increased empathy between team members, and 3) collective ownership of outcomes.  It was not going to be easy.  We did discover that we could combine coaching techniques to gather information and come up with scenarios for common pain points.  From there we could collect data and try to inform and persuade others on how to approach situations.  It is not a script or prescriptive but more like a way to practice common coaching techniques with common problems on agile teams.  It is not perfect, and we are still forming approaches, but for the rookie coach or scrum master, it acts as a safety net.

Flash forward to the Agile 2018 conference, and I heard other people discuss their challenges in getting buy-in from product owners and developers.  It is why I am grateful for Alex Sloley and his discussion about transplanting the brains of product owners and scrum masters.  By shifting the roles of a scrum master and product owner, we get to “walk a mile in someone else’s moccasins.”  The product owner understands the challenges of the scrum master and developers while at the same time the developers and scrum master understand the challenges of the product owner.  It was a nice juxtaposition, and I will use the term “backlog coaching” in my practice for the rest of my career. 

So to me, “healthy ownership,” means putting yourself in another person’s situation and understanding the unique challenges they face.  It means that it may be necessary to do a “brain transplant” or less drastic measures for people to understand what is going on in the development process.  Product ownership is the weak leg of a scrum team, but it is because coaches and scrum masters do not pay enough attention to the role and how to make it better.  It is why I am going to be spending more time with my product owners and walking a few miles in their moccasins.  With a little luck, I will reduce the stress on my development teams and improve the performance of my product owners.

Until next time.

Tuesday, August 14, 2018

Looking back at Agile2018

Spending time with fellow
 speakers Michele Sliger and Erika Lenz
This year is a personal and professional adventure for me.  I journeyed to the Scrum Alliance coaches retreat in London.  Last week, I was a presenter at the Agile 2018 conference.  Each of these experiences has made me a better scrum master and agile coach.  Now, that I am back home and have a more stable schedule; I will be blogging on a more regular basis.  This week a few take-a-ways from the #Agile2018 conference.

Data and Metrics-

The Wednesday keynote was Troy Magennis who spoke passionately about data and agile.  He proposed that agile professionals find a better way to present data to others and that data should inform decision making rather than reinforcing existing prejudices. 

He also provided data showing notions of teams being smaller than nine people may be counterproductive in larger projects.   He pointed to studies where groups of eleven to nineteen people are less efficient by a fraction compared to seven to nine-person teams.  He then argued that fewer handoffs between teams would make up for this difference.  It was provocative, and I look forward to people testing out his thesis. 

Presenting for the first time. 
The conference featured numerous presentations on metrics and data in agile.  I believe the use of quantitive data rigor in project and business management is a good thing.  For the remainder of the conference, numerous sessions covered the use of data and metrics in Agile. 

Outcomes are better than output-

The Agile Alliance with its speakers unwittingly created a theme for this conference.  The idea was outcomes of real features and progress are more important than outputs of stories, unit tests or story points.  Countless presentations emphasized working code delivering real-world value.  My presentation about the Cobra Effect reflected this dynamic as well.  When we measure outputs, we get perverse incentives.  When we measure outcomes, we get a better perspective of performance. 

Facilitation and Radical Candor-

The life of an agile coach or scrum master is a life of responsibility without any authority.  It is paramount to successful organizational change coaches develop superhuman skills of persuasion and facilitation.  I attended several sessions on how to be more credible and persuasive.  Many of these sessions pull from the insights of Kim Scott, a former Google Executive, who authored the book, “Radical Candor."

I learned plenty of valuable lessons at #Agile2018, and I look forward to the next conference in 2019 in Washington D.C.  I better start working on my presentation outline. 

Until next time.

Monday, July 30, 2018

How I became a Pirate Bear

I am a pirate bear. 
If you have been following this blog for any length of time, you understand that I have been an outspoken advocate of Agile and Scrum.  It has become the central focus of my career.  I am one of those eccentric and creative people companies want but do not know how to utilize.  I am an anomaly in the business world, and I am comfortable with it.

Like any other technology professional, I spend my free time learning new skills.  In preparation for the Scrum Coaches Retreat in London, I spent some time learning how to use #slack.  To be honest, I am still struggling with the platform.  It feels alien to me.  I have not mastered all the tricks, lingo or etiquette of a #slack community.  I think the same way I did eight years ago when I started using Twitter.  I was able to master that, and I will be okay with the new platform.

When you join a new social network one of the more important things you do is choose a name where others can quickly identify you and touch base.  The same is true with #slack and since the network does not allow for duplicate names people rapidly get creative coming up with handles.  I decided to give myself the moniker “The Pirate Bear.”  I posted a color picture of myself in a fez and began my journey in #slack.  I was swapping information, slide decks, and gossip with other agile coaches for a few weeks when someone from England asked why I chose “The Pirate Bear.” I did not have a chance to answer the question then but feel compelled to answer it now.

Since I began my vocation as a technology professional, I have been heavy.  I blame this state of being on the nature of the profession and by using food to cope with the pressures most technology professionals confront.  I am both big and tall.  It prompted the woman who loves me to label me her bear affectionally.  Additionally, many of my LGBTQ friends and colleagues say that I would pass as a “Bear” in the gay community. I felt awkward about this at first, but I embraced it as good-natured teasing from friends.

Piracy has been a significant theme in the zeitgeist since Johnny Depp wore the costume in the first Pirates of the Caribbean movie.  Piracy has been the banner many rebels and outcasts have embraced since the age of sail.  Illegal radio stations sailed the North Sea offering programming the BBC would not provide. It became a pirate radio which has been copied by numerous radio stations around the world.  When Steve Jobs put together the product team of the first Macintosh, he told each of the engineers, “It is better to be a pirate than to join the navy.”  The secret pirate crew then changed personal computing forever.

It sounds very glamorous. The swashbuckling and mythology of piracy is quite appealing.  The reality is that a pirate’s life was dangerous and cruel with significant shifts between poverty and wealth.  A pirate sailor often faced execution if captured and often succumbed to illness at sea.  You chose piracy for many reasons, but the main reason is that you did not fit in anywhere else.

In the sclerosis of most corporate environments, if you are going to make a change, you will have to be a pirate.  You will have to be smarter, nimbler, and more unconventional.  You will suffer from being an outcast.  You may also fail in an embarrassing and ignoble fashion.  On the off chance none of that happens, you will cut a romantic figure in front of black sails and wallow in gold and rum.

Given a choice between the routine and tedium of a professional career and being a pirate; I choose to be a pirate.  It is why I am the pirate bear on #slack.