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.

Machiavelli knows agile.

Machiavelli, knows some things about agile.

The agile reformation is all about satisfying customer needs, improving product quality, moving quickly and maintaining a sustainable pace of work.  These differing prerogatives require changing the way we think about work and looking at problems differently.  It means for agile to be successful a scrum master or coach must lead change.

Many times, I feel like Don Quixote jousting at windmills around the office. During a down period, one of my product owners pointed out a quotation from Machiavelli.

“It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success than to take the lead in the introduction of a new order of things.” 

Leave it to the prince of political manipulation to provide me with some fodder for my blog.
Change is hard because people prefer to have routine and ritual in their lives.  Also, people who benefit from the way things are will resist change because they might lose authority, money or status.  It is easy for individuals to see reform as a zero-sum game with a gain for someone else equal to a personal loss.  It is a pathology which I see in both technical and business professionals.

On the business side, it is a huge culture shock to work side by side with technical professionals.  Now they discover the systems and technology they take for granted is not the result of magic.  They collaborate on the authoring of requirements, and they have “skin in the game,” when it comes to the success or failure of an initiative.  No longer will the alibi of, “…it is technology’s fault,” work in an organization behaving in an agile fashion.

The rapid feedback is a benefit to both the business people and technology staff.  It avoids “death march” projects.  The days of building software which does not drive value to the business disappear with each iteration.  A software project can quickly pivot to new regulatory or market needs.  Finally, the CFO will see a reduction in cost overruns and failing projects.

Agile not only changes the business professionals who practice it; agile changes technology professional who follow it.  Developers begin to understand the challenges the business faces.  An engineer sees business partners as equals and worthy of respect. Writing unit test and performing automated deployments build trust with business partners as bugs and defects decrease.  The arrogance of software professionals being the smartest people in the room gives way to the humility of helping others succeed.  The hacker ethos of development gives way to a more professional perspective.

Agile is not perfect.  The reformation is only eighteen years old, but it is growing and improving.  It is starting to become the de-facto technique of doing new software development, and it is spreading to other areas of business.  Change is perilous.  Getting knocked off your horse is not fun, but nothing worth doing is easy.  The reformation is not going to stop and you either lead, follow or get out of its way.

Until next time.

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.

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.