Harsh start-ups and smooth landings

I recently participated in an end of release cycle product demonstration. It was a wonderful experience and I was proud of the team’s achievement. It’s a great feature that will make a significant impact to our customers and to our business.

During the product demonstration, I couldn’t help but reflect back on the first several sprint demonstrations. Those were much different. Whole screens were thrown to the scrap pile, basic flows were challenged, and even seemingly simple functionality caused excitement among the stakeholders.

As the sprints went along, the conversations deepened, the team solidified, and the product began to mature. With each sprint, the discussions evolved away from major issues and towards minor suggestions and tweaks. During the last product demonstration, the feedback was positive and only a few cosmetic changes were suggested.

The technical lead remarked that we were doing pretty well if that was all the feedback we received. I had to agree. On my way out of the room, I remarked that we had experienced a “harsh start-up and a smooth landing.” Walking back to my office, I started thinking more about the factors that led to this point in the project.

Here are a few ideas for you to consider:

• Trust
  If a feature isn’t working, is confusing, or just plain wrong, anyone on the team or in the stakeholder community has an obligation to say so. This may appear to be an obvious truth, but it doesn’t always happen.
  
  Someone assumes another will catch it. Someone feels that no one will listen. The list of reasons for remaining silent goes on and on. As a leader, you can create an environment where people will stand up and use their voice. Make it clear that all feedback provided (respectfully) is welcome. People provide feedback if they trust that they will be heard, and that they will not be judged.
  
  In short, this trust is what leads to honesty. You have a vital part in making this happen.
  
  
• My product, your idea
  Our sprint teams welcome input from all sources: customers, internal stakeholders, and each team member. I’ve seen QA folks make design recommendations, customers provide workflow suggestions, and internal groups offer changes to improve service and supportability. The teams absorb the input willingly. They do so because they know it ultimately leads to a better result.
  
  They aren’t interested in whose idea anything is. They are interested in producing a quality product that delights our customers and helps the business. This ego-less attitude has to come from you – their leader.
  
  Praise the team each time they incorporate a suggestion from outside the team. Help them understand their contribution to a culture that promotes others to contribute. Encourage them and reward them when they respond to input from others. Their job is to produce a great product – not pretend to know everything. That often means listening to others.
  
  
• Act on feedback
  Do you want to encourage feedback? Then act on it when you receive it. At our demonstrations, I often hear the team place suggestions (and criticisms) they receive into their sprint backlogs. They then prioritize the feedback accordingly. The person who provided the input knows immediately that they are heard, and that the team and the business are going to treat their input with respect.
  
  Make sure everyone knows that not everything raised will get into the release, or even into the backlog. On the other hand, not everything is ignored. It is critical that each person understand the rationale for why a suggestion does or does not make it.
  
  Equally important is assuring the team that all feedback is regarded equally, regardless of the source. I have been told on more than one occasion that my input will go into the backlog – not immediately addressed just because I’m the VP. And that’s OK. I should have to justify a request just as much as any other stakeholder.
  

In the end, build a culture that honors feedback, regardless of where it originates, and does something with it. You will also likely see the degree of ownership among your stakeholders skyrocket. They will be transformed from talking about “the” product to talking about “our” product.

I'm in love!

Yes, that's right. I'm in love. Oh, I've known it for some time, but I don't think I was ready to admit it. So, here I am, ready to say it to the world.

I love my customers.

OK, you may be thinking that I've lost my mind. Or, you may be wondering what the big deal is. After all, aren't we supposed to love our customers? Of course we are. But do we?

All right, let me explain.

You see, I'm privileged to work in a truly meaningful industry. As a software vendor to Home Health and Hospice providers, I have a chance to impact clinicians who are doing deeply important work. The patients my customers serve are among the sickest and most vulnerable among us. They are often faced with end of life illnesses or chronic diseases.

The choices my team and I make impact whether a clinician stumbles through a maze of screens and widgets, or seamlessly uses technology to care for a patient. My customers are real to me and to my team. When we start a project, we think of the customers that will benefit. I don't mean personas. I mean real people with real names. As we solicit input, we talk to them, share our thoughts with them, and listen to their feedback. We treat them as first-class team members - people who know what they need to get done and why.

Again, I know this isn't exactly earth-shattering. But the affection my team and I have for our customers matters. It's what drives us to spend the time and energy to get a feature from "useful" to "delightful." Affection wasn't obtained overnight. It has been cultivated through reaching out to and building relationships with our customers.

This effort pays off. I often stop by the desk of someone working late and ask them what is going on. And more often then not, the response is something like "I spoke to Sally of such and such Hospice, and she had this great feedback I wanted to mock up for the developers to get into the next sprint." You see, a User Story can wait until the next day. Helping Sally happens now.

I hope my customers know how much I care for them, and respect what they do. When things go bump in the night, sure they get frustrated and sometimes even angry. But so far, after all these years and the occasional setback, they have always trusted that I care about them and their patients. At the end of a sometimes long call, they tell me that they know my team will do whatever is necessary to allow them to do what matters: care for patients.

And when they are delighted by the software or service provided, they are equally eager to share. I guess what it comes down to is that after we look at markets and segments, personas and users, eventually you have to realize that on the other side of every decision you make is a real person.

Burden? Or Purpose?

I was driving the other day, feeling the weight of the world on my shoulders. Typical "woe is me" stuff. You know, feeling as though everything depended on me, and wondering whether this burden would ever end. Poor me.

Out of nowhere, something flashed into my mind. What if this isn't my burden?

What if it is my purpose?

What if every experience I've had, every part of my current life, every person who looks to me for assistance and guidance is here because that is the way things are supposed to be for me? I began to understand that I am here to be part of something, not to get away from everything.

This revelation was fascinating to me, since I've been in leadership positions for nearly my entire career. I never thought of this as a burden, although for years I've felt tremendous pressure to be successful at helping my teams and my companies achieve great things. Recently, I recognized that I actually was considering this a burden - something I had to endure.

The subtle shift in my frame of reference was a like a jolt of energy. I understood I'm here for a reason (or perhaps I was remembering something I once knew). That reason is to help others accomplish great things, and even many "good enough" things. I was given certain strengths - gifts, if you will - and it's up to me to use them.

That is at the core of what leaders ought to be doing.

Do you think of your team and your customers as burdens? Or are they an opportunity to explore and utilize your strengths?

Are they a source of growth for you? Or an energy drain?

They can be any one of these. It's your choice.

Building On-line Development Communities

I've been thinking about how I could use social networking to strengthen the sense of community on my product development team. As is the case with most things, this is not a new idea. Open Source Software development has practiced this and embraced community development for years. In fact, one often hears references to the "open Source Community".

My team already has a strong sense of identity and community. But there was (at least) one area I wanted to improve. We didn't really have a repository of our history. Like most software shops, our "history" resides in our e-mail and file systems. That's nice, but it is not easy to find or share. As long as you know the right person to ask for a copy of an e-mail thread, you are fine. Even then, you get whatever thread fragment that person deemed important to save.

There are two distinct technologies I have deployed that have impacted our ability to record history. The first is Discussion Forums; the second is wiki pages. Again, there is nothing new here. However, very few teams I talk to use these technologies. I'm assuming you can figure out how to get these technologies installed and available. I will focus on what might help your
team adopt these technologies.

Start with yourself and your management team

Before rolling out to your entire team, start with your leadership team. Create private discussions and Wiki pages for the leadership team. Seed the topics and encourage your leaders to provide their input using discussion forums and wiki pages. Redirect normal conversations to the new technologies. For example, if someone sends an e-mail to the leadership team, copy it into a discussion forum and reply to that.

Begin to post key information in discussion forums and wiki pages. Make your leadership team accountable for knowing the content by giving them no alternative to find out what you are asking of them. Once you've done this for a few weeks, deploy to the next level.

Deploy to functional teams

Next, require each of your managers to deploy to their teams. Here I assume you have functional managers, such as development, quality assurance, writers, etc. Resist the urge to post into the functional areas. However - and I consider this critical - monitor activity for a few months.

Your goal in "eavesdropping" is to ensure the teams are using the technologies to build communities within the functional areas. If you don't see much activity, discuss it with the functional manager - not with the team. If you do see a community building, by all means praise it publicly. Make it clear you are aware of what is going on. That is perhaps the single best way to make it obvious that this is important to you.

Deploy to project teams

Once folks have gotten used to on-line functional communities, drive adopt to project teams. These are cross-functional teams working on the same release or feature. These are smaller communities that are transient, just for the life of the release or feature.

The key here is to build a community around people trying to solve the same problem. This is also where you build a lot of product history. The discussion forums record the conversation among the team (for example, alternatives for technical design strategies); the wiki pages record the actual decision (final design decision and rationale).

This is not easy, but if your team trusts you and you show leadership, you can be on your way to building deeper on-line communities in a matter of months. I'd love to hear your experiences.

Partnership and Client Orientation

I’m sure that nowadays nobody doubts that a real partnership with your clients and vendors is a key factor in the successful business development. Your clients who consider you as a reliable partner will return to your services every time they need them. Your vendors will strive to deliver the best services they have to justify partnership.

In the previous post Neal described a wonderful approach on the building partnership relations with an offshore team from the customer’s perspective. I’ll try to continue this topic from the vendor’s point of view…

So, from the vendor’s perspective: what is involved into building partnership relations with your clients?

In my opinion answer to this question is tightly related to such term as Client Orientation. Many (if not all) organizations delivering some sort of services are declaring themselves as client-oriented. However, what does it mean to be client-oriented?

Well, every company answers this question on its own. Sometimes this comes out to a set of rules to be followed while working with a customer. For example: Say “Hello”, Smile, Introduce yourself, Ask client what he is looking for, Direct him to a proper person to help. I saw such instructions in one large bank which positions itself as very client-oriented. Guess what? I spent almost an hour talking to very polite and smiling clerks who directed me to each other until I called a manager to get whatever I came for.

Another example: some time ago I had a chance to select a vendor for some services that my organization needed. Every candidate I asked the same question: “How are you going to help me?” Only one actually asked me back regarding why I need their services in the first place. The rest were describing their offers and explaining to me why I need to buy from them. I think it’s obvious which of vendors was selected…

So, I believe client-orientation starts from understanding client’s business needs. In other words, you have to clearly realize how client is running his business and how you could help him to be more successful in it. In our sales-driven world such behavior is quite rare. Eventually, we are hiring sales people to sell our services, aren’t we? Therefore, it’s necessary to focus sales team to build long-lasting relationships with clients.

Now, when you understand client’s business and make efforts to help him, is it enough to be recognized as client-oriented? Is this that simple? Unfortunately, it’s not.

Regardless how smart and perspicacious we are, it’s very unlikely we would know client’s business better than he is. Moreover, our economy is so dynamic and priorities changes so often that it’s almost certain that we will be one step (at least) behind our customer. This means we will do mistakes in our efforts to help the client. However, these mistakes should not harm our relationships.

Therefore, client has to trust us to recognize as a partner.

In terms of client orientation, what should we do to gain client’s trust? To answer this question it makes sense to understand whom we trust the most. I think it’s obvious – to ourselves. Because we know exactly what we do and what we don’t, we know why we are doing something and how we are doing it. There is no chance to lie to ourselves.

Thus, I believe there are three instruments to build trusting relationships between you and your client.

Reliability – When we are going to do something then we know exactly that we will do it. No exceptions. Moreover, when we are not going to do something then we do not fool ourselves with promises first and excuses afterwards. We just know we will not do it. It should work with clients in the same way. All our commitments have to be kept and we should not take commitments that we are not going to keep.

Visibility – Once we commit to something when we know exactly what we will do to achieve required outcome. That allows us to ensure there are no missing pieces jeopardizing positive results. The same we should do with clients – all actions we take have to be visible so clients could justify we are moving in the right direction.

Transparency – When we actually started to do something then we know how we are doing it and what corrections are needed. Therefore, we are not surprised by changes of original plans when it’s necessary. So, we should be completely transparent to clients in the same way. This will ensure great flexibility to adjust approaches without jeopardizing original intentions.

Apparently, listed methods have to be used in-line with described above understanding of client’s business needs. They will allow pro-active adjustments and corrections along with changed priorities.

Summary:
Ultimately, only the clients have a right to name your organization as client oriented and recognize you as a true partner. To achieve that it’s necessary to:

• Recognize and understand client’s business to help him to grow it;
• Build trusted relations with the client by applying reliability, visibility and transparency approaches.

The only drawback: it does not happen overnight – both client and you need time to build partnership relations.

By the way, in software development world SCRUM Framework utilizes and even dictates mentioned approaches. However, in my opinion it does not make sense to implement SCRUM if you do not follow these principles. In opposite way: you could be recognized as a partner without applying SCRUM, but with using described instruments.

Winning with offshore

I recently had an opportunity to speak about being successful with offshore partners. Having worked with several partners in my career, I was fortunate to be able to have some experiences to draw on. There were three themes I eventually landed on:

• People versus resources
• Relationships versus transactions
• Collaboration versus isolation
  

People versus Resources
The language we use is a reflection of our thoughts and shapes future thoughts. So here's a simple question: Do you report the number of people or the number of resources you have offshore? You see, resources are interchangeable and anonymous. People are flesh and blood.

Several years ago, my former manager began penalizing our team every time we referenced our partner either by their country ("I don't know how that happened, Antarctica tested that feature") or by their company name ("I can't believe Igloo Offshore would have coded it that way!"). She forced us each to examine the way we viewed them. Were they simply a group of disposable parts? Or were they committed and loyal people, just like us.

And guess what? Things changed. Professional respect across the two teams emerged. As people visited (every try to buy a round trip air ticket for a 'resource'?) back and forth, we began to learn names of our counterparts. Phone calls, instant messaging, and web cams became the preferred method of communicating.

More importantly, we built trust. My manager was on to something those years ago. She knew that when a person has a name, they are real.

Relationships versus Transactions
Once we began to see our partner as a collection of people, this next distinction sort of fell into place. You can't have a relationship with a resource. You go to an ATM and withdraw money from a machine, not from Bob. Once we began to know each other as people, we evolved to a new relationship. We became interested in career development on both sides. We deepened our relationships with their families during visits.

OK, you might be asking what this has to do with costs and productivity. And that, I assure you, is my point. Sure, you can get what you negotiate for in terms of transactions (do project X by March for Y dollars.) But our product isn't piece meal. It is a living, breathing product that evolves over time. I can't afford to have people coming on and off my project, all the while keeping the "resource count" level.

That's the punch line.

Our relationships are the bond that allows for continuity. We have wonderfully low turnover and deep experience with our offshore team. I fundamentally believe that is a result of the relationships among people from both sides. It's more than just a cool project on the resume. It about being on a world-class team with people you care about.

Collaboration versus Isolation
This too is a natural extension of the previous point. We don't distinguish between whether a person is here or there, with the exception of a few key customer facing positions. In other words, if a test lead is better situated there, then so be it.

We often have feature (scrum) teams comprised of people from both us and our partner. And because of the strong relationship, they work well together. Not only in a "feel good" sense, but in a hard core results delivered sense. People work hard for each other because they know each other. They have shared a meal together. They know about each other's families and celebrations. They have worked side by side together.

So when we need that push, we get much more than compliance because we are the customer. We get the energy, the passion, and the loyalty that is the difference in being able to deliver great software.

Ironically, these themes are exactly the way you should be treating your onshore team members already. Ultimately, it's about being able to look across your two organizations and see one team.

Why not?

Igor's post really got me thinking.

What are we really trying to achieve as leaders? Igor's notion of a "star team" is compelling. It is also rare in my experience. That isn't necessarily due to team talent, environment, or other factors. It ultimately comes down to me and my willingness to make space for the team to grow.

So here is an interesting "quiz" for you:

• Are you comfortable taking vacation and not staying connected to your team?
• If you couldn't present a topic to the E-staff, would you be comfortable with a team member presenting on your behalf?
• Do you let your managers have their own meetings without inviting you? And can you resist the urge to drop into their meetings to check in on things?
• Can you let your team execute a plan you don't agree with, knowing that they have the right goal in mind?

If not, why not? Take your time - think about this. Again, why not?

Now here is the kicker...

Now that you have an answer to "Why not?', ask yourself what you are doing to remove that barrier. The "Why not" is a barrier to your team member being successful. For example, imagine you said to yourself "Sally couldn't possibly brief the E-Staff. She gets too nervous in front of people." Sounds like Sally is doomed, right?

Wrong.

Her inability to brief the E-staff is as much your responsibility as it is hers. This is what I mean when I ask, "What are you doing to remove the barrier?" That is where people development comes in.

It's not about finding people's limitations. It's about removing them.