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 announced two new training programs.  This week, I would like to talk about these new programs. 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.