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.

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.

A better way for conferences

Ever heard of Open Space? If you haven't heard about it and experienced it, you will never think of a conference the same way again. I had the pleasure to attend a 2-day conference here in Portland for Agile Open Northwest.

Here's how it works, according to Wikipedia:

In Open Space, a facilitator explains the process and then participants are invited to co-create the agenda and host their own discussion groups. Discussions are held in designated areas or separate rooms known as 'breakout spaces' and participants are free to move amongst the discussion groups. Each group records the conversations in a form which can be used to distribute or broadcast the proceedings of the meeting (in hard copy, blog, podcast, video, etc). Online networking can occur both before and following the actual face-to-face meetings so discussions can continue seamlessly. In a multi-day Open Space, participants have the opportunity to announce new discussion topics / late-breaking sessions each new morning. At the end of the day (or 2 days or 2.5 days) the full group reconvenes for comments and reflection. This helps participants to re-engage in the full group over the duration of the meeting.

While the mechanics of Open Space provide a simple means to self-organize, it is the underlying principles that make it effective both for meetings and as a guidepost for individual and collective effectiveness. The Law of Two Feet -- a foot of passion and a foot of responsibility -- expresses the core idea of taking responsibility for what you love. In practical terms, the law says that if you're neither contributing nor getting value where you are, use your two feet (or available form of mobility) and go somewhere where you can. It is also a reminder to stand up for your passion. From the law, flow four principles:
* Whoever comes is the right people
* Whatever happens is the only thing that could have
* Whenever it starts is the right time
* When it's over, it's over

The organizing theme of an Open Space meeting is that people who care about the subject will come together. The initial meeting notice takes the form of an invitation, thus the people who have attended have chosen to be there and are willing to contribute. The objectives for the meeting and the time available affect design decisions such as whether action planning is included in the Open Space or not.

What did I like about it?

1) The content was tailored to the audience. Nobody selling their services or products that people may not care about. Topics were relevant to the desires of the people attending. Otherwise, nobody attended!

2) Many different perspectives were represented. I had expected that it may be more developer-centric, but there were several sessions for customers, product owners, testers and other roles. People attending also came from all of those perspectives.

3) Great respect for everybody in each session. I truly expected hidden agenda, egos, holy wars, and other things to dominant discussions. Never happened! Differences of opinions were just that - differences! No question was stupid, no perspective was invalid.

4) You could decide how much you wanted to participate. There were many that didn't say a word (or not much). Others felt very comfortable from the beginning. Some got more comfortable (like me) after some time had passed. Sometimes the experts talked. Sometimes they listened. It was very comfortable.

5) Tremendous sense of energy and community. I really can't describe it, but I never felt there was a slow time. Lots of things happening. You could feel the energy. I felt at the end a sort of sadness that the two days were ending. In most other conferences, I couldn't wait for it to end!


What could have been improved?

1) Some of the meeting rooms had more that one session in it and one of the them was also the gathering place for people between sessions. This made it very difficult to focus at times. Felt like we were on a party line competing with each other to talk. It would have been better to have one session per room and the general communal place to be located away from sessions.

2) Some of the sessions I felt that we talked problems but little solutions. Perhaps it was to be that way so that we could all go back to the real world and come up with solutions. Not sure I expected all of the problems solved but was a little frustrated because of that.

3) I didn't take any notes because all notes were to be gathered by each of the session "hosts" and placed on a common wiki for everybody to access. Unfortunately, some of the sessions never made it to the wiki or didn't have complete information. I would have filled in the blanks, but didn't take notes to focus on the conversation. This might have been just this conference as I have seen notes from other ones that seemed more complete.

If you have a chance to go to a conference or seminar that is set up this way, I highly recommend it. Don't come with too many expectations. Be open to anything happening. And hopefully my experience will encourage you to go. You will find those conferences to be the best you have attended. You will also wonder why you ever did conferences a different way. Lastly, you will probably never go to a typical conference again!

Before there were projects

Though project management has been around for longer than I have been born, in the mid 80's I wasn't really exposed to the idea of software projects managed by project managers. As a programmer working in both an IT shop as well as consulting, life was much different.

I was assigned tasks by a manager (functional or account managers). Sometimes these tasks were very specific, such as "add this information to an existing report". Other times these tasks were more generic, such as "customer would like a new report that shows this kind of information". The requirements were always clear, but there was always flexibilty in the design. This applied to everything from traditional maintenance tasks (bug fixing, smaller enhancements) to major new product or system development from scratch. As a junior developer, I appreciated the extra support I had as I was learning the tools and systems necessary to excel at my job. Once I got there, I appreciated the flexibility that my manager gave me to figure out the solution with the customer more on my own. In other words, the tasks moved from specific to generic as my experience increased. It became my job to get to the details.

The manager was the initial "go-to" person when there were any questions. He or she needed to have a certain level of knowledge about what the customer wanted. However, they weren't the customer so their responsibility was to get clarity from the customer when needed. Sometimes, that could be done "off-line" so that I could focus on other things. Other times, it was determined that I needed to be there if the discussion became more technical in nature.

Another key difference is that there was little or no specifications. Essentially, most requests if written were a simple one page form providing some high-level information enough to get the conversation going. Other requests were verbal in nature. There were no project plans to review, drafting and review of a large functional specifications document, etc. So where did you capture this information, you ask?

Most of the conversations involved at that point were verbal, with the occassion taking of notes to go back to my desk. However, and here is the important part, the code WAS the specification. It represented the requirements and design. It was expected that you would go through several cycles of the changes. These weren't prototypes, but early looks at the finished product. At first, some things weren't finished or even developed yet. However, the point was to get feedback not just from the manager but many times from the end customer. "Are we on the right track?" "Is this what you were expecting?" In the process, we learned technical limitations such as "we had to redesign the report because the new data would not fit" and couldn't have expected some of those things until we got into the code.

As I progressed in my career, I look back to these early years and wonder if things are better now. Sure, technologies have changed but so have other things that perhaps have gotten in the way. All I know is that things seemed much faster in those days even though the technology was slower. But I have to believe that with improvements of technologies that things should be screaming now. However, they aren't. But that's a discussion for another day...