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.

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.

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.

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.