A PO's Perspective

I recently read a blog post about s*** tornados.  Yes, you heard that right.  I imagine you can glean what this means, but if not, you can read more about what they are here.  I am not writing this to tell you what they are, but to share what I believe is a prime example of a s*** tornado.  

We have a situation that I will do my best to give you a visual of.  Picture one code base that lies underneath a vast array of products and modules.  Imagine two teams working independently of each other on that same code base.  Now picture each of these teams contributing their new code to be wrapped together as a deliverable to customers.  (Just got a little windy in here, huh?)

Next I want to put yourself in the position of trying to coordinate this.  It all starts out great.  There is a plan, a set of features and tasks that everyone has agreed on.  We will all work on X number of things, and try to finish up about the same time.  

We have team A that has decided to add a new feature that is relatively low in risk and will take about a week to code.  Team B is finishing up two small bug fixes and they realize that team A will be working for a few more days.  What is a team to do?  

I’m sure you have encountered developers who are not quite comfortable with slack time.  Any solid employee feels that need to be productive, to stay busy, to produce something tangible.  Slack time is not always an easy pill to swallow.  So team B decides to pick up a new task.  It looks simple, it should only take a day to code, not a problem.  

That simple thing just turned into a week long project that held more risk than imagined.  And so the cyclone begins.  We have just entered the spinning of one team trying to stay busy while waiting for the other team to finish up.  Team A finishes, and team B is now knee deep.  

Who sits idle while waiting?  When it comes down to it someone will have to enter the dreaded slack time.  We need to recognize the value of the eye of the storm.  That calm, quiet time when you can catch up on some reading of a new technology emerging, or research an upcoming project.  When you can sit back, breath, and read through some of those long, lost emails.  

Instead we end up with more and more work being pushed into a release.  The risk increases every time code is checked in.  The sheer size of what we now have to work with has become.... you guessed it, a s*** tornado.  

I am learning to listen to myself. I know that sounds odd, but how many of you really listen to yourself? Do you truly listen when you are hungry? Or eat what you want, when you want to? Do you listen to when you are tired, or push yourself to the limits of exhaustion? 

Do you practice what you preach? Or do you go on and on offering advice to others, only to do the exact opposite yourself?

How about your music? As I am really listening to me I am discovering that some of the tunes I listen to are really making me more anxious than I started out. Do you listen to your favorite artist, and walk away feeling relaxed, or hyper? 

I started to meditate to (yes, you guessed it) deal with work related stress, and am learning a wealth of things in the process. Learning to listen to what your body and mind are trying to tell you is an eye opening experience.

Measure your reaction to what you hear, see, experience.  Learning to just let thoughts come and go, and not react to them is quite the challenge.  But it is well worth the time.  I am learning to take that anxiety that builds in my chest, causing me to be short of breath, that dry mouth, that headache from the tension, and turn it into a life lesson.  Turn it into just things coming and going. I am getting some headspace (that's the program I use) and I recommend it to anyone who is interested. 

We often hear the edict that we should read, read, and read some more. I wanted to share a little bit of what I am learning from a book I recently read.

This book was suggested by a co-worker. When it was first brought up as a great book to read, I couldn't quite figure out why "Zen Mind, Beginner's Mind" was related to work, at all. 

Now that I have finished it, I understand the why. I have learned more about interacting with other people than I could have possibly anticipated. This is a book about meditation, yet every time I sat down to read a little more, I ended up writing quotes on my white board.

So much of this reading was centered on things I already know; but am thrilled with some of the subtle reminders. So, I wanted to share a few of the quotes that have meaning for me, and perhaps you all will find some meaning too.

"The result is not the point; it is the effort to improve ourselves that is valuable"

"Building character is like making bread, mix it up little by little, step by step"

"In constancy there is no particular effort involved, there is only the unchanging ability to accept things as they are"

"When you listen to someone you should give up all of your preconceived ideas and your subjective opinions"

"True communication depends upon our being straightforward with one another"

From this awesome (yet difficult) reading I am relearning how to interact with others and was reminded to show them the respect they deserve.  I think in the long run, becoming a good leader evolves by becoming a better person. 

"In the beginner's mind there are many possibilities, in the experts there are few"

Standups are all about communicating. We have our daily standup at 10:00 am. I was recently asked about these; why we do them, why every day, what do we get out of it. My answer was simple: Everything. 

I hear others grumble about their jobs and how no one communicates. A standup is all about sharing what you did, what you plan to do, if you had any problems. It is about listening to what others in your group (organization, company, etc) are doing. It is an opportunity to offer insights, solve problems, ask for help. 

Standups make everyone accountable. You simply can't not do anything or you are exposed as the bottleneck. If you are the bottleneck, they the rest of your team swarm to help you. 

Standups are a great way to tie into visualizing your workflow. Whether you use kanban, an application, a whiteboard, stickies, or whatever works for you, when everything begins to stack up on you, it is obvious and it's time to say "hey, I need help". 

Our standups consist of one full team, and two smaller teams consisting of one person on each. When asked if there was value in having these two others participate I could not help but insist they remain with us. While many times you just wonder why each day they are there to say, "everything is fine, no impediments"; there are those days when there IS a problem and we are all there to help. 

I read an article recently which talked about the impact listening to negativity has on you. I firmly believe in order to succeed you must surround yourself with people who have a positive influence on you. 

If you wake up in the morning and are immediately slammed with negativity, you are bound to enter your day negative. However if you start out with an optimistic outlook your day will go in a different direction.

You know how you remember the 'little things'. Something that happened and when it comes into your mind later you are amazed it left enough on an impression that you bothered to remember it?

I want to share one of mine with you. I was grocery shopping, one of my least favorite things to do. So I was not necessarily in a great mood to begin with. I passed this one lady down every asile. She looked so sad and lonely. She was perhaps in her 80's and just seemed angry with the world. Who knows why, maybe her kids never visited, maybe she didn't have anyone left. 

As I was nearing the last asile, I decided to smile at her. We passed and I beamed. And she beamed back! I mean her whole aura changed; she looked so different. It was like no one had smiled at her in ages. In the last asile, she thanked me. That was it, just in passing, a shy smile with a "thank you". I will never forget her.

The article I read suggests if you listen to enough negative noise, you will behave negatively. So wouldn't the contrast be true, if you listen to positive people, you will indeed behave positively? Or better yet, if you act positive you may actually influence others to do the same.

Imagine taking that person at work who is so negative you never want to get stuck at the coffee pot with them. Now, turn the table and when they begin to go on and on about how terrible their situation is, ask them "what are you doing to change it?" Don't feed into their negativity but try to bring them away from the dark side. 

Speak well. Listen. Stop talking. I tell myself this on a daily basis. I find it so frustrating to talk to someone, only to later realize they really didn't listen to a thing I said, or worse, only half listened and made all the wrong assumptions. 

Then to think I could be doing this to someone else is, well, horrifying. I worry that I could be imposing this frustration on others. I know how angry it makes me feel, how unimportant.

There are some little things you can do to stay engaged. Ask questions. You have to pay enough attention to ask the right ones; otherwise you look foolish! And remember, if you are talking the whole time, you simply can't be listening. People want to be heard, just like you do.

We hear a lot at TLC about the art of “failing well.”  This post is about a milestone we had and how we have turned it into a huge learning experience.   We release new features, functionality and bug fixes in what has historically been referred to as a patch, but we now call it a Release.  Over the years this process has been a growing, living, forever changing approach.   We plan each of these releases with as much foresight as we can, but without a doubt, this never happens as we plan.  We must address issues from every angle which can cause our well laid plans to fall by the wayside.   Over time I have learned to try to minimize the contents of each release, but I don’t believe this lesson has truly been achieved until recently.  Where I would plan out a specific number of new features and bug fixes, and hope we could get them all in, I was not taking into consideration the ‘other’ things that come up.  And when those other things happen, which undoubtedly they do, I would simply add to the burden of the team to get those done too!   Not only was I introducing risk, but I was also adding unnecessary complexity.  As well as additional stress to the team.  Now, as each release would grow, so would the length of time between releases.  This was causing each release to be huge, unwieldy, and unpredictable.   Add to this complexity that there are actually two teams contributing code to each release.  While we are generally aware of what the other team is doing, we are not specifically aware of the impact one may have on the other.  All of this added up to a release that we would much rather forget!   While we quickly realized how embarrassing this Release had become, internally as well as externally, we had to step up and fix the(all seven times!)  It was time for a re-evaluation of our process.  

The first thing we have done is commit to keeping the patch size small.  Our team retrospective exposed how scary it was becoming when we ‘touched’ a ton of different code.  By simply minimizing the number of modules we include in a release, we minimize the overall risk.  This also allow us to get our releases out a bit more quickly.  No sense in having that “inventory” sitting on the self. The next thing I have done is label every task that flows across our board.  By tracking things like planned versus unplanned tasks, things that are included in the release, versus things which are not part of the release, and the emergent issues that come from support, we are able to pick up a pattern in our metrics.  

My first blog post was about getting the team to buy into new ideas; helping to formulate how to approach new features and bug fixes.  Now I would like to explore how we can get ourselves AND the team in the habit of asking some basic questions with everything that 'pops' up.  

Many issues that cross our board are well thought out, planned tasks.  We already know the implications, ramifications, and risk involved.  I need to talk about the unplanned ones.  The surprises, the bugs, the fires which need to be put out.  Multiple teams working on different modules, all pulling from the same database.  The initial risk already exists.  

The cross team communication is another thing.  It often falls to the product owners to try to figure out if what team A needs is going to break something team B will need to fix.  Pushing out code to customers that use BOTH products means we MUST ask these important questions....constantly.

How big is this?

What will this impact or affect?

Do we need to involve the other development team?

What are the implications of doing this?

What is the risk?

What will we break?

On a scale of 1 - 10, how painful will this be for all teams?

How long will this take?  (I don't mean an actual estimate but more along the lines of T shirt sizes: Teeny-Tiny, Small, Medium, Large, Humongous!)

We recently encountered a very rough release.  Two teams were contributing code to one bundled patch.  After re-wrapping for the 7th time (yes, 7!) I was hearing a lot of sarcasm, negativity, and general discouragement.  

So, how do we keep things on the light side?  How do we encourage everyone to stay positive?  Here are a few ideas:

Bring food (cookies preferred)!  Better yet, bake them yourself.  Special treats are an amazing way to get everyone smiling.  It shows you care and you don't regret the flow of events.

Stay positive!  Show by example that this is not the end of the world. 

Move forward.  If you keep bringing up the failures you are creating an environment in which you can not overcome them.  You must demonstrate it is ok to keep on keeping on.

Learn from the mistakes.  If you don't actually take away anything from your mistakes, it is wasted.  Have your retrospective and use what you learned.

Follow through.  During your retrospective you talked about what went wrong and what could be done to prevent these things from happening again.  It only helps if you follow through on the ideas that bubbled up.

Don't place blame!  This one is so important.  In a "Team" everyone creates one entity.  It is no one persons fault, there is no one head that will roll.  Present a united front and no one can point that proverbial finger!  

We are down to 7 pitches / teams.  Creating hypothesis and assumptions today.  Validation comes tomorrow.  Everyone is grouping in teams, working together.  I can't wait to see how many of the original ideas stick, what changes will be revealed tomorrow.  

We are doing a Lean Startup Machine project.  What a fun, exciting experience.  I can not begin to express what a phenomenal practice this is.  We spent this week having a sticky war.  We created stories.  We created people for them, environments, themes, actions.  From these we created components.  From THESE, we each wrote a pitch.  There are about 30 of us participating in this project.  We have about 50 pitches.