When the Going Gets Tough Emotional Intelligence is a Force Multiplier

One of the most frustrating things I experience is business people making promises to customers and expecting technical professionals to keep those promises.  It is a clear violation of the social compact of agile.  Sadly, it is also a common occurrence.  In these high-pressure moments, it is clear that the people making the promises do not have the technical knowledge necessary to keep those promises.  If the situation becomes, egregious people can wind up in jail.  I have spent plenty of time working on these intense projects, and I want to try and provide a few tools to keep you from going insane.  

William H. Janeway is a founding silicon valley venture capitalist; his book “Doing Capitalism in the Innovation Economy” includes a great piece of wisdom about times of crisis in the investment world.  When situations deteriorate in a business, investors want cash and control.  The money is necessary in case of more economic hardship, and the control ensures work gets accomplished.  It is a harsh truism.  

With deadlines looming, executives are under intense pressure.  An executive often micromanages a team because it is the only way to look like they are in control.  It feels like playing a game of twenty questions with someone on amphetamines, pointing a gun at your head.  

Conversations resemble the following.

Executive #1 – “Those two bugs, when are they going to get fixed?”

Product Owner – “We wrote up the bugs five minutes ago when we were testing, so we are going to diagnose the problems and provide logs for the development team.“

Executive #2 – “We promised the client a release date on X.”

Product Owner – “I am aware, but releasing buggy code is going to undermine our relationship with the customer.”

Executive #2 – “We need that by X.”

Executive #1 –  “Can you give me an ETA on those defects so I can report them to my boss.”

Product Owner – “Yes, as soon as we trouble-shoot the problem and gather response object from the failed service.”

Executive #1 – “So when?”

Product Owner – “I am not sure.  Let us work the problem.”

Executive #2 – “We could lose millions of dollars if we don’t release by X.”

As you can see, conversations like this resemble something out of a Kurt Vonnegut novel.  The stress levels increase, and no one benefits from the increased attention other than the executive. 

Often you are working with people inside your team and outside to address crises.  It requires plenty of emotional intelligence to do this correctly because many of the people around you begin to panic and are frazzled.  When confronted with situations like this, it is best to be the calmest person in the room.  State the facts and tell people what you are doing to work the problem.  Also, share with leadership the others working with you to fix the problem.

Next, let people know they are creating unnecessary stress.  If a manager is asking for updates each hour for a bug in testing, point out that their concern, while necessary, is not improving the situation.  

Finally, be kind to others and yourself.  Deadline pressure is never fun, but everyone is in the same difficult situation.  Being mean or showing a lack of kindness will create a feedback loop of reprisals on the team.  If the unit is fighting, they are not focusing on the deadline.  Kindness and grace are not easy during a deadline, but they are necessary to get the job done. 

High pressure and uncomfortable situations happen in software development.  As a coach or scrum master, you must show emotional intelligence when others are not.  

Until next time. 

Navigating the Fog of Uncertainty

The natural state of projects is fog.

Recently, I have been focusing on the basics of agile.  Master those simple skills and rituals and it will make you a better coach and scrum master.  Today, I want to focus on something which is your constant companion in business: uncertainty.  The ability to deal with uncertainty, mitigate risk, and address the unknown are essential business skills. 

When project managers discuss uncertainty in a project, they are all the unknown factors that crop up.  There is no right way to understand all the nuances of a project until you begin work and experience them.  Plans are helpful, but they often rely on assumptions that do not exist.  A plan usually takes for granted the people doing the work are all the same and have the same training and experience.  A plan also assumes that conditions will not change throughout the project.  When confronted with the realities and nuances of a project, the plan often shifts or is discarded.  

It is why project people have come up with the term “cone of uncertainty.”  At the beginning of a project, the estimate of time can vary significantly.  If you are fortunate, completing the work may take a fraction of the time allotted.  Often, a project will run over time and budget because the team did not know the hidden factors involved in completing the effort.  As the team continues to work with the project, the uncertainty narrows, known as a cone.  As time goes on, the team has a more realistic understanding of what needs to get done to finish the work.   

It helps understand the cone of uncertainty because it provides a helpful guide for people outside of the project to understand what is going on inside.   Often the situation is more confusing, and I use the term “fog of uncertainty.”  When the problem is more confusing, and people are fumbling around looking for a horizon or clear direction.  Like backpackers lost in the fog, they are stumbling over the ground, walking in circles, and easily distracted by strange sights and sounds.  As a business leader, you will face these situations.  

When in a fog of uncertainty, the team will fight over which direction to take.  Each stumble could escalate into a major crisis.  Finally, deep anxiety will take hold, and it will undermine the effectiveness of everyone.  It is at this point that a project fails because its goals are most concealed. 

Just like hikers in the wilderness, there are some techniques you can use to avoid getting lost.  One of these methods is to rely on a compass to maintain a direction.  In a corporate environment, executives fill this role pointing people in the correct direction and providing landmarks for people to follow.  An executive cannot banish the fog, but they can provide help when necessary.  Next, the team can do rapid inspections and make sure they are not going in circles.  The developers can rely on known facts and then use them to build out where they go.  It is why database models and UML diagrams are helpful because they behave like maps for the team.  Small common-sense tricks and experience can make uncertainty manageable.  

As the team progresses, uncertainty dissipates.  When the path becomes more evident, the team can move faster toward its destination.  The skills they use to navigate through the fog are still helpful and will further create certainty on the project.  I find these techniques work well with a no-estimates approach or with story points. 

So to navigate the fog of uncertainty, use the tools of agile to find your way.  Do rapid inspections of work and adapt to changing conditions.  Use executives or clients to provide direction and guidance.  Finally, clear landmarks like UML or Data maps can help make life easier for the team.  Being stuck in fog is awful, but you will reach your destination by taking a few simple steps and careful navigation.  

Until next time. 

Delivery Counts in Agile

You are successful when you deliver.

One of the most common misconceptions about agile is the belief most of the time and energy of an agile team is spent talking about creating software instead of building it.  Plenty of articles have been written about the subject.  I disagree strongly and this week, I want to talk about it. 

At the scrum gathering of 2014 in New Orleans, one of the Keynote speakers joked about deadlines not being real.  He said flippantly there is always another sprint and work is never finished.  The rest of the room chuckled because each of us had heard this sentiment echoed by a developer or testers.  I have said it myself in jest.  The truth is deadlines matter in agile.  If a team is not delivering software at a steady cadence then it is not a good team.  

The empirical nature of software development with agile demands the delivery of software for customers.  If the team is struggling to deliver a shippable increment at the end of a sprint it is up to the team during a retrospective to figure out how to do better.  Instead of solutions being imposed from above, it is up to the team to come up with answers.  

The team coming up with solutions to problems is called self-organization.  Experienced developers mentor junior developers.  Business people provide meaningful direction about how the software should operate.  In the middle of it, all is the scrum master who helps remove impediments and forcing the team to become better.  It is a process that requires plenty of conversation and experimentation.  The bo-product of these efforts is working software in a production environment.  It is why the agile manifesto says, “Working software of comprehensive documentation.”

Software professionals are not successful unless they are delivering value to stakeholders and customers.  In the consulting world, you are not paid if you do not ship software.  In the enterprise systems world, shipping software affects pay-raises and promotions.  Being flippant about being able to deliver working software is a lousy career move.  

The process of Scrum requires the team to deliver value to customers.  Each iteration the team does show off what the team has delivered and gives them a chance to prepare for the next series of work.  The customer sees each step of the way and they can make corrections if necessary.  

I am touchy about this subject because the accusation that agile does not deliver value has no merit.  An agile team delivers each sprint, and if they cannot they self-organize to find a way in which they can.  We still spend plenty of time talking about software but in the world of agile all of that conversation is focused on the delivery of working software.  

Until next time. 

Avoiding the Dumpster Fire

I have seen this ugliness before.

Technology is evolving and improving.  What is not improving is how we lead technology projects.  I have been in the business for twenty years, and it is clear how we lead technology projects needs significant improvement.  Last week news broke Hertz rental car was suing Accenture for 32 million dollars because it could not deliver improvements to its website.  I am surprised this kind of thing does not happen more often because plenty of large projects burn through obscene amounts of cash.  On the blog this week I want to talk about project failure and how it should provide businesses with a model on how not to do large projects.

Nathan Allen writes an excellent blog on all the things which went wrong during the Hertz affair.  It would be amusing if it did not involve the squandering of millions of dollars.  It contains all the usual culprits in a massive software delivery death march.  Salespeople made promises to executive and then forced technology professional to keep them.  Poor infrastructure at the client exacerbated poor development from the consulting company.  The deadlines were unrealistic, and the client abdicated all responsibility for the success of the project.  Add in a pinch of arrogance from a top tier consulting firm, and you have a perfect example of what scrum masters and project managers alike call a dumpster fire. 

Nothing is more dispiriting than working on a dumpster fire project.  It stinks, and it is fraught with getting your career burned.  Often, developers put their heads down and hope no one blames them for the catastrophe.  The main reason for this state of affairs is large projects are so big that any small setback will grind the project to a halt.  The state of affairs undermines the psychological safety of the people doing the work, and everyone is afraid to step forward and be honest with project leaders.  I suspect this was the primary factor why the project failed.

Deadlines were missed and missed multiple times.  When it was over, 32 million dollars disappeared.  What makes the entire episode more galling is Accenture refused to do more work unless Hertz paid more money to fix a broken project.  Failure crashed into failure setting more money on fire, and the only solution was to throw more money into the flames.

I have worked with several people from Accenture.  They are very good at selling products and getting paid, but they are not good at delivering results.  In the world where they work, it was more important to get paid than it was to provide value.  According to the agile manifesto, this is a refutation of the value of customer collaboration over contract negotiation.  It is clear Accenture is more interested in contracts than helping customers.

I entered the agile reformation because I wanted to build things rather than toil in obscurity.  I have worked on projects where we extracted money and value from the customer rather than deliver it.  Working on a project like this does pay the bills, but it does not move the practice of software development forward or improve the reputation of the development profession. It is up to experienced agile and project management professionals to pour cold water on these dumpster fires.  The business needs to set a standard which is more than watching piles of money burn.  Otherwise, we will have more trash fires like Hertz and Accenture.

Until next time.

Story Points for the Misinformed

It is all about planning poker.

Last week, I wrote a harsh critique of how project estimation is done at many organizations.  I do not like using the words farce and tragedy lightly, but in my experience, many projects devolve into these realms.  This week, I want to talk about story points and how they solve some of the problems I discussed how estimation is broken.

I have written two essential blog posts on story points.  The first was my reappraisal of story points as measurements of difficulty and ambiguity.  The other blog post illustrated how story points could be used to meet deadlines.  Reviewing those blogs, I think they are a clear explanation of the advanced uses of story points.  For those new, to story points, this blog is for you.

Last week I said traditional forms of project management rest on the mistaken notion that time and money equal the same thing.  It means when a project manager or developer gives an estimate and executive treats it like a quotation of work.  The experience is similar to going to an automotive mechanic receiving an estimate for $300 of work and getting a bill for $3,000.  As a consumer, you were expecting and budgeting for a $300 bill.  When confronted with an invoice ten times larger than expected, a person usually falls into a spiral of rage.

Story points defeat this situation.  First, the team members are playing planning poker and are collectively deciding how many points it takes to complete a unit of work.  It is not the opinion of one person be a consensus of numerous technical professionals.  Next, story points are the sum of ambiguity and difficulty of a unit of work.  There is no meaningful way to convert a story point into money or measure of time.  The only things that are certain is a team can complete a specific number of story points in a sprint time box.  The average number of story points completed over at least three sprints is called velocity.  I illustrated in an earlier blog velocity allows executives, scrum masters, and developers a means to forecast deadlines.  Finally, story points allow for severe discussions about scope, resources, and time without having to discuss dollars and cents.

My colleague, Steve Sether, points out story points are not a silver bullet for poorly managed projects.  Story points can be inflated to create the illusion of increasing velocity. Accountants attempt to put a dollar figure to story points and executives often ignore them to make promises without consulting the development teams.

For me, telling an executive, we have 213 story points in a software backlog is much more informative than claiming we can hit an arbitrary deadline.  We can take some action and make more informed decisions rather than rely on gut instincts.  Project estimation should not be farce or tragedy; with story points, a development team and a scrum master have a better way of estimating work and delivering to the business.

Until next time.

Understanding Estimation for the Misinformed

When I speak with business professionals, they often struggle to understand the basics of the agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I am expecting results.  Many times, I feel like am discussing a round planet with people who still think the earth is flat.  These kinds of misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks I will try to explain some of the basic ideas agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  The reason why is many estimates for creative projects is a lie.  The company is lying to itself about what it wants and how much it is willing to pay for it.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying, money is getting spent, and nothing gets into production. 

Project Estimation is farce and tragedy.

The agile manifesto came into being with the twelve principles of agile because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensated, and payroll met a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  For the attentive, you will notice the business executives do not experience the same reality of the front line consumers or employees.  Thus, a software project begins with a pile of money.

The managers and directors once they receive this money then have to figure out how to spend it.  The money comes with plenty of strings.  The project has to meet a deadline which may or may not be grounded in reality.  The plan must work with current technology at the firm.  Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next is something resembling a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams asking how much time it will take them to satisfy the project requirements. The consulting company will bid a price to earn the business.  The internal developers will offer an amount to remain employed.  It goes on until the bidding ends and the project begins.  The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with the limited budget and impossible timeline fail to deliver.  Making matters worse developers are expected to incorporate changes mid-stream and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out for working numerous hours of overtime to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause for this kind of disaster is many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and ability which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week I will show you how that works.

Until next time.

Three types of failure in an organization.

When it all goes wrong

I have been spending plenty of time looking at best practices and patterns in software development.  The more I learn, the more I discover knowledge in the field is growing logarithmically.   Thanks to the web, developers and scrum masters can share hard-won wisdom.  Sharing this knowledge makes everyone better at what they do.  We can also gain understanding taking a look at bad practices and seeing how they hurt an organization. 

A maxim in the agile reformation is everyone should be allowed to fail early and often.  Failure is an early building block for future success and innovation.  I see failure as an excellent teaching instrument.  It means an agile practitioner should take a fair and empathetic view of failure and see what we can discover.  Agile practitioners need to call out what works and what does not.  Reviewing bad practices and business failure educates in ways success cannot.

The Cargo Cult

A cargo cult comes into being when individuals create totems and rituals to mimic success without understanding how to achieve that success.  I have blogged about this topic, and it came from South Pacific tribe who built faux airports and vending machines in the hope cargo planes, and Coca-Cola would return.  I see it with businesses who begin a digital transformation but do not want to change their command and control structure.  The open office movement is another excellent example where business leaders hope to improve collaboration and instead ruin employee morale.  The lesson is to discover the “why” and “how” something works before implementing anything in your organization.

Cultural Inertia

If you work at an organization where people introduce themselves by how many years they work for the organization instead of what they do for the firm you are dealing with cultural inertia.  The term inertia comes from the field of physics. An object can remain still or in motion as long as outside forces do not act on that object.  Complex business organizations exhibit this trait.  These organizations get accustomed to doing things a particular way.  These organizations hire and promote specific people.  Thus, when confronted with change they treat is like heresy or deviance.  Managers or executives kill ground-up initiatives.  Digital transformations fail because line employees have no buy-in.  As a coach or scrum master, inertia is going to be your biggest obstacle.

Software Samurai

Software development is a human activity which resists automation.  So far, no Artificial Intelligence can write C# code or take vague business requirements and turn them into working software.  Human beings are messy, complicated creatures.  Smart and talented people are messier than standard employees. Making matters worse is the glorification of the “Hacker,” or “Brogrammer” culture of software development.  It is a worldview which is misanthropic and sexist.  The glorification of a software developer as a disruptor, visionary, alpha-male, shaman and deity has a few consequences.  It creates a toxic stew of smart people who are smug and contemptuous of business partners.  It also makes developers behave like lonely samurai willing to show off their skills only to other developers in battles for supremacy.  By following “the way of the samurai,” these developers ship poor quality code which does not meet business needs and impossible to maintain.  When called out for this conduct a samurai will say, “If they were good enough a developer they could maintain that code.”  Samurai coders are why agile fails at the team level, and it is up to a coach and scrum master to help these individuals reform their ways.

So here are three ways agile can fail in an organization; cargo cults, cultural inertia, and software samurai.  Each of these situations spells doom for your agile maturity.  Be on the lookout for these examples of failure. 

Until next time.

Agile is about Deadlines

I have nothing on Martin Luther
but I know a little about software development.

Five hundred years ago a German monk named Martin Luther hammered 95 theses to a church door.  He was calling attention to corruption inside the Catholic Church and started the events which created the protestant reformation.  The agile manifesto is only sixteen years old, but it has produced a transformation in the business world.  I consider myself one of the evangelists spreading the word.  With every reformation, there is a counter-reformation, and today I would like to discuss one of the principle objections used by opponents of agile.

There is an excellent blog post written by the Wall Street Journal called “9 Myths About Agile.”  I strongly recommend it.  One of the most durable myths about Agile is the preconception that deadlines do not matter. Work gets completed, and deadlines are not necessary.  I wish to argue that deadlines are an essential part of the agile process and provide an example of how it works.

The most central feature of Agile and Scrum is the time box of the sprint.  For two to four weeks, the development team completes goals.  If they do not finish the stories in that period, then the sprint is considered a failure.  Failure is not a bad thing it is a learning opportunity for the team can to do better next time. Scrum relies on deadlines to focus effort and drive improvement.

Skeptics would then argue that sprints are well and good, but there are not firm due dates to communicate to upper management or the people paying for the work.  My reply is that with a sprint backlog following Roman Pichler’s DEEP model, it is easy to forecast when work will get completed.  The backlog is detailed to show the volume of work.   The backlog is estimated because it allows the product owner and the business to predict when work will get done.  The backlog is emergent so it can adjust to changing conditions as a project moves forward.  Finally, prioritization allows the firm to say what matters and what does not.

I am now going to provide a simple example.  The marketing department needs to incorporate social media into its website.   The works need to be accomplished by November 1st. The product owner gets to work, and come up with a list of features.  It should look like this:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
  • Feature: Google+
  • Feature: Twitter
  • Feature: Pinterest

Now it is up to the Product Owner and development team to write stories.  After a week or two of effort the backlog looks like the following:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account.
    • Create Hooks into Facebook API.
    • UI for Social media on the page.
    • Create log internally when pages are shared.
  • Feature: Google+
    • Set up Google+ corporate account.
    • User Google tools to allow sharing of stories from the website.
    • UI for Social media on the Page.
    • Create log internally when pages and shared.
  • Feature: Twitter
    • Set up a corporate Twitter account.
    • Use Twitter API to post content.
    • UI for Social media.
    • Create log internally when pages are shared.
  • Feature: Pinterest
    • Set up corporate Pinterest account.
    • UI for Social media.
    • [Spike] prototype how to use Pinterest API.
    • Create a log when pages are shared.

The backlog looks typical to a scrum master or anyone on a development team.  The Vice President might understand what the group plans to do. The group estimates with story points because business people treat hours estimates as quotations of work.

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account. - 2
    • Create Hooks into Facebook API. - 3
    • UI for Social media on the page. - 3
    • Create log internally when pages are shared. - 13
  • Feature: Google+
    • Set up Google+ corporate account. - 2
    • User Google tools to allow sharing of stories from the website.- 3
    • UI for Social media on the Page. - 3
    • Create log internally when pages and shared. - 13
  • Feature: Twitter
    • Set up a corporate Twitter account. - 2
    • Use Twitter API to post content. - 3
    • UI for Social media. - 3
    • Create log internally when pages are shared. - 13
  • Feature: Pinterest
    • Set up the corporate Pinterest account. - 3
    • UI for Social media. - 3
    • [Spike] prototype how to use Pinterest API. - 8
    • Create a log when pages are shared. - 13

The estimates from the team point out severe risk and ambiguity.  Also, the team has not worked with Pinterest, so they are going to do some experiments to understand how it works.  The sponsor of the product might get frustrated at this point and ask, “When will it be done? Can I have it by November 1st?”

The scrum master should be able to answer that question.  According to the backlog, there are roughly 91 story points of work.  The team can do 21 story points a sprint and each sprint is three weeks long.  It will take roughly twelve weeks to do the job. It is good news if it is June but bad news if it is September.

So a process of negotiation begins where stories get prioritized, and others ignored.  If the company sells food products, Pinterest may be more critical than Google+.  A media company which relies on breaking news might ignore Pinterest and focus on Twitter.  The product owner might notice that each social media site has its analytics suite and that an internal log is not necessary.  Fifty-two story points fall off the board.  We have 39 story points of work which we can get done in two sprints or six weeks.  If we begin in August, we will hit our due date.  The final board looks like this:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account. - 2
    • Create Hooks into Facebook API. - 3
    • UI for Social media on the page. - 3
  • Feature: Google+
    • Set up Google+ corporate account. - 2
    • User Google tools to allow sharing of stories from the website.- 3
    • UI for Social media on the Page. - 3
  • Feature: Twitter
    • Set up a corporate Twitter account. - 2
    • Use Twitter API to post content. - 3
    • UI for Social media. - 3
  • Feature: Pinterest
    • Set up the corporate Pinterest account. - 3
    • UI for Social media. - 3
    • [Spike] prototype how to use Pinterest API. - 8

So in this brief and simple example, I have shown there is a quantitative and drama free fashion to discuss projects where deliverables get negotiated, and deadlines get met.   Agile and Scrum can help people make educated decisions about what work can get done and when it will get done.  All that is required is a conscientious product owner, a dedicated development team, and a scrum master who will speak the truth to decision makers.

Agile is about deadlines, and I am willing to put my career at risk to prove it; just like that German Monk from five centuries ago.

Until next time.