Monday, October 15, 2018

When the Story is Not Done

Things go wrong during sprints.
One of the most important facets of agile is the quick cycle times make it possible for people to react to change rapidly.  The end of each sprint is an opportunity to gauge success and look for areas of improvement.  The speed forces us to do work in smaller chunks and gather feedback and direction from customers.  An agile team can bite off more than it can chew in a sprint.  Today on my blog, I want to discuss some recommendations on how to handle stories which take longer than a sprint.

In a perfect agile practice, each team completes all of the work they commit to in a sprint.  The need to “roll over,” critical work to the next sprint does not happen.  In the fallen world where most of us live and work, stories do not get finished at the end of the sprint.  It creates a challenge because the unfinished story might delay a release or throw a delivery timeline off schedule.

The Scrum Guide does not say much about what to do when a story is incomplete at the end of a sprint.  Since there was no consensus, a beginning scrum master just rolled over the story and asked the team to finish the work in the next sprint.  The approach was no different than letting a milestone slip in a waterfall project.  The collective wisdom of the web stepped forward, and experts suggested an incomplete story should return to the backlog and reprioritized.  If the story still had value it can be placed in the subsequent sprint; otherwise, it can wait.

Concentrating on what is important rather than what is unfinished each sprint is what makes agile so powerful.  Unfortunately, unfinished work can become technical debt overnight and create conflicts inside the agile team.  Many stories are incomplete because the team has not met the standard of care for the story.  Unfinished unit tests and incomplete acceptance criteria are prime culprits for this situation.  The group wants to split the story and lower the number of story points so that it does not look like the velocity of the team is impacted.  The truth is velocity is affected.  The team failed to deliver story point in the previous sprint, so the velocity has gone down.  A team should both see and feel the effects of not meeting the standard of care.  People outside the team should also see an honest portrayal of the challenges the team is facing.  There should be no secrets on an agile team or in an agile enterprise.

When a team fails to deliver this is also an opportunity to bring up in the retrospective what caused this kind of setback.  Product owners should understand there is more to a story than writing code and developers should be more assertive about how they communicate.  The team should own up to the failure and try to do a better job next time.

Failure is hard, but it educates better than any success ever could.  It also makes future victory sweeter.

Until next time.

Monday, October 8, 2018

Agile and the Toxic office

The Open office plan circa 1960.  
A modern office resembles the dark vision of Jean-Paul Sartre’.  In his play “No Exit,” he traps three characters in a room.  The characters psychologically torment each other.  The lights never dim and no one can escape.  To Sartre’, “hell is…other people,” and they are impossible to escape.  It sounds like a perfect description of the modern office with cubicles and open floor plans.  By design or neglect, the contemporary office has become a toxic hell which white collar workers navigate each day.  As an agile coach and scrum master, you need to fight this toxicity and make work better. 

The open office is not a new concept.  As business expanded, hundreds of people were needed to perform necessary clerical work.  Captains of industry required contracts typed, checks deposited, and in a time before computers numbers crunched.  Many of these jobs became obsolete with the advent of computers and photocopy machines.  Today, an employee with a laptop can be more productive than an entire 1950’s office pool.  It is impressive when you think about how office work has changed over the last seventy-five years.

It is also surprising how little has changed.  Alcohol abuse is still a problem in the corporate world.  The “Peter Principle” which promotes people to their level of incompetence is still in practice.  Finally, according to Gallup, two-thirds of workers in the United States are disengaged.  I feel strongly Agile came into being because competent, hardworking people thought it was possible to do better.

The reason offices converted too open plans is the combination of perverse economic incentives and naive notions of what it takes to build a collaborative team. In cities with large business communities, rent is at a premium.  In Chicago rent increased by 20% in 2016 and currently leases at $50 to $60 a square foot.  Based on the price pressure, business owners have the incentive to get the maximum amount of use out of each square foot.  The open office makes that possible and managers can squeeze more people into less space.  The open office plan began with Frank Lloyd Wright and his Johnson Wax office building; it also has an origin in German design from the 1950’s.  The open office would facilitate conversations, collaboration, and innovation.  The reality of open offices is an environment employee’s loath.   

It does not help the shareholder value theory of business motivates many managers.  To these managers, the only thing which matters in increasing the share price or dividend for the company stockholders.  Thus, the open office and the shareholder model of business creates a fiendish replication of Sartre’s hell.  We are trapped economically in a space which is designed to torment us.  It is this combination of poor work environment and leadership which ignores stakeholders, customers, and employees are why I think we have such a severe problem with disengagement and alcohol abuse in office culture.  When there is a disconnect between your work and your wellbeing, something has to give; for many, it is their self-esteem and enthusiasm for work. Marxist philosophers call this “Labor alienation,” and it is just as bad today as during the sweatshops of Dickens.

Agile came into being because people doing the work of building the world economy through there was a better way.  These people were project managers and technologists.  None of them were Fortune 500 executives.  Individuals and interactions, responding to change, customers collaboration, and working systems were more important than everything else at the office and embracing these values we say we are trying to make the office less toxic. 

Many of us feel we are powerless to change things in the office.  Agile gives us the tools to expose dysfunction and reduce alienation.  We have to be brave and smart enough to use those tools; otherwise, we will continue to have the same office as we have had for seventy-five years and there will be "no exit," for us. 

Until next time.

Monday, October 1, 2018

No secrets on an agile team.

No secrets on a crap game or agile team.
I went to San Diego this week to talk about “Healthy Ownership,” with other agile professionals.  The experience got me out of the office and listening to others and their challenges making their workplaces better.  During the discussion, I recalled an old saying I learned when I worked as a dealer and pit boss at Harrah’s casino, “There are no secrets on a crap game.”  It occurs to me that wisdom can be applied to any agile team.

Working a crap game in progress, for the uninitiated, is confusing.  Dice are flying in the air and depending on the number they land hundreds or thousands of dollars can be won or lost.  It is a loud, frantic, and intense game of chance.  Since it is so fast, the dealers need to have incredible arithmetic skills, manual dexterity to make payments, the customer service skills of a butler, and the grace under pressure of a bomb disposal expert.  It was the most difficult job I ever had.

The reason dealers and pit bosses say, “There are no secrets on a crap game,” is things move so quickly on a crap table that bets are often made while the dice are in mid-air.  Only by shouting out your bet and having it confirmed by a dealer does it “count.”  If the dice bounce off a player’s arm on a crap game the other players will get angry and will often leave the table.  The superstitious behavior of gamblers encourages craps dealers to vocalize everything they do.  A dealer repeats back bets to the players.  A dealer often recites the payouts they are making and where those bets are located on the felt in front of them.  All this happens because the game needs to keep moving and no one wants to lose out on a bet.

In a world where agile teams have healthy ownership, the teams should exhibit three qualities.

  1. Open Dialog.
  2. Increased Empathy.
  3. Collective Ownership.

For a crap game to be successful, open dialog needs to exist on the crew.  It is why everything is vocalized.  At casinos, my experience was crews were scheduled together so they learn to work together.  Finally, everyone on the crew is accountable if someone cheats or something goes horribly wrong.  It seems the casino business was into healthy ownership before agile professionals.

What does this mean for software development teams?  To achieve open dialog, the development team, scrum master, and product owner need to be in constant communication.  Stand up meetings need to be frank and to the point.  Product owners should listen in and make sure they can answer questions.  Scrum masters should facilitate discussion using the product backlog as the central hub of information.  Finally, developers should follow up on acceptance criteria to make sure what they are building is what the product owner needs.  If anyone is in doubt the should speak out.

To increase empathy on the team, the scrum master and product owner should share a work space.  It allows the scrum master and product owner to understand each other’s routine.  Using video conference equipment also helps.  It lets individuals see each other as real people instead of disembodied voices on a conference call.  Teams should work together in open spaces with areas for mob programming and rooms for privacy; I find both are necessary for the success and sanity of developers.  The most important piece is to make sure each member of the team understands the challenges and responsibility of the others so they may have empathy.

The final outcome of collective ownership is necessary for Healthy Ownership to thrive. It means the scrum master, product owner, and development team share equally the success and failure of each sprint.  I find this to be the most difficult outcome to achieve.  It requires highly skilled people to give up a little of their ego and make sacrifices for others.  To borrow a phrase from Benjamin Franklin, the agile team needs to hang together or all of them will hang separately.

To have healthy ownership an agile team needs; open dialog, increased empathy, and collective ownership.  The development team should not have any secrets just like a casino craps crew.  Following this model will create the healthy ownership which will help every team a success.

Until next time.

Monday, September 24, 2018

Listening, Compassion, and Shared Context make coaching rewarding.

Healthy Ownership requires plenty of tools.
I have spent a majority of my life around educators.  I have family members who were teachers and administrators.  Many of my peers in college are teaching at the university and high school level.  I also spend my time on social media following teachers, trainers, and educators of all stripes.  A common refrain I hear from all these people in my life is satisfaction they receive when students they serve understand a difficult concept or master a skill.   For many of them, this feeling of satisfaction is why they got into education.  It is the same reason I am an agile coach and why I am championing the notion of “Healthy Ownership.”

My attendance at the agile coach’s retreat earlier this year was an awakening for me.  I spent time with other coaches and learned some valuable lessons about myself.  I also worked closely with ten gifted people who held each other accountable and created something called “Healthy Ownership.”  Born out of frustration in my agile practice, “Healthy Ownership: was an opportunity for me to learn better techniques of coaching. It was also a chance to step aside and learn how others lead and motivate teams.  It is surprising what I learned. 

The most important lesson is to listen to what people are saying.  I struggle with this ability at work.  Put me in front of a PBS documentary, Anime show or Kaiju film, and I am perfectly attentive.  In work situations, I struggle to listen.  My inability to pay attention to verbal and non-verbal cues hurt my coaching.  Thus, I am committing myself to be a better listener, so I understand the hidden and apparent challenges to the teams I am serving. 

After listening, I need to work on guiding others to have more compassion for their colleagues.  You cannot fundamentally change how empathetic a person is but you can help someone it is their self-interest to help others. Ayn Rand speaks about the “virtue of selfishness.”  I consider her thinking to be an alibi for callousness and contempt which will undermine any team attempting to succeed.  It is why everyone needs to understand they are working together.  You may not be able to increase team empathy, but by reducing callousness and contempt among team members, a coach will have a better success rate. 

Finally, after guiding others to help team members, it is essential to create a shared context.  It means a product owner, developer and scrum master should understand how to better focus on what they need to do together to be successful.  For instance, my teams discuss technical debt daily. The purpose of the discussion is for product owners to understand the obstacles the teams need to overcome to deliver the product.  The mindset of continuous improvement seeps into everyone’s mindset, and during sprint planning, we have frank discussions about the amount of refactoring we need to accomplish.  The shared context is building quality for the customer faster.  If the product owner sees how hard it is to get stories finished, they pay attention to technical debt. 

I am going to be in San Diego as part of the agile coaching exchange talking about “Healthy Ownership” and how it has changed my perspective.  As you can see, I am going to be talking about it for the remainder of my career. 

Until next time.

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.


Monday, July 23, 2018

Coaching should reject triage

Good for the battlefield bad for society and business
Usually, I spend my time on the blog discussing agile and how to better improve software development.  I avoid political discussion because there are much better places for people to discuss that topic.  This week, I would like to discuss something different.

This week a young person I have known since her days as a college undergraduate wrote and thoughtful post about her struggles with mathematics in elementary school.  As early as fourth grade she was taken on field trips to grocery stores to learn about careers stocking shelves after completing school.  None of the other students attended that trip.  As early as nine years of age educators and members of the community were making decisions about her life.  Today, Stephanie Orme is a Ph.D. from Penn State who is a nationally recognized public speaker and recently gave a TED talk on Diversity Game Design.  

I am very proud of Stephanie.  I consider myself one of the stepping stones on her journey and I look forward to seeing her further adventures in academia.  Her story made me think about my trip educationally and as a scrum master.  We make too many judgment calls about young people, and those judgments are harming our society and the business community.

Our education system in the United States has wide gaps of inequality.  Private schools appeal to people of means and have been training grounds of the children of business and political elites for the last 100 years.  Parents often pay a premium real-estate prices to live in communities with highly rated schools.  Young people living in rural or poor school districts are not so fortunate; it means that school districts make do with what they have, and they get involved in a practice known as triage.

Initially, from the medical field and pioneered by the French during the Napoleonic wars triage means the sorting of people to help them when confronted with scarce resources.  For example, someone with a head missing from a cannonball does not need a blood transfusion that blood can go to someone with a better chance of survival.  Paramedics, emergency rooms, and combat medics use the concept of triage daily to save lives.

As early as middle school, I experienced triage in my education.  The “smart” students participated in honors courses and segregated from other students.  These students not only had to have good test scores but they also had to have good grades.  The poor students were in remedial classes, and the unwashed middle got by with standard courses.  The exception to this rule were those with cognitive and learning disabilities who received special education.  I was terrible at mathematics, so I attended learning disability courses.

As time wore on, the honors students became more privileged as standard and remedial students shifted into less challenging classes.  Honors students received college AP courses, scholarships, and opportunities to excel. Once labeled a basic or a standard student, opportunities to reach the upper echelon was difficult.  It created a type of resentment and desire to prove those who doubted me wrong.

I was more fortunate than most.  My community college prepared me for university study. I was lucky enough to receive a scholarship to a four-year school for debate and speech.  Thanks to the financial sacrifices of my parents, the incredible support of my teachers, the encouragement of countless adults, and a little luck I became a college graduate.  If you had checked in with me as a nine-year-old, you would have concluded that I would be stocking shelves.

It would take seven years working in the radio and the casino business to find my true vocation; software development.  It would take another ten years before I would discover agile and share its worth with others.  I got by on grit, but I would be fooling myself if I did not acknowledge the privilege of supportive parents and my educational background.

It is this knowledge which has shaped my perspective.  The Harvard business review talks about a “fixed mindset” vs. a “growth mindset.”  Thanks to triage in education, we take young people and place them into boxes.  We then triage those boxes into careers and roles in our community.  It is a more significant problem in business because often leaders are more comfortable around people with similar educational and cultural experience.

As someone who has not fit neatly into a box his entire life, it encourages me to adopt a growth mindset for others around me.  I cannot help everyone, but I will try to help those I can.  With a little luck, there will be more people like myself and Stephanie Orme helping reform business and culture.

Until next time.

Monday, July 16, 2018

Why Healthy Ownership

"Healthy Ownership" created to fight abuse
I have been in deep thought about what we in the agile community need to do to make businesses more responsive to market demands.  The reality is that many relationships in the technology world can be abusive; this why I want to talk about the reasons why I have been working on “Healthy Ownership.”

It is not a secret that software developers can be jerks.  It is also not a secret that there are plenty of raging asshats in the technology business.  Finally, if you work in a shrinking industry, the pressure to do more with less can be absurd.  With all of these realities, there is no reason to be involved in the following behaviors.

Questioning the estimates of a development team.  

I have written several times about the underlying social contract of agile.  Product Owners set priorities and development teams to estimate how long it is going to fulfill those priorities.  I had a product owner question those priorities saying, “You did something similar last sprint so I thought you could do it faster this sprint.”  All user stories should be negotiable but for things like scope and acceptance criteria.  When product owners start questioning how long it takes to complete that scope you break the social contract of agile.  It is this kind of conduct which demotivates the development team and gives them license to question the judgment of priorities of the product owner. 

Not writing a unit test or chipping in with QA work.

I have known developers who have looked down on quality assurance people.  Experience tells me that these individuals are not very good developers.  Software development is complicated, and the process of authoring it creates intellectual blinders.  Quality assurance people guarantee that those blinders are less convincing.  They ask uncomfortable questions, probe weaknesses in logic and are willing to take a sledgehammer to a sink to make sure that everything works as promised.

Quality assurance people help developers improve, and developers help QA people understand what they are testing.  A recent blog post mentions a professional golfer is not finished with a hole until they put the ball into the cup.  For weekend beer league golfers, it is good enough to get it close to the hole and “pick it up.”  Writing unit tests and doing QA work separates professionals from beer league developers.  Refusing to do this means you are rejecting the professionalism of your craft. 

Ignoring refactoring and technical debt

Technology is a brutal business.  It is unforgiving and humbles the best of us.  It changes so quickly; a developer needs to relearn their job every eighteen months.  It means that code they are working on needs continuous refactoring.  What is working in the short term may be hard to maintain or adapt to changing business needs.  It is why technical debt and refactoring matter.

Many people in leadership roles have a, “if it is not broken do not fix it,” attitude.  Neglecting technology is like ignoring your household plumbing.  It may work now but when it does break it is going to create a tremendous mess.  Paying attention to technical debt and refactoring is common sense like changing the batteries on your smoke detectors. 

All three of these pathologies brought me and others together to create “healthy ownership.”   These behaviors are abusive and counter-productive to any team.  Only be addressing these dysfunctions will the practice of software development improve.

Until next time.

Monday, July 9, 2018

What You discover at a coaching retreat

Why teammates from the Agile Coaching retreat.
I have been offline for a few weeks.  The reason was I had to have some downtime as I was involved with a conversion of a TFS 2015 server over to an instance of VSTS.  Also, I was getting ready for a trip to London for the Scrum Coaches Retreat.  The pressure along with the time requirements forced me to set aside my writing.  Things have settled down, and so I can get back to writing about agile.

It has been a whirlwind three weeks.  Family functions, work, and this trip to London have been my focus.  When you have time out for yourself, you learn a few things.  The primary lesson came from a scrum master I met from England.  Dominic Kavanaugh who pulled me aside during a stressful moment and said, “This retreat isn’t about shipping anything; it is about learning.”  From that moment, I had an epiphany.

The agile manifesto says working software over comprehensive documentation.  The principles of agile stress shipping software in small increments.  What I realized is I have forgotten a fundamental lesson about continuous improvement.  Learning and growth are a vital goal of being agile.  Shipping software is not a hamster wheel where everyone goes around and round shipping software and not improving.  It was my big revelation.

The revelation came as my team of coaches came upon the idea of “Healthy Ownership.”  I was complaining about the abusive relationship developing between my product owners and developers.  Soon another joined my group and spoke about quality assurance not working well with developers.  Finally, Dominic entered the group and talked about technical debt.  What united all three of these themes was that the development teams did not have a shared sense of ownership to the work they were doing.

Together, the team of us set out on a journey to try and come up with a way to discuss dysfunctions and how to fix them using a coaching approach.  It was the first time I exposed to terms like “clean language,” follow-on questioning, and guided conversation.  It was positive to have ten strong personalities in the room who were all success focused.  One person was our enforcer of norms.  The other was making sure we covered the topic of quality assurance.  Another was our enthusiastic product owner.  All of us learned to work together in three short days, and we came up with a “Healthy Ownership” model of coaching.

I am pretty proud of the small part I had to play in the creation of this tool; I hope to use it for the remainder of my career.  First, it is a descriptive approach to solving problems.  Often as a coach or scrum master, you want to jump in with an answer to a technical question or process problem.  It may answer the question, but it impedes self-organization on the team.  Next, we approach issues like a doctor looking at symptoms.  We gather information, ask a few questions and provide the right nudge to a person.  Finally, we are just getting started.  All of us have committed to being ready to improve and flesh “Healthy Ownership,” out.

I was not sure what I expected at the coaching retreat, but now that I have attended one, I see it as a valuable and worthwhile experience.   I am looking forward to going the next time.  I am also looking forward to sharing with you my experiences.

Until next time.

Monday, June 11, 2018

No Estimates have a spot at the Campfire

Lots of debate around the campfire.
One of the best things about being a member of the Agile community is the smart and enthusiastic people you encounter online and in person.  It is refreshing and challenging to be around people who have a shared vision of making business faster, sustainable, and more intelligent.  The commitment to the goals of agile does not mean we are ideologically unified and dogmatic.  Like any healthy practice, we disagree with each other about basic principles, ways to spread adoption, and innovations.  The creative tension is essential.  I want to add my two cents to an on-going debate which a colleague Ryan Ripley brought to my attention from the sober and restrained convention floor of the #BetterSoftwareCon in Las Vegas. 

The #NoEstimates movement has become a very vocal camp in the agile reformation.  If you follow the debate, it is easy to see why.  The estimation process at many companies is farcical and corrupt.  Story points were created to provide the benefits of estimation without the obvious drawbacks.  The #NoEstimates crowd take this to a logical conclusion and say estimating is a waste of time and energy.

I do not feel very strongly about #NoEstimates.  What makes it interesting is it provides a different perspective to authoring software.  Neil Killick then posted a white paper this week showing some qualitative measurements which show a no estimates approach works just as well as a story point approach.  

I was skeptical but, I decided to give the article the benefit of the doubt.  Killick uses T-Shirt sizes to measure ambiguity and difficulty.  Using arithmetic and charts, he shows how he can forecast project completion.  The approach is well thought out and clear.  It is also story points dressed up to look like #NoEstimates.  It requires the product owners to spend time doing arithmetic instead of writing stories and working with customers and developers.  Personally, I struggle getting product owners to perform the basics of their duties.  Thus, using Killick’s approach may work for a different agile implementation but not for mine. 

I genuinely dislike debates which generate more heat than light.  Killick provides a good approach for a more mature agile team.  I am glad I had a chance to learn about it and will keep it in my chest of tools if I feel it worth trying.  The agile manifesto says, “Individuals and interactions over, processes and tools.” I believe that Killick’s approach is a process which might work with a particular set of individuals.  I also think that discussion of #NoEstimates is good for the agile movement.  People try out ideas, test them, and they are adopted or rejected over time.  It sounds mighty agile to me.

Until next time. 

Monday, June 4, 2018

Break out of your rut!

I have been thinking about my craft.  A scrum master is a coach, therapist, and advocate for their team.  We have emotional ups and downs in the profession.  We are also fortunate enough to make a difference in the organizations we work.  It is rewarding but filled with the trade-offs professionals are confronted.  This week wanted to discuss a constant force in the life of a scrum master continuous improvement.

As a professional, it is easy to get into a rut.  Decision fatigue sets in and so you order the same thing for lunch or manage how you deliver software.  Routine and inertia are comfortable because it provides a false sense of security in an uncertain world.  Your heart could stop from a simple blob of cholesterol or the company share price could crumble overnight, but thanks to the routine we ignore these catastrophes.  Inertia is safe and secure.  It is also the enemy of continuous improvement and agility.  It is why scrum requires retrospectives.  The feedback allows everyone evaluate how to improve. Development includes the product owners and the scrum master.

I was doing a product increment planning meeting for the product owners to coordinate releases and plan for the future.  On a whim, I decided to include a retrospective of the last quarter to get a sense of where we are and where we are going.  A tense hour later a few lessons were learned.  Using a four “L” retrospective, I wanted to understand how as a product development team we were doing.  The answer was unambiguous.  Some things which we could control had to change.  The retrospective included passive aggressive conduct, and a few choice criticisms pointed at me.  It was worth it.

Based on what I learned, I am going to conduct retrospectives differently with the development teams.  I am going to work with the product owners more closely to help them manage their work more closely.   Finally, I am going to try and break out of my decision fatigue.  Continuous improvement matters, and if you expect it of others, then you should expect it of yourself.

Until next time.

Tuesday, May 22, 2018

Scrum does not have too many meetings

Each reform in society is confronted with a backlash.  The Protestant Reformation spawned the Inquisition.  It is natural that those threatened by it would oppose progress.  It is happening in businesses across the nation with the Agile reformation.  A common objection many have toward agile or scrum is there are too many meetings.  This week I want to discuss agile and meetings.

According to the scrum guide there are four events in scrum, they are:

  • Sprint planning
  • Daily Scrum or Stand-Up
  • Sprint review 
  • Sprint retrospective.

In the span of a work week, these meetings should be brief and informative.  A stand-up meeting should take approximately fifteen to thirty minutes.  If it takes longer, you should review how you are facilitating this meeting.  A sprint review is a demonstration to the business users and should take no longer than an hour.  Retrospectives allow a team to inspect and adapt their process.  Typically, this meeting is about sixty to ninety minutes in length.  Finally, there is sprint planning where the development team estimates stories and plans the next race.  Sprint planning can take as little as an hour and as much as six.

Based on this rough estimate we can determine how many hours the agile team is spending in meetings.  Based on a three-week sprint where is how it break down.

  • Typical work week 40 x 3 = 120 hrs.
  • Standup meeting – 0:15 x 15 = 3:45 hrs.
  • Sprint Planning – 6 x 1 = 6 hrs.
  • Sprint Review – 1 x 1 = 1 hrs.
  • Retrospective – 1 x 1:30 = 1:30 hrs.
  • Total Time budgeted in meetings = 12:15 hours of a 120 hrs. sprint.

Thus, a developer at worse case scenario spends just over ten percent of their time in meetings.  The remainder of the time is devoted to writing software and creating value for customers.  It is significantly less than in the world of waterfall project management with its numerous meetings to cover everything from architecture to problem-solving.

The scrum master and product owner spend their time in meetings, but it is to protect the team from being distracted from delivering value.  It is why I attend meetings about I.T. governance or architecture so that my team does not have to.  It is why the product owner is answering customer inquiries and meeting management.  We attend the meetings so the development team can concentrate on what is important which is shipping code.

It is why I find the argument that agile has too many meetings disingenuous.  People who are opposed to agile are not opposed to the meetings they are opposed to the routine nature of the meetings and the expectation to ship working code at the end of each sprint.  Transparency of this nature quickly exposes the unwilling, incompetent, or invisible people in an organization who do not deliver value.  When we discover these individuals, it creates a backlash in the organization.

So, scrum and agile does not spend too much time in meetings; it concentrated on what is essential.  An agile team’s first and foremost duty is to deliver value to the business; anything else is waste.  I am looking forward to hearing from you and knowing what you have to say.

Until next time.

Monday, May 14, 2018

Story Points for the Misinformed

It is all about planning poker.
Last week, I wrote a harsh critique of how project estimation is done at many organizations.  I do not like using the words farce and tragedy lightly, but in my experience, many projects devolve into these realms.  This week, I want to talk about story points and how they solve some of the problems I discussed how estimation is broken.

I have written two essential blog posts on story points.  The first was my reappraisal of story points as measurements of difficulty and ambiguity.  The other blog post illustrated how story points could be used to meet deadlines.  Reviewing those blogs, I think they are a clear explanation of the advanced uses of story points.  For those new, to story points, this blog is for you.

Last week I said traditional forms of project management rest on the mistaken notion that time and money equal the same thing.  It means when a project manager or developer gives an estimate and executive treats it like a quotation of work.  The experience is similar to going to an automotive mechanic receiving an estimate for $300 of work and getting a bill for $3,000.  As a consumer, you were expecting and budgeting for a $300 bill.  When confronted with an invoice ten times larger than expected, a person usually falls into a spiral of rage.

Story points defeat this situation.  First, the team members are playing planning poker and are collectively deciding how many points it takes to complete a unit of work.  It is not the opinion of one person be a consensus of numerous technical professionals.  Next, story points are the sum of ambiguity and difficulty of a unit of work.  There is no meaningful way to convert a story point into money or measure of time.  The only things that are certain is a team can complete a specific number of story points in a sprint time box.  The average number of story points completed over at least three sprints is called velocity.  I illustrated in an earlier blog velocity allows executives, scrum masters, and developers a means to forecast deadlines.  Finally, story points allow for severe discussions about scope, resources, and time without having to discuss dollars and cents.

My colleague, Steve Sether, points out story points are not a silver bullet for poorly managed projects.  Story points can be inflated to create the illusion of increasing velocity. Accountants attempt to put a dollar figure to story points and executives often ignore them to make promises without consulting the development teams.

For me, telling an executive, we have 213 story points in a software backlog is much more informative than claiming we can hit an arbitrary deadline.  We can take some action and make more informed decisions rather than rely on gut instincts.  Project estimation should not be farce or tragedy; with story points, a development team and a scrum master have a better way of estimating work and delivering to the business.

Until next time.

Monday, May 7, 2018

Understanding Estimation for the Misinformed

When I speak with business professionals, they often struggle to understand the basics of the agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I am expecting results.  Many times, I feel like am discussing a round planet with people who still think the earth is flat.  These kinds of misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks I will try to explain some of the basic ideas agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  The reason why is many estimates for creative projects is a lie.  The company is lying to itself about what it wants and how much it is willing to pay for it.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying, money is getting spent, and nothing gets into production. 

Project Estimation is farce and tragedy.
The agile manifesto came into being with the twelve principles of agile because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensated, and payroll met a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  For the attentive, you will notice the business executives do not experience the same reality of the front line consumers or employees.  Thus, a software project begins with a pile of money.

The managers and directors once they receive this money then have to figure out how to spend it.  The money comes with plenty of strings.  The project has to meet a deadline which may or may not be grounded in reality.  The plan must work with current technology at the firm.  Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next is something resembling a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams asking how much time it will take them to satisfy the project requirements. The consulting company will bid a price to earn the business.  The internal developers will offer an amount to remain employed.  It goes on until the bidding ends and the project begins.  The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with the limited budget and impossible timeline fail to deliver.  Making matters worse developers are expected to incorporate changes mid-stream and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out for working numerous hours of overtime to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause for this kind of disaster is many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and ability which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week I will show you how that works.

Until next time.

Monday, April 30, 2018

Choose a Growth Mindset

Growth is not easy in this business.
One of the major features of agile is its emphasis on continuous improvement.  Teams, people, and processes can always get better.  If you do a 1% improvement each sprint and perform three-week sprints over the course of a year that equals a 17% improvement by the team.  Many times, small improvements are equivalent to significant increases over the long term.  What works with software development teams also works for scrum masters.  A scrum master should consider continuous growth to be a personal goal in their practice of agile.

I am currently working on becoming a Certified Team Coach.  It has been a time-consuming process with me logging hours and filling out forms.  I reviewed the five dysfunctions of a team and practiced SOLID code development.  I was about to file the first part of my two-part application when someone suggested that I get a pre-screen.  I was deeply disappointed by what happened next.  My screener said the first part of my application would be accepted, but I would ultimately be rejected in the second round because I did not have a “coaching mindset.”  I was disappointed.  It was as if the last five years of blogging, coding and being a scrum master were an empty exercise.  I was given a verbal pat on the head and sent on my way.

After doing some reflection, I went over my notes, and there were some suggestions for graduate-level courses in coaching.  I also spotted a class from the Harvard Business Review on coaching for leaders.  The pre-screener was even kind enough to recommend some graduate-level course in coaching which was local.

Maybe I was not ready.  During this time of reflection, I was exposed to the work of Stanford University professor Carol Dweck.  Her most influential idea is people to be successful need to move from a fixed mindset to a growth mindset.  This very positive idea is one which postulated that everyone is capable of growth and improvement.  Having a growth mindset means that development only happens if people actively seek improvement.  Traditional command and control methods of leadership are less effective than asking questions and having people find solutions rather than having them provided for them.  As I said, it is optimistic.  Professor Dweck can fail students who do not turn in the homework.  Me, I am stuck with product owners who will not write user stories.

I can see a few scrum masters and executives shaking their heads.  Authoring user stories is a fundamental part of being a product owner.  A leader with a fixed-mindset would take disciplinary action or try to teach that product owner to write stories promptly.  A growth mindset leader would ask questions, guide mindset, and follow up with the product owner to get them to improve on their own.  It is touchy-feely and genuinely optimistic.  It also runs counter to how I learned in the field of media and technology.

I was skeptical, but I decided to give it a try.  What happened next was a surprise.  A person responded positively.  They got better at what they did.  They did not improve as quickly as I would have liked, but they did enhance so after four weeks I noticed a difference.  Furthermore, when the person did things which usually triggered in the past, I saw a different motivation.  Now, instead of seeing them attempting to undermine my credibility or authority; I saw them checking for understanding and holding others accountable.  The situation is not entirely sunshine and rainbows, but it is improving.  I should embrace improvement over stagnation.

So here I am attempting to adopt a growth-mindset and continuously improve one small step at a time. Taking a growth-mindset is the next step in my agile journey.

Until next time.