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.