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.

“Roar!”

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.