Dream the Big Dreams

Every Leader should have a dream

Like many scrum masters, I spend plenty of time learning new things about my profession.  I am participating in the Chicago State University, Certified Agile Coach program to brush up on my coaching skills.  We have been discussing a wide range of topics, from active listening to servant leadership.  This week, something struck me during class, and it was the observation a servant leader needs to dream big dreams.  You do not usually think about leadership requiring big ideas, but imagination is a necessary component if you are going to lead in a global economy. 

Begin labeled a dreamer is often considered a stigma in academics and business.   It implies a lack of seriousness and an inability to recognize the practical realities of the world around us.  To be a dreamer is to be either a rock star or a hippy.  I beg to differ.  People who are dreamers have a vision about how things should be.  Having the imagination to see things differently and the determination to make it happen is something that makes investors swoon and makes innovation possible. 

Being a dreamer is positive.  It looks forward and asks, “Why not?”  A leader replies, “Not yet,” when they hear something is impossible.  It is not mindless optimism; instead, it is a quiet determination to look ahead and see a better future.   In addition to seeing that better future, a servant leader needs to share that vision to provide meaning and purpose to others and yourself in this absurd world.  The ability to dream helps you gather strength in bad times and excel when the opportunity comes along. 

A dreamer is someone each organization craves because much of the business world contains drudgery and monotony.  People crave purpose and want to feel the effort they put in daily is worth the struggle, so a good vision helps fulfill this role.  As a servant leader, dreaming big dreams is necessary. 

Until next time. 

Motivate Others Instead of Bossing Them

Motivation is Powerful

The biggest challenge for a coach or leader is motivating others.  If anyone could do it, the world would be a different place.  Problems like hunger, climate change, and a properly fitting pair of slacks would quickly happen because people would want to address those problems.  In reality, we struggle with these challenges because it is hard to motivate others, and there is an entire group of people who want to discourage people from thinking there are solutions to these issues.  Motivation is getting people to swim against the current of conventional wisdom. 

 

Motivating others is a full-time job.  It requires the application of soft techniques of persuasion and other times the blunt force of human resources.  People want to feel useful and challenged, but often they settle for security and routine.  A leader needs to work with these messy people and give them a chance to rise to their circumstances.  I struggle with this because I come from a command and control environment.  I would discover later in my career; this approach does not work with technical or creative professionals. 

 

The global economy has shifted from building things to creating experiences, services, and ideas.  It is a complicated process, and it requires more than following orders.  It requires looking at things from different perspectives.  The creative process requires a sense of craft.  Finally, it demands that people look at problems and question established answers.  People who excel at these skills are rarely the type to follow orders.  

Because we rely on information and creativity more than ever, leaders need to convince people why things need to happen instead of what needs to happen.  Give a problem to a bunch of creative people and tell them why it needs solving; you will be surprised by the effort they will put into solving it.  Telling people why something is essential creates a common cause with the team.  Explaining the urgency and necessity gives importance to work.  People with purpose are better than those with a plan.

So as a leader, you need to show others where you want them to be rather than telling them. Act as an example by listening to others and avoid asking someone to do something you would not do yourself.  Support others as they struggle to come up with solutions and listen to what others have to say.   It is surprising what you will learn.  

I do not have a magic recipe for motivating others.  Each day, I do my best to explain why certain things should happen.  The team should be concerned with how it should happen.  Finally, try to be an example for others to emulate.  Motivating others is not an easy process, but if you can do it right, the results are deeply satisfying.  

Until next time. 

Good Habits, Teamwork, and Grace Create Agility

Forgiveness is Agile

Being a business person is the ultimate endurance sport.  Each day we awaken and try to earn a living for ourselves and the people we love.  It is a grind.  It goes on for years, and if we are lucky, we will get a chance at the end of our lives to reflect and relax.  It is a precarious existence of striving and survival.  The business person confronts this reality each day.  We compete for the quick win and the big score but understand the long term nature of being a business person.  We need to take a look at the long term nature of the life of a business person and how agile can make the experience more sustainable. 

Building a business is a harrowing process.  For every entrepreneur who succeeds, there are more who fail.  Some of the best ideas fail because they can not find a market, while some of the most trivial can generate oceans of wealth.  The random nature of the success breeds arrogance, and these captains of an industry often ignore problems within their organizations until it is too late.  Only when threatened with extinction do organizations feel the need to change.  The scrum master steps into the world of organizational change when the stakes are highest.  It is the realm of failing fast and making corrections.  For some, it is like building the business from scratch all over again. 

The first step is building successful habits among the people doing the work.  It means meeting standards of quality, showing up to meetings prepared, and communicating correctly to make sure everyone understands what needs to happen.  The process of setting up the fundamental expectation of excellence is outlined by philosopher Will Durant who said, “We are what we repeatedly do.  Excellence, then, is not an act; it is a habit.”  Asking people to develop good habits and practice them is the first step to improvement.  Do not ask people to work extra hours and do not expect them to treat their work as a heroic struggle.  Work should be at a sustainable pace; heroic action is unnecessary. 

It is after this process that you enter the second step.  Everyone should understand the business succeeds or fails together as a team.  It takes a team working together and complimenting each other’s strengths to be successful.  The success is constructed on positive habits and relying on others to do their part.  It is the salesperson respecting the administrative assistant for getting the presentation organized, and it is the developer understanding the quality assurance tester wants to ship quality code.  Everyone has a role to play, and it only happens when we work together. 

Habits of excellence and creating a team mentality in the organization are entry-level steps in creating agility.  It also requires what religious people call “grace.”  A pastor once told me the Christian definition of grace is, “…getting absolutely, positively something you do not deserve.”  It is having school canceled when you did not study for an important test.  It is the client rescheduling a meeting when you are stuck in traffic.  I also think grace is when you forgive yourself and someone else for a bad day.  It is the extra cup of coffee or bag of chips as you muddle through the day.  It is letting some go home early to look after a sick child or deal with the side effects of chemotherapy.  Grace means that you can trust others on the team to step up when you are not performing at your best. 

It is only by combining the habits of excellence, creating teams, and practicing grace do we create a more sustainable business environment.  It is a place where the day in day out grind becomes a day of learning, innovation, and forgiveness.  The victories are more regular, and the defeats are more educational.  It is a new way to look at work and one which I hope to pioneer. 

Until next time. 

We need to teach the agile reformation

Everyone in agile is an educator. 

I have a love affair with teachers.  My Aunt was a teacher and an elementary school principal.  My first wife was a teacher, and my current romantic partner is a teacher.  I owe my career and success to teachers who invested time and energy on me.  Teachers are the glue which holds society together, and without them, the world would collapse into a puddle of ignorance — teachers mater.

I some respects, I have become a teacher myself. I have spent the last few decades of my life learning software developments and project management.  Now I am sharing my knowledge with others and helping make business better one project at a time.  Being a scrum master and agile coach means you have to be a teacher.  The Agile manifesto and principles of agile are a foundation of a massive ecosystem of learning about how to make work more sustainable, satisfying, and sane.  It is a calling, just like teaching.

The world of agile is continuously changing. After the creation of the agile manifesto, we did not know how to scale agile to larges organizations; software testing was not part of the conversation, and many though it would only work with technology.  Today, thanks to the contributions of thousands of people we have solutions to those challenges.  We use agile in Human Resources, Education, Marketing and Finance.

To me, the reasons are clear why agile is growing.  The emphasis on transparency, inspection, and adaptation prevents organizations from being dogmatic about how they do things.  It is a pragmatic approach which makes an effort to deal with the chaotic nature of the contemporary world.  It is also a world view seen through the lens of engineering, where people fix problems and discover solutions.  Finally, it is an optimistic approach to the world where we make small and steady continuous improvements one sprint at a time.

The agile reformation is not entirely unicorns and glitter.  People are resistant to changes, and large organizations are notoriously hard to transform.  I have suffered numerous personal and professional setback in this field.  Every reformation has a counter-reformation.  Still the hard work and dedication to teaching others how to do things a better way is what keeps the movement going forward.  My love affair with teachers began when I was a child.  The love has grown stronger as I have become a coach in the agile reformation.

Until next time.

Four Simple things

It can get lonely.

The biggest challenge as an agile professional is leading organizational change.  Often, you are a lonely voice in an ocean of indifference.  People do not like the daily routines and rituals disrupted, and agile professionals are doing it with frequency.  The resistance is a natural response to change.  Humans have a craving for stability in an uncertain business world.  The situation sets the agile professional up for isolation and loneliness.  I want to discuss the support system you need to overcome the adversity.

Being a scrum master or coach is a difficult calling.  It requires tremendous emotional labor, and you are attempting to overcome decades of resistance to change within an organization.  To be successful, you need to have a support system which will help you get through the rough patches.  Here is my formulation of that system.

An Understanding Significant Other

If you have a spouse, boyfriend, or girlfriend, they need to be understanding.  You are going to have unannounced late nights being with the team fixing production bugs.  As a servant leader, you will confront difficult emotions, and it will take you time to unwind from them.  It helps to have someone in your life who loves and respects you to listen. Finally, they should be willing to work with the ebb and flow that technology professionals encounter daily.  It is like being married to a police officer or firefighter.  The job always finds a way of intruding into the relationship.

A User group or Network of fellow Agilests

Many organizations do not have a large cohort of agilests.  It is why being a coach can be so isolating. It is why you need a regular group of people to meet with discussing current trends and new techniques.  It can be an online group or frequent meetup.  The purpose is to have a peer group which can provide emotional and professional support.  Often a problem you think is intractable is something someone else has solved.  The user group acts as a repository of information, a social circle of peers, and group therapy.

Support from Senior Leadership

Change does not happen, spontaneously.  Often, it requires outside events to force change or an internal mandate to make change happen.  An agile coach without the support of senior leadership is not going to be successful.  Cultural inertia is a common obstacle to change.  Often when you ask why something is done a particular way the response is, “…because we have always done it that way.” Senior leadership can give you a mandate and authority to improve a process.  Executives provide the nudge necessary when things need to change and when people dig in their heels.  Finally, senior leadership is a source of validation which makes the hard work and sacrifices worthwhile.

Allies in the Organization

As a firm moves along the agile journey, a coach or scrum master is going to gather like-minded people who are allies.  Organizational allies are gold to a coach or scrum master.  The people joining you will spread the message you are sharing. Associates will provide emotional and technical support.  Colleagues will support you during a difficult decision and join you for lunch when times are less stressful.  Cultivation of colleagues will keep the agile transformation going long after you have left the organization.

So to avoid burn out and isolation a coach or scrum master needs; an understanding significant other, a network of fellow agilest, support from senior leadership, and allies in the organization.  Without these things, an agilest will have a lonely run with an organization.

Until next time.

No Estimates have a spot at the Campfire

Lots of debate around the campfire.

One of the best things about being a member of the Agile community is the smart and enthusiastic people you encounter online and in person.  It is refreshing and challenging to be around people who have a shared vision of making business faster, sustainable, and more intelligent.  The commitment to the goals of agile does not mean we are ideologically unified and dogmatic.  Like any healthy practice, we disagree with each other about basic principles, ways to spread adoption, and innovations.  The creative tension is essential.  I want to add my two cents to an on-going debate which a colleague Ryan Ripley brought to my attention from the sober and restrained convention floor of the #BetterSoftwareCon in Las Vegas. 

The #NoEstimates movement has become a very vocal camp in the agile reformation.  If you follow the debate, it is easy to see why.  The estimation process at many companies is farcical and corrupt.  Story points were created to provide the benefits of estimation without the obvious drawbacks.  The #NoEstimates crowd take this to a logical conclusion and say estimating is a waste of time and energy.

I do not feel very strongly about #NoEstimates.  What makes it interesting is it provides a different perspective to authoring software.  Neil Killick then posted a white paper this week showing some qualitative measurements which show a no estimates approach works just as well as a story point approach.  

I was skeptical but, I decided to give the article the benefit of the doubt.  Killick uses T-Shirt sizes to measure ambiguity and difficulty.  Using arithmetic and charts, he shows how he can forecast project completion.  The approach is well thought out and clear.  It is also story points dressed up to look like #NoEstimates.  It requires the product owners to spend time doing arithmetic instead of writing stories and working with customers and developers.  Personally, I struggle getting product owners to perform the basics of their duties.  Thus, using Killick’s approach may work for a different agile implementation but not for mine. 

I genuinely dislike debates which generate more heat than light.  Killick provides a good approach for a more mature agile team.  I am glad I had a chance to learn about it and will keep it in my chest of tools if I feel it worth trying.  The agile manifesto says, “Individuals and interactions over, processes and tools.” I believe that Killick’s approach is a process which might work with a particular set of individuals.  I also think that discussion of #NoEstimates is good for the agile movement.  People try out ideas, test them, and they are adopted or rejected over time.  It sounds mighty agile to me.

Until next time. 

Break out of your rut!

I have been thinking about my craft.  A scrum master is a coach, therapist, and advocate for their team.  We have emotional ups and downs in the profession.  We are also fortunate enough to make a difference in the organizations we work.  It is rewarding but filled with the trade-offs professionals are confronted.  This week wanted to discuss a constant force in the life of a scrum master continuous improvement.

As a professional, it is easy to get into a rut.  Decision fatigue sets in and so you order the same thing for lunch or manage how you deliver software.  Routine and inertia are comfortable because it provides a false sense of security in an uncertain world.  Your heart could stop from a simple blob of cholesterol or the company share price could crumble overnight, but thanks to the routine we ignore these catastrophes.  Inertia is safe and secure.  It is also the enemy of continuous improvement and agility.  It is why scrum requires retrospectives.  The feedback allows everyone evaluate how to improve. Development includes the product owners and the scrum master.

I was doing a product increment planning meeting for the product owners to coordinate releases and plan for the future.  On a whim, I decided to include a retrospective of the last quarter to get a sense of where we are and where we are going.  A tense hour later a few lessons were learned.  Using a four “L” retrospective, I wanted to understand how as a product development team we were doing.  The answer was unambiguous.  Some things which we could control had to change.  The retrospective included passive aggressive conduct, and a few choice criticisms pointed at me.  It was worth it.

Based on what I learned, I am going to conduct retrospectives differently with the development teams.  I am going to work with the product owners more closely to help them manage their work more closely.   Finally, I am going to try and break out of my decision fatigue.  Continuous improvement matters, and if you expect it of others, then you should expect it of yourself.

Until next time.

Fix Technical Debt NOW!

Technical debt is a lot like leaky pipes

I am very fortunate to spend time with smart people.  The day goes by faster when you spend it with intelligent and capable people.  One of those talented people is a former colleague of mine, Larry Gassik.  He was asking me a few questions about technical debt, and it occurred to me that I have not shared many of my thoughts about it on the blog.  Technical debt is becoming a growing concern in the agile community as more teams expand into enterprise systems and confront legacy code.  This week a brief conversation on technical debt.

When I think about technical debt, I use the metaphor of plumbing.  Indoor plumbing has existed since Roman times, but its innovations only became global in the 20th century.  Thanks to plumbing, the spread of cholera have ended.  Indoor plumbing has given millions of people clean drinking water and helped reduce pollution.  Plumbing is so ubiquitous that the only time we notice it is when it is not working.  When a toilet backs up or a pipe bursts, we become very aware of the effects of plumbing on our lives.

The “if it isn’t broke don’t fix it,” attitude we have about plumbing is prevalent in the business world.  Many business professionals in the corporate world are focused on shareholder value and profitability.  When business professionals think about technology, it is either an expense or inconvenience.  It is why many organizations have not made the switch to cloud-based systems and use old versions of Microsoft office.  To them, the investment of money is not worth the rate of return.  The reality is that not paying attention to older technology systems is just as negligent as ignoring the maintenance of your home; you risk broken pipes and greater expenses caused by water damage.

The technology of pipes and plumbing has changed over the centuries to be safer and less expensive.  In Roman times, pipes were lead.  The contaminated drinking water caused outbreaks of “Saturnism” which was a polite term for lead poisoning.  Terracotta pipes followed, but those broke down over time thanks to tree roots and natural decay.  Iron pipes came along, but they were brittle and caused water to be rusty.  Copper pipes came along and have been a good solution, but they are expensive and require welding which creates maintenance a problem.  Today, most new construction relies on PVC pipes because they do not corrode, are inexpensive, and easy to maintain.  If the materials of plumbing can change so radically, image what is happening with technology moving at the speed of the internet.

Forty years ago, while the Sex Pistols were singing “Anarchy in the U.K.” there was no personal computer market in the United States.  Microsoft and cellular phones did not exist, and a modem was fast if its speeds were 300 bits per second.  Mainframes dominated computing, and most business transactions were done over the phone or in person.  Compare that business environment to smartphones, personal computers, and Gigabit speed internet we have today.  There is no credible way the technology of 1977 could support the needs of business today.  The difference between the needs of the firm and the ability of the technology to support the business is something agile professionals call technical debt.

Technical debt is cancer threatening to metastasize and kill the business.  Here is how it happens.  Slow or ineffective systems undermine customer confidence.  Weak confidence means less use and less use guarantees less money for the company to maintain the system.  Less money translates into slower time to market for new features and updating the system.  It means employees and IT professionals will take shortcuts to bypass the pokey system.  With the system jury-rigged to address business problems, it becomes more expensive to maintain, and improvements take longer to roll out.  Finally, you create a situation where the system fails, and it does not provide benefit to the business.  If you pay attention to the technical debt, you can avoid this kind of failure.

A business with significant technical debt will have trouble attracting talent.  Computer professionals being smart, know what technologies the market supports, and they are terrified of having skills which are obsolete.  It means they will gravitate to businesses and projects which have a smaller portion of the technical debt.  It also means that college graduates will avoid working for companies with old technologies.

Technical debt is the difference between what the business needs and what they technology systems support.  If you do not address technical debt, it is a threat to the success of the firm.  Finally, the mitigation of technical debt is no different than routine household maintenance.  Do the right thing and focus on technical debt before the pipes burst in your business.

Until next time.

Respond to Change or else

Change is not magic.

Software development is a weird stew of activities.  It is a creative activity taking the vague guidelines of others and turning it into working code.  It is an engineering activity because it requires a certain mindset only found in engineering.  It requires business acumen because software should do something which supports business.  Finally, a software developer has to adjust to change because technology, business, and the world are moving at the speed of the internet.  It is my firm belief that the best software developers and Scrum Masters need to acknowledge this change and learn to work with it.

I am coming up on twenty years in the software business, and the skills I needed at the beginning of my career do not match the ones I use today.  Some principles do translate like HTML, CSS, and object-oriented programming but in the beginning, there was no such thing as generics, responsive web design, or C#.  I relearned the skills I needed in my career every 18 months.  The reward for this struggle is employment and opportunities to share my experiences with others.  I want to make sure that no one suffers the kind of failure or mishaps I have in my career.

The constant theme in my career has been responding to change.  When VB.net careers began to dry up, I learned to code in C#.  As screens became smaller and mobile computing began to grow; I had to learn Bootstrap CSS and Jquery Mobile.  I was an early adopter of Agile and Scrum, but that has not stopped me from reaching out to find out more frameworks like LESS and SAFe to be successful.  In this business, a person needs to keep learning and growing.

In the agile manifesto, this idea is called, “Responding to change over following a plan.” In our contemporary economy, there are no promises in business so as a working person it is important to make sure your skills are up to date and marketable.  As an employer, it is important to address technical debt and make sure your staff is learning the latest skills to keep your company infrastructure up to date.  Upgrade your servers, use an office suite in the current decade, and shun mediocrity in all its forms.

The only thing sure in the business community is change and to be a successful software developer or scrum master you must learn to embrace change.

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.

Scrum should not be a cargo cult.

Scrum should not be a cargo cult.

Blogging about business and scrum opens you up to feedback and criticism.  Confronted by people who challenge your ideas allow you to reflect on your knowledge and beliefs.  A college of mine took offense to me referring to the meetings of a scrum as “rituals” last week.  I would like to address his concerns.

The primary criticism of my article was that I was encouraging a “cargo cult” kind of scrum.  The term comes from a Scientific American article from 1959 which documented primitive tribes in Melanesia coming in contact with missionaries and soldiers.  The connection prompted these indigenous people to create cults to encourage cargo to be delivered to them.  Primitive air strips, airplanes, and shipping terminals cropped up in the hope that actual cargo planes and people would show up.

The pre-modern culture felt if they mimicked the trappings of technology without understanding the principles behind that technology they would receive the prosperity which comes with modernity.  This assumption is wrong.  The tribes created many faux landing strips and cargo depots in the South Pacific.

People in the agile community, use the story of the cargo cult to illustrate the difference between going through the motions of agile and being agile.  In a perfect world, a business would reconfigure itself to follow the word and spirit of the Agile manifesto.  We do not live in a perfect world, so it is up to scrum masters and agile coaches to provide structure for the transition from traditional business to agility.

The events of scrum provide a means to help speed that transition.  Business people and developers are forced to inspect, act and adapt to changing situations.  That is the heart of an agile business.
When I refer to the meetings and events of the scrum as rituals, I mean the meetings should have purpose and significance.  I am not attempting to create a “cargo cult” in an organization.

I am glad someone challenged me on my assertions, and I look forward to more give and take in the future.

Until next time.

Why we have rituals in scrum

Becoming a scrum master is like becoming a priest

I am in the process of training a new scrum master at my office, and they asked why we have so many meetings in Scrum.  This week I wanted to share my thoughts on the subject.  The Scrum Alliance has plenty of documentation about Agile, the roles in a Scrum team, and rituals associated with it.  As an experienced Scrum Master, I wanted to dig a little deeper into the activities and explain why they are important.

The role of a Scrum Master is a complicated one.  I have written about the topic numerous times.  As I have grown more comfortable in the role, it occurred to me that this position resembles the life of a parish priest or Protestant minister.  You are always visible and accountable to the people you serve.  I firmly believe in the need for a human being to have ritual and routine in their lives.  Both Carl Jung and Joesph Campbell, mention that the collective unconsciousness is something which needs nurturing.  If we do this, then we are on the way to building effective teams.

The daily stand up-

Each day the team gathers around the metaphorical campfire and talks about what they have done, what they will do, and obstacles.  Working in an office creates a few anti-social behaviors.  It is very easy for people to cocoon into their desks and ignores others.  The stand up breaks people out of that unhealthy habit.  Each day for 15 minutes they interact with the scrum master and each other.  The group stands because it forces people to pay attention to one another.  It also keeps side talk to a minimum.  Finally, it helps foster a sense of teamwork because everyone is participating and involved in the success of the project.

After a few weeks or months, the scrum master should not facilitate the meeting.  Instead, the team should learn to run its stand-up meetings.  It is part of the ethos of self-organization.  It is essential to the success of agile at any organization.

Backlog Grooming or Refinement – 

The Product Owner has the most difficult job in agile.  They work with the “business” and the development team to create software each sprint.  Backlog refinement is where most of this job happens.  The Product Owner and the development team go over the backlog.  This meeting is designed to clear up any misunderstanding, explain user stories, and set priorities. It is an informal meeting with back and forth conversations.  The Product Owner facilitates this session.  It can be done regularly each day or scattered around a work week.  The keeps communication between the team and the product owners flowing.

Sprint Planning – 

The Scrum Master, Product Owner, and development team get together to decide what they want to work on in the next sprint.  Using the refined backlog the team and the Product Owner decide what to do next.  This meeting is a little more formal as the team estimates and tasks out the work.  The meeting also ends with a consensus about what the sprint goals are and how to meet them.

Sprint Review or Demo –

One of my biggest frustrations I had as a developer was spending a year on building a software product and then showing it to the user community and having them say it is not what they wanted.  The sprint demo is designed to eliminate this situation.  After a sprint, the development team shows off their work to the Product Owner and the people who are stakeholders in the project.  Here they gather notes and feedback where they can improve.  The demo also shows the business that things are getting done and that they will have software in a measurable amount of time.

The Retrospective – 

The retrospective led by the scrum master.  It is a combination of rituals.  It is about what happened.  It is also a look forward at how to improve.  Everyone participates in the process, and everyone contributes.  It is up to the Scrum Master to take notes and help the team improve on how it is supposed to do its work.  The retrospective is the most difficult part of the scrum process, so a scrum master good at facilitating meetings is essential.

So this is my take on the rituals of Scrum and why we do them.  They are all important, and if you do not do them, the effectiveness of your scrum teams will suffer.

Until next time.

A scrum master should do more than punch a clock

A good scrum master is like a good camp counselor

As we head into summer, it is a good time to reflect on the first half of the year.  I am going through numerous personal and professional changes.  My role is going to be changing at my firm and there are plenty of comings and going.  This week I wanted to discuss some insight I gained at the office.

Many of you know, I am a big fan of Angela Dugan and her blog The TFS Whisperer.  For three days, she came to my firm and conducting training for Visual Studio Team Services and spent quality time with Product Owners at my firm.  What happened next was a revelation.  The following Monday half of the scrum masters in the organization were rolled off.

I think it would be unprofessional and small to discuss the details of why those scrum masters are gone.  Instead, I will say their departure reflects a divide in the agile profession of scrum master.  There are two camps; one camp see being a scrum master as being a glorified project manager, the other camp sees the scrum master as a servant leader, coach, and therapist for development teams.  I belong in the latter camp.

There is plenty of blogs on the web which say that being a scrum master is not being a project manager.  Yet, I see some scrum professionals who see their job as nothing more than scheduling meetings and updating the scrum board too.  This is not being a scrum master.  It is a person accustomed to doing things the old way of attempting to survive in the corporate rat race.  They do not really add value and often create scrum-butt situations.

In my opinion, a scrum master is more than someone who punches a clock and generates reports.  They are more like a camp counselor or youth pastor minus the bad facial hair.  They have to hold other people accountable.  They have to train product owners to a basic level of competence.  They have to make sure that people are shipping working product into production.  Finally, they have to keep people motivated because software development can devolve into a soul-crushing activity.

In short, being a scrum master is hard emotional and intellectual work.  If you are not willing to do that work then you are likely to get rolled off a client.

Until next time.

Reputation is not licence to be a jerk

We know lots of people like this.  A few of them 
 set the conversation of the technology world.
 Image courtesy of Slate.com.

The world of technology is filled with plenty of smart, talented and colorful personalities.  This dynamic was one of the reasons why I was drawn to the business.  This week I want to talk about of these colorful personalities and how he represents some of the worst impulses in the technology business.

There are plenty of stereotypes in the technology business.  These are reinforced by popular culture in productions as diverse as James Bond movies, the Fox series 24, and the HBO program Silicon Valley.  Having over 18 years’ experience in the business, I have seen many of these stereotypes in real life.  I have also met plenty of great people who are unique and innovative in every way.

By any standard, Alex St. John should be seen as one of the leading minds in the technology field. He was self-educated and self-taught.  He created the DirectX technology which powers Xbox and just about every PC game on Windows.  His work helped make Microsoft the power house it is and he earned further accolades founding his own company.  This kind of achievement should make St. John a good will ambassador for the technology field instead, he is coming off as a colossal jerk.

I can provide numerous examples which have already been articulated elsewhere on the web.  These offenses break down into three categories.

• He does not see the value of women in technology.  Exhibit A.
• He thinks that exploitative work conditions in the software business, particularly, the game business are acceptable.  Exhibit B.
• Finally, anyone who disagrees with him is a “whiner” of not willing to work hard.  Exhibit C.

I have stated repeatedly, technology needs more women.  The fresh perspective they provide to technology is essential to improving product quality.  It also makes the office less like a Mongol raiding party and more like a 21st century work place.  The less testosterone in technology the better.

Next repeated studies have shown that long hours are a hindrance to productivity rather than a boon.  Notions of “crunch” time and working eighty hour work weeks are exploitative and boarder on the illegal practice of wage theft.  Additionally, the twelve principle of Agile discourage this mindset stressing development should sustainable.  To St. John and others developer burn-out, turnover, and alienation are the cost of doing business.  Technology workers are not different that sweatshop workers and they should be grateful for the conditions.

Finally, St. Jon has ridiculed people who disagree with him about issues of diversity and exploitation of tech workers by claiming they are not ambitious enough or smart enough to understand his arguments.  In St. John’s world, I would have died of a heart attack because I would be living on steady diet of caffeine, pizza, and stress.  The technology world has undermined two of my marriages because of high stress, turn over, and uncertain employment conditions.  It is hard to keep good employees if they don’t see or sleep with their significant others.  I consider myself a valuable professional to any organization, but to St. John, I am just a pencil to be ground down into a nub to be replaced by someone else just as disposable.

Bottom line, if you do not agree with St. John, then you are neither smart nor talented enough to work in technology.  This may explain why he is spending more time coaching CEO’s and HR professionals on how to recruit technology talent than actually managing technology talent.  I have worked for people like St. John who are convinced of their intellectual and moral superiority. It is not fun and I consider those periods the low points of my career.  Technology is changing thanks to agile and efforts to improve diversity.  Faced with the changing environment you can, lead, follow, or get out of the way.  I think that St. John is about to get trampled to death.

Until next time.

The Coffee Pot and Innovation

The coffee pot can tell you a lot
of things about the corporate culture. 

Certain things happen in a business which are illustrative of that organizations culture and its approach to innovation.  This week I wanted to share an example.

The facts

It is 8:30 on a week day.  The coffee pot is out of fresh coffee and a pound of fresh ground coffee is sitting next to the pot.  The department manager comes into the office and sees there are no pre-measured packages from the coffee service.  They retrieve three pre-measured bags of coffee and make a pot of coffee.

The maker and innovator in the office perceives 

“This is why we cannot innovate in the business.  You had a pound of coffee and could not make a pot of coffee without a measuring spoon or visually filling the coffee filter.  This means we are inflexible to changing situations, unwilling to try new things, and unable to deal with ambiguity.”

The person who made the coffee perceives

“I don’t see it that way.  The pre-measured coffee is just the right amount.  I do not have to measure it.  I don’t have to guess and I know that I am going to get a good pot of coffee every time.  This means less waste and everyone got a cup of coffee with no fuss.”

Some conclusions

I need to read some Wittgenstein or take a class on his feelings about the nature of reality.  I am the innovator in the office and being unable to make coffee without pre-measured packages makes me crazy and is an example why change and innovation is so difficult.  The person who made the coffee does not see this as a symptom of a larger cultural issue and is more concerned with the end result rather than the process of making coffee.

This further reinforces what I have been reading in business literature and in cognitive psychology.  People want creativity until they are confronted with creative people and ideas; then educators and business leaders reject creativity.  So we create a situation of cognitive dissonance where we want people to be creative and adaptable but when they are we discourage those behaviors.

This is the world of shadows that a scrum master needs to navigate. We need to help people learn new ways of doing things but not be too creative otherwise we are going to face backlash and rejection.

So how do we agile professionals learn to better manage change in organizations who prefer the coffee in pre-measured packages?  I would love to hear your recommendations.

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.

Why I am learning TDD.

I am in the middle of a journey.  By day I am the scrum master for agile teams across two continents.  In the evenings, I am attempting to run a business and do development for that business.  It is not easy.  One of the hardest things about my job is that I have to improve my knowledge every 18 months or I will become stagnant.  A technology professional who does not continue to grow and develop, is someone of diminishing value.  This week, I would like to discuss that trend.

A software developer is a profession which is constantly learning and evolving.  When I began working as a software developer; Visual Basic 6 was a popular tool for enterprise applications.  Active X Data Objects were the means to connect to an SQL Server 7 database and ASP classic was just starting to supplant perl script for web development.  Today, all of those technologies are considered obsolete.  If I had not bothered to learn the newer technologies coming over my career I would be out of work today.  I had to learn Entity Framework, MVC, C#, and cascading style sheets otherwise I would be unemployable.

Fortunately, developers and other technology companies have numerous tools to retrain themselves with the new technologies as they come out.  There are educational video services, countless on-line tutorials, and numerous user groups around the United States to help software engineers keep their skills sharp and up to date.  Finally, developers are natural tinkerers and so they spend hours and even days learning to master new skills.

I am talking about this today because over the next few weeks I am going to start working on a project for work and at the same time I am going to attempt to master test driven development.  I know it is not going to be easy but I think with some hard work, I will be able to adequately author tests and help others understand why this is a good approach.  I have been putting off this learning for a long time so I hope it will make me a better scrum master and developer.

Until next time.

Why do we treat customers like users

It was a big week in technology.  Microsoft had a massive press conference to promote its new operating system.  E3 had a big technological breakthrough which will lead to new products which I will share more about in a later blog.  Finally, there was the state of the Union address which almost devolved into playground insults.  It was not a bad week.   What struck me most about the week was a tweet from Yahoo technology critic David Pogue he said the following,

Microsoft CEO Nadella just now: “We want users to love Windows.” You could start by not calling us “users.” http://t.co/kgtlt2Ux15
— David Pogue (@Pogue) January 21, 2015

The over-caffeinated pundit from Yahoo is right there is something wrong with software engineers because we refer to our customers and consumers as if they are drug addicts instead of full partners in the software experience.  This week I want to talk about that.

The term “user” has been around as long as I have been working as a software developer.  My suspicion is that I can trace its origins back to the early days of corporate computing.  Large Mainframe and AS/400 systems housed tremendous amounts of data centrally and the “operators” of these systems the network administrators and programmers allowed “users” to run programs to gather data.  Ever since the 1960’s, the term has stuck and I feel it poisons the relationship between those who make software and those who use it.

Since the first moon landings, the powerful computers which took us to another world can now conveniently fit into a contemporary smart phone.  Instead of mainframe systems, we have the internet and cloud based computing.  In addition, an entire generation has grown up swimming in technology.  Sadly the habits and attitudes have struggled to catch up.  Daily, I see developers use the term “users” to refer to the people who depend on the software we create.  Users are stupid, selfish, clueless, and careless in equal degrees and they are the bane of the life of a software engineer because they are constantly breaking their creations.

I understand this feeling.  I spend hours working on software trying to get it to work correctly and then someone comes along and breaks it with little or no effort.  It is part of the sense of pride and skill developers have which allow us too figure out how to bend technology to our will. When someone dismissively breaks that technology, it creates a spiral of rage inside me which is difficult for me to explain.  That software is my “baby” and for someone else to call it defective or ugly is a serious insult.

What we do not talk about is that the “users” are really not trying to break our creations or insult our intelligence.  They just want things which work.  They do not plug in a lamp worrying about amperage or voltage.  They just want to plug in a lamp and have it light the room.  Software is supposed to solve problems and help make the day go easier and faster.  They should not have to worry about out of memory exceptions or properly filling out forms.  They just need to use the software on their computer, mobile device and tablet.

They are not users of software; they are consumers and customers.  Those of us in the software profession need to remember that and treat these people accordingly.

Until next time.

Sincerity is greater than charm.

I had the good fortune to get out of the house and go to the movies.  My date insisted on “Into the Woods” and like all good natured boyfriends I went along for the ride.  What struck me about the movie is how it took a Tony Award winning musical from Stephen Sondheim and made it work for the big screen.  It also gave me a bit of dialog which is going to stick with me and that is what I want to talk about on this week’s blog.

Toward the end of the movie, it becomes obvious that the prince charming is NOT a respectful or loyal husband.  He confesses to his wife which he cheated on, “I was raised to be charming not sincere,” and then rides off into the distance.  Being charming was more important that making sincere commitments to our prince.  This is direct contradiction to what one of my mentors out of college told me when I first joined management.

He said, “I have known people who get by on charm and cuteness their whole lives.  I have no use for them.  Sooner or later you are going to have to quit being charming and cute.  Someday you are going to have to suck it up and know what the hell you are doing.  Then we can work together.”

No matter what job you do, you are going to have to prove some competence in that field.  In other words you have to be sincere about your skills and what you can do with them.  Twenty years since that message it has still stuck with me.  It is a message which sticks with me for the management of my business and it sticks with me for the way I lead my scrum team.  I need to be honest and sincere with people in order to be successful.  This is good because I can’t imagine working any other way.

Until next time.

2015 Predictions

Happy New Year

The New Year has come and gone and I am glad to say that I made it out the other side with no major damage.  When you go through a mile stone like the New Year it always makes you reflect on the past and look forward to the future.  This week on the blog I would like to discuss some trends you should watch out for 2015.

Competition kind of works in 2015

Trends we saw at the end of 2014 are going to accelerate in 2015.  Particularly price wars between the major providers of cell phone service.  I went to the store complaining about my service and I got rapid help and extra data on my plan for no additional cost.  The reason why, a major competitor is was stealing customers away.  So now I am being treated like a valued customer instead of an obedient revenue stream by my wireless company.

You are also seeing this trend in gasoline prices.  According to the Economist, prices are down because OPEC nations are trying to discount the price of oil because the United States using technology to undercut their market share.  This has kicked off a price war with OPEC hoping to make it too expensive for America to pump oil.  It is a geopolitical and economic game but for consumers in America it is a welcome change.

So while many academics and members of the political left complain about the failures of capitalism, we can point to the last three months and the upcoming year and say that capitalism works from time to time in a consumers favor.  We should savor this moment.

The Internet of things takes a pivot

The internet of things or IoT was supposed to big deal in 2014.  What happened is that it was exposed as wind and sails. In the meantime, firms are working along the edges to create smart devices which will fulfill some of the promise of the IoT.

I noticed this at the Chicago Auto Show in 2014 when all the new cars had at minimum blue tooth connectivity with mobile devices. Then later in the year GM was offering cars with 4G LTE service.  This means that the morning car pool or play date will allow people to stream movies or play games across the web.

I am also looking forward to home security and energy consumption being managed over the cloud with Google’s purchase of Nest.  Now with a smart phone or web connection you can set the temperature in the house or make sure the smoke detectors are working.  I hope they have a feature to tell me which ones I have to swap the batteries for instead of guessing based on how they chirp.

The biggest IoT moment is the sale of smart televisions.  Now people can treat their televisions like their mobile devices.  This has been huge for Netflix.  Google has also gotten into this bandwagon by making it possible for devices running the Lollipop operating system to show programs on the screen so now the difference between a television and mobile device is a question of size.

Agile Grows 

When I was first exposed to Agile, I was greeted with a lot of skepticism and contempt for many of my employers.  Today, I am part of a movement where I am making a difference in organizations showing them how to make better software faster.  What a difference a few years makes.

What I am seeing is that Agile is facing some serious problems in the business community which are not engineering problems but are organizational and behavioral.  This means project managers such as myself are going to have to continue to rise in organizations and in order to help them realize that uncertainty and agility are not threats but rather chances to succeed.  It is not going to be easy considering that many executives have no idea how the operations of their business work.

So those are my predictions for 2015.  I am able to survive another year thanks to some consulting business and people paying invoices so I look forward to another year of sharing my experiences of growing my business.

Until next time.