Social media and the Surveillance Culture

Living as I do right in the heart of D.C., things like this happen: I had lunch the other day with a friend who is very knowledgeable about the hacker world within in the so-called "intelligence community". This is a world where it's common to get your secret clearance before you are old enough to buy a beer. And a sizable crew of these young folks are deployed to monitor - and participate in on behalf of the agency - all sorts of social media activity. Our conversation focused on Facebook, Second Life, and Skype. "The Agency is deeply involved in Facebook," I was told. This includes both developing techniques to pierce the Facebook's security, and active communication with persons of interest. "Security and Privacy are non-existent on Facebook" my informant told me. The same with Second Life. Organizations hold meetings on Second Life, I put on a sexy female avatar with my breasts hanging out, and I'm just accepted. All the guys have learned to use female avatars and personae on the sites. People will tell you anything" More ominously, I was told they have had some success accessing the computers of people connected to Second Life. As for Skype, the e-bay owned internet phone service: "There is basically no security employed by Skype. You can use an ordinary packet-sniffing software like any network engineer might buy to detect calls from a specific IP address and reassemble them. We've been working on editing them on the fly to change the content of an active conversation." Just something to bear in mind, eh?

Control and Flexibility

Control and Flexibility. These might be two of your goals in in working with your personal trainer. But in configuring your network and key applications, there is always a tension between these ambitions. How much do you lock down to prevent error and occasional malfeasance? How much do you leave open so that each staff member has the greatest ability to work freely and serve your community without running into roadblocks? It's one of the key areas where we see organizational culture influencing Information System design For example, board members and donors are hoping you keep good track of the comings and goings of their dollars. So there is a pressure to lock down access to financial records to one or two highly qualified individuals. On the other hand, if it takes the CFO to issue a five dollar refund check, you've created a real bottleneck. Somewhere between these two is your financial control balance point. This fulcrum won't be in the same place for all organizations. For example, a YMCA with it's hectic point-of-sale environment and fifty or sixty part-time or volunteer front-desk staff will arrive at a different solution from a trade association with a full time staff of ten professionals. The same dichotomy between control and flexibility arises when you start to push out e-commerce capabilities to your community. We see some organizations who are loathe to let a member change his own address. "Do you really work with organizations who do that? What if they make a typo or something?" And at the other extreme, there are organizations who say "If someone calls and wants to register for our workshop, we direct them to the website to enter it themselves. We genlty insist they do it themselves. Staff time is a scarce commodity". Again, your organization needs to find its own comfort point along this scale. You should rethink this balance periodically though - it is not a simple issue. Too little flexibility and you weaken your staff, your donors, and your membership, diminishing commitment they bring into the organization. Too little control and time, money, and energy flow out the door.

Timeboxing Risks

Before I got delayed we were talking about delivering software projects on time. Using the Timeboxing approach, the delivery schedule is the one absolute in the implementation plan. What features will be included in the delivery can slip, but never the date. New requests from the user are added to the queue, but the date is not modified to accomodate them. Unexpected technical problems may delay a feature, but never an install. With this approach, progress may be slower than anticipated, but it never halts, as it can with traditional scheduling, where an installation might be put on hold until all the planned features are completed. We've outlined the benefits to this approach, but there are also some risks. The most critical risk is safety. If Timeboxing is taken to mean that we just work away at the application until the scheduled delivery date, and then install whatever we have, users can get some nasty shocks. A major new feature might be only partially implemented. Spurious messages meant only for the programmers might appear. Untested calculation might charge people incorrect fees. The solution is release planning. Timeboxing is not a come as you are party. Sometime before the due date, the team needs to decide what requests can actually be included. Testing on those items must be completed. Features that are not ready for prime time need to be hidden. Changes that should not be delivered need to be rolled back out. This is where a good version control system comes in. Even the sacred install date can be slid by a day or so - not more -- to assure that the work already done is ready to debut. What this really means is that internally the timebox needs to end a day or two early, so the app can be cleaned up for its public appearance.

The Humane Society's LOLseals

But before we get back to delivering IT projects on time, let's look at some funny pictures. Certainly none of us have been spared the LOLcats phenomenon - where folks photograph cats and give them funny captions. Here's one my god-daughter Leah posted on Facebook, for example: Taking off on the popularity of this craze, my friend Carie Lewis, the dynamic internet marketing manager for the Humane Society of the US - one of the most savvy non-profits around when it comes to interactive and social media - has launched an LOLseals contest on the HSUS website. Take a peak. The idea is to create your own caption for one of the seal pictures. A panel of celebrity judges will announce a winner, who will take home a bunch of great HSUS seal gear. It's a great idea to encourage engagement and awareness of the ongoing plight of Canadian seals. What is exciting about this contest is the way it changes the images used in educating folks about the seals. The Canadian Seal Hunt is still the worlds largest slaughter of marine mammals. And it happens every year. We are all used to seeing images of baby seals being clubbed. This campaign reminds us of how appealing these animals are, rather than forcing us to look at violent images we've learned to shield ourselves against over the years. It gives the community a new way to engage with the issue, a new way to feel about these animals. It can be hard to find a new way of presenting the same old story - HSUS has found a way here.

Timeboxing your Development Efforts

How can you make sure you meet your promised deadlines when implementing software projects at your organization? And without late night pizza-driven coding sessions? One approach is Timeboxing. Timeboxing, quite simply, is an approach to IT implementation planning where the one thing that you do not allow to shift around on you are delivery dates. Everything else may seem totally out of your control. The users have eighteen new features they absolutely need. Your best programmer quits suddenly because she was offered a bit part in a horror movie. You just can't find that bug where new members are going in without their addresses. But you will install SOMETHING on March 18th. When I first read about timeboxing more than a decade ago, it seemed a nearly impossible technique to explain to the user community. Folks in our client organizations had a list of fixes and enhancements they wanted, and they were not interested in seeing a new version until these were done. But software methodologies have grown to emphasize a more iterative approach to development. In these so-called agile methodologies, fixing the schedule for each new delivery makes perfect sense. In the Scrum development model, for example, a new version is typically delivered every thirty days. At the beginning of the cycle, the team agrees on what outstanding requests will be included in this release. But if the work does not proceed as smoothly as planned, some of the requests will be left out to allow the iteration to complete on time. The ones that were not completed will be included in the next round. The advantages of this approach? 1. Users are not left waiting for new features already written as a delivery date keeps moving out to accommodate incoming requests. 2. By getting more features into users hands more quickly, the feedback cycle is tightened and the applications improve more quickly. 3. By allowing feature lists to slip, the "Death March" pressures around deadlines are alleviated, allowing programmers to perform work of a higher quality. Of course there are risks to timeboxing as well. We'll look at what they are and how release planning can mitigate them in the next post. ------ More reading on timeboxing can be found here.