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.

Product Owner Anti-Patterns

If your product owner behaves like this
way they are doing it wrong: very wrong!

Every scrum master needs to be on the lookout for some anti-patterns in how product owners do their jobs.  In a perfect world, the product owner and the scrum master are like siblings working toward the same goal.  The reality is that mismatched business priorities and lack of cooperation by business partners can happen in any organization.  So this article will help you recognize the smells which you should look out for as a scrum master.  I hope a few of you will be kind enough to provide some suggestions of how to deal with these anti-patterns.  Many of these examples come from Roman Pichler’s excellent book on product ownership.

The Under Powered Product Owner

We have all seen this product owner.  They have the look of an abused animal.  They are not empowered to say “no” and they when they say that they speak for the business you know what they are really saying is they speak for their boss who will overrule them when it is convenient.  The under-powered product owner is a figurehead who is their because the scrum process says so.  The people with the real say will not abdicate their authority to let this product owner do the job.  The authoring of user stories consists of being called into the boss’s office to take dictation from the boss.  Priorities are set by the boss and if something goes wrong it is the fault of the development team rather than the boss.  Everything is a priority so nothing is a priority until something goes wrong which triggers a spasm of unsustainable development. 

The Over Worked Product Owner

According to Certified Scrum Master training, each software project should have a product owner and a scrum master along with a group of developers ranging in size from five to seven people.  Executives look at this as a waste of resources and often assign multiple scrum masters over many development teams and do the same with product owners.  The by-product is the over worked product owner.  Currently, at my firm I work with a Product owner with his work divided among four software development teams.  What this does is that it forces the Product owner to only spend the minimum amount of time necessary to get stories written and to make sure that priorities are getting fit into the sprint. The stories are rewritten by the scrum master or another developer so they are clear enough to be understood by the other developers.  Stand up meetings, retrospectives, and demonstrations are missed because they are not considered critical by the product owner.  The only time they turn up is when something goes wrong or when upper management is paying attention.  Quality suffers, and the notion of sustainable development is nothing more than a sick joke.

The Absent Product Owner

Sometimes projects are kicked off and the executives who demand the work can’t find or won’t hire a product owner.  The software is still expected to get written but no one can be bothered to write the user stories.  Software developers and scrum masters should just be smart enough to find out what creates user value.  This creates situations where what is constructed is often not what the business wants. Fortunately, the failure process is faster so the executive can ask questions like “what is wrong with you people?” and “this is a simple business process why am I paying you so much money to screw this up?” 

The Product Owner by Committee

Some projects have a great deal of visibility and multiple project teams; this creates the product owner by committee.  These are individuals who are all empowered to write stories in the backlog and they are also equally empowered to set priorities.  This pulls the development like taffy and forces the scrum master and the development team to juggle priorities with dexterity of chain saws.  One mistake creates, the loss of a limb and the destruction of a career.  In addition, the horrific aftermath generates meetings which are outside the scrum process and cut into the productivity of the team.  This is why many of us in the agile community are discussing how to scale large projects because multiple development teams and product owners leads to this situation.

The Rogue Product Owner

This is a product owner who has his own personal interests in mind rather than the needs of the business when creating work for the development team.  You know when you work for a rouge product owner when your boss comes to you and asks what your team is working on.  This is because the team is making life easy for the product owner but new customers are not being generated because the features to attract those new customers are not prioritized as highly by the product owner.  This undermines the agile process because the only value being created is for the product owner instead of the business. 

So there you have it; five different anti-patterns for product owners.  Be on the watch for all of them otherwise your life as a scrum master is going to become very painful.

Until next time.

When the Mad Hatter gets Sick and Tired.

This mad hatter needs the party to end.

The work of a scrum master is full of details, stress, and strain.  This week it caught up with me and I wound up in the hospital suffering from food poisoning and inflamed bowls.  Being sick is a humbling experience and it puts things in perspective.  I wanted to share some of that perspective.

Lewis Carroll the fellow who wrote the Alice in Wonderland books, said “Between the idea and the reality lies the shadow.”  As a scrum master in a large bureaucratic organization, I have been living in those shadows for two years.  I have witnessed incompetence tolerated and rewarded for longevity with the organization.  I have also witnessed one of my business users speak to a developer as if they were cocker-spaniel.  I have spoken about sustainable development and had an executive look me cold in the eye and say, “You are agile figure it out.”  I have also said and done a few things I am not very proud of.

The stress of the deadlines imposed by others not related to the teams, the lack of qualified product owners, and the open hostility of some of my business partners to scrum and agile have taken a toll on me and my health.  Sometimes what keeps me going is the hard work of the developers who work with me and that desire to be successful.

It has occurred to me that I have been pushing myself too hard.  A night in the hospital under observation will do that to a person.  So I am going to try and take a step back and try to pace myself a little better.  No late nights and answering e-mail at weird hours.  Saying no more often when asked to do things.  Finally, just acknowledging that I cannot change my organization.  It is going to take more than this Mad Hatter to change an organization like mine.

This sounds like defeat.  It is not; it is me taking care of my own health and well-being.  I blame stress on what happened to me and I need to remove some of that in my life.  Until I leave the shadows, I will just have to accept my current role.

Until next time.

Show some love for the product owner

Show your product owner some respect.

I spend a lot of time talking about agile and what it means to be a scrum master.  This week I wanted to change things up a little bit because I think many of us in the agile community have been neglecting one of the most important people in the agile process- the product owner.

I am a big fan of Roman Pichler’s book on product ownership.  In it, he says that being a product owner is one of the hardest jobs in technology.  You need to understand the nature of the business, be able to act as a liaison to the technical team, and finally understand the nature of building software.  I would like to add a few more.  A product owner should be able to advocate the priorities for the business, they should act as a cheerleader for the team, and most importantly they need to be empowered to say no.

Too often in large organizations, executives treat their departments like feudal kingdoms.  The only way to get promoted or advance is to serve at the pleasure of the lord or lady running the department.  This forces the people working under these feudal rulers to avoid telling the truth about project progress and saying no to situations which are misguided.  It is up to the product owner to act as this informed chancellor to the lord or lady of the department.  This delicate balancing act is not for the meek.

Making matters worse, if that projects in large organizations are funded by the project instead of by the department.  This means the product owner is not a full time position but rather someone appointed by an executive because they have some project management experience.  So in essence you have a product owner who is not empowered, not able to say no, and has no vested interest in the project being successful.

This is where I spend a great deal of my time trying to train product owners as they come and go in the organization.  I teach them how to write user stories.  I teach them how to write given, when, then statements to help the developers with test driven development.  I also try to help them navigate the weird world of technology as they are asked countless questions by the development team for situations they never considered.

I work with three product teams over two continents.  I also have two very different product owners.  I have to be respectful and firm to both of them.  I also feel a great deal of empathy.  They are working one of the hardest jobs in technology.  I also understand that I can be eccentric, mercurial, and a little tightly wound so their job is just a little more difficult.

So the next time you get cranky with your product owner; take a step back and think for a moment.  They are working in one of the hardest jobs in technology.  They are also working with you and your goofy technology team.  Show a little love and respect.

Until next time.

A Little Respect for the Scrum Master

I spend my days working with software developers and helping them get work done better, faster, and with higher quality than they did before.  This week,

Building software is not for the meek!

I wanted to take some time out and talk about why being a scrum master maters.  Technology is one of the hardest things in business to manage and it helps put things into perspective.

One of the key things everyone in technology needs to understand is that the ability to write code is rare skill.  For every thousand people working in accounts receivable, there may be only five able to write software which manages the accounting systems.  Because of relative scarcity of people with these skills, there is always too much work for too few people.  This makes business people testy because they are taught that customer service should be instantaneous and to be forced to wait for IT seems like a waste of time.  Often business people accuse IT departments of being lazy or non-responsive.

 Also many people outside technology think that putting together good working software code is as easy as composing a power point slide or an excel spread sheet; this is a gross misunderstanding.  So they see the eccentric people who develop software as detriment to the business.  Combined with how expensive software developers are to hire, it is no wonder that there is so much push for off-shoring.
 
The funny thing is that off-shore teams and no different than their domestic counter-parts.  A developer in India or Northern Ireland is just as rare as they are in the United States.  They are paid higher rates than their peers and make a very good living because they still very rare compared to the world population.  They are less expensive that American or European developers but they are still an expensive labor force.  They are also just as over-worked as their on-shore colleagues.

Now add to the mix a twelve or thirteen-hour time difference, child care concerns, and the cultural obstacles which obviously crop up between two nations and you have a recipe for disaster.  Fortunately, software developers being smarter than the average person have learned to deal with the obstacles and build software.  It is not pretty at times but the work gets done.

It is up to scrum masters to get development teams working together and efficiently.  We have to bridge the ocean gaps and make our off shore partners feel like they are making a difference.  It is up to us to put together a vision and then direct others to make that vision possible.

I was attempting to explain my job to others and it is hard.  Some people get offended that I work with off-shore teams because they think I am enabling the loss of jobs in the United States.  Others think that what I do is not real work because all I do is participate in conference calls.  The truth is that scrum masters who work with distributed teams are essential parts of the global economy.  We keep the projects going.  We make sure the software is delivered on time.  We keep the promises executives and sales people make to their clients each day.  It isn’t like being a nurse or a fire fighter but it is just as important.  

So if someone says they are a scrum master give them a little respect. They are the people who make sure the global economy does not collapse into a big ball of mud.

Until next time.