The Most Interesting Day

I had a very interesting day. Today, I tried to quit my job. Somehow, I kind of failed at it.I know exactly why I need to quit - and I know that it is what I must do. I am also aware of a few things that are happening around me and how these things affect what is going on. And I thought that maybe, some of you have similar situations and may benefit from my experience.

The Hydra and the Abyss

I recently had occasion to speak to a good friend about the state of agility in general and the needs he was looking at in his organization. This brought me to the question – what is your biggest problem and how are you trying to address it? The answer surprised me a little – because I have dealt with it before. He was looking at the integration of the “last piece” of the IT structure. How do we get the mid tier and back end IT support groups into the Agile umbrella? If I recall my mythology correctly, the hydra is a dragon like monster with many heads – and when you cut one off, two heads grow in its place. I find this an ideal metaphor for transformations, because it seems just when you identified and resolved a core issue – you have two more issues take its place. The challenges I face are always interesting, but they seem to circle around three “heads” – management misalignment of expectations, team misalignment of expectations and product team involvement. I have dealt with all three of these recently, and have realized that any one of these can “kill” a coach immediately.

When I grow up...

Lately, I have been thinking about what kinds of things I LIKE to do. I have been thinking about my personal environment and my personal preferences. After some time, I finally had a revelation on it. Like everything else, it was triggered by a conversation that a few friends kept having with me. It always starts differently, but somehow it seems to always end the same. The question often comes up "how are you able to do X?" The answer seems to be "It depends on the team"!!

Row, row, row your boat?

Sometimes, we try to change something about ourselves that we believe will be simple and straightforward. A great example of this is the weight issue. Most everyone can relate to trying to lose or gain weight – and more importantly, keep it off or on! But this is a good example because it is actually simple to start, sometimes simple to achieve – but extremely difficult to maintain. I do not have the answer to the weight issue, but I have noticed that many companies try to change by looking at an exterior methodology – and think this will answer all their issues. But many times, these new ways of doing things only surface the deeper issues – the ones that do not require a simple change. Worse yet, sometimes the organization does not know why it is making the choice it will pursue; it is blind to the deeper issues. This natural blindness can get people and organizations into some interesting trouble.

R & R?

Interestingly, R&R does not always mean Rest and Relaxation! In some cases, it can mean roles and responsibilities. And recently, I had a chance to visit this concept in the most interesting way. You see, when you are trying to change a system, you have to take into account the “built in” biases that the current system has in place. Sometimes, even with the best intentions, we forget that there ARE boundaries that can lead our analysis. I was reminded about a very sad meeting I once attended…

A long time ago, in a client far far away, I was brought in as the Scrum Master for a consulting team. The client needed a solution delivered with solid practices, high quality, short timeline and “no budget restrictions”. So, they brought “us” in. And, initially, they agreed to provide a PM to support us with their process so we could “do” our Scrum –maybe teach them a thing or two along the way.

Sadly, as is often the case, things started to immediately change. Our project was high priority, but cost started to become an issue. The USERS were in love with the team, particularly the UX part of the team, but IT started to have a problem with our “execution”. This was because we were asking hard questions, some that had not been asked for months. This, along with our delivery to commitment started to make people uncomfortable. In addition to this, throw in layoffs and a massive change in direction in IT, and well – you have all the ingredients for a recipe that does not end well.

In the midst of this chaos, our team continued on, and we were able to deliver a healthy first demo. By this time, the project had just been pared down by IT – to the chagrin of the business users. It made us all awkward, and was rapidly followed by the request that we provide our own PM support for the project. It just so happened that I had a few years experience as a PM, and was able to jump on and start providing what they needed. Within this framework, and because the liked what I was doing (getting a PM as a bonus) they decided to invite me to their PMO sessions. As a special guest and Agile adviser.

This was a solid milestone for me, because I already knew that PM work is not well appreciated in most organizations. In addition, I knew some of the structural issues they had to deal with – including the budget. I also knew that every PM had more than one project under their responsibility. This was a special meeting, the CIO was to show up and “rally the troops”. What he did was awesome – in every measure of the word.

The new CIO introduced himself to the team, and mentioned how important project management was to the organization. He asked for feedback, which the entire group was hesitant to provide. Finally, one of their best PM’s spoke up – and asked for help with all the challenges they were having. His response was measured and calculated. In a nutshell, he listened attentively and told them something like this: “In my neighborhood, I have a person that picks up the trash twice a week. I live in a nice neighborhood, and things are expected to be clean and tidy. We pay our dues and have a reasonable expectation that we do not notice our trash service. If I have to talk to the garbage man, you can bet something has gone terribly wrong. Project Management is like this to an organization. When I do not have to speak to you, I know things are going well. And as you can see, I am having to speak to you today” The silence was stunning. Grown men were twitching, women were squirming – they all got the message loud and clear. He then insisted that the goal of the PMO was to reduce all projects by cost and timeline with a positive change of 10%. And he asked what they thought.

The PM who spoke up was crying – in rage. She basically asked if he had any ideas of the load that they and the teams were carrying, and if he could suggest ways that his goal could be accomplished. At this, I checked out.

To me, this was brutally horrible. I do not think I could muster the guts or idiocy to address a team the way this man did. But it was done. And I was reminded recently of this horrible exchange with something much less insidious. At a recent meeting, another leader wanted to show how this new organization was supporting the PM community. The presentation was positive, pleasant really. When the value of the PM role was brought up the feeling ceased to be innocuous. In their assessment PM’s, in a best case analysis are considered “overhead” because in terms of delivery, they are not in the “front line” of the actual development team. The leader who brought this up did so almost apologetically, but still – the weight of the message certainly felt the same.

I have been a good PM. And I have been a good SM. I think I may have posted about the developer who asked me “why he should buy into this agile thing”. The answer to him that mattered was that in Scrum, he had a voice – a place – within the project and the delivery. For him, that was enough, because in his entire career he had always felt like a cog in the wheel. We all want to matter; we all desire to be a part of the solution. And I often get the question (especially by my PM and ex Dev Scrum Masters) about the differences between being a PM and being an SM. This is an interesting question, and I answer to the best of my ability and experience. But the answer is not really that relevant – because the question belies the real issue. We all want to MATTER, we all want to FIT. And many of our organizational structures work against this. Sometimes without leaders even being aware of it.

For me, becoming a SM was very natural, I care about teams and innovation and all sorts of other cool things that Scrum allows me to be myself with. I feel valued and free when I am scrumming. Within the topic, I feel that being a SM puts a person in the revenue generation space, because in the best of cases, any team should be free to innovate new solutions. This can lead to new products, and new sales. As a PM, I have to work within a rigid system – one that puts me as an overhead resource – a cost to the overall effort. At best, as a PM I can bring “cost reduction” to an organization. Leadership sees me this way too, and I am all too aware of it. Like everyone, I want to matter, I want to count. And it is just much simpler as a SM in a waterfall world.

Love what you Do?

I love fishing. And when I say this, different people understand it differently. Most assume I like to drink beer by a pier while reading a book. Some may think I like to go to the lake and spend some time in a boat. Others imagine I catch a lot of fish and cook them. But my friends that do go fishing usually ask a few more questions. Like, are you a cat or a bass man? Do you fly or bait cast? Have you tried noodling? These guys know that there is more to fishing than just what people imagine there is. And these guys know there is a huge difference between fishing and catching! More on that later…

The Bucket - or the Tin Cup?

Last post, I was speaking to an old friend about the amount of work technical teams take on, and the negative impact to the overall effort. Our thoughts immediately went to leadership, but the reality is that most problems are complex and may need a separate approach. Just having experienced a painful team experience lesson, my thoughts went straight to how we see problems, and how as humans we try to solve them.

The Bucket

Recently, I was speaking to an old friend about a very common problem. The problem was the amount of work technical teams take on, and the negative impact to the overall effort. Our thoughts immediately went to leadership, but the reality is that most problems are complex and may need a separate approach. Just having experienced a painful team experience lesson, my thoughts went straight to how we see problems, and how as humans we try to solve them.

And now for something COMPLETELY different!

A long time ago, I used to write poems.

Not usually great, but some had merit.

Below, a sample of some recent inspiration - 

There was once a Manager from Nantucket

He put his To Do’s in a Bucket

Directors came down

And left with a frown

And the manager started to drown

More to come soon!!

Camaron que se dureme…

Shrimp are DELICIOUS! And in the old Spanish saying, a shrimp that falls asleep is taken/swept away by the current. In my imagination, right into my plate! This is a saying that focuses on the importance of direction. And as a coach, I can tell you that to have a direction you need to have a vision. Because if you lack vision, and have work to do – you will float right down the stream of maintenance – and into oblivion. It is hard enough to move when you have no vision, but what if your leaders have no vision. Then you are really in a pickle!

Recognizing your Weaknesses

Today I got an interesting compliment. A good friend of mine told me “if I could give any team you are working with some advice it would be – just close your eyes, and do everything Harry tells you to do no matter how crazy it seems. Because there is a plan to the madness”. This friend of mine went through a coaching engagement with me, and he discovered and is following a role in Leadership. Indeed, high praise from someone who had to see lots of change within a very tight timeline. But looking at myself, with a new team, in a new organization, with an environment that is NOT interested in my best value proposition – I find that there are things I can improve. After the whining and the pity party, I started to look at myself. And I discovered that I was being lazy, disorganized and complacent. There were great excuses for this – but that is exactly what they were. And I realized I had to make a decision. The very thing I try to get organizations and teams to discover about themselves. So it got me to thinking about the team and the environment…

Happy Mother's Day!!

One thing I tend to do every mother's day is send out a text to all the contacts in my phone that I know are moms. This inevitably leads to a few awkward moments, but by and large it is really well received. A lot of people I work with in Development happen to be moms. All of them fulfill different roles, but they work hard, juggle life at home, life at work, team issues and the usual nuances - and they look at things differently. Because being a mom absolutely changes the way you see things, whether you like it or not.

The Grind...

So - one of the dangers about a "quick blog post" is that you really get no time to fully think through and review what you are writing. But sometimes, this can be a good thing. Because you go with your gut, and jot down what is important to you at the time. Hopefully, in retrospect it helps someone. I just happen to have one of these moments now.

Recently, I started helping a new client. One of the things I noted is that though most of the culture is open and vibrant, the culture within IT is actually quite the opposite. Which led me to start asking questions, and start offering ideas on ways to change this to match the rest of the company. I was very surprised to be met with skepticism and slight resistance, even in light of the fact that the team I am helping seems to get along well together. The results of my gentle prying in terms of "why is it this way" resulted in two points that seemed to travel with the question. The first was "what do you think? Are we doing things right?" - which really is a masked version of "what are we doing wrong?". The second, and more surprising was "why do YOU think YOU will be able to change things, when so many before you tried and failed?". This second one was interesting!!

The first question is actually relatively common. Almost every client goes so far as to tell me that they are SO messed up, there is no way to fix them. The truth is, most organizations suffer from some fairly common issues. And really, the "solutions" are usually relatively benign, but difficult to implement. On the rare occasion, I will get an outlier - wither a client that has little to no issue, or one that REALLY is messed up. Even here, most of the time the teams who want to work together usually get out of their funk and start performing to their expectations or more. This leads us to the more sinister and troubling second question...

This second question reminds me of David and Goliath. And those of us who have had to fight this fight understand exactly what I am talking about. It is daunting to go to an organization, and know that you or a small group of you will be the select group telling everyone - this needs to change. I have had to do this with a few or alone in relatively large organizations, some with extremely defined cultures (the oldest in existence for about 90 years!). And I have seen the heads roll - for the simple task of asking "why". In some cases, it has been MY head!!

So, when my team member kept asking "why will you be different" I would answer, but have this nagging feeling in the back of my neck. Not until I STOPPED and LISTENED, after I saw what was going on and how people were confined by process, expectation and environment did I comprehend what he was asking. Indeed, why would I, a single person in the cog, make a difference in this medium sized client, with an established reputation of fluidity and chaos? Why would I, the new guy, be able to change hearts and minds where there were few people listening, and with little to no protection? Indeed, after a few days the comments were interesting. "There once was a time where questions like that would get you hired on the spot" and "You show a lot of courage - too bad we don't value that anymore". I am in a culture that is self sustaining, and flexible enough to bend to the good intents - but resilient enough to go back once the pressure is removed.

Now that I understand the question a little better, I have a choice. Do I stop trying, and go with the flow making minor changes here and there where I can get easy wins? Or do I "charge that hill" with blazing courage and innovation shooting out of both barrels? The answer is - I don't yet know... I am not sure if I can change the whole thing or not. The one thing I am sure of is - I will help this team, and this client as much as I am allowed to - in hopes of nudging this ship in the right direction. If the occasion calls for outlandish courage, I can do that. But a friend told me - "Not every opportunity is a shoot out at noon". Maybe I need to be more subtle in my approach. Because at the end of the day, it is my job to try to help the culture change - hopefully to help out the teams that make up the organization.

The Desk

I had an interesting experience today with the help desk at the company I currently am trying to help. It was so interesting; it inspired me to write a small blog post on it!

One of the things I like about Agile is the core concept of asking WHY. Asking the "why" about everything is a critical first step on many Agile journeys, and it is a step that when skipped, will lead to interesting results. In addition to asking why, one of the things we want to try to be able to do is be helpful. I know I wrote about the negative side of this, but my experience deals with the exact opposite. In fact, if I could summarize the experience I would do so as being a victim of the Ticket mentality.

To infinity and beyond - Guest Blogger +Todd Azbill

Today we have a guest Blogger, and this is his first try at this. I'd like to present +Todd Azbill and some thoughts on his current role change...

I am currently a Scrum Master for two teams on a short-term project.  I am also new to Scrum Mastery.  During my transition, my manager pulled me in to a meeting where he asked me if I was planning to continue coding…

…I’ve actually given this a lot of thought.  On one hand, I don’t want to lose my technical skills.  They've gotten me where I am.  You could almost say I’m defined by them, right? At the same time, I don’t want to be the best Scrum Master I can be.  Doesn't that mean the teams deserve my full attention?

The trouble with Tribbles…

One thing I have noticed working with developers over the years is that they are very helpful people. So helpful, in fact, that sometimes they help themselves right into a corner. And in a modern organization, they have infinite possibilities to get in just such a bind and find themselves with no one to help them out of it!! This is only one of many ways people have found to work with Agile to be able to change the scope of the story/project/program they are working on. In this case, it is the face of friendship that can cause issues – in other cases; it is not quite as benign.

No, your ScrumMaster will not just “whip up a backlog” for you

As Agile practices have been communicated to all segments of industry, you see well meaning but completely clueless recruiters and HR groups post the most interesting requests. “SM/BA desperately needed”, “SM required, must have 10 years Development experience”, “Looking for Agile PM, SM certification a must”. It is almost as if the organizations want to tell you how mature they are, and how much they understand the Agile “fad! But really, it is almost an aspect of human nature – we all want to get more for less, we all are looking for a deal. This is just an attempt to get two roles for one person. And while you can combine some roles, others just don’t work out so well. Today, let’s talk about one of these toxic mixes – the SM and PO, speaking to the SM/BA combination.

Inspection and Adaptation

The least understood and most ill used ceremony in the Scrum toolset has got to be the Retrospective. More teams request to be excused from this exercise than any other, and most coaches, and some practitioners are always happy to oblige. It turns out that the humble Retro is absolutely the most powerful tool in the Scrum toolset, and more than any other tool can take you from one level of performance to the next – if you let it.

Being American

There is an interesting thing about America - it tends to creep to all areas of our lives. It is a funny thing, and everything we do tends to reinforce it. From sports, to work to politics, to religion - we now need it to "be" American. It was not always the case, but as we progress more and more, it creeps into our culture in unavoidable ways - and leads to an interesting condition and dysfunction. In our current culture, we see things in pairs - always two, and ONLY two sides to everything. There has to be a winner, and a loser. There has to be a "good" and a "bad". It is summed up in the immortal words of Ricky Bobby "If you ain't first, you're last". And it is now true in almost every activity we try to do.

Unexpected Help

Sometimes, you get help from the least likely places. And in the least likely ways. It seems that when projects get to a point of closure, all of the issues that a team has refused to look at come crashing in – almost always at the same time. But every once in a while, something unexpected happens and the troubles are averted. You see, every once in a while, against all odds – people listen, and more importantly, do something about it.

It reminds me of a fishing story I have been meaning to share. Not ALL blogs have to be about boring stuff!! No, some can and should go right into the mystical realm – to illustrate a point. You see, one of the things I I enjoy doing best is fishing – the solitude and the immersion into nature is extremely healing and refreshing to me, and I never seem to have enough time to do this on a regular basis. But on this occasion, I did. I had moved to a new city not long ago, and had adjusted and began to research fishing spots to replace the near idyllic one I had left behind. To boot, I had found some friends, and fishing had changed – ever so slightly. We had gone to a nearby lake, and had a few adventures and some laughs – a really nice time to aid with the transition. But on this cold spring morning, I found myself alone, in the new spot, with an overcast sky and a deep sense of loneliness.

Oh The Humanity....

The Agile manifesto is a very simple statement, and a small one at that. In many ways, it is almost haiku-like in its simplicity and  profound insights. The interpretation of this manifesto has led to people learning to make software in more efficient ways, and to saturate the entire industry with a new way of thinking. But for a long while now, I have been a little bothered that each of these ways of doing software (Kanban, Scrum, Lean) and the people coaching/guiding others tend to stray from the original manifesto – to the detriment of the teams they are trying to help. I wondered how this was possible, and recently I think I see a pattern emerging. But the big take away from me is that in order for a coach to be effective, one must focus and study the manifesto and it’s principles to help teams “uncover better ways of developing software by doing and helping others do it”

How do we know what to do?

One of the most contentious items for an Agile team can be the requirements. Yes, I said it - REQUIREMENTS. Because how you set up your communication with the Business partner matters a lot. It really can set you up to succeed or fail, especially if you have an immature organization, or an ambiguous process to work with.

Requirements can take on many forms, and each form has its strengths and weakness. The most common requirement form in most agile organizations is the User Story. And if you research it a bit, you can see why "requirements" and "user story" do have some significant and important differences. The one thing they have in common is that it is a vehicle that allows a development team to work towards delivering something of value to the business. Less common forms include use cases, Technical Specs, Functional and Non-Functional Requirements or just plain wish lists. Each form has it's particular nuances, and I wish to write about this because if you work with an organization that is familiar with the less common forms, I find that the  easiest way to "become agile" is to use the old process and re-name the new items "User Stories". This can lead to failure even before you get started.

When Success bites you...

Many posts so far have dealt with the challenges of growing and dealing with issues within a team or a project. But what happens when you actually start to get positive results? This can be a surprising challenge for many organizations, and some inadvertently end up snuffing out a success just because of the surprise factor. I'd like to help you today by speaking about what do we do when we succeed.

There are many factors with Agile implementations, they include the coach, the teams, the environment and culture of the organization. All of these factors have to line up in order to start getting some progress. There are some logical steps with the initiation of this effort that go along with the “growing pains” of culture change – but in all instances, one of the things that must happen is that people who have been selected to work together have to at some time choose to become a team and work together or decide that they are not the group to do so. When this finally happens, the simple, logical steps to Agile start to “click” – and then things can go really fast in either direction.

Care and Feeding of a Team

Lately, I have been working with a group of people that are involved in a high stress low feedback project. This got me to thinking - how can Agile help you treat your people well, so that the organization fully benefits from healthy happy team members? Is this even a goal in the organization?