Monday, April 9, 2018

This reformation may take a while

Progress takes time.
  Image courtesy of Pawel Jonca.
The history of progress and social change is rocky.  The first feminists from the Seneca Falls convention did not live to see the passage of the women’s suffrage.  Women would continue to struggle for equal rights and acceptance outside the home and today women in technology face the soft misanthropy of “Brogramer” culture.  It is discouraging that each step forward leads to another pushback from people who feel threatened by that change.  It has been on my mind as I see businesses struggle with accepting the agile reformation sweeping business. 

Like many technology professionals, I receive e-mail messages daily from recruiters.   These individuals want me to sell my home and relocate to remote parts of the country for six to twelve-month contracts.  I ignore these messages politely or reply that I am not interested in relocation.  This week I receive a notice for a “scrum-project manager.”  I was intrigued.  I glanced at the requirements, and this is what I found. 


  • Two to three years’ experience in SCRUM
  • Two to three years’ experience as a BA/Project manager.
  • One or more years of Experience in JIRA.
  • Great Communicator.
  • Organized.
  • Salary 50k to 75K


I did a double take and then attempted to unpack this request.  According to the Scrum guide, there are only three roles; developers, a product owner, and scrum master.  There is no mention of a project manager.  Agile and Scrum according to the manifesto put, “Individuals and interactions over process and tools.”  I appreciate the author of the job post understands that communication skills and organization are not optional for a scrum master.  Finally, the salary requirements are laughable and way below the $100,000 national median compensation stated in LinkedIn.  For a company attempting to adopt agile, this is not a credible offer.

The person who wrote this job requirement should be embarrassed.  The salary is in the lowest percentile quarter of prevailing wages.  The author does not understand the role of a scrum master, and they confuse agile experience with project management.  Anyone who is thinking about this role should reconsider.  It will stunt your career growth, and the company appears to be paying lip service to Agile.

It is my hope businesses will do a better job writing these requirements and recruiting proper agile talent.  Unfortunately, this means executives and human resources professionals still have a long way to go before they understand agile and what it takes to be a twenty-first-century company.  Just like the feminists of Seneca Falls, after seeing job requirements like this, I am afraid that I may not live to see that change.

Until next time.

Monday, April 2, 2018

A sweet and sour career

The stuff of life.
It is the Christian holiday of Easter.  I am spending time with my family and friends.  I am also taking a look back at the start of the year.  It seems like only yesterday, I was counting down to midnight and wearing silly hats.  Now, I am wrapping up the first quarter.  I am unsure where the time goes.  This week, I would like to do a little reflection on the ebb and flow of being a scrum master.

I have repeatedly said on this blog being a scrum master is a calling.  It takes devotion and a touch of insanity to lead software developers and organizational change. I spend my days helping people ship software and then my evenings learning how to be better at my profession.  Someone I respect very much calls it the “sweet and sour” of a career.  Experiencing hardship makes accomplishment more meaningful.

This week I discovered I would be presenting at the Agile 2018 conference in San Diego.  I will be talking about the Cobra effect and how you can fight it.  It is a pretty significant accomplishment, and I am deeply grateful for the opportunity.  It also encourages me that I am not some voice in the wilderness.  I have spent nine years as an agilest, and it is profoundly satisfying that people are interested in the insights I have picked up along the way.  It is a lovely feeling.

The sour is the daily grind of putting out software.  I take calls from India each day.  I work with product owners to help them be successful.  I have created close bonds with my development partners because the pressures of shipping software are enormous.  It is early mornings and late nights.  It is cold coffee and petty arguments.  It is what must be done to create value for the business.

I accept the sour to appreciate the sweet.  Family, friends, and loved ones talk me through the sour times and help me celebrate the sweet.  It is not glamorous or pretty, but I have found meaning in the Agile reformation.  My life is a mixture of sweet and sour.

Until next time.

Monday, March 26, 2018

A lack of skin in the game for employees

From the blog: ON ART AND AESTHETICS
Last week I talked about three types of cultural factors which can make an agile implementation challenging.  I also spent some time catching up with some of my contemporaries discussing the application of Agile at different firms.  It was a disappointing discussion.  This week I want to talk about agile and the lack of follow through in many organizations.

I started thinking about the inability for the organization to improve their agile maturity when fellow agilest David Koontz posted an article from the Harvard Business review about the failure of digital transformation at many firms. It opened my eyes.  I then noticed a new book published by the author Nassim Nicholas Taleb called “Skin in the Game,” about the uneven relationships we create in the labor market.  The most telling passage was the following.

“True, a contractor has a downside, a financial penalty that can be built into the contract, in addition to reputational costs. But consider that an employee will always have more risk. And conditional on someone being an employee, such a person will be risk-averse. By being employees they signal a certain type of domestication.”

In short, being an employee of a large company creates people afraid of risk and rocking the boat. The company through its leadership and culture incentivizes particular behavior.  The employee trades their skills and dependability in exchange for a paycheck.  It creates situations where conscientious people tolerate ignorance and inefficiency because they say, “…that is how we have always done it.” Thanks to this submissiveness large firms stagnate and die.

It also explains to me why agile coaches are contractors.  In the words of Ken Schwaber, agile holds a mirror up to an organization.  Many organizations are not equipped professionally or psychologically to look at that reflection because they would see the incentives they have created are perverse and the services they offer are not meeting customer needs.  It is like being in the Jean-Paul Sartre novel “Nausea.”  The world we know crumbles away, and we see the disorienting reality of how things are working. Confronted with this we have three choices:
  1. Wallow in despair and impotence
  2. Ignore the truth and pretend nothing has happened
  3. Take action and try to make change

The modern corporation incentivizes employees to make the first two choices.  Those who choose the third option either quit or the company fires them.

So as a scrum master or agile coach we are stuck making a change at the margins and moving on when we cannot do anymore.  The global economy continues to spin, and nothing seems to change. It is easy to get discouraged, but the size and diversity of the agile reformation continue to grow.  According to Scrum.org, over 100,000 people are trained at Scrum.  Figures from the Agile Alliance and Scrum Alliance are harder to come by, but eighteen years ago the manifesto began with fifteen people in a ski lodge.   The growth of the movement has been increasing and today’s consultants and practitioners will become tomorrow’s managers, directors, and executives.  It is a matter of time, and the Agile reformation will be driving reform inside the business establishment.

So perverse incentives prevent businesses from being more innovative and agile. The good news is the agile reformation is growing and with this growth will come increasing acceptance.  It will not be easy, but it will be worth it.

Until next time.


Monday, March 19, 2018

Three types of failure in an organization.

When it all goes wrong
I have been spending plenty of time looking at best practices and patterns in software development.  The more I learn, the more I discover knowledge in the field is growing logarithmically.   Thanks to the web, developers and scrum masters can share hard-won wisdom.  Sharing this knowledge makes everyone better at what they do.  We can also gain understanding taking a look at bad practices and seeing how they hurt an organization. 

A maxim in the agile reformation is everyone should be allowed to fail early and often.  Failure is an early building block for future success and innovation.  I see failure as an excellent teaching instrument.  It means an agile practitioner should take a fair and empathetic view of failure and see what we can discover.  Agile practitioners need to call out what works and what does not.  Reviewing bad practices and business failure educates in ways success cannot.

The Cargo Cult

A cargo cult comes into being when individuals create totems and rituals to mimic success without understanding how to achieve that success.  I have blogged about this topic, and it came from South Pacific tribe who built faux airports and vending machines in the hope cargo planes, and Coca-Cola would return.  I see it with businesses who begin a digital transformation but do not want to change their command and control structure.  The open office movement is another excellent example where business leaders hope to improve collaboration and instead ruin employee morale.  The lesson is to discover the “why” and “how” something works before implementing anything in your organization.

Cultural Inertia

If you work at an organization where people introduce themselves by how many years they work for the organization instead of what they do for the firm you are dealing with cultural inertia.  The term inertia comes from the field of physics. An object can remain still or in motion as long as outside forces do not act on that object.  Complex business organizations exhibit this trait.  These organizations get accustomed to doing things a particular way.  These organizations hire and promote specific people.  Thus, when confronted with change they treat is like heresy or deviance.  Managers or executives kill ground-up initiatives.  Digital transformations fail because line employees have no buy-in.  As a coach or scrum master, inertia is going to be your biggest obstacle.

Software Samurai

Software development is a human activity which resists automation.  So far, no Artificial Intelligence can write C# code or take vague business requirements and turn them into working software.  Human beings are messy, complicated creatures.  Smart and talented people are messier than standard employees. Making matters worse is the glorification of the “Hacker,” or “Brogrammer” culture of software development.  It is a worldview which is misanthropic and sexist.  The glorification of a software developer as a disruptor, visionary, alpha-male, shaman and deity has a few consequences.  It creates a toxic stew of smart people who are smug and contemptuous of business partners.  It also makes developers behave like lonely samurai willing to show off their skills only to other developers in battles for supremacy.  By following “the way of the samurai,” these developers ship poor quality code which does not meet business needs and impossible to maintain.  When called out for this conduct a samurai will say, “If they were good enough a developer they could maintain that code.”  Samurai coders are why agile fails at the team level, and it is up to a coach and scrum master to help these individuals reform their ways.

So here are three ways agile can fail in an organization; cargo cults, cultural inertia, and software samurai.  Each of these situations spells doom for your agile maturity.  Be on the lookout for these examples of failure. 

Until next time.

Monday, March 12, 2018

XML Substitutions in Visual Studio Team Services.

One of the biggest challenges as a software professional is staying on top of the latest development practices.  I have been fortunate to be part of the Chicago Application Lifecycle Management group and know people like Donovan Brown who have shown me the power of continuous integration, dynamic releases, and using Visual Studio Team Services to reduce deployment time to a matter of minutes.

Today, I want to share with you a technical blog on how the management of configuration files is a breeze in Visual Studio Team Services (VSTS).

The first thing a rookie developer learns when they start working is NEVER HARD CODE ANYTHING in an application.  It is a significant anti-pattern, and it will make your professional life miserable.  To avoid this anti-pattern, .NET developers use App.Config and Web.Config files to save file paths, database connection strings, and variables which change sporadically.  When a Vice President or network administrator needs a change, the development team can correct the file without having to recompile the code.  Afterward, everyone involved can get back to business.  It was a great approach if you have one environment and one file to change, but many firms have multiple settings for development, testing, and production.

A developer has three options:
  1. Keep three separate files and maintain each of the files separately which is prone to error.
  2. User XML transformations in Visual Studio which is less prone to error.
  3. User XML replacements in VSTS or Team Foundation Server.

The first option is a recipe for disaster because you have to maintain three files and have an obsessive attention to detail.  I have lost numerous hours of sleep making file comparisons to find a configuration error.  The second option works, and I include a link how to do this from Microsoft.  The drawback is a developer must build the application three times; once for each environment.  It could create a situation where code may have the correct configuration file, but the compiled code may not match it.  The final option is the best because we perform one build and the configuration files change based on where the code is deployed.  The rest of this article will focus on how to use this approach successfully.

This example is a simple MVC 5 application which I am deploying to a staging/UAT environment.  Treat this as a “Hello World!” example of how you can do this in your organization.










In the web.config file create a variable which will change depending on the deployment environment.




Next, write a scrap of code to display that information in your MVC application.  Note: this code will break a unit test do not use this approach in professional code: see this link for more information. 



This next step is where the magic happens.  My network administrator installed the agent on servers and created development groups.  Navigate to the library tab and create a variable group by selecting the button labeled “+ Variable Group.”  Once you have done this, give the variable group a meaningful name.  In this example, I use “Development_Variables.” After providing a detailed description of the group, select the “+Add” link.  When you select the button, an inline form will appear; provide a name and then a value.  It is a key value pair which makes it possible to match the values in the Web.Config file.  Make sure the name of the variable matches exactly the spelling and case sensitivity in the Web.Config file, otherwise the transformation will not work.  Repeat this process and name the other variable group “UAT_Testing_Variables.”

Now that we have variable groups for each environment add them to a release pipeline; select the release tab in VSTS and select the “+” sign; “choose “Create Release Definition.”



You should see a screen similar to the one above.  For this example, I used a simple IIS Website deployment.  I add the build to the artifacts section then I create a deployment process.



The important part is in the IIS web deploy task.  Make sure the checkbox XML variable substitution is selected.  Select the variable tab in the pipeline chose the link “variable group,” button then pick a variable group you created in the earlier process.  Make sure the scope is “Environments,” and then set to “Development.”



The variable tab should look like above and when all these settings are made you are ready to test; kick off a build in VSTS.  When the build is finished, the code will be deployed to the development environment.  Upon a successful deployment navigate to the website on the development server.  The variable on the front page should be the same as variable defined in the variable group.

Using this process, you can maintain variables in VSTS without having to worry about configuration files and the variable groups can be secured via active directory.  Finally, configuration changes can be deployed without having to recompile code.  Thanks to VSTS and XML substitutions you have a smooth and error-free way to speed up the development process.

Until next time.



Monday, March 5, 2018

Watching the changes roll by

Heraclitus would be pleased
The Greek philosopher Heraclitus has a special place in my heart.  He was one of the first thinkers to observe the importance of change, and he coined a slogan which business people use each day.  Heraclitus said, “The only constant in nature is change.” This maxim in philosophy and business got a bit of a work out this week as the Scrum Alliance and Scrum.org announced two new training programs.  This week, I would like to talk about these new programs.

Scrum.org announced a new class and certification called Professional Scrum with Kanban.  My initial reaction was skepticism.  Kanban is widely discussed among agile practitioners and understanding how to do it properly is part of learning Scaled Agile Framework for Enterprise (SAFe).  I was confused.  With this wealth of information, why would anyone want or need a class on Kanban and scrum?  It occurred to me people learn in different ways.  Some individuals can handle self-directed learning on Kanban.  Other people, will benefit from classroom training and the guidance of an experienced trainer.  So, a course on Scrum and Kanban is not so strange or confusing. 

The next big news in the agile world is the scrum alliance announcing the Advanced Certified Scrum Master and the Advanced Certified Product Owner credential.  I was much less skeptical about this news.   I worked as an agile developer for four years before becoming a certified scrum master.  The credential gave me instant credibility with hiring professionals and with executive leadership.  What the training did not provide me were some of the soft skills I would need to be a more successful scrum master.  Abilities like active listening and creating a dialog with stakeholders were skills I would discover by trial and error.  The advanced program from the scrum alliance provides a solid background in the basics and the skills required to spread the use of agile to other parts of the business outside of technology.   As someone who has been a CSP for the last four years, I wish I had this training during the early portion of my career.  Now the scrum alliance is offering it, and it is a positive development for those who know the basics but wish to be more successful.

Any training and development from the agile community is a good thing for the people out in the field.  The sharing of knowledge and information between the different licensing bodies also creates a cross-pollination of ideas.  It prevents the practice of technology and project management from getting stagnant.  I use approaches from SAFe and scaling scrum with scrum side by side. I have to deal with waterfall budget processes and graft them to scrum teams.  Finally, I deal with business partners who think everything I do is magic.  I need all the training I can get to be successful and deal with those challenges.

Heraclitus was a teacher.  This founding father of change spent his time educating others about it.  If agile is to continue to grow and spread; its practitioners need more opportunities to improve their skills and gain knowledge.  It means these new courses are good news about the health of the Agile reformation.

Until next time.

Sunday, February 25, 2018

Incomplete leadership is good leadership.

The world has plenty of leadership styles there are leaders who inspire fear and others who foster deep admiration.  The spectrum streams from the sublime to the ridiculous.  My thoughts on the subject have evolved over the years.  I have experienced many forms of leadership and what strikes me most is this notion of the “mask of command.”  According to this theory of leadership, a leader must create a persona of command which conceals weakness from people who they work. This week on the blog I would like to do a little unmasking.

I was an early proponent of the “mask of command.”  I would have an air of authority and credibility.  Anyone who has worked with engineers, creative professionals, and medical workers will quickly realize this is folly.  All of these groups are exceedingly smart, and all of them have been trained to be skeptical.  They know when you are putting on a mask and when you are inauthentic.  Once this lack of authenticity is detected, these kinds of professionals will tune out. 

Since professionals are not receptive to the mask of command, there has been a myth created around leadership.  Leaders of organizations must be “complete.”  They must have experience in the industry, work their way up the organization, and have the perfect mix of personal traits to succeed.  It has fostered a leadership style which discourages innovative thinking.  Bland and uninspiring leaders advance because they reflect the status quo of their organization.   They are not leaders but rather caretakers of their organizations.  The corner office and perks of executive leadership are enough to keep these individuals content.  If they are lucky, they will retire and let someone else do the necessary organizational change.  It is how organizations wither and die.

If the mask of command creates inauthentic leaders and the desire for perfect leaders creates uninspiring leaders what should a scrum master or agile coach aspire?  I have been thinking about this for some time.  It did not become clear to me until I read Deborah Ancona's essay in the Harvard Business Review, “In Praise of the Incomplete Leader.”  In her essay, Ancona talks about the myth of a perfect or complete leader who in her words is a “…flawless person at the top who’s got it all figured out.”  Today, organizations with their inherent complexity and global reach require “incomplete,” leadership who can delegate their weaknesses and play up their strengths.  Leaders do not have to be the perfect fit instead they should be good enough to help the organization.  Instead of the emperor or general, a leader is more like a therapist or pastor to support the organization see a better way. 

Ancoma goes on to describe four leadership skills every person has in varying degrees: sensemaking, relating, visioning, and inventing.  Those traits overlap each other, but it is clear to me that if you are equally good at all four of these areas, you are not good at any individual area.  Steve Jobs was fantastic at visioning; he was lousy with people and relating.  George Patton had great sensemaking and scared the pants off the German generals.  He was also insubordinate and bad at relating with his troops or commanders.  Meg Whitman took the chaos at HP and used her sensemaking and relating skills to improve the organization.  Not any of the leaders, I cited were “perfect.”  They were flawed and human.  They were good at certain things and delegated everything else.  It is why I think Omar Bradley was the best thing to ever happen to Patton. 

As a leader and scrum master, we need to accept we are imperfect.  I excel at sensemaking and visioning.  I will admit my shortcomings. I struggle with relating and inventing.  Only by acknowledging these vulnerabilities can we build trust, and to succeed trust is essential.  We also need to accept that each leader is incomplete.  Some will hide behind the mask of command, and other leaders will feign equal competence in these four areas of leadership. 

I have a different vision of leadership.  It is one where the masks fall away, and smart people work together for a common goal with a sense of trust.  It may be a little touchy feely but if it is good enough for the Harvard Business Review it is good enough for me. 

Until next time.


Monday, February 19, 2018

It is worth it!

The work is worth it.
I have been doing plenty of reflection.  I blame the dispiriting winter season in my hometown of Chicago.  The cold winter nights force you to confront your past and ponder your purpose.  My friends and social media contacts are asking me plenty of questions about my weird profession.  These kinds of existential moments make me want to do a little explaining.

I joined the agile reformation in 2009.  I was working as a contractor for a family run medical supply company.  I was thoroughly miserable.  I had no job security and little hope. I spent each day grinding out code for capricious people who treated everyone not family as medieval peasants.   Family disputes would boil over on to the sales floor, and anyone caught in the crossfire could lose their job.  It was such a dispiriting place to work.  I witnessed the ten-year-old grandson of the founder tease a salesperson saying, “Daddy says you are fired.”

In the middle of this night of the soul, a project manager decided the team should try “agile.”  It began with daily stand-ups and doing releases in two-week chunks.  It ended with unemployment.  The project manager left for a better job.  The IT Director realized I had more credentials than he did so I was a threat, and it made me expendable.

Between job searches, I did research and the more I learned about Agile, the more I realized it was a better way to lead software projects.  I also realized that the concepts while simple to explain were hard to implement.  Thanks to the Agile Manifesto and the early proponents of the scrum, there was a way to perform technology work without abusing people and providing better value to the business.  I would spend the next four years as a developer spreading the word about this new approach.

Things finally came to a head when I left my last role as a senior developer and became a scrum master full time.  I was no longer some developer mentoring others.  I was leading other teams and setting an example.  I thought I was ready.  I was wrong.  Over the last five years, I have been tested and challenge in numerous ways.  I have succeeded in public ways and failed in equally public fashion.  I am not the scrum master I was five years ago.  Everything I have learned along the way has made me better.

I keep thinking about a quotation from Dave Burgess I tweeted out last week.


The last nine years of my agile journey have been challenging, but it has been worth it.  I am a better leader.  I am a better developer.  The software is getting shipped on time, and the office is a little less capricious.  I do not have entitled ten-year old’s threatening to fire me, and the business community seems to be catching up to my way of thinking. 

This hard journey is probably worth it, and I am proud to be sharing it with you.

Until next time.

Monday, February 12, 2018

Flying my Pirate Flag

I am letting my pirate flag fly.
Being a full-time scrum master or agile coach is a labor of love.  An agile coach needs devotion.  The successful scrum master needs to do more than manage the version control system.  At times, they need to act like Don Quixote jousting at windmills.  All the time, they are they misfits in the organization attempting to get it to improve when inertia governs the corporate culture.  It is very lonely, and it requires reservoirs of passion which many people do not possess.  This week, I talk about the passion for being a scrum master.

It takes a unique individual to get up before the sunrise and make a phone call with a group of developers half a world away.  Additionally, that person spends hours to coordinate product owners and executives so that those developers can work efficiently.  A scrum master handles this responsibility with no authority, everyone involved has the right to say no; It takes a particular kind of person to lead and facilitate this type of activity.  It requires passion.

Being human beings, we are creatures guided by emotions and reason. The modern business has toxic emotional situations and pressures to perform.  Over time, it leads to burn out and passive-aggressive behavior.  A person does not give it their all because it will not make a difference to our bosses or the organization.  Only the application of passion can get someone through the day.

Currently, I am reading a fantastic book by Dave Burgess entitled “Teach Like a Pirate.”  Using techniques he has developed over his career as a teacher, Burgess talks about how to be a better teacher using techniques to build a passion for the subject, build rapport with students, and create situations where enthusiasm can triumph.

What is refreshing is Burgess, knows the difficulty of teaching and how high school students can be the most terrible room for any professional.  What is interesting, is that one of the first things he talks about is the need for passion.  He is also brave enough to admit that he cannot be brimming with passion every day.  He calls people who do freaks.

So unless they are all freaks, how is it that outstanding teachers can maintain a passion for what they do?  Burgess gives a simple answer, and that is to ask questions about what inspires passion in a person. The first question is what subject areas in your field of expertise excite you?  For me, it is metrics and measurement of continuous improvement.  Nothing is more satisfying than putting an easy to understand chart on the wall explaining the team is improving.

The next question is what part of your job is the most satisfactory?  It is the reason you keep doing it.  I have written about this for years.  When software ships and the team feels like they have done a good job is what keeps me taking the call from India each day.  The final question is about personal passions.  For me, it is board games, family, friends, craft cocktails, and good food.  Those things provide me with inspiration and love for what I do.

So in the lonely world of a scrum master or agile coach, it helps to find your passion daily.  With Dave Burgess and “Teach Like a Pirate,” I might have seen a means to do that.

Until next time.

Monday, February 5, 2018

Five simple steps.

Constraints matter.
I have been involved with Agile for nine years.  One of the greatest discoveries of my agile journey is the realization that I am learning new things and continuously improving the way I conduct my servant leadership.  I was encouraged to read Eliyahu M. Goldratt’s, “The Goal,” and it exposed me to the theory of constraints.  Now that I have finished the book I have a few thoughts on the subject.

I have written about the theory of constraints in the past.  The main gist of the book is to identify bottleneck or limitations in an organization.  Once you find a restriction, work can be done to mitigate the effects of that obstacle.  It seems common sense, but in the rush and frustration of our daily jobs, we often miss these common sense approaches.

Goldratt shows his most revealing insight. The mitigation of constraints follows a clear and easy to reproduce the process. The process is as follows:
  1. Identify the system's constraint.
  2. Decide how to exploit the system constraint
  3. Subordinate everything else to the above decisions
  4. Elevate the system constraint
  5. If in the previous steps a constraint have been broken return to step 1, but do not allow inertia to cause a system constraint.
Five steps and it does not matter if you are working in a machine shop or managing a bunch of creative professionals, a person can improve the efficiency of a process.

I have been struggling with the notion of exploiting and subordinating a constraint.  Fortunately, the theory of constraints has plenty of academic support and an excellent blog about these five steps.  I look forward to using them at my firm.

Until next time.


Monday, January 29, 2018

Empathetic relations come before education

As an agile coach and scrum master, I find myself in a peculiar place.  I have been with one organization for five years, and I am unable to increase their agile maturity.  We are stuck.  We are going through the motions of agile but work is not sustainable, and dysfunction exists between the business partners and the development team.  This week, I face an agile implementation which is stagnating.

As an agile coach and scrum master, you need to take a hard look at yourself and how you do your job.  It is lonely and unforgiving.  You need to evaluate how you can improve and how you help others.  In many respects, you are acting like a teacher, therapist and camp counselor. 

Where do teachers go for support?  How do therapists deal with human suffering without being crushed by its weight?  What does a camp counselor do when they cannot be enthusiastic?  The answer to all of these questions is they depend on the support of peers and more experienced professionals.  There is an entire branch of therapists who treat other therapists.  Teachers have support groups and working teams.  Camp counselors rely on directors and adult leaders for support.

Scrum masters are very alone and are misfits in many organizations.  They belong to a company, but they spend a majority of their time fighting the corporate culture to meet goals.  Their managers misunderstand them and because they do not have any real authority often ignored by others.   For me, I depend on the support of others from the agile coaches’ symposium in Chicago.  I count on my immediate manager and interact with other coaches on LinkedIn. 

I depend on these people like a drowning person clings to piece of driftwood. Leading organizational change requires the stamina of an Olympic athlete, the patience of Job, and the self-esteem of Rod Blagojevich.  Few people have all three of these traits.  It is why I have to depend on the coaching of others.  It is a both a means to improve and receive the support I need to get through the day. 

Currently, I am dealing with exceptional levels of toxicity from business partners.  The situation has deteriorated so much one product owner will not speak to me directly but will tell someone else to convey information to me.  It may be acceptable behavior for mean girls in high school but is outrageous for a business person to act in such a fashion.  All I can do it take responsibility for this professional failure and make the best of the situation. 

Someone I respect said, “Empathetic relations come before education.”  This week that message clobbered me like a sixteen-ton weight.  Crushed by this new knowledge and experience, it occurs to me that I can not just attempt to teach others the skills of agile with the power dynamic of a teacher to a student.  For greater agile maturity at an organization, the coach needs to relate to the business partners as peers. 

If agile is going to grow then, people must want to be open, committed, focused, courageous, and respectful.  It is now clear to me I cannot use the coaching style of a movie director or drill sergeant.  I cannot be a teacher at this stage.  My knowledge needs to be offered as a friend.  If not, then agile will stagnate and not mature at an organization. 

A failure is a useful tool.  It educates more than any success possibly could.  This week, I experienced a failure I might not recover from at my current firm.  Whatever the future might bring, the lessons are going to stick with me the rest of my career.

Until next time.

Monday, January 22, 2018

The Social Compact of Agile

If you don't set priorities your office could be like this.
From the Iron Mitten web site.  
One of the biggest challenges in technology is there are not enough people to do all the necessary work.  Only about 18.5 million people in the world of 7.4 Billion people can maintain software and modern computer networks.  That means that less than .05% of the world have the skills to keep the global economy spinning. It would not happen without dedicated project professionals and smart technologists holding everything together.  Without prioritization, the gears of the industry would grind to a halt, and that is what I want to talk about this week.

When Thomas Hobbes wrote “The Leviathan,” in the aftermath of the English Civil War; he spoke about something called the social contract.  The social contract to Hobbes was an unwritten set of rules where individuals traded their liberty with the state in exchange for safety and protection.  Ignore the social contract, and society would collapse, and philosophers and social scientists still use the idea of a social contract to explain how communities work.

In the world of business, we also have social contracts.  People who have more authority have offices instead of cubicles, so they meet with people in private.  When it is time to distribute profits, shareholders receive preference over employees.  Finally, no one gives human resources any trouble because they have the authority to hire and fire anyone.  None of these rules are written down, but we all know they exist.

In agile, there is one social compact.  The product owner sets the priorities, and the development team says how long it is going to take to do the work.  The developers may disagree with the preferences, but they have to accept them.  The product owners may not like how long it will take to do the work, but they have to agree with them.  It is the trade-off which makes agile work.  If neither the developers nor the product owner respects this setup, then the implementation will fail.

It is well and good if you have only one project and one team.  What happens when you have multiple projects and not enough teams to do the work?  It is when prioritization becomes more critical.  Business leaders need to be part of the process, and they need to know what is being worked on and when.

There are plenty of processes to set priorities.  The most significant challenge for me is the mindset of the business of professionals.  Sales and marketing professionals are trained to think each “no” is one less objection to “yes.”  It is admirable for a sales professional; it is madness for a large organization as self-interested and selfish people scratch and claw to “yes.”  Projects hopscotch up and down in priority as developers struggle to stay ahead of the shifting needs of the organization.  Unclean code is released to production because someone needed a feature released “today.” I continue to struggle with this challenge.

So as a scrum master or agile coach, you need to enforce the social contract of agile.  That social contract is product owners set priorities and developers say how long it is going to take to do those priorities.  If you can do this, you just might succeed.

Until next time.



Monday, January 15, 2018

Smoke detectors explain technical debt

Should have checked the smoke detectors.
Since the holidays, I have made a point to spend time with people outside the technology field.  This experience has been beneficial because I spend my time explaining what a scrum master does and how we do it.  This review of the basics is allowing me to reflect on work and how to make it better.  It is a fresh perspective which has allowed me to look at old concepts in a different light.  This week I want to revisit technical debt.

I own my own home.  Since I am a homeowner, I have smoke detectors.  These little battery powered devices warn me when there is a fire or when I am burning a roast on the stove.  So smoke detectors offer protection to a homeowner so they can escape the house quickly and call the fire department.  Smoke detectors are so useful you receive a discount on your home insurance if you have one, and, in some municipalities, you are required to have at least one in your home.

Smoke detectors have one significant drawback; they are battery operated.  When the batteries run out, and a fire breaks out you are helpless.  The smoke detector companies fix this by forcing the alarms to “chirp” which is a friendly reminder to change the batteries.  This week, I awoke to my smoke detector “chirping” at 2 AM in the morning.  Like many men my age, I attempted to roll over in bed and ignore the situation.  Ninety minutes of insomnia later, I wandered the house searching for batteries to replace the faulty one in the “chirping” detector.

The next morning over an extra cup of coffee, it occurred to me that I treated my smoke detector like many organizations treat technical debt.  I do not change batteries until I have to and usually it is at an inconvenient time.  Fortunately, being a former boy scout, I was prepared with batteries in an easy to find location.  I swapped out the batteries and went back to bed. 

If you are a homeowner, you have four strategies to deal with smoke detectors.

  1. Change all the batteries at once typically during daylight savings time.
  2. Change individual batteries when they run out of charge and begin chirping.
  3. Ignore chirping smoke detectors until you get fed up and change the battery.
  4. Remove and disconnect all the smoke detectors and hope you never have to deal with a fire.

As a homeowner, I use strategy two and three.  I know others who use the other two approaches.  Swap out smoke detectors and batteries, and you have the four classic strategies companies use to address technical debt.

The most efficient way to deal with technical debt is to follow the first strategy by changing batteries and updating systems on a regular basis.  By doing this, you reduce expected outages.  Agile and scrum encourage this approach.

Many CIO’s and managers I know consider this madness because there is a not enough time, money or people to keep updating systems.  It means they rely on strategies two and three.  It may be suitable for a chirping smoke detector on a cold night but is lunacy for a multi-billion dollar enterprise.  It creates situations where firms could lose millions of dollars while they wait to bring systems back.   

So the next time someone looks are you funny when you talk about technical debt just explain it to them like changing the batteries in a smoke detector.

Until next time.

Monday, January 8, 2018

Eat up

I feel like a shark!  "Chomp!"
Social movements and organizational change are difficult to measure, and it is particularly hard to do in the world of business.  The business press concentrates on investing and accounting.  Since the beginning of the agile reformation, those of us involved in the change have openly wondered if we are making an actual difference.  As 2018 begins, it looks like agile is becoming mainstream and successful.

In 2011 a famous editorial appeared in the Wall Street Journal, It was titled, “Software is eating the World.”  The principal thesis was for companies to succeed they have to behave more like software companies.  It was a daring argument.   The seven years which followed have vindicated that notion.  Google, Tesla, Amazon and a funny project called Bitcoin are dominating headlines and the business community.

Tesla is still struggling to meet its production commitments and Bitcoin, to me, feels like a blue sky stock but what all of these firms have in common is a willingness to innovate, iterate, and move fast to satisfy customer demand.  Even companies who lost their way are embracing blockchain technologies, cloud computing, and rapid software development. 

It is satisfying to know that my career choices have mirrored changes in the business.  While business is changing business leadership is struggling to keep up.  Organizations charts still matter in many places.  Command and control measures which existed for years are difficult to discard, and inertia prevents most organizational change.

It has created a quandary and spawned an entire industry of coaching and consultants, who are attempting to show others how to do business with the agile paradigm.  What these coaches discover, is a business is a social construct along with a business entity.  The ego of a director may be more important than the needs of the company.  Board members excuse a lousy quarter because they golf with executives.  Whole industries condoned sexual harassment and assault as long as the abusers generated revenue.  

Which is why I find the turnaround at Microsoft so fascinating.  They went from a sales culture under Steve Balmer to an engineering culture under Satya Nadella.  After product failures like Zune, Vista, and Windows Phone, the organization decided to place its future in the hands of a software engineer who felt building better products was the path to commercial success.  It is a gamble which has paid off handsomely.

Microsoft has embraced Agile, and it is paying enormous dividends.  That is why this week an article appeared in Forbes called, “Agile is eating the World.”  The reformation is growing, and the success is getting noticed.  It is a satisfying development to me.  I am no longer a lonely missionary in the wilderness, but a professional at the table is making a difference.  It is nice to see the times change.

Until next time.

Monday, January 1, 2018

Saying good riddance to 2017

Would you invite these two over for dinner?
This image captures 2017 better than anything else I have seen.
I want to say good things about 2017; I really want to do it.  The sad reality is that the last year was the equivalent of inviting guests over for a dinner party and they allow their toddler to break your china and defecate on your tablecloth.  The world of politics, business, and agile felt like that disgusting and awkward dinner party.  This week, I take a look at last year’s predictions and look ahead to 2018. 

My first prediction came true in ways I did not expect. The new president and the Republican Party kicked off a wave of deregulation. It was not your garden-variety deregulation typical of GOP control of the White House; this was something radically different.  The Secretary of Education had no experience in educational administration.  The new Secretary of Energy on the campaign trail demanded that the department is dismantled and then used his position to promote the interests of the fossil fuel industry.  The head of the EPA is building a secure secret office and treating the organization he is leading as a security threat. 

By far, the most egregious in a colorful cast of characters is Treasury Secretary Steve Mnuchin.  The Goldman Sachs alumni made a career exploiting financial regulations and staying one step ahead of regulators.  Now he is in charge of those rules, and it looks like a repeat of the events which led to the great recession of 2008.  Adding insult to injury is his spouse who has appeared in public with the personae of a Walt Disney villain blended with a trust fund sorority sister.  Her words about how she and her husband do more for the economy are going to live forever in history books written about this period. 

My second prediction was the brief life and death of Net-Neutrality.  Ajit Pai served on the FCC board and said net-neutrality was unnecessary in 2015 when the board supported it.  With the election, he and the Republican members became the majority on the FCC board, and the net neutrality rules were repealed.  In spite of 22-million comments supporting net-neutrality and opposition by 80% of the public, the repeal went through.  It is going to be a considerable give-a-way to companies like Comcast and Verizon.  It is going to hurt innovation and turn internet service providers into protection rackets charging businesses and organizations extra to have high-speed service.  I hate this turn of events and will work with my elected officials to reverse this decision. 

So that was last year, what trends are we going to see in 2018.  I forecast three events. 

Democrats Resurgent?

I made a political prediction in 2016, and the election threw it back into my face.  This time around I am going to say that Democrats have a credible chance of retaking the Senate and the House of Representatives.  Plenty of things can happen between now and November, but if Democrats are smart, they might have a chance.  Some credible polling and research are showing this might happen.  If it does happen, I hope the new Congress will attempt to unwind, the budget-busting tax cut and work on regulating the internet like a utility so that net-neutrality does not come and go with each regulatory change of power. 

The Battle of Home Assistants.

Google and Amazon began a pretty and bitter war last year, and it will get worse in 2018.  The competition between “Alexia” or “Google Home” will get more heated.  It should be good for consumers, but it is going to be a mess.  Home thermostats, lights, and even appliances are going to be affected by this conflict.  It is a battle for billions of dollars in revenue so grab some popcorn and enjoy the spectacle. 

I will own my brand.

For me professionally, 2017 was a tough year.  Thanks to the good folks at the Agile Coaching Symposium in Chicago, I realized that I am part of an elite group of professionals.  We are a caring, creative, and hard-working group of souls who just want to improve how people work.  I am going to embrace that community further.  I am going to put in for my Certified Team Coach credentials from the scrum alliance.  I will also try to become a presenter for the Agile Alliance in fall.  I hope to learn more about LeSS and how it might help my organization. 

So that is my take for 2018, I look forward to sharing it with you. 

Until next time.