Avoid Heroism and Practice Radical Interdependence.

Anyone who tells you leadership is easy is either a liar or a fool.  Each day leadership is tested by interpersonal disputes, market demands, and gaps in knowledge.  People count on leaders to have emotional balance when everything is going wrong.  It is facing difficult questions when you do not know the answers.  You must be firm one moment and understanding the next.  When things go well, you give credit to others, and during failure, you take responsibility.  Leadership is one of the most challenging skills to cultivate.  It is a duty and calling rather than a heroic struggle.  I want to discuss it.  

Leadership is more than a stance.

We often train a leader at an early age.  Young people become captains of sports teams or members of the student government.  Junior ROTC programs do an excellent job of teaching the skills of leadership and followership.  The early training in leadership is beneficial, but over the last thirty years, I have discovered that it is incomplete.  For the last two hundred years, we have expected leaders to have answers to every challenge and be able to motivate others.  A leader formulated a plan, and the followers executed the project.  Today, in a global and creative economy, this is no longer true. 

A contemporary leader must depend on others with specialized knowledge.  A deep understanding of the law, finance, computer software, logistics, and marketing is impossible for one person to gather in a lifetime.  Today, a plan requires multiple people to formulate and execute.  The contemporary world is too complicated and chaotic to come up with natural solutions.  

It is why I discovered a TED talk from South African food executive Lorna Davis.  She talked about how she bought into the myth of heroic leadership.  She also found heroic leadership did not effect change within her organization.  People applauded her works and went about doing the same things they did before she joined the organization. Heroic leadership failed.  She goes on to mention that a new model of leadership needs to develop, and she called it “radical interdependence.”  A leader should have a goal, and it is up to the team on how to achieve that goal.  It requires listening, empathy, and giving others a chance to excel.  It is anything but heroic.  

I did not realize I was using this approach when I confessed during a meeting I was stumped.  I did not know how to address a quality problem, and I asked, “Anyone have any idea how we are going to fix this?”  Within a day, I had answers, and the leaders at the off-shore office were implementing them without checking for permission.  The off-shore team knew if I disapproved, I would let them know, so they decided to take the initiative.  I am confident our quality issues will clear up.  

Radical interdependence requires trust and allowing others to come up with solutions.  It involves a surrender of control, which many successful people find uncomfortable. It relies on asking questions instead of giving orders.  It is physically and mentally exhausting because you are stretching your emotional intelligence and practical knowledge.  You are learning and growing with the people you are leading.

Leadership is the most challenging skill a person can acquire, and it is impossible to master.  It is clear why the military calls command a burden.  Each day you are tested, and failure can mean the loss of millions of dollars or even lives.  I think Lorna Davis has some useful guidance about leadership.  I am going to ignore the liars and fools.  

Until next time. 

Self-Organization Works If You Let It.

Teams cannot be assembled like Lego bricks.

I spend much of my time working with agile teams.  A big challenge is often these people are thrown together and forced to behave as a “team.”  The self-organizing team is one of the most critical pieces of an agile project, and it is one of the hardest things to create.  I wanted to spend some time discussing why building teams is so difficult.

In most business environments, a team is formed by hiring consultants and putting them together with existing employees.  The team is broken up, and the consultants are laid off or moved to a different project when work is complete.  The approach from an accounting perspective might make sense, but it creates plenty of unnecessary work.  Teams are continually going through Tuckman’s stages of group development and are in the “storming” stage of team maturity.  In a more agile environment, work comes to teams, and then the teams do the job.  The group moves on to a different project when they finish work.

According to the Harvard Business review teams which stick together have a 19% decrease in defects and 30% decrease in budget deviations.  The bottom line is that spinning up units and disbanding them is a foolish use of company money.  So what makes the team self-organizing?  Yvette Francino has an excellent blog on the subject.  In short, teams which self-organize have a few properties:

1. They hold themselves accountable for success and failure.
2. They healthily handle conflict.
3. They have a common goal which they strive to achieve.
4. They have a standard way of working.
5. Finally, they have stable membership.

These traits make an excellent self-organizing team, and it is up to agile coaches and scrum masters to hold them accountable.  Notice that these requirements do not mention test-driven development, SOLID Development, or other technical paradigms.  Most of these skills are soft skills.  It means that a team needs to learn how to work together outside of the technical skills, and this is difficult.  People have egos and subtle hierarchies of expertise and authority.  Add to the mix unrealistic deadline pressure and micromanagement from outside leadership, and you corrupt the five characteristics of self-organization.

So look toward creating more functional teams and allow upper management to understand how they are more successful.

Until next time.

Transform at the speed of the Team

Coaching is more than presentations.

Software development is not rocket science; it is a branch of engineering but, it is not rocket science.  I say that because rocker science depends on the laws of chemistry and physics which have not changed since the big bang.  Software development is changing daily.  Javascript libraries are constantly being updated and going in and out of fashion.  Versions of PHP change and open source code is in constant flux.  Finally, software development is dependent on the fickle demands of consumers who use it.  The level of chaos and change are staggering.  It is why software development is such a challenging profession.  As a scrum master and coach, you must understand those challenges and guide development teams through the process.

One of my favorite pieces of journalism is Bloomberg’s weighty essay entitled “What is Code?” It talks about the person in the taupe blazer and the frustrations of software developers.  It also does a great job talking about the headaches the executives who manage software developer face.  The essay captures perfectly how smart people struggle daily to get dumb machines to act intelligently.

The world of software has tremendous power, but that power belongs in a small subset of the world population.  I calculated that less than .05% of the global population of 7.4 billion could maintain software and computer networks.  Many of these individuals work in the quiet recesses of government and business keeping things running.  They go home to families and friends.  They pay bills and try to live their lives as best they can.

Because of the laws of supply and demand, computer professionals receive large compensation, but the compensation comes with a trade-off.  The trade-off is long hours on uncompensated overtime and business leaders expecting them to perform magic.  It creates conditions which lead to poor quality and burn out.  I have experienced this situation as a developer and as a manager.  As a customer, I have stumbled on numerous situations where fatigue, complexity, and unrealistic expectations have combined into a poor product.  The history of the internet contains plenty of companies which had a few pixels and an unhealthy dose of hype.

Technology professionals have lived in that world since the early 1990s, and you can excuse them for being suspicious of new approaches to doing things.  For every Amazon.com there are hundreds of companies like Pets.com.  So bringing ideas like Test Driven Development, S.O.L.I.D. programming and Agile is going to face resistance.  As a scrum master or coach, I recommend you begin slowly introducing concepts letting people test out an idea to get comfortable with them.  It also helps if you understand and recognize the pressures the team faces.  Are they distracted by requests which are urgent but not important?  Do you have a healthy cadre of product owners or is the role being performed by a manager?  Finally, are they working with a brittle technology stack? Answering those questions will determine how fast you can go during your agile transformation.

Software development is not rocket science.  It is a challenging field prone to error and burn-out.  Only by paying attention to individual challenges each software development team faces can they be coached into an agile way of doing things.

Keeping it simple.

The light switch should be our inspiration

One of the most important principles in Agile is simplicity.  I work with plenty of clever people which means we come up with plenty of complicated ways of doing things.  True innovation and progress happens when we find simple ways of doing complicated things.  This week we are covering the virtues of simplicity.

When we talk about simplicity, we are not talking about something which is simple.  We are talking about something which is simple to use, simple to work with and simple to understand.  The example I like to use most, is the electrical power grid.  When we need to put a light in a room we plug in a lamp and turn on the switch.  The technology and work that goes into getting electricity to that lamp is very complex to but to us it is simple.

Technology like smart phones, web sites and accounting software should be like the electrical power grid.  Sadly, it is not.  Microsoft technologies are great for PC’s but in order to write web applications for a phone you need Xamarin or understand HTML5 to write Windows 10 applications.  Those applications do not work on Android and iOS devices.  This is just a sample of some of the technologies which do not play nice with each other for either market or technical reasons.

The blame for this trend is very smart people who, instead of working together to create simple and elegant solutions, have split into warring tribes.  It would take an entire book to discuss the history of why this has happened.  So to the average consumer we have a layer of complexity to everything we do and it needs to stop.  Even Apple has made music players a colossal mess making it impossible for people to manage the thousands of songs in their music libraries.

I do not have any magic bullets to fix this but is up to everyone in the agile community to try and reduce this kind of complexity.  It will not be easy but neither was setting up the national power grid.
Until next time.

Getting DEEP with your Backlog part 1

Product Owners need to get DEEP.

The hardest job in the technology world is the job of product owner.  At my firm and others, the product owner is an afterthought to an agile transformation.  They are usually a business analyst or a mid-level employee working in the department needing software and then they have to spend half their time doing their full time job and then the other half writing user stories and trying to understand how software gets constructed in their organization.  So this week and over the next four weeks, I am going to offer some helpful direction to people who find themselves as product owners.  We are getting DEEP in the month of April.

I am a big fan of Roman Pichler’s book “Agile Product Management with Scrum”.  This series of blog posts is going to draw heavily from his work on how to be a good product owner.  In the agile world there is a social compact.  The product owner sets priorities for what work gets completed.  The development team says how long it will take to do these priorities.  When the work is done they have a retrospective to assess what can be done better and faster.  Then the entire process starts all over again.  In order for this to be successful, the product owner has to create a backlog of work which follows the DEEP model.  A product backlog has to be detailed appropriately, estimated, emergent, and prioritized.  This week we will talk about how a product backlog should be detailed appropriately.

A backlog is nothing more than a series of user stories.  At a start-up or small business a user story can easily fit on a post it note or index card.  At a fortune 500 company requirements are often giant binders with mind numbing detail.  I feel there is a balance between the two extremes.  A user story should be in the following format and it is familiar to most people in the world of scrum:  As an "X " I want "Y " because of "Z".  This is the one sentence mission statement for the story.

Next, a user story should include the definition of done.  I have discovered that the best way to get developers and business people to effectively communicate what needs to be done is to use something from the world of test driven development: given, when, then statements.  The GWT syntax or Gherkin language is a perfect means to communicate what it means for the user story to be complete.  It also makes it possible for a developer to easily write unit and functional tests speeding up development in the long run.  When the development team reviews a story, I usually demand that stories include GWT statements for both affirmative and negative situations.  This way we avoid a lot of recriminations during the retrospective when a product owner says we did not finish our work.  A given, when then tends to clarify what it means to be done.

So each user story in your backlog should include a mission statement of what needs to get done, and enough GWT statements to cover positive and negative outcomes.  UML diagrams, attachments of XML, and wire-frames are helpful but not necessary for a story to be detailed appropriately.  As a scrum master it is up to you to train the Product Owners to have user stories which are detailed appropriately.  Next week, we are going to cover what it means to have stories estimated in a product backlog.

Until next time.

Laquan McDonald can teach us something about scrum.

They look cute until they undermine your efforts

One of the hardest things for a scrum master to do is lead organizational change.  For example, showing developers how to do SOLID development and test driven development is not enough.  The developers should see the utility of what they are doing and be compelled to practice it.  If your development team refuses to follow your lead you are stuck.  This week I wanted to discuss what happens when institutional needs meets resistance from the front line employees.

There has been plenty of news in the press about the killing of Laquan McDonald.  The young man was carrying a knife and walking away from a police officer when he was shot 16 times by a Chicago Police officer.  Video footage of the police officer using lethal force on McDonald was caught on a dash board camera in a police car.  The audio for the event was lost because the microphones were either disabled or broken.  McDonald’s death has sparked protests and calls for the mayor of the city to resign and has made the election of the attorney general a wide open race.

What is not being said in all this protest is that police officers have been wearing body cameras and using dash board cameras for roughly five years.  The shooting of McDonald also included a three year effort by the city to prevent the video footage from reaching the public until a judge gave the order during the December of 2015.  So on the one hand you have efforts to make the police department more accountable and on the other the information is suppressed by self-interest by police, politicians and prosecutors.

Currently, news has surfaced that eighty percent of the dashboard cameras and body cameras have the audio feature disabled on them.   There is a great deal of doubt as to whether this is because of tampering among police officers or poor maintenance; either way the optics look very bad.

So you have a government which wants to make the police force more transparent and cut back on the use of deadly force in communities and you have a the members of the police force with equipment which does not make that happen.  There is a lesson here for the scrum master.  If you are going to institute change then that change needs to be embraced from the bottom up rather from the top down.  Otherwise, you will be confronted with sabotage, monkey-wrench efforts, and stonewalling.

It is a shame that it takes a dead kid and embarrassing headlines to make that point.

Until next time.

Agile and Scrum Prevent You From Cutting Off Your Own Hands

You can learn a lot about software from a table saw.

Over the weekend, my father and I collaborated on a woodworking project for my home.  As I have grown older, I appreciate the time I have with him.  Over the last seventy years, he has acquired plenty of wisdom.  He likes to share it with me from time to time.  This week I want to share my father’s wisdom with you.

We were working with a table saw constructing a gaming table for my house.  I am intimidated by power tools.  I am afraid of injuring myself or someone else.  My father said, that my fear was justified but I needed to get comfortable with power tools because, “It isn’t any harder than writing software,” he joked.

After a few hours on the table saw, my father mentioned, “We have plenty of wood son; you only have two hands,” At this moment, I realized this bit of wisdom also applied to software and Agile.

Too often, software developers are trained in isolation learning to work by themselves.  They do not learn to work with others and once they basics are mastered they develop their own “style” of programming which is often incompatible with other programmers.

You also do not see formal training in Test Driven Development and debugging code.  I realize now this is like not warring safety goggles when you are using a power tool.  The “commando code” style many developers learned needs to go away because when something goes wrong it really goes wrong with that style.

Unit tests make sure that if a class changes and functionality is disrupted a developer can find and diagnose the problem.  Otherwise, it could take hours to track down and fix the problem.  Source control systems such as Git and TFS exist to make sure everyone is working on the same code set.  This prevents one developer from overwriting the changes of another developer.  Finally, design patterns like SOLID, make sure that developers have a common reference point to discuss the architecture of software.

As a junior and intermediate developer, I rebelled against these practices.  Now that I am a senior developer and scrum master, I embrace them.  My career is testimony to this change of heart.  I have broken software builds, destroyed production servers, and over billed numerous credit cards.  The results of this carelessness were long bouts of unemployment and financial hardship.  To put it mildly, I have figuratively cut off my hand more times than I can count.

So to my fellow Scrum Masters and developers.  Slow down there is plenty of wood but you only have two hands.  It is advice, I should have followed years ago.

Until next time.

Liberal Arts and Return on Investment

It was not a failure to launch
it was a rotten economy.
(Picture from Time.com)

Being an entrepreneur during times like this is very difficult.  Each day, I see myself confronted with frustration and failure.  It gets old and it sucks the enthusiasm out of you.  That is when I have had to rely on family and friends to pick me up and make sense of my crazy fate.  You see I have always traveled the more unfamiliar path my entire life and in spite of my choices I have managed to earn a living and develop the skills necessary to found my own business.  I reflected on that when this week when Payscale.com published its annual list of return on investment colleges and college majors.  Naturally, degrees from colleges near Silicon Valley and with big focus on science and technology had the highest rankings.  This kicked off another round of articles about how a humanities education was a handicap in today’s global economy.  As someone who comes from a humanities background, I can say that those articles are gross exaggerations.  This week on the blog, I will argue that a humanities background is an advantage in this mixed up global economy.

When I graduated from college in 1990, George Bush Sr. was president and we were in the middle of a recession which guaranteed that none of us graduating were going to find a job.  It was very discouraging for someone who wanted to work in radio.  I found an internship which paid minimum wage and worked nights as a disk jockey at a night club.  It was awful.  I was forced to live like a teen-ager with my parents and I had enough money for gas.  I could not afford to rent my own place or provide for myself.  Adding insult to injury was the cover of Time Magazine telling everyone that my failure to launch was due to laziness. As someone who said no to drugs, worked his nerdy butt off in high school and college, and sacrificed so much to become an academic and professional success; it was a bitter pill to swallow.

It was during this time that I felt the first rumbles of the internet.  I discovered the Prodigy data service and also learned about this funny thing called Microsoft windows and how it made life easier.  It did not know it yet but a path in my life was revealing itself to me.  It would be almost eight years from college graduation to my first technology job but I think my liberal arts background made it possible.  I had to learn strange languages.  A course in symbolic logic I took as part of my philosophy minor made it easier to understand decision trees and algorithms.  The years working in print media and radio helped me bridge the gap between old-media and the new-fangled media of the web.  Without a communications degree, I would not have the skills necessary to collaborate with customers and users.  Liberal Arts and humanities have served me well.

As I earned my MBA the study skills I learned as an undergraduate came in handy.  I was more prepared than my fellow students, understood the turn of a phrase and could take complicated things and make them easy to understand.  I doubt I would have learned those skills in a computer science course.  Now that I have an MBA and I have founded my own business, I see that I have been able to merge my experience with technology with my liberal arts background.

I also know that I want to hire a mix of liberal arts and technical professionals as my business grows.  I have terrible spelling so I have to rely on others to proof read my work.  That means that English majors are going to receive preferential hiring treatment from HR department.  For every developer who understands monads and SOLID programming, I am going to make sure I hire a few people to understand how to conjugate a verb and understand what Gottfried Leibniz meant by monads.  I feel this way because a diverse group of people can better solve the problems of customers.

So looking at the news that a liberal arts background may not provide the most return on investment for a professional, I politely ignore it.  I have been surviving and thriving as a professional because of my liberal arts background instead of in spite of it.  I have learned to ride the wave of the internet as it picked up steam and I have founded my own business hoping to help others take advantage of those trends.

If you would like to know more about my business and how we can help you improve your profits and bottom line please give us a call.

Being an entrepreneur is frustrating but I would rather follow this path rather than the well-traveled one.  I hope you get the chance to wander with me.

Until next time.

A Bootstrap World

Bootstrap makes us better.

You might have noticed some changes to the web site.  This week I pushed some changes into production and it reflects some of the newer technologies on the web.  We are now using MVC5 and Bootstrap web to provide a consistent experience for people using the website on a mobile device or web browser.  This week on the blog I want to talk about Bootstrap and how it fits in to our mission to provide web applications which work any time and any place.

I believe that I am a late adopter of Bootstrap.  The first open source version was released in 2011 and it became the most popular download in the GitHub development project in 2012.  I stumbled upon it in 2013 when I was about to change the careers.  Another developer had exposed me to it was some kind of revelation.  Now there was a way to build web sites which looked good on small browsers and that functioned well on full screens.  It was a revelation but it did not seem like something that would work with the Microsoft technologies I was working with.

This changed with the release of Visual Studio 2013 who used Bootstrap 3.0 as its default tool to manage the look and feel of web pages.  When I saw how easy it was to work with, I quickly became a convert.  Instead of noodling around with web pages and cascading style sheets, I had a built in tool to help build web applications which scaled from the mobile phone to the big screen.  It was also great that Microsoft included tools like LESS to create my own styles and to add tweaks to my layouts.

For you the consumer this is a big deal.  Now, you can rest assured that there is an industry standard way to make sure that your web site looks good on a small browser or on a giant screen.  In addition, your web applications will now work anywhere you have a connection to the web.  This gives you significant power managing your business processes because you can look up inventory on the phone, tablet or laptop with no major interruption of service.  This is the cloud based connectivity that we boast about.

All of us at E₃ systems are excited about this technology.  It is nice that the collective wisdom of the world wide web has embraced this approach and that just means that you the consumer now have an industry standard to measure progress against.  Contact us today and find out how we use Bootstrap to help you.

New technology is fun and using a new technology to solve a business problem is even more fun.  Bootstrap is one of those technologies which does both and you are going to see more of it as time passes. It is a bootstrap world and we are living in it.

Until next time.

Patterns in the Code

Square Pegs is round holes. Could be design patterns

I spend a great deal of time reading other peoples code.  It is part of my day job as a Scrum Master.  It is also what I do as the president of E₃ systems.  It is a tedious task sometimes but I recommend it for every developer working today.  This week on the blog, I want to discuss code patterns and why they are important for any developer.

In the world of literature, there are countless critics and competing schools of literary thought.  Fortunately, the world of computer science does not have that problem.  The most important standard for software is that it works and that it meets the needs of customers.  This is changing as software becomes more complex and it has become more important to the operation of the business.  Standards cropped up thanks to this new reality and I think it has been a good thing for the industry.

Developers in many respects are like painters; they are creative, temperamental and a little crazy.  Ask two developers to write the same software with the same requirements, you will get code that is written very differently.  Multiply this by several hundred developers over three continents and you have a recipe for disaster.

Most coding standards are fairly common sense.  I personally like the standards from Microsoft regarding C#.  However, I am starting to see some troubling trends.  First, the Gang of Four, design patterns for Java are being used as a cudgel to punish self taught developers.  These design patterns have been taught in computer science classes the last ten years and the original book on the subject came out in 1994.  Today those patterns are used in numerous development languages.  A good developer with an understanding of the object oriented development doesn't need to use these patterns but some architects and a sizable minority think they should be the necessary grammar of development.

I strongly disagree with this position.  Gang of Four design patterns are a style of development not the last word on the subject.  To barrow from my friends in English and Communications theory, the Gang of Four represents a dialect of coding rather than the grammar.  Just like the formal language of a court room is different than the informal tome construction workers use on the job site.  There is a time and place for both and slavish devotion to design patterns make about as much sense as using a hammer to drive a wood screw.

Software developers often that they are artists but in the real world they are often being used like animators helping create large and complicated pieces of work with an almost infinite number of moving parts.  The Gang of Four design patterns are helpful but are being misused by a minority in the development community to judge the ability of other developers who do not understand these processes.

I am much more open to the SOLID programming approach which creates general guidelines for flexible code.  These guidelines make design patterns possible but not necessary.  If you use SOLID are more likely to write cleaner and easier to use code.  Furthermore, this approach instills good habits in both self-taught and classically trained developers.

A developer is his own worse critic.  I know that I look at code I worked on three years ago and cringe at my lack of technique.  I think I am a better developer now than I was when I started fifteen years ago.  I may not use design patterns but I think that I can create satisfying customer solutions.  In the end, that was why I wanted to be a programmer in the first place.

Until next time.