The short answer: Twitter can enable osmotic communication in virtual teams, and avoid social isolation.

Twitter, or any Twitter-style equivalent, is an endless stream of short messages created by millions of people around the globe. These messages can contain every type of information: a weather condition, the content of a fridge, a stock tip in response to someone asking; if you can fit the message in 140 characters, you can throw it in the Twitter information river.

Sender

You can add a message into the stream for no particular receiver, or you can address your information package to a particular person. If you want to sent me a message on Twitter, you do this by starting the 140 characters with @projectshrink.

Receiver

If you are plugged into Twitter you can try to follow every bit of information that flows by. Within 10 seconds you will drown by the sheer amount of bits. Twitter provides two ways to slice and dice the flow to get the information you might consider relevant. By person and by content.

• Person: you can follow every Twitter user you want. By selecting a person his or her Tweets (messages) will be shown to you.
• Content: you can create searches with keywords, and Twitter will provide you with a stream of all messages containing this keyword.

Real Time Small Messages

The most prominent characteristics of Twitter are “real time” and “small messages”. That is why it feels like “conversations in the background”.

If you run Twitter in the background (using tools like Tweetdeck) it is almost like listening to people talking in the background. Sometimes something catches you attention and you mentally zoom in.

It provides a virtual connection with the people you are following. Where ever you are with your laptop or iPhone, you get subtle impressions of what “the others” are up to. It creates a sense of “group”.

Osmotic Communication

Alistair Cockburn introduced in his book “Agile Software Development” the concept of osmotic communication – indirect information transfer through overhearing conversations or simply noticing things happening around you. To me personally it happens very often that a talk between people in the same room morphs from murmur in the background to a conversation you find yourself all of a sudden eavesdropping on.

Osmotic communication is a very important type of communication. It provides “missing” information, you don’t know you are missing. It provides sources you normally would not think about. It provides information in a context you haven’t considered.

The “triggers” for zooming in to chatter on the background are patterns. With Twitter we can use keywords popping up in a message as a trigger. If someone is talking about your project, mentioning it by its name, you will zoom in.

Sense of Group

The project landscape is turning mobile, multi-cultural, 24×7, highly distributed and in ever flux. The group you are working with can be scattered all over the world, in every time zone, but also just in the building across the street. Projects are allocated cutting almost every boundary in existence. This working environment increases the risk of isolation. Even in a room full of people one can have a sense of not belonging to any group. Feeling left out.

People need to feel part of a group. In the end we are social animals. Luckily for us, Twitter is social media. By following the people you want to form a group with, want to create a social connection with, you can have each other’s “presence” in the background at all time. As with all forms of communication, to create a real connection you need to participate, have a genuine two-way conversation.

Bas holds a masters degree in Business Informatics and lives with his wife in The Netherlands. He is author of the book “Surprise! Now You’re a Software Project Manager”

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Why You Should Use Twitter Style Communication In Your Project is a post from: Project Shrink.

Or Not Every Single Process Component Is Effective Alone

Although I propose picking different techniques and process components from every method that you can lay your hands on, this doesnt mean that you can just pick a single piece from a method and hope it will work.I stress that an issue should be tackled by the introduction of a certain process component. A certain risk should be reduced. So sometimes this means that you have to add another piece in tandem with the technique you had in mind. They go hand in hand, and one without the other would be useless.

Alistair Cockburn provides a nice example in his article, “Are Iterations Hazardous to Your Project?“. Simply doing iterations in development without involving the users in the intermediate results is just wasting your time. Iterations are intended as a feedback mechanism; just iterating without the feedback part will make the techniques ineffective. In the words of Cockburn, “Danger grows when the results of the iteration are not directly linked to delivering the product to the end user”.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Using Iterations is a post from: Project Shrink.

Managing Agile Projects is a book edited by Kevin Aguanno, a noted speaker and educator on agile project management. It describes techniques for managing projects in environments where the scope is constantly changing. This book is about techniques common to nearly all of the agile development methods (Extreme Programming, Scrum, Feature Driven Development, DSDM, Lean Development, Crystal Methods, Agile Software Development, Agile Project Management, etc.) that you can use to reduce risk, improve quality, and dramatically increase customer satisfaction in high-change projects. Chapters were written by the gurus of the agile movement: Scott Ambler, Alistair Cockburn, Ron Jeffries, and many others.

All author royalties from this book will be going to the International Red Cross for disaster relief.

A good time for me to have an interview with the editor. 

One could think “Another book on agile?” What makes this book different from the rest?

[KA] Almost all the other books on agile are focused on explaining agile methods to technical teams (programmers, architects, tech. team leads, etc.) This book focuses more on explaining the business benefits from employing agile methods and some techniques for controlling these projects. The BIG differentiator is that this book is targeted at project sponsors, project managers, and development managers. These more business-focused managers may have heard their teams are considering agile methods, and want to know more about the methods and also how to manage/control them. The book is about dispelling fears and explaining how agile can find a place in their existing management structures.

Why did you decide to create the book?

[KA] I am a senior project manager who primarily works on custom software development and systems integration projects. In these types of projects, changing requirements and technical uncertainty are a daily reality, unlike more production-driven projects that can be better controlled with more predictive processes. I am regularly faced with the challenge of trying to structure and control these custom development projects to meet aggressive timelines while still following “best practices.” Naturally, I began using techniques such as XP, Scrum, and FDD; however, I found my biggest challenge was not getting the buy-in of the technical teams — they already read about these techniques in their magazines — but rather the business executives who fear terms like “extreme” and see these methods as introducing unacceptable levels of risk. I saw that some education for executives and senior managers was required that explained how these methods actually are used to REDUCE risk. They needed to hear how these projects are structured, controlled, and managed. Finally, it is an uphill battle to introduce agile techniques into any organization, so I thought it was important to devote a chapter to explaining the topic of Stealth Methodology Adoption — a technique for packaging and introducing agile techniques to make them more palatable to the organization. With such a strong belief in the need for this book, I felt compelled to put it together.

Such a respectable team of contributors? How did you get them together?

[KA] Getting the buy-in of the other contributors was rather easy. I had first planned out what topics I thought the book needed to cover and then vetted that content with a few target readers. Given their feedback, I was able to prepare a chapter plan that divided the required content into chapters. Once I knew what I needed, I went out and did my homework, looking for top-rated articles (where I could find them) that fit one of the required chapters. When I could not find existing content that filled one of the slots, I asked authors who were known in the industry for their expertise in the specific area to write one for me. With only one exception (due to copyright restrictions) every contributor immediately came on board with the plan. I was surprised at how easy it was to get everyone’s agreement.

Do you remember your first transition from traditional PM to agile PM?

[KA] I think it was back in the mid 1990s when I finally realized that the way I was doing things didn’t seem to work well for the eCommerce and other Web projects to which I was being assigned. I realized that I didn’t have the right tools in my toolkit for managing these projects and began to look for better (more appropriate) tools. I first came to RAD and used that for a while, realizing the benefits from iterative and incremental development approaches. But more structure was needed, and I continued to search, eventually finding Extreme Programming, Scrum, and FDD. I have used these now for several years and have enjoyed great successes in doing so. While I don’t believe that Agile methods are ideal for every project, I do find that they are the tools in my toolkit that I grab most often, given the kinds of projects I manage.

What did you find the most interesting “new” fact or insight when compiling the book?

[KA] For me, I think it was the tight link with traditional methods. Agile methods are not all that radical — these techniques have existed for many years, and indeed are just evolutions of what previously existed. When you look at “the history of agile,” you will see that the techniques we have packaged into our named methods (XP, Scrum, etc.) were used long ago, we have just grouped them together and formalized their interactions. We have cobbled together methods from existing techniques — there is little revolutionary in the techniques, but much in the thinking behind the methods. Agile methods are a mental revolution, but a technical evolution.

In your introduction you write “While agile methods may not fit every project..” What makes a project suitable for agile methods? Is there still a role for “traditional” methods?

[KA] Definitely. Agile methods work best on projects where high levels of change are expected. Changing requirements, technological uncertainty, the need to experiment and evaluate different approaches to see which one works: these are the factors which indicate agile methods might be a good choice. However, some projects are fairly stable. Change is not going to be a big factor on these projects. Also, since all agile methods use iterative structures, and some projects cannot effectively use iterative development for their main deliverables, traditional sequential techniques still have a role to play. I tend to think of these non-agile projects as “deployment” projects — where the design and development are already done, we are just looking at installing and testing the products. I was once involved in rolling out a chip upgrade to thousands of cash registers across the country — on a project such as this, agile methods did not provide much value — though I did use a few techniques stolen from those methods.

An important factor within agile is colocation, as I understand it. How do you see this in respect to offshore outsourcing of development?

[KA] Colocation is definitely the ideal. Wherever possible, I have my development teams working together. The reality is, however, that most of my projects are rather large, and that the development teams can be scattered. On one project, I had almost 200 developers in 17 cities across North America and India. General colocation was not possible, but I WAS able to assign individual components to colocated teams where possible. I centralized the cross-component interfaces so that one colocated team (composed of members from each distributed component team) could work out all of the issues in one room. Finally, we can use technology to lessen the impact that distance introduces. Cockburn has a wonderful diagram that shows how different tools (such as teleconferences, instant messaging, screen sharing, etc.) are placed along the continuum between face-to-face interaction and communicating via documentation. When scattered teams are a reality, we can use daily teleconferences, instant messaging, web-based document repositories, etc. to increase the communication bandwidth and reduce communication delays.

If someone applies for an IT Project Management job a PMI certification will help him more then e.g. being a SCRUM master. Why is this in your opinion? Will this change?

[KA] Both of these are primarily a knowledge-based certification. Neither proves that the recipient is actually competent at what they do. So, removing competence from the equation, all we have left is ascertaining which knowledge certification is more valuable. I think that learning all of the project management techniques and best practices takes a lot longer than learning the techniques such as Scrum. If I needed someone with both, it would make sense to me to hire the one with the PM knowledge certification and teach them the Scrum practices on top of that, rather than the other way around. I also feel that PM knowledge must be complemented by IT knowledge for a PM to excel in managing IT projects. But underlying this discussion is still the need to choose candidates that can demonstrate the personal characteristics that one cannot learn from a book — honesty, open communications, self-confidence, ethical behavior, leadership, etc. — I look for these items first, as the rest can all be taught in a classroom.

If someone is working in a large corporation that uses “heavy methods”, how can he convince senior sponsors to let him go the “agile way”? How does your new book help in this respect?

[KA] I have a chapter in the book on this called “Stealth Methodology Adoption.” The chapter is quite involved, and I could not reproduce all of its main points here, but one of the key techniques is to avoid the concept of “selling Agile” at all. Instead, propose adptations of the existing methods that incorporate some agile techniques, one by one, and explain how they are being done to reduce risk, improve quality, etc. Don’t brand the changes as “Extreme Programming” or any other methods, but rather just call them tweaks to the existing method. That way, you can slowly adopt more and more of a method without earning the ire of the “process police.” See the “Managing Agile Projects” (www.agilesecrets.com) book for more details, or you can buy just that portion of the book as a Palm Reader (PDB) eBook at www.mmpubs.com/publications.html.

Do you have plans for another book?

[KA] Yes, I have one in the works on career development for project managers that helps them plan out what they can do next after they have attained their PMI certification (PMP). It is called “Beyond the PMP: Advanced Project Management Certification Options.” I also have a half-completed manuscript called “Project Closeout Best Practices.” I have plans on writing a book at some point on Scrum for non-IT projects as well.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Managing Agile Projects is a post from: Project Shrink.

To download the mp3, just click on “Download MP3″ on the page you reach by clicking on this link.

I love this interview as it touches some fundamentals of software development. First he mentions the use of the “cooperative game” as a metaphor / mental model of software development. Taken from his Crystal Clear book:

The cooperative game manifesto says: Software development is a series of resource-limited, goal directed cooperative games of invention and communication. The primary goal of each game is the production and deployment of a software system; the residue of the game is a set of markers to assist the players of the next game. People use markers and props to remind, inspire and inform each other in getting to the next move in the game. The next game is an alteration of the system or the creation of a neighboring system. Each game therefor has a secondary goal to create an advantageous position to the next game. Since each game is resource-limited, the primary and secondary goals compete for resources.

The good thing about thinking of development as a game is that you have moves, there is no right and wrong, it is about better or worse.

Fascinating is his explanation of the misconception people have of software development as engineering. Originally engineering was also a cooperative game of communication and invention. However after the second world war engineering took an odd turn. Because of the achievements of it during the war (rockets, bombs, radar) the emphasis got to applied maths and physics. Therefor applied maths got shoved into the engineering discipline curriculum at colleges and universities. So, engineering became equivalent to math and physics.

At the end of the 1960s some people argued that we had gone to far; that we had lost the art aspect of engineering, part were people have to communicate and get in touch with the materials they are using to get a deep understanding of domain, to be creative and inventive.

However, still at that time practitioners got devalued and the theorist more valued.

In 1986 at a NATO meeting people coined the term Software Engineering as a provocative term. Not to say “software development IS engineering”, but more like “suppose it is like engineering, what will then happened”? Just see where we end up from there. The result is that software development is falsely associated with the term engineering within the context of today (applied maths and physics). But Cockburn helps us to remember, there are similarities: originally both are games, cooperative games of invention and communication.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - MP3 Interview With Alistair Cockburn is a post from: Project Shrink.

The part that particular interests me is mentioned as Overcoming failure modes. One of the characteristics of humans the project manager should take into account is the mode people are working in. This is more or less a default behavior people have, strategies they tend to do more likely working in projects.

The failure modes are behaviors that probably lead to problems in your project. So recognizing them will bring you already half way a solution.

The five failure modes he describes are:

- making mistakes
- preferring to fail conservatively
- inventing rather than researching
- being creatures of habit
- being inconsistent

Making Mistakes

People make mistakes. Wow, that is an eye opener How obvious this may seems, it is amazing how many managers assume that everything goes well, that people will do their work flawlessly. You can not only recognize this by optimistic planning, but also projects were iterations are incremental approaches are not used. These approaches are invented because of the recognition that people make mistakes.

Preferring To Fail Conservatively

For me personally this is a surprising one. However, I do recognize it. The idea behind this is that people would rather choose an option that they know, that they have done in the past, EVEN if the outcome is likely to be unsuccessful, than trey something new, where the outcome may be positive, but unsure. An example is the use of the waterfall approach. Although the outcome will almost be guaranteed not to be the desired one, because it is an accepted approach, people will prefer it above agile approaches that are unknown to them.

Inventing Rather Than Researching

This is the tendency of people to try to create new solutions all by themselves, instead of looking for previous solutions that might work. Reasons for this behavior are the preference for creative processes (more intellectual satisfying, more recognition among peers) and the not-invented-here syndrome.

Being Creatures Of Habit

It is difficult for a person to change is behavior; it is very unlikely that someone changes his standard approach to situations. It is almost hardwired and unconscious. I must admit that I sometimes catch myself doing this; if you work for more than 10 years in the industry, you have a lot of been there, done that. But I guess that is how the dinosaurs got extinct.

Being Inconsistent

One huge mistake is to think that people will behave consistent. Different moods and different situations cause humans to act different than in almost identical situations. If you live together with someone for a lot of years, you know how your partner can still surprise you after all those years!

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Human Failure Modes: Why You Make The Same Mistakes Over And Over is a post from: Project Shrink.