The known-known of Donald Rumsfeld and agility

I took some time away from the blog to be with family and friends during the American Independence celebration.  Unlike George Packer's stereotyping of the professionals like myself, I am intensely patriotic, which made it pleasant to watch fireworks and listen to a marching band.  I encourage people to take time off.  It allowed people to set work aside and concentrate on the family and friends we neglect during the workweek.  While I was away, former Secretary of Defense Donald Rumsfeld died.  His passing made me want to reflect on his leadership style and what that means for the people left behind.  

I'm not particularly eager to write about politics on this blog.  There are better voices about the subject on both the liberal and conservative end of the spectrum.  I also feel that if I am going to contribute to the conversation of making life better for others, I feel that concentrating on project management, agile, and business culture are areas where I can provide meaningful insight. I used Rumsfeld and his quotation about ambiguity and uncertainty to discuss what scrum masters should be looking for when they join an organization.  You can read the original post here.  

Now that Rumsfield is gone, it is time to take a serious look at his leadership style.  Secretary Rumsfeld is a formidable person; he graduated from an Ivy League institution, completed a Navy ROTC scholarship, and was a member of the house of representatives for three terms.  You do not accomplish those things unless you are intelligent and rugged.  I will also point out Rumsfeld is a fellow Eagle Scout.  

One thing that stuck out for me when I review his biography, he was a naval aviator and did not see any combat while he was flying.  He understood the reality of being a naval officer but never had shots fired at him by a communist in a Mig.  He also never commanded sailors at sea.  In most areas of his life, he had tremendous authority with little responsibility for the outcomes.  It is a crucial hallmark of his life in public service and private business.  It transformed him into an individual with tremendous arrogance and a shallow understanding of things unrelated to his advancement.

It drove Rumsfeld to fits of anger when asked about his motivations or influences.  Someone could not question him because he assumed he was always right.  Soon, Rumsfeld was surrounded by people who could not say no because their careers depended on making the boss happy.  It created a bubble where regular inspection and adaptation to changing circumstances became impossible.  Numerous generals risked their careers to point out flaws or nuance to Rumsfeld's decisions.  One general, Eric Shinseki, was relieved of duty when he pointed out the occupation of Iraq would take more soldiers than the ones involved in the actual invasion.  

The most prominent example of Rumsfeld's leadership style is the Freedom-class Littoral Combat Ship or LCS.  The U.S. Navy requires large crews of specialists to operate their combat ships.  Professions diverse as plumbers, mechanics, and fuel technicians keep the Navy afloat. Vessels have specialization with some sweeping for mines. Others are missile cruisers designed to shoot down enemy aircraft, and aircraft carriers are floating airports that could project American power anywhere in the world.  It is expensive in both people and money to operate a giant navy.  The LCS would work with a fraction of the crew, hi-tech computer systems, and a modular hull which allows the ship to be reconfigured in port depending on its mission.  It was the brainchild of Rumsfeld.

It became apparent the LCS was a bad idea.  Crew members would shift from cooking meals to operating weapons.  The goal was to allow the U.S. to have a bigger military punch with fewer sailors and ships.  The reality of the situation was a mess.  Since none of the sailors assigned to an LCS had engineering experience, no one checked the engines for oil levels or seawater contamination.  The modular system never worked in practice, and LCS ships spent more time in port than at sea.  Finally, the vessels broke down when on duty and were towed to port because no one on the boat could do repairs at sea.  The Navy learned plenty of lessons about the LCS; they were reluctant to act on those lessons because it was Rumsfeld's idea, and even though he was gone from the department of defense, his shadow loomed large over the project.  Currently, the U.S. Navy is planning to retire the LCS Freedom-class, considering the program a failure.  

Based on his biography and papers, Rumsfeld comes off as a traditional leader who never wanted to hear bad news and expected his ideas to be implemented magically by the people he was supposed to serve.  People who were not obedient to Rumsfeld and his ego would be swept aside as he moved forward with stubborn persistence.  It is the mindset of a naval aviator who never had someone try and shoot him down.  The entitlement and arrogance are clear to see.  

Toward the end of his life, Rumsfeld published his "rules" for successful leadership.  If you followed his process, you would achieve greatness.  The funny thing about technology and reality is it humbles your greatest ambitions.  I doubt he ever learned that lesson, and it is up to coaches and scrum masters to remind leadership not to follow Rumsfeld's example.  

Until next time.

Two Leadership Themes

My leadership will keep on sailing.

I spend plenty of time with other professional people.  We often discuss many subjects, and we often talk about our family lives, careers, and what motivates us.  Occasionally, we talk about deeper topics, but the main topic of our conversations is leadership.  How does a person lead a group of people?  What does a leader do when faced with incompetence or insubordination?  Today, I want to discuss my feelings on leadership.  

The main focus of my career is helping others avoid the mistakes I have made in my career.  I want people to avoid the hardship and disappointment I have encountered during my adventures working as a software developer and project manager.  Failure is the best educator someone can experience in a career.  I want to share the hard-earned wisdom of failure with others so they can avoid the roadblocks and setbacks I have encountered.

Along the way, I have discovered two main themes which have guided my leadership.  The first is servant leadership.  I was exposed to this as a teenager with the help of Marine Corps JROTC.  I discovered leadership is lonely.  It required being a servant for the people you lead.  It also forced me to put my needs on hold while things got done.  I gravitated to leaders who practiced this ethos, and it further shaped me as a person and leader.  

The other is the discovery of Kim Scott and her book Radical Candor.  Her writing and efforts' central thesis is that leadership requires a combination of honesty and empathy to be successful.  Truth without compassion is obnoxious aggression.  Empathy to hide the truth is ruinous.  Kim Scott brings plenty of experience to her writing, and it is bracing to hear her talk honestly about her mistakes.  

I combine Radical Candor and servant leadership to guide how I work with others.  It is not a straightforward approach, but it has given me tremendous satisfaction over my career length.

Until next time.

It is never about you.

Serve others it isn't about you.

The best part of being part of the agile reformation is the community of supportive professionals who inspire each other.  I can rely on the experience and wisdom of thousands of people who are on a similar journey attempting to make work saner, sustainable, and satisfying.  Currently, I am training at Chicago State University to improve my credentials as a certified agile coach.  It is an excellent experience with people from all over the globe.  Someone from the Philippines has the same challenges I do when leading change.  It is always nice to know that we are all facing similar struggles and challenges. This week, I learned a rather important lesson, which often gets lost as we become more experienced in agile. 

 

One of the critical foundations of agile is the notion of servant leadership.  The best leaders often are those who see themselves as servants helping the people; they lead rather than viewing the people under their authority as people who serve them.  As you gain experience and credibility within the profession, it is easy to let the certifications, recognition, and respect go to your head.  We are scrum masters, and people look to us for advice and guidance.  It is intoxicating.  

The reality is that being an agile coach or scrum master is about service to others.  It is not about us and our journey.  We should remember that success in this profession is when others take the lessons we have learned and apply them to their challenges.  If we are doing our jobs properly, our wisdom will help build success for others.  We should celebrate the achievements of others and the growth of people under our charge.  Unlike other areas of business, being a coach or scrum master means taking the focus away from yourself and directing it at the teams you are working.  

It is nice to learn from others.  The most important lesson is discovering that to be a servant leader, you need to remind yourself it is not about you but the people you are leading.  It is a lesson worth repeating.  

Until next time.  

Failure is the Fertile Soil for Growth

Failure happens

A common theme in business writing is the mythologizing of success.  It is an easy narrative to promote.  People enjoy reading about the success of others, and wealth is always intoxicating.  The struggle, failure, and sacrifices necessary to achieve that wealth have a glossy sheen in popular culture.  For me, the most exciting part of the story is how others deal with failure and crushing disappointment.  It interests me because my career has numerous episodes of frustration.  A setback proceeded with each significant improvement in my career and life. Defeat is a teaching tool for me, and now I incorporate it into my coaching practice.  

I have made numerous references to how failure is an exceptional learning tool.  Instead of failure, I should barrow the mindset of Carol Dweck and her Ted Talk from 2014.  Instead of saying, I failed, I should say that I have not yet succeeded.  It is the classic growth mindset which motivates people to figure things out and improve.  It sounds noble, but it is difficult for people to do because it challenges an individual’s self-worth.  

Thus, I spend lots of time taking the sting out of the everyday failures and mix-ups which happen in an office.  It means being kind in moments where your lesser self would like to snicker.  It means saying, “not yet,” and “what could we have done differently.”  It is holding others accountable without being mean about it.  I struggle just like the next business leader, but I have noticed that people respond to this approach.  Instead of beating a drum, a leader needs to show the way and get a little dirty in the process.  

Failure is real, but how we react to it makes the difference between a fixed mindset and growth and continuous improvement.  I choose a growth mindset any day of the week.  

Until next time. 

Goodhart's Law is Going to Get You.

Goodheart's law strikes!

Information technology is hard work.  I have written about it before on this blog.  I have plenty of empathy for others who work in this profession.  I do not have much understanding of poor service or lazy behavior.  I am even less forgiving when large organizations brag about their success in public and struggle to do the basics in private.

I am at a client, and I have the following interaction with someone from the help desk; they said, “Can we close this ticket? If it ages any longer, it effects out SLA.”  My first reaction was surprise.  My second emotion was anger.  The help desk person was asking permission to close the ticket and open a new one because if they did not fix the ticket at a particular time, it would reflect poorly on him and his consulting company.  He was going to lie to make his response time look better than it was. 

It is human nature to please others.  British economist Charles Goodhart coined the maxim, “When a measure becomes a standard, it ceases to become a good measure.”  When you judge or pay people based on a measure, they will game the system in any fashion to make themselves look better.  You see this in economics.  It happens in video games and depressingly at work.  My help desk technician was living proof of Goodhart’s law.

Martin Fowler wrote a great article on the subject, and it outlines how to avoid this trap in agile practice.  Metrics are abused regularly in business.  In a large organization, the only way leadership can track progress is by reviewing these metrics.  Thus, the people doing the work are more focused on the outputs of hitting the metric numbers instead of the outcomes satisfying the customer.

I see service level agreements or SLAs as a necessary evil in business.  You have to hold vendors and third-party partners accountable.  Such a contract controls my current situation.  In a perfect world, my help ticket would age, and someone who could help me would respond to my issue.  The technician was afraid that if the ticket aged, they would receive a poor performance review or get fired.  It is an ugly situation, and if a company is going to succeed, they with have to address it. 

Large organizations need to focus on execution.  To focus on this goal, metrics and SLA’s need to be used judiciously; outcomes are superior to outputs.  It is a message which did not reach the help desk or his boss. 

Until next time.

Leadership and Eating the Elephant

Abrams as servant leader.

When I am not at the office, I relieve stress by pursuing several hobbies.  I am a big movie buff and love debating cinema of all types.  I also collect and play with toy soldiers.  I have been in the hobby for nearly forty years, and I am a member in good standing with the Historical Miniatures Gaming Society.  You pick up military history by process of osmosis when you collect soldiers.  Interestingly, some of the trivia I have picked up along the way have informed my agile practice.

I have written about military history in the past.  I recognized Eisenhower performing the greatest act of project management in history with his preparations for the D-Day invasion.  I also pointed out Richard Armitage’s efforts to save South Vietnamese soldiers and civilians during the fall of Saigon.  Military history has plenty of stories of heroism and cowardice.  People are elevated to their highest ideals or reduced to animalistic squalor. You are changed forever when you experience it.

It is the ultimate nature of warfare which makes it such a bad metaphor for business.  War is wasteful and is never sustainable.  Many of the lessons of war are not relevant in today’s office because the worst thing that could happen is losing your job.  In combat, a person can be maimed or killed.  It is why when I talk about military history in my agile practice I avoid strategy, tactics, or logistics.  I spent most of my time talking about leadership.  It is the leadership of ordinary people in extraordinary situations which inspires me and which I use to encourage others.

One of the most inspiring leaders I know is Creighton Abrams.  He was a tank commander in World War Two and was part of Patton’s Third Army in Europe.  Abrams nicknamed his tank “Thunderball,” and he had the name emblazed on his tank in bold white letters.  Abrams survived the war in spite of the German’s destroying “Thunderball,” seven times.  He was lucky, brave, and he led his troops from the front.  He never asked a soldier to do something he would not do himself and inspired tremendous loyalty.

After the war, he continued to move through the ranks commanding tank units in Korea and Europe during the early 1960s.  Where his leadership ultimately expressed itself was his command of the U.S. Forces in Vietnam.  Abram’s took over for fellow West Point classmate William Westmorland after his promotion to Army Chief of Staff in 1968.  Abrams assumed command at a dangerous time.  American forces had defeated the North Vietnamese Army and the Viet Cong during the Tet Offensive.  It was an ugly and brutal victory which turned a majority of public opinion against the war in Southeast Asia.  The Communist Vietnamese were going to keep fighting no matter how many people died in the process.  Morale was low, and the mission of U.S. forces in Vietnam was in question.

Newspaper reports asked Abrams how he was going to preserve the South Vietnamese government, beat the communists, and keep U.S. casualties down.  He responded, “when eating an elephant you do it one bite at a time.”  The quotation would guide him the next four years as he led the U.S. withdrawal from Vietnam.

Unlike his predecessor, Abrams shunned the perks of leadership.  He replaced the ornate wood desk first used by the French provincial governors, with the standard steel desk used in the U.S. embassy.  The mission of U.S. combat forces was simplified, and Abrams implemented the Nixon plan of Vietnamization.  By the time he left Vietnam to become the Army Chief of Staff, U.S. forces had reduced from 576,000 to 24,200 troops.  The big test of Vietnamization and Abrams came in 1972 during the Easter Offensive.  With a fraction of the troops he had four years earlier, he stopped a significant assault on the country.

Abrams was the kind of leader who accepted responsibility for both victory and failure.  The My Lai massacre became public during his tenure.  The Khaki Mafia swindled the army out of millions of dollars.  Finally, the battle of Hamburger Hill further inflamed anti-war sentiment.  Despite these challenges and unreliable allies in the South Vietnamese government, Abrams stood as an example and ate the elephant one bite at a time.  The main battle tank in the U.S. Army was named after him; the M1A1 Abrams.

All of this history relates to agile because we should embrace the servant leadership of Abrams.  Instead of hunkering down in our offices or via conference calls, we should lead with our teams.  Instead of grand gestures of reform, we should pile up a stack of little victories which will lead the organization forward.  We should act as servants to our teams and shun the privileges of rank.  The flaws of our organization should be transparent.  Finally, when confronted with a threatening challenge we will be able to adapt and overcome.

Leading change in an organization is difficult.  The adoption of the agile mindset in business is going to be the most significant change in civilization since the protestant reformation.  I draw inspiration from figures like Abrams.  He inspires me to take plenty of small bites from the elephant which is my career.

Until next time.

Looking back at Agile2018

Spending time with fellow
 speakers Michele Sliger and Erika Lenz

This year is a personal and professional adventure for me.  I journeyed to the Scrum Alliance coaches retreat in London.  Last week, I was a presenter at the Agile 2018 conference.  Each of these experiences has made me a better scrum master and agile coach.  Now, that I am back home and have a more stable schedule; I will be blogging on a more regular basis.  This week a few take-a-ways from the #Agile2018 conference.

Data and Metrics-

The Wednesday keynote was Troy Magennis who spoke passionately about data and agile.  He proposed that agile professionals find a better way to present data to others and that data should inform decision making rather than reinforcing existing prejudices. 

He also provided data showing notions of teams being smaller than nine people may be counterproductive in larger projects.   He pointed to studies where groups of eleven to nineteen people are less efficient by a fraction compared to seven to nine-person teams.  He then argued that fewer handoffs between teams would make up for this difference.  It was provocative, and I look forward to people testing out his thesis. 

Presenting for the first time. 

The conference featured numerous presentations on metrics and data in agile.  I believe the use of quantitive data rigor in project and business management is a good thing.  For the remainder of the conference, numerous sessions covered the use of data and metrics in Agile. 

Outcomes are better than output-

The Agile Alliance with its speakers unwittingly created a theme for this conference.  The idea was outcomes of real features and progress are more important than outputs of stories, unit tests or story points.  Countless presentations emphasized working code delivering real-world value.  My presentation about the Cobra Effect reflected this dynamic as well.  When we measure outputs, we get perverse incentives.  When we measure outcomes, we get a better perspective of performance. 

Facilitation and Radical Candor-

The life of an agile coach or scrum master is a life of responsibility without any authority.  It is paramount to successful organizational change coaches develop superhuman skills of persuasion and facilitation.  I attended several sessions on how to be more credible and persuasive.  Many of these sessions pull from the insights of Kim Scott, a former Google Executive, who authored the book, “Radical Candor."

I learned plenty of valuable lessons at #Agile2018, and I look forward to the next conference in 2019 in Washington D.C.  I better start working on my presentation outline. 

Until next time.

Learning to Manage time

Time should never be wasted

A software developer is a unique brand of employee.  The profession requires mental toughness and creativity.  The ability to create software also requires strong time management skills.  As a scrum master, you need to help your colleagues learn to manage time better.

If you work in technology, you confront a stark reality.  To keep the global economy moving there is a too much work chasing too few people.  Less than .05% of the world's population can build software and maintain the networks which run it.  Software engineers are under constant pressure to grind out code.  For those who do not understand, it feels like cramming for an exam every day of your working life.  This kind of pressure takes a mental and physical toll on the people doing the work.  Developer’s abuse alcohol, binge eat, take numerous prescription medications and engage in unhealthy behaviors to mitigate the stress.  It is an abusive cycle which leads to burnout and bad quality.

As a scrum master, we need to help others learn to manage time better.  First, create a routine for the development team and business owners.  The daily stand up should never state late, and everyone should attend.  Next developers need “quite time” to concentrate and do work.  People who are looking for favors, football pools, and making lunch plans are forbidden if they interrupt the developers.  Finally, headphones and other techniques to create a state of flow should be encouraged.
Business people divide their day in hour long chunks.  Software engineers think in thirds.  There are morning, afternoon and evening and each period is an opportunity to work and write software.  Another reason I have no meetings scheduled in the afternoon for the development team; I want the afternoons to be interruption free for the developers.

I also use it as a time management tool for product owners.  After lunch, I have a one-hour sprint refinement meeting.  We discuss stories for an hour and then adjourn for the day.  The time after sprint refinement is a perfect opportunity to write user stories.  Developers get into the routine of meetings in the morning and open afternoons of coding.  Product owners understand that the time after the sprint refinement meeting is for writing stories.

So a helpful way to help others better manage their time is to give them clear routines so they can set aside time to do the work.  It is not perfect, but it beats flailing around the office in a panic.

Until next time.

Beware the Temptation of "Dark Scrum"

Avoid the temptations of "Dark Scrum"

I have been an agilist since 2009.  I began collecting certifications for Agile and Scrum since 2013.  I even finished up my master’s degree studying the differences between waterfall and iterative project management processes.  I have some skills.  What I find most challenging as an agile practitioner is a disconnect between those of us doing the work and the business people who depend on us.  When this happens, it creates a situation Ron Jeffries calls, “Dark Scrum.”  As a scrum master and agile coach, it is your duty to avoid this situation.  This week on the blog avoiding the temptations of “dark scrum.”

In my formulation, "dark scrum," is when the business users of Scrum use the methodology to enforce control over software development rather than use it to improve quality and customer satisfaction.  Jefferies gives plenty of good examples on his blog, but I would like to provide two more.  I consider them to be pathologies of a dysfunctional organization.

Dark scrum pathology – shoehorning arbitrary deadlines on to sprints.  

One afternoon, I was in the office of a Vice President.  I had been raising concerns with him that a project was going poorly and that I would need his support and intervention.  The meeting did not go well.

“I promised the board that this project would be done by X date,” he said.

I told him based on the stories we had and a three-week sprint cadence we could deliver by a later date.

“You are agile, figure it out,” the VP said, “I need it by X date.”

The executive violated the social compact of agile, and we removed stories and features to meet the arbitrary date.  The customer was disappointed, and the Vice President looked bad.

Dark scrum pathology – why do I have to meet with the off-shore team.

Product owners write stories, but because of the time difference between the onshore and offshore components of the project, did not participate in the stand-up meetings.  We had created a situation where the developers would ask questions, and it would take over 24 hours to get them answered.  Product owners also complained that the team was not understanding the detailed requirements to get the work done.  When prodded to attend the stand-up call with the off-shore team a product owner indignantly said, “I am not waking up that early to talk with India!”

We were able to correct these pathologies.

To address the arbitrary deadline problem, bring in executives and product owners to level set expectations.  In the world of Scrum, the product owner is the person primarily responsible for the success or failure of a project.  The executives outside the team are responsible for funding and helping to remove organizational obstacles.  Knowing financing and deadline commitments provides the product owner a framework to write stories.  The scrum master can then use team velocity and the sprint cadence to let everyone know when a deadline is realistic and when it is not.  This way the social compact of agile is respected, and there are not secrets for all the parties involved.

We solved the next pathology by moving up the stand-up meeting by thirty minutes.  The product owner could take the call from home when they got out of bed but before they came into the office.  Product owners answered questions quickly and user stories improved.  Also, automated testing got better as product owners relied on the offshore QA professionals to streamline acceptance testing.  What was once a burden, became a win-win for the entire team.

The hard part about being a scrum master and agile coach is you are forced to come up with solutions like this each day to prevent your organization from falling into “dark scrum.”  Any situation where those in power ignore the input of the people doing the work is going to add darkness to the organization.  It is why the agile reformation is so important.  By beating back the pathologies of “dark scrum,” we can be successful software developers and professionals.

Until next time.

A March in the Mud

One of the dirty little secrets of software is for every splashy app or disruptive business there are countless hours of toil.  The mental exertion takes years off your life. Software also alienates because, to be successful, you need to be thinking about software and how to keep your skills current.  The compensation is generous but the mental and time demands of the profession are oppressive.  It made me think about what makes a scrum master successful.  This week I want to talk about the gritty nature of the business.

When I was growing up, I have a great Uncle Paul who fought in Europe with Patton’s Third Army.  He refused to discuss his experiences, and when asked about being in combat he remarked bitterly,” I was cold, and it rained a lot.”  Over the years, many of the combat veterans I have known have behaved in a similar fashion.  Whether they served in Korea, Vietnam, Desert Storm or Afghanistan; the prevailing attitude was I would be unable to understand their experiences because I was not physically there.  Instead, I relied on the narrative from books, documentaries and those veterans would share their experiences.

What struck me during my investigation was the tedium of military service.  Moments of terror punctuated countless hours of boredom and following procedures.  Each day is a grind with little room for heroism or glory.  While I have never made the kind of sacrifices required of combat veterans, the grinding nature of a military campaign is familiar to anyone who has worked on an I.T. project.  In fact, every developer has a story about being on a project which resembled a “death march.”  One of my favorite illustrations by Bill Mauldin, who created the famous Willie and Joe cartoons from World War Two, is tired and muddy American Troops guarding German POWs and they are marching through the rain.  The caption offers brilliant commentary, “Fresh, spirited American troops, flushed with victory are bringing in thousands of hungry, ragged, battle-weary prisoners.”  The irony being everyone during the war is tired, hungry and battle-weary.

Anyone who works on a software project gets tired and weary.  There are too many late nights, too many slices of pizza, and too many problems to fix.  In many ways, we are like those soldiers trudging through the rain.  It is why developers prefer agile methods over the more traditional waterfall approach.  Instead of long aimless slogs in the rain and mud, at the end of each sprint, we track our progress and take stock.  Big bang releases would become a thing of the past and development would be made more sustainable.

The reality has been more complicated.  As we have learned to release software in shorter intervals, business leaders have demanded that we cram more feature into each release.  So instead of work being a “death march” it resembles being pushed out of airplanes each sprint shouting “Geronimo” and hoping we survive the experience; this is not sustainable development.

Metaphorically, scrum masters and developers are seeking a happy medium between long marches in the rain and jumping out of an airplane.  Each day should feature a win or forward progress.  Developers should not put in heroic efforts or engage in crunch time.  It is a lofty goal, and if we are doing our jobs correctly, one the agile community can accomplish.

It takes communication with business leaders and regular deployments of software into production. We need to pay better attention to the DevOps movement to see how to implement continuous integration and pipelines for projects.  Finally, it means saying “No” when people demand ten pounds of sand fit into a five-pound bag.  To do otherwise means we are no different than those soldiers slogging through the mud.

Until next time.

All about forgiveness

Talking about forgiveness.

It is evident to me that 2017 is the year of messiness.  Software is a messy activity.  The clutter is caused by the human emotions of foibles which are part of the creative process.  As a scrum master, you are the servant leader of messy people who write software.  You are supposed to live the agile manifesto and principles.  You set the example.  As a scrum master, you set the tone and help the team succeed.  It is rewarding work, but I have my moments where I am not very proud of the example I am setting.  Continuous improvement means striving to get better.  It also means you need to be able to forgive others and yourself.

My professional career has was shaped by my training in journalism and engineering.  The world of mass communications is very judgmental.  We criticize television anchors for hair color choices and how good their dentition looks on camera.  Radio disc jockeys are slaves to ratings and program managers who can crush your career.  Ratings mean money and if you provide ratings, people will ignore some of your worse personal faults.

Engineers are also a judgmental bunch and are willing to back up that judgment with the scientific method.  The code could run a few nanoseconds faster.  The class could better use the Liskov Substitution principle.  Finally, you could always tighten up the code to make it less error prone.  There is additional machismo where team members compete to assert dominance using their intelligence or programming skill.  It is brutal, and these environments discourage vulnerability and innovation.

As a scrum master, you are encouraged to help remove these dysfunctional behaviors.  Sometimes a scrum master gets caught up in these bad practices.  When you do, you are going to hurt the team.  When you hurt the team, you are undermining your credibility in the organization, and with the people, you are supposed to serve.  The first thing you should do when you hurt your team or someone on it is making amends and apologize.  Asking for forgiveness is hard, but it reinforces the agile values of respect and openness.  A team which can forgive each other when they make mistakes is going to be higher performing than one which is not.

Forgiving yourself is a much harder skill.  We know ourselves better than anyone else.  We are also the least forgiving of our mistakes.  We can feel like frauds to ourselves, and this is imposter syndrome.  Our emotional intelligence may be below average, and we find ourselves in situations which would puzzle others.  Finally, emotional control can be undermined by people who just do not want to improve.  You become a tangled bundle of rubber bands, and you feel like you can snap at any minute.  You do snap you feel riddled with guilt and self-loathing.  Over my career, I have spent a few mornings thoroughly hating the person I see in the mirror.  These feelings are not rational or objective.  These feelings just are, and you cannot escape them.

I have been leaning on friends and family for the last few weeks to receive relief.  I am seeing a doctor in order understand if the stress of the role is contributing to my emotional recriminations.  Finally, I have been avoiding alcohol and caffeine.  My brain chemistry is bad enough, and I don’t need to make it worse with outside stimulants and depressants.  I am making a conscious effort to try and forgive myself for past mistakes.

From the outside, this process is not going to look beautiful, but I need to do it if I am going to improve as a scrum master.  Everyone deserves a dose of forgiveness now and then.

Until next time.

Explaining being a scrum master to civilians.

A scrum master is a servant-leader

One of the things which make working in the 21st century so dispiriting is most people cannot easily describe the work they do.  During the middle ages, people were farmers, blacksmiths, nobles or merchants.  The roles and job descriptions were easy to understand.  Today, the work of content curators and account managers creates plenty of ambiguity and misunderstanding.  This week on the blog, I want to clarify the definition of a scrum master.

The Elevator Pitch

When I am at social functions, networking events or family gatherings people ask me what I do for a living.  I say scrum master and I get a puzzled look, and they ask me, “What kind of job is that?”

This is what I say.

“I build software and help developers and businesses develop software on time, on a budget, and with minimal bugs.”

The person nods and smiles, once this sinks in and switches to a new topic.

The Scrum Master Syllabus

When I describe the job of a scrum master, it often looks like a college syllabus.

A good scrum master is:

• An excellent communicator with individuals, small groups, and the organization.
• They understand the agile manifesto and principles of Agile and practice them every day.
• They are a trainer and coach making product owners, developers better and their job.
• They educate business leaders and stakeholders on how agile is making their business better.
• They are good listeners
• They have grace under pressure
• The can educate developers on TDD and SOLID development
• They are servant leaders
• They ship working software regularly.
• They make a god damn difference.

These are the signs of a good scrum master, and I try to aspire to these goals each day.

The bottom line.

Being a scrum master is a hard job.  It is also a calling of sorts closer to being a priest or pastor than a software professional.  A good scrum master can reinforce your belief and faith in agile, or they can turn into a tool of oppression.  I have never been into oppression, and I want to be someone who makes a difference.  That is why I am a scrum master and why I have such high standards for the profession.

I hope this clears up any misunderstandings.

Until next time.

Well Fargo is a Victim of the Cobra Effect

Anyone who follows this blog knows that I rarely hold a grudge and I don’t like kicking an individual or organization while it is down.  I am just not wired that way.  This week I am going to make an exception because of the lesson that can be learned for everyone in the agile community.  I am talking about Wells Fargo and their latest scandal regarding opening bogus new accounts for existing customers.

This isn’t the first time I have had my differences with Wells Fargo.  They were involved in a financial literacy campaign which denigrated humanities majors and liberal arts students.  Now thanks to federal regulators they are paying a $185 Million dollar fine for creating new accounts for customers without consent.  This gets to something the agile community call perverse incentives.

One of the central tenants of “scientific management” is that you measure how an employee does their job and then based on the data, as a manager, you figure out how to make that employee more efficient.  On the surface it seems like a smart idea.  A business person measures how work is done and then they strive to use that data to improve the speed and quality of the work.  This is where the perverse incentives come into play.  If you measure something and then use it as a performance incentive it ceases to be useful because it will force people to game the system to meet the metric.  This is called the “cobra effect” and I have blogged about it repeatedly.

Based on his testimony to congress, Well Fargo CEO John Stumpf said that he set up the incentives to “cross-sell” bank services to improve the company stock price.  This was the beginning of over two hours of uncomfortable questions and criticism from both Democratic and Republican congress members.  You know that you have done something bad when both Democrats and Republicans denounce you in public.

It did not have to be this way.  Stumpf could have measured performance and created training and education programs to make his staff learn how to better “cross-sell” products.  Instead, he used the blunt instrument of job incentives and it worked for a while until regulators and congress got involved.  Wells Fargo now faces additional investigation and possible criminal penalties.  It did not have to be this way but “cobra effect” can claim another victim and it could be a major American financial institution.

Until next time.

History is NOT over! It is just beginning.

Not the same person who graduated from ISU.

It is a special anniversary of sorts.  Twenty-five years ago I walked commencement for my undergraduate degree from Illinois State University.  Five years ago, I received my Masters in Management from University of St. Francis.  I am very proud of those accomplishments but I confess what I gained from those educational journeys was not what I expected.  The web site LinkedIn has gotten into the act by having its major authors talk about what their current selves would tell their freshly scrubbed 22 year old selves graduating from college.  This week I don’t want to share advice but rather illustrate the radical changes which have taken place in the last 25 years.

Putting things in perspective, my senior year of college, was supposed to be “the end of history.”  The Berlin Wall had fallen.  Communism was in retreat.  The economy was in a downturn but we would not know how bad it was going to be until the college canceled the job fair.  Microsoft had just released widows 2.0 to the market place.  That did not matter to most of us college kids we had MS-DOS personal computers or Apple II computers to do our work.  The phone system in the dorms was so bad that we could not hook up a modem because each room did not have an individual line.  We were on party lines where if someone picked up a phone in another room it would disconnect the modem.  Silicon Valley made semi-conductors and not millions of start-up dollars.  Mark Zuckerberg was a six year old.

That was the world I graduated into.  My brilliant career in radio lasted 18 months and then I drifted around in retail and the casino business before finding my way at the age of thirty working my first entry level job as a Visual Basic programmer.  Over the last seventeen years, I have seen trends come and go.  I have witnessed the giddy and stupid days of the dot-com bubble.  I suffered through the economic downturn of the post 9/11 economy.  I saw the birth of Windows 95 and the flop of Vista.  I watched Microsoft transform from a smug master of the universe to the technical power house which wants to be loved.  All of this in my lifetime.

I think the most important thing I have witnessed is the birth and spread of the Agile Reformation.  It began innocuously enough with top project managers getting together at a ski lodge and to share ideas.  It ended with the agile manifesto.  Now fourteen years later, I consider myself to be a missionary of sorts spreading the word and trying to make business a little less oppressive.  Sometimes I feel like I am tilting at windmills and other times I earn a little victory.  As a whole, I am trying to change a business culture one step at a time.  I am also trying to build my own business at the same time.

I don’t think I could give any advice to my 22 year old self.  I doubt he would believe all the missteps failures and misfortunes he would experience would lead to the life I currently have.  I find it surprising myself.  At 22, I was going to be a disc jockey to rule the world instead I became a missionary quietly leading change in global business.  The future belongs to misfits like me and other innovative individuals who want to change the world.  I am glad you are along for the ride.

Until next time.

Little Victories

A win is a win.

In the daily grind of business, you take your wins where you can get them.  This week I want to talk about one of those wins and a lesson learned in the trenches as scrum master.

Each quarter my product owner gives a presentation to the executive committee about how the business is doing and how the software development team fits into that vision.  It is dry affair filled with power point presentations and back slapping.  As I was gathering up metrics for the presentation, I noticed something peculiar.  The number or software support tickets had declined over the last fifteen months from an average of 40 tickets a month to 20.  The development team had cut the number of bugs that were in production by half in the span of a year.

I am pretty impressed with this accomplishment but it also taught me some valuable lessons.  First, change and improvement does not happen overnight.  It took numerous refactoring tasks, late nights, and admonitions to do things the right way in order to reduce the number of defects in the applications I was responsible.  Next, change requires everyone to change.  In this case, the developers, the business team, and I had to learn how to work in an agile process together.  It was not easy and everyone had to sacrifice a little of themselves to make it happen.  Finally, measuring results in a concrete fashion puts in perspective what you think might be happening.  I knew that we weren’t having as many support tickets but thanks to the metrics from the ticket system, I could quantify my hunch.

This means what has felt like a long slog for my development team and I is really the continuous improvement that business leaders always talk about.  It is not glamorous but over 15 months we have cut defects in half and are improving the products for the business.  I need to learn to be more patient with myself and others.  Small things do make a difference like asking that bugs get written up in the backlog and always asking why we do things the way we do.  It can feel like repetitive work and be very frustrating but if you keep at it there is a payoff.

Like many scrum masters and business leaders, I suffer from what is called “Impostor syndrome” that feeling that I am not good enough to do what I am doing.  What I have discovered is that I should learn to ignore that voice.  I am not an impostor.  I am a scrum master and servant leader to my team.

Finally, I realize that this improvement did not happen in a vacuum.  It took the efforts of my software development team and the hard work they put into the project.  They were the ones who wrote the code.  They were the ones who worked weekends and late nights.  They were the ones who saw me saying, “There has to be a better way,” and they found that better way.  They are the reason we had this happen.

It is not perfect by any means.  There is still a great deal of work to do but I do not feel like I am swimming against the stream as much as I did.  It is a little victory on the way to bigger victories and I will take it.

Until next time.

You are not a ninja!

Agile professionals are NOT ninjas!

Like most professionals, I tend to get ornery from time to time.  I am beginning to think that this is a healthy response to working in present day corporations.  Human beings have gone from being hunter gatherers to living in cubical farms in the span of 5,000 years.  It does not surprise me that there is not some kind of psychological backlash to this situation.  Further changes in the professional world like the hoteling of work spaces and the growing dependency on contract workers has made life in the corporate world seem like something out a Franz Kafka novel.  Today, I want to talk about something that have been bothering me over the last few weeks.  The growth of faux titles that agile professionals are using to try and describe themselves.

My irritation began when I noticed that someone began using the phrase “code ninja” to describe themselves and scrum master skills.  I have already blogged about what I think about people who describe themselves in this manner.  Now, I am seeing terms like “Agile evangelist” and “Wizard” cropping up in some discussions about agile professionals.  I understand why people are doing this to try and brand themselves and make themselves more appealing to the market but it really needs to stop right now.

We are agile professionals.  We are not wizards pulling rabbits out of our pointy hats and summoning a Patronus when an impediment crops up.  We are not Jedi because I doubt we would ever get the licensing from Disney to use the title and we don’t have cool light sabers.  This also means we have to deal with Sith and frankly the thought of executives with the power to force choke is a little disconcerting.  We are not ninjas because even though we are highly skilled professionals we are not being asked to kill people.  Finally, we are not evangelists.  Evangelism requires blind faith, total dedication, and the commitment to orthodoxy.  That is the antithesis of Agile.

Agile requires its practitioners to try new things.  One of the tenants of the manifesto, is we respond to change over following a plan.  Pragmatism, the scientific method, good engineering, and relying on a community of professionals is what makes us agile.  Contemporary evangelism tends to shun these values.  I will concede that it does take a leap of faith to try and change how contemporary business is done but we are no different than the professionals who applied W.E. Deming’s methods in Japan or the lean manufacturing professionals currently practicing in the United States.

Finally, if you call yourself an agile apostle and you are not one of the original signatories of the Agile Manifesto you deserve a good dose of scorn and ridicule.  Agile was not dictated to us like the Koran to Mohamed or revealed to us via golden tablets to John Smith.  It is the product of thousands of people attempting to pull business out of the 19th century and into the 21st. It is changing and evolving and responding to change.

Drop the silly titles and let your work speak for itself.  We are Scrum Masters and Agile Coaches.  We are servant leaders trying to help others be more productive and content with their careers.  We need to get our hands dirty, refactor code, attend meetings, deal with the personal problems of our developers and try to make a difference in the lives of the people we work with.  This is not glamorous or flashy work but it needs to be done.  I you want to call yourself a ninja or Jedi then I think we are not going to work well together.  Don’t worry those of us exhibiting the quite professionalism the job requires will still be here to clean up your messes.

Until next time.

The Magic of Doing the Right Thing

Doing the right thing is not magic.

There is a lot of news that has bubbled up through the web and media about doing the right thing.  From administrators mismanaging VA hospitals and providing inadequate care to our nation’s veterans to the ongoing controversy regarding the National Security Agency; each day we are confronted with people who made impossible choices and exposed wrong-doing or corruption.  Setting aside the politics of this news, it is clear that people will do the right thing even when it is not in their best personal interests.  This gives me hope because as long as there are people in business and politics willing to do the right thing there is hope for the future.  I wanted to discuss this in my blog this week.

Doing the right thing is a very vague term.  If you Google it you are taken to a weird mixture of self-help sites, quotations, and a shout out to the Spike Lee joint by the same name.  During the revelations of the Pentagon papers, Daniel Ellsberg was considered both a traitor to the nation and a hero to the counter culture.  Looking back on the situation, it is clear that without Ellsberg’s efforts open debate about how to prosecute the war in Vietnam was greatly informed by the leaks of this classified information.  Thanks to Ellsberg and his efforts, congress understood how Democratic and Republican administrations lied to them about involvement in Vietnam.  It was also a valuable source of scholarship for historians and military professionals seeking to understand the conflict.  As Ellsberg said himself, “I felt that as an American citizen, as a responsible citizen, I could no longer cooperate in concealing this information from the American public. I did this clearly at my own jeopardy and I am prepared to answer to all the consequences of this decision.”

In 2009, Mattel the makers of Barbie and other popular toys was dragged into court because they had violated the federal ban on lead paint in their products.  This time the whistle-blower was a Chinese factory worker and the plant manager committed suicide before the full extent of the contamination was exposed.  Thousands of toys were recalled and the company had to pony up 2.3 million dollars to pay fines.  Worse was the hit to the reputation to the company, as it went into the holiday shopping season and had to explain to nervous parents how their products were now lead free.

These two stories have one thing in common.  When someone was confronted with an ethically dubious situation or a clear example of corruption, they decided to expose it and then they took responsibility for their actions.  They did not “play ball” and allow these situations to continue rather, they decided to change them with the only tools they had at their power which was information.

I have spent the bulk of my career trying to do the right thing for my customers, co-workers, and clients.  In some situations, I was rewarded with unemployment.  In others, I was demoted or marginalized.  That did not change how I operated because I always felt that when the chips were down others would always remember when you were under tremendous pressure and still did the right thing.  This was one of the reasons why I founded E₃ systems.  I wanted to be the owner of a software development firm and I wanted to continue to do the right thing.  Please look us up and we will tell you more.

So as we come out of a long holiday weekend commemorating the sacrifices of military during the history of our nation.  Take a little time to recognize the people big and small who sacrifice every day doing the right thing for others.

Until next time.

Science Fiction Dreams and Travel Realities

Science Fiction Dreams and Reality this week on the blog

I have been busy with trade shows and travel this week and that makes it hard to stay on top of my business and blog.  One of the interesting things about travel is that it does move you outside your comfort zone.  I also got to see the best and worst trends in technology in their natural environments.  In this blog, I want to talk about how we are living in the best of all possible worlds right now when it comes to technology.

My flight was booked via an electronic system known as SABER which has been the backbone of the airline industry since 1960.  I traveled with a mobile phone running the android operating system with the Trackit application which allowed me in real time to follow my travel plans.  I also had a tablet which used Android with three books for me to read on my flight.  Throw in my laptop and I had more computing power at my disposal than many third world countries.  This was not out of the ordinary or unusual because many of the other business travelers I journeyed with were similarly equipped.

All of the airports I traveled through had Automatic Teller Machines but no pay phones because everyone had at least one mobile device to contact someone if they needed help.  Tweets were sent, Facebook status messages were sent and deals were negotiated in terminals while people were waiting for their flights.  There were even video chats taking place via Skype.  Again none of this was out of the ordinary or unusual.  The science fiction of my 1970’s youth had come true. 

This does not mean that everything was perfect.  American Airlines canceled my flight and their customer service was spotty.  Planes were on runways without crews and it was clear that some of the flight attendants were being forced to work extra shifts to deal with the traffic.  So a two hour trip to Atlanta turned into and eight hour adventure flying to Dallas and then to Atlanta. It was an example which illustrated even the best technology cannot stand up to bad weather, institutional inertia and poor service. 

I suppose this is why Voltaire spent so much time making funof Leibniz when he said that “We live in the best of all possible worlds.”  In spite of all the modern conveniences, which we enjoy, traveling still sucks.  It is also not made any better by the dysfunctional processes we have put into place to manage travel and airport security.  This has been mockingly referred to as a “First World Problem,” because this kind of thing is merely an inconvenience and does not have life or death consequences like cholera or malnutrition. 

We are living in a technological golden age; we just take it for granted.  We can communicate with anyone via our smart phones and computers but we find it hard to communicate with the people sitting next to us on the plane.  Social stratification, government short sidedness and corporate inertia make it difficult for us to utilize the utopian dreams of all the entrepreneurs who helped inflate the dot com bubble in the 1990’s.  I wanted to become an entrepreneur because I thought I could do something anything to escape the Kafkaesque world of software consulting.  I also thought that I could help small businesses play with the big dogs and better serve customers. 

It is a grandiose thought but one that still drives me and my business.  So we do not live in a perfect technology utopia which was promised twenty years ago but when I complained about my flight being late on Twitter no one censored me.  When I made a call to my bank to deal with an overdraft I was able to compare math with the customer service rep via a mobile application.  Finally, I made dinner reservations via text message and was able to update my boss via e-mail via my tablet. 

Travel still sucks but it sucks less thanks to technology people who like me who dream big and wish to make this the best of all possible worlds.

Until next time.

Crazy, Junky Technology

Technology should not be like working with trash.

As an entrepreneur, I spend a great deal of my time keeping up on the latest literature.  I also spend a great deal of time coding for both my day job and for the company I have founded.  This week I have received a reprieve of sorts.  I am getting ready for my company trade show.  My experiences are further reinforcing my belief that for many businesses we are way behind the times.

You would expect during a trade show vendors would use mobile applications to manage buying and selling.  You would also expect them to use their smart phones to conduct business with the help of applications like Square.  No, I am spending the next four days loading primitive Windows CE devices to attempt to handle transactions.  Each device has to be individually updated and they do not synch with the web but instead over Wi-Fi to a proprietary database; if it sounds like madness that is because it is.

This would be so easy if the system was connected to a secure cloud based application which worked on the vendors own smart phones.  No set up time.  No primitive devices to configure and finally, a technology that the vendors know how to use because they use their smart phones all day.  I think that smart phones and other mobile devices are the key to success in this marketplace and I see too many small businesses let this trend pass them by.  Even the not so small business which I consider my day job doesn't quite seem to understand.  It is frustrating.

This is why when I founded my company I made sure that I had applications which worked on both the web and on mobile devices.  You should look into us and find out more. 

It just seems crazy that I have to spend my time supporting outdated and obsolete technology.  It is just as crazy that you do too.

Until next time. 

A Christmass Wish to You

The holidays are always a weird and frantic jumble.  Between parties, shopping and networking with business people who do not want to do business until after the holiday it can get a little dispiriting.  Still, I have a lot of optimism about what happened during the 2012 and I look forward to 2013 as a very productive year.

In 2012, we had the release and marketing of the Sully 2.0 system.  We are also working on a new project called Andre which we will give you more details in the coming year.  I am proud to say that we are starting to behave like a modern business with a bids and contracts going out.  As a friend of mine says, "small steps complete the journey." 

I want to take time out to say thank you for your business and attention.  We look forward to a prosperous 2013. 

Until Next time.