Overcoming Fears with Collaboration

Since Agile is so team-centric, collaboration between team members and customers is essential for success. However, for some people collaboration isn't an easy thing. There may be some fears that need to be overcome to fully see the benefits of collaboration.

Fears fall into these categories:

1) External Fears - The organization may have fears of being too transparent to their customers, competitors or other outside interests. Sharing too much information could be considered giving away company secrets to your competitor. Having your customers talk with other may uncover issues they have with your organization. Your customer may have information you might not want to hear (but should).

2) Organizational Fears - Executive management is supposed to drive the long term vision and strategy of the company. Operational teams are supposed to implement this strategy. But what if the two groups should clash? What if the operational teams come up with ideas that will cause a need to change the direction of the company? What if strategy is on a "need to know" basis and executive management doesn't give enough information to operational teams? What if management doesn't trust operational teams? What if operational teams don't trust management?

3) Individual Fears - Perhaps the individual hasn't had the education and skills developed that encourage collaboration. Most people grew up going to school where the teacher talks and everybody listens. The teacher gives you the homework and you follow the instruction. No coloring outside the lines. No challenging ideas. Speak when spoken to. Then, that person starts their career where the manager talks and you listen. The manager gives you tasks and you complete them. Same structure, but highly different than a collaborative environment.

So, how do you combat these fears?

1) External Fears - Managers worry about transparency because they think that outsiders don't know what is going on in the company, but in this Information Age the opposite is true. Customers will talk with other customers. Competitors will find out what you are doing. The competitive advantage is no longer how you hold on to information, but how quickly and better you can implement those ideas. Once you understand this, you will be more open to knowing what is out there. The more transparent the organization can be in an collaborative environment, the more accurate you will meet the needs of those "outsiders". The competitor who is most open and both listens and responds to what is being said, the better they will be.

2) Organizational Fears - Collaborative environments have one thing in common - an environment of high trust and respect for each individual. Strategies need to be shared. Everybody may have knowledge on any topic so every topic should be shared. People need to understand the vision. Most of all, everybody in the organization should help influence where the company needs to go. It's not just Executive management's role, but everybody who has a stake in the company.

3) Individual Fears - New people have the most opportunity for collaboration because they come with a fresh and naive perspective. No questions are "dumb" ones. Organizations need to encourage new employees to contribute in any way possible as soon as possible. There needs to be retraining and rethinking about how individuals should contribute. Some people are more comfortable in a verbal discussions. Others need time to digest information then respond. Yet others feel more comfortable in "tweaking" existing ideas instead of coming up with new ideas. Others like to respond in writing. You need to provide an environment that plays to each person's strengths and allows them to participate.

Team Power

In both Agile and Lean circles, there is constant emphasis on the team rather than individual efforts in resolving issues, making decisions and suggestions for improvement. "Two heads are better than one" rings true! Over at LeadingAnswers blog, the latest post called "Team Solving: The Under Utilized Power" demonstrates this fact. Here is a synopsis of the findings:

Power #1: By asking the team for a solution we inherit consensus for the proposal. The fact that the solution came from the team and not me, meant I did not have to sell it, it already had support. It is easier to steward a sub-optimal solution with good support to a successful outcome than build support for an optimal solution and ensure its successful execution. If challenges arise and people subconsciously ask “who’s bright idea was this?” the answer comes “Oh yeah, it was ours” and they are more likely to continue.

Power #2: Accessing a broader knowledge of the facts. Team members are closer to the details and bring additional insights other than your own. I did not know that the business folks bowled, this was collective knowledge (Chris knew three users bowled and Julia knew two others did also) together we found a new piece of useful information. Asking the group taps the collective knowledge of the team.

Power #3: Solutions are practical. Anyone who has worked hard to craft a solution only to be told “That will not work here because...” will know how frustrating and disheartening these words are. Team sourced solutions have been vetted for practicality and, because created internally, solutions found for implementation issues.

Power #4: When consulted people work hard to generate good ideas. The simple act of asking for suggestions engages team members beyond the role of “Coder” or “Tester”. People appreciate having their inputs valued and generally work hard to create innovative and effective solutions. Treating workers as interchangeable resources is a poor model inherited from the command-and-control methods of the industrial revolution. Leading companies such as Toyota and 3M recognize that their best ideas come from inside their companies and we need to make use of this intellect. It is partly due to these methods that these companies innovate better, have higher quality products, and better labor relations.

Power #5: Asking for help shows confidence not weakness. Asking for ideas and solutions to problems is not a sign of incompetence or an inability to manage. Just because we ask for input it does not follow we are dumb. Instead it demonstrates valuing the opinion of others, and being thoughtful. In essence it demonstrates how all problems should be tackled, which is the next power.

Power #6: Seeking ideas models desired behavior. Project managers have a leadership role of “modeling the desired behavior” i.e. behave as we wish others to behave. If we stay silent, make decisions with incomplete awareness of the facts, and do not ask for help when we need it, what message is this sending to the team? Well, it is an obvious message that we expect team members to behave the same way and work in isolation. Lots of time and money is wasted on team building activities that are then eroded my management-in-a-vacuum.

Here are also some cautions where the team can actually lose power:

Caution #1: Real problems - We should use this on real problems only, not on which brand of printer toner to buy. Remember we are modeling desired behavior and if people take it too far and consult their team mates when deciding what color dialog box to create; no work will get done. It is a tool for when you are stuck and the problem is important.

Caution #2: Poor team cohesion – If the team is fragmented and has opposing groups then resentment for “fixing their problems” will undermine the process. We need to get the team aligned for team solving to be most effective.

Caution #3: Team and Project Changes – Over a long period if a significant portion of the team changes, we need to re-canvas the team to ensure they are still on-board with the approach. Exercising the bright ideas of others is nearly as bad as not being consulted; we need to ensure people still agree this is a good policy. Likewise if the project changes significantly, we need to checkpoint in light of these new facts and get the team to review the approach.

Caution #4: Follow-through – once you ask for solutions make sure you follow through on them with execution. It is pretty demoralizing to be asked to work on a solution and then see it wither. It is fine to go back with implementation problems that need to be solved, but don’t waste peoples time by asking for input and then ignoring it.

Another View of Lean Leadership

Joe Little from Agile and Business has an excellent post today called "Leaders, Managers, Bosses and Administrators". Actually, he focuses on what leadership means in the Lean and Agile world. He refers to the Poppendieck book, "Implementing Lean Software Development: From Concept to Cash" (If I had to pick one book to understand Lean as applied to software, this would be the one!). Here's his take on leadership after reading the book:

They [Poppendiecks] raise several excellent points.

1. A team needs leadership. Which is to say, vision. Someone to inspire and someone to help them put their hearts in the game. And keep it there.

2. The project needs decisiveness. If the team has too many leaders, and the leaders squabble about decisions, then the team wastes time. The team needs to know how it will make decisions. There is a trade-off between making the right decisions, and making decisions quickly.

3. Generally, the team needs to learn to make decisions only at the last responsible moment. So, much of the decision-making is about when to make a decision. At what point have you learned enough to make a good/better decision?

4. The project needs business decisions and technical decisions. This is very true. So the team needs business people and needs technical people who are ready and able to make those decisions. And, preferrably, business people who understand technology and technology people who understand business (and the customers).

5. And there are many other types of decisions to be made too. People decisions. Decisions about whose insights to go with on specific areas. Process decisions. Decisions about who is working effectively and who is not. Decisions about how to get the team to communicate better and learn faster.

6. In Scrum, we have ScrumMasters and Product Owners. These roles are endowed with certain leadership aspects. This is different than the leadership of the Chief Engineer, which is a role Toyota uses.

7. Project managers have also provided leadership. (And we have the whole PMP, PMI thing, too.) PMs have also provided managership, bossiness, administration and other things.

8. We know that no bosses are wanted. We want all the best from every person, and a boss will only inhibit that. A boss wants to command others, and thinks he knows all. These are not helpful traits in a learning situation. (So, semantically, we are using "boss" here to represent all the bad things that a boss can be. Of course, few managers or leaders are as bad as a boss, but we all can be that way sometimes.)

Read more in Joe's post.

Now, Rules for Self-Leadership

A few posts ago, I talked about a great post by Rosa Say around self-management. Now, she has followed this up with a separate list this time focused on leadership qualities. I agree with Rosa that there is a difference between management and leadership qualities and that everybody should strive to accomplish both. Here, Rosa elaborates on this as well as presents the 12 Rules of Self-Leadership. Enjoy!

Management and Leadership are not interchangeable words for me. We need both of them, for in part, management tends to be more internally focused (within a company, within an industry, within a person) whereas leadership is more externally focused on the future-forward actions you will take in the greater context of industry, community, or society. They have commonality to be sure, for instance, both are about capitalizing on human capacity, however they are defined by the differences we value in them: Management tends to be about systems and processes, whereas Leadership is more about ideas and experiments.

I believe there is both art and discipline in each, and I think of these rules as the discipline which helps reveal the great capacity of the art. Thus last time, twelve suggestions to help you self-manage, with a more disciplined you newly able to reveal your art. Now, twelve to help you self-lead, so a more disciplined you is newly able to reveal the art in others, those who choose you to lead them.

12 Rules for Self-Leadership

1. Set goals for your life; not just for your job. What we think of as “meaning of life” goals affect your lifestyle outside of work too, and you get whole-life context, not just work-life, each feeding off the other.
2. Practice discretion constantly, and lead with the example of how your own good behavior does get great results. Otherwise, why should anyone follow you when you lead?
3. Take initiative. Volunteer to be first. Be daring, bold, brave and fearless, willing to fall down, fail, and get up again for another round. Starting with vulnerability has this amazing way of making us stronger when all is done.
4. Be humble and give away the credit. Going before others is only part of leading; you have to go with them too. Therefore, they’ve got to want you around!
5. Learn to love ideas and experiments. Turn them into pilot programs that preface impulsive decisions. Everything was impossible until the first person did it.
6. Live in wonder. Wonder why, and prize “Why not?” as your favorite question. Be insatiably curious, and question everything.
7. There are some things you don’t take liberty with no matter how innovative you are when you lead. For instance, to have integrity means to tell the truth. To be ethical is to do the right thing. These are not fuzzy concepts.
8. Believe that beauty exists in everything and in everyone, and then go about finding it. You’ll be amazed how little you have to invent and much is waiting to be displayed.
9. Actively reject pessimism and be an optimist. Say you have zero tolerance for negativity and self-fulfilling prophecies of doubt, and mean it.
10. Champion change. As the saying goes, those who do what they’ve always done, will get what they’ve always gotten. The only things they do get more of are apathy, complacency, and boredom.
11. Be a lifelong learner, and be a fanatic about it. Surround yourself with mentors and people smarter than you. Seek to be continually inspired by something, learning what your triggers are.
12. Care for and about people. Compassion and empathy become you, and keep you ever-connected to your humanity. People will choose you to lead them.

Read more in her post!

Rules for Self-Management

If you want Agile to be more successful for your organization, you need each individual to think differently about their role and expectation from management. For the teams to be self-organizing, you need each individual to be self-managed. This isn't to say that management in an Agile organization isn't necessary, as they need to be there to provide direction and remove roadblocks for the team if the team cannot do it for themselves.

However, the more the team can manage for themselves, the greater the productivity and efficiency. After all, part of Agile is to be able to deliver working software with better quality and response time.

Rosa Say has always been one of my favorite bloggers on the top of management. She has a recent post on her Talking Story blog that as I read it realized how well it would work on an Agile team if the team adopted her 12 Rules of Self-Management. Here they are, read it for yourself and imagine if each individual followed these rules:

1. Live by your values, whatever they are. You confuse people when you don’t, because they can’t predict how you’ll behave.
2. Speak up! No one can “hear” what you’re thinking without you be willing to stand up for it. Mind-reading is something most people can’t do.
3. Honor your own good word, and keep the promises you make. If not, people eventually stop believing most of what you say, and your words will no longer work for you.
4. When you ask for more responsibility, expect to be held fully accountable. This is what seizing ownership of something is all about; it’s usually an all or nothing kind of thing, and so you’ve got to treat it that way.
5. Don’t expect people to trust you if you aren’t willing to be trustworthy for them first and foremost. Trust is an outcome of fulfilled expectations.
6. Be more productive by creating good habits and rejecting bad ones. Good habits corral your energies into a momentum-building rhythm for you; bad habits sap your energies and drain you.
7. Have a good work ethic, for it seems to be getting rare today. Curious, for those “old-fashioned” values like dependability, timeliness, professionalism and diligence are prized more than ever before. Be action-oriented. Seek to make things work. Be willing to do what it takes.
8. Be interesting. Read voraciously, and listen to learn, then teach and share everything you know. No one owes you their attention; you have to earn it and keep attracting it.
9. Be nice. Be courteous, polite and respectful. Be considerate. Manners still count for an awful lot in life, and thank goodness they do.
10. Be self-disciplined. That’s what adults are supposed to “grow up” to be.
11. Don’t be a victim or a martyr. You always have a choice, so don’t shy from it: Choose and choose without regret. Look forward and be enthusiastic.
12. Keep healthy and take care of yourself. Exercise your mind, body and spirit so you can be someone people count on, and so you can live expansively and with abundance.

What part does Credibility play?

In both lean and agile cultures, it is important that teams are self-organizing, self-improving, and self-managing. To be able to do that requires a certain amount of autonomy and latitude to "do the right things". This in turn requires a certain amount of trust that the right things will happen and respect that the team and individuals on that team have the right knowledge and skills to accomplish the work. All of this requires establishing credibility.

What is credibility? I see credibility as a track record. Each person can have a good track record or a bad one. A good track record is one where the person says what they are going to do (integrity), their opinions are proven through implementation (knowledgeable), and their actions are in the best interest of the company (commitment). A bad track record is one where one or more of these components are consistently being challenged by others. "Is this person representing the company?" "Do they know what they are doing?" "Will they really follow through and deliver?" If these and other questions continue to happen, this will impact the credibility of not just particular individuals but eventually the team as a whole.

Why all of this talk around credibility? Because if you want good communication between customers and the development team you need credibility. If you want the team to think in Lean concepts and perform in an Agile manner, they must have an appropriate level of credibility at some point. This isn't just an Agile or Lean thing, the same can be said about any employee, department or project team. It's just much more apparent and critical with Lean and Agile since the focus is on teamwork and the role of teams.

Whenever you have your next brainstorming or design session, look around and listen to what people are saying and how others are reacting. If you hear things that are based on little fact, make sure that work is done afterwards to experiment and prove out the theories and assumptions. If you see that others are showing through their words (and more importantly their body language) that they don't believe individuals or even worse the team, talk to those people and coach them on credibility. Make sure they see examples that hurt credibility as well as those that improve it.

As a manager, I am highly sensitive to the reputation of people, teams or the entire department. Typically, credibility and reputation go hand-in-hand. I want individuals to be successful. I want trust and respect established. I want them to have the highest integrity. Each of them should want it just as bad. Many times, they may not know why they aren't getting it. Credibility isn't something that is easily given, it must be earned. It is something that is earned over your lifetime. Think about that for a moment...

Transparency is the key

Recently, we did a retrospective at the end of one of our iterations. As part of this process, we show a working demo of functionality that has been completed as part of that iteration. Usually, this goes pretty well but this one didn't end up as well.

During the demo, things started out smoothly. We demonstrated the functionality and everybody was pleased with the results. It was the conversation that happened afterwards where things went downhill.

Those that were representing the customer wanted to know about some functionality that had been talked about but hadn't been completed yet. The Developers assumed that the Customers were accusing the team of not delivering something yet. They got on the defensive quickly saying such things as "That functionality wasn't part of the scope of the project" and "I wasn't tasked with that work so I know nothing about those requirements" and "I don't remember those conversations" and "I thought it was part of a future project". What's was interesting is that none of these conversations were really true, but they were used as a defense mechanism. Once these things were uttered, the Customers also became defensive. "What else have you forgotten?" "Have you even thought about these things?" "Will the current solution accomodate this new functionality that is added later?" "When are these requirements being considered, if at all?"

After we ended the meeting, I met with the Project Manager/Scrum Master who had also attended the meeting to recap. She was as surprised as me to the statements that were made and was a little upset that the Developers had acted that way. I went to talk to the Customers and she went to talk to the Developers. Here's what we learned...

The Developers knew the right answers but felt they were been questioned for things that they weren't focusing on at the moment. So, they tried to do a little CYA for their lack of knowledge with the questions. Instead, they could have easier said to the Customers, "Though we have talked about that functionality, we haven't really focused on it because the functionality that you saw today needed to be completed first (because it was core and highest value). The Scrum Master could have talked about when those discussions would happen. In my talking with Customers, they knew what was being shown and understood the team was to deliver what they saw but just wanted to know how much thought had been given to the design and implementation so far to the next functionality that is being considered. It was an honest question that should have had an honest question. Instead, the Developers interpreted the question as blame for not having more to show in the demo.

I realized that there is still much work to be done to encourage transparency between Customers and Developers. It is ok to discuss roadblocks and issues between groups as they happen. Bad news shouldn't be hidden. It is ok to discuss that there are things that haven't received the focus on the team yet. It is ok to discuss changes and new ideas that weren't part of the original conversations. We should encourage feedback (good or bad). We should encourage honesty in where we are at. If this is done, it will establish better trust and respect between these groups and a healthy relationship will grow. Perhaps we are dealing with years in which Customers and Developers didn't spend much time together and the relationship was strained and distant as the result. When they got together, it was more like contract negotiation across the table than a partnership with much collaboration.

In the end, I was glad to see that this happened and know how to coach others in better communication in the future. Retrospectives are to be a checkpoint on where you are at in the delivery of work. Not just a checkpoint on what you deliver but also how you deliver it. The process is just as important as the deliverables. Both need feedback and constant improvement based on each "checkpoint". This is one of the key benefits of Agile -- to embrace changes based on constant feedback towards providing better customer and business value. How you work with others is a big part of that.

What kind of person do you need for Agile?

What kind of people does it take to be successful with Agile? I have learned that there are some attributes that are critical for success. If you don't have many if not most of these qualities, you or your team will suffer the consequences. As you are developing your team (and perhaps hiring people outside of your company) think about these things as you are determining who will be on your Agile teams:

Team Player - Agile is focused around communication and collaboration with other team members. If you can't play well with others, you will have a difficult time. If you are uncomfortable communicating within a team, you need to get out of your comfort zone. You are not doing Agile if you sit somebody in a corner to code.

Disciplined - Many people when seeing Agile for the first time think it is very informal and therefore undisciplined. I have experienced first hand that it takes a lot of discipline. There is never really down time. With shorter iterations, every minute really counts. You must be organized with your time. You must think how to be more efficient. You must constantly be thinking about the architecture, how to test, how to redesign, integration, builds. These can happen on at least a daily basis if not more frequently. This takes discipline!

Adaptable - As Agile requires the flexibility in the process to embrace change, so should each individual have the same approach. Processes will be constantly improving. Code and design will be changing. Customers will have the opportunity to change their minds more often. If you don't like change, you will have difficulty with Agile. You must accept that change will happen and prepare for it mentally.

Takes Initiative - Agile requires that the team be aware of not only what the customer needs but always looking for ways to improve the quality of the deliverables. Creating tests, looking at design, code review, refactoring takes initiative. Each person is expected to tell the team what needs to happen and sign up for tasks along the way. That takes initiative!

Self-managed - Though most Agile teams have some kind of manager or coach present, whether that be a Project Manager, Scrum Master, or Agile Coach, the ultimate goal is for the team to be self-organizing. If management is present, it is only there as help from the team to remove impediments and may be involved to report progress to stakeholders outside of the team. The team is responsible for taking what the customer wants and delivering it in increments. They must figure out how best to work as a team, who is going to take what, and know that each person is responsible for the team's success. In order to do this, each person cannot require somebody to assign tasks and have that person check progress. They can't be micro-managed but need to manage themselves against the team.

Experienced - Though Agile can work with some members of the team being junior-level, it does require experience from most of the team. Experience will technical skills. Experience with "soft" skills. Experience with Agile. Experience with the domain (customers, industries, products, services). The team will do better with the confidence that comes with experience. It is also crucial that junior-level people get up to speed quickly so they don't slow the team down. By developing in small increments and using techniques such as pair-programming, this can make the learning curve smoother.

Customer/Business Minded - Though most Agile teams have a dedicated customer, it doesn't free the team up to not worry about what the customer wants. In fact, I would say that Agile forces you to put yourself in the customer's shoes. "Am I doing what the customer wants?" "Does what I provide help the customer's business?" "Are there ways to help the customer be more successful?" I have seen people on teams who could care less about the customer but just want to go do their work. In the long term, this really won't work with Agile. Since everything is around prioritizing the work based on customer value, you can't be effective if you aren't thinking about the customer.

Did I cover them all? What other attributes can you think of that individuals need to possess?

Myths about Developers

In our process of implementing Agile and Lean, I have realized that there are things said or thought of about developers that Agile/Lean are showing as myths. If you still believe these statements are correct (or have developers believing them as well), you need to change your thinking if you want to adopt Agile/Lean. I used to believe some of these myself until I was surprised to find something much different.

Myth 1: Developers make poor testers. We established an entire QA department based on this myth. Developers don't like to test. Developers don't know how to do it. Developers are too close to their code. Developers should not test their own work. We said these things thinking that testing was a unique skill that could only be taught to non-developer types. What we realized is that these skills can be taught to anyone but few developers really know how to think about tests. The value of QA (or other testers) is to make sure that multiple people validate the test results. Two heads are better than one.

Myth 2: Developers do not work well in teams. It is thought that most developers by nature are introverted, and would rather go off and work in the corner than interact with others. Therefore, they we thought they would have a hard time with the teamwork that is required of Agile and Lean. What we realized is that developers just want to make sure there is value working in teams and they will come out of the comfort zones if it makes sense to accomplish more as a team. I will agree that for some this is an easier process than others, but eventually I have seen all developers warm up to working with others on a team.

Myth 3: Developers are not good in front of customers. Developers are too technical for customers. They talk above their heads. They don't have great communication skills. They are too brash and abrupt. They don't really care about what the customer wants. These are things that I have heard (and perhaps even said). However, just like testing Developers just haven't received the proper training and experience to work with customers. For most, it isn't natural to them. But, if you have them working often with customers they learn quickly. The customers also learn how to adapt to working with technical people. In the process, they learn the value of some of the "technical talk". Agile/Lean forces everyone to think in terms of the customer and working more directly with customers (or customer representatives).

Myth 4: Developers only care about coding. I just want to get back to my real job. When we used to use Waterfall, I would hear these words ALL the time from developers. After spending days and days in requirements and design meetings, I couldn't really blame them. However, I knew the value that they brought to those meetings in addition to the knowledge they gained to do a better job of coding. Agile helps developers get to coding more often, which is what they love. While at the same time, they appreciate the time to understand what needs to be accomplished. It's now the time it takes to do that is in matter of minutes or hours instead of days and weeks (and sometimes months!).

Myth 5: Developers want everything figured out at once. As we first implemented Agile, I got some push back from Developers that doing things in pieces would lead to poor architectures, design, missing requirements, etc. With Waterfall, they believed that they were able to get all of those right at the beginning of each project. However, I reminded them that pretty much every project we found changing requirements which lead to changing design which lead to changing architecture. So really how valuable was it to figure everything out in the front?? With that question posed, they gave it a try. And found that they could more easily adjust architecture, design, code by working on things in increments.

Myth 6: Developers cannot self-organize or self-improve. As a manager, this is where I really learned that this was a myth. I honestly thought that project managers and myself as a functional manager needed to be there to identify where improvements needed to be made and make the team implement those improvements (whether or not they truly understand the improvements). As a result, the team became dependent on management to make things better. Those dependencies became bottlenecks, because we would try to implement big changes instead of a lot of little changes. I also thought it was management's job to help assign tasks to people and make sure those people stayed on task. Again, this caused more bottlenecks. Here, the role of management was to REMOVE bottlenecks, yet we were BECOMING the bottleneck. All because of this notion that developers needed management to do these things for them. What developers really needed was practices that provided them the focus, direction, feedback and autonomy to do their work well. They are in the best place to know how to do their jobs well, so shouldn't they be the ones who figure out how best to accomplish that? When management backs off and the teams realize that it is their responsibility to improve things, they will do so. Plus, in the process they will feel better about themselves, their role in the company and their feelings about management.