29 June 2011

Remixing Innovation

A few months back, I finished reading a book by Steven Johnson called Where Good Ideas Come From. For a while now, I have intended to write a review of the book, but lets be honest, I suck at book reviews. It is difficult enough to encapsulate so many good ideas (pun not intended) into a short post for a book that was just ok. It is infinitely more difficult when the book you read is this amazing.

Thankfully, I have been saved from such a task by the latest installment of the Everything is a Remix (part 3).

One of the things I find so amusing is that this entire video contains elements that could have come directly from Steven Johnson's book. Many of the examples and all of the themes in the video exist in the book, in a condensed and concise format. The book expands and adds to these concepts a great deal. I highly recommend reading the former and watching the later.

As a teaser, I'll give you my favorite quite from the video:
We can’t introduce anything new until we’re fluent in the language of our domain, and we do that through emulation.
Do you remember your first project? The one where you were lost about what to do so you grabbed a bunch of templates, formatted your notes into them and prayed no one noticed you were just making all of this up? Yeah, me, too.

Do you remember your most recent project (assuming they're not the same one)? When you compare the two can you see how your actions in the first project, for good or ill, led you to what you've done most recently?

Its all remix, yet when we recombine things, sometimes we hit upon something that fits just perfectly. Its why everyone has created or modified an existing requirements or project plan at one time or another. Something wasn't right, you had this idea you got from a different domain, you put them together and something just clicked. You innovated.

What I think frustrates me the most about innovation is how most people just don't get what 'it' really is. We're told to "Go get creative; find a solution that doesn't blow the budget, can be implemented by a typing monkey and will be done in two weeks" yet those issuing that edict don't seem to get that good ideas can't be forced in that way. Yes, 'creativity', if defined as 'slap something against the wall and hope it sticks before I lose my job', then I can help you with that in a short time frame with no budget or resources.

But if you want a solution that is fully conceived, builds upon the right foundations in knowledge and infrastructure and, most important, actually solves the real problem, you probably want to put some effort behind it besides driving the whip.

28 June 2011

Being a manager, this amuses me...

I haven't said it in a while, but I *love* this web comic. Pure genius. I will say that I have never passed anything along to one of my employees that I haven't already done at least once myself, but there have been a few times where I thought to myself, "At least its not me dealing with it this time!" Sad but true.

Red, Amber, Green, Know what I mean?

If you are going to use traffic light colours to indicate project status you probably want to start red rather than end red.  Here is the justification.

Most projects don't deliver on their promise.  
Call out industry reports which show the rate of fails, challenged, over budget and schedule, etc.  Go wider than the Standish/Chaos report.  There are plenty of alternatives that tell similar stories.  The best evidence comes from internal records.  Check out the last 5-6 projects of a similar scale to yours.  Have a look at the initial planned budget and the actual budget at completion.  The put it in a slide deck.

Project Management Can Help
When I was doing my formal project management studies I cam across a number (which I can't recall, but may have been about either 30% or 300%, the source was a PMI Turner) that described the typical benefit project management can bring to <ahem> chaos.

Project Management is important but insufficient
You also need three other things to make a project work.  Without these three things you are guaranteed to run into troubles. They are

  1. Support from a sponsor that understands the project and is prepared to roll up their sleeves when necessary,
  2. A Team who have sufficient technical skills and can work together as a unit,
  3. Stakeholders that are informed about and aligned to the project goals so that they understand how to manage user requirements and to work with the project team to fulfil the sponsor's goals.
So, based on the evidence you have today what's your current project status?  Until each of these criteria (plus any other local issues you have) are addressed and tested you are in the red.

Start a project in the red, know you are in trouble and manage your way out of it.  It's much better to work this way than the other way around.

27 June 2011

Build Work Around Teams to Solve the Estimating Problem

Some teams are moving away from forming, closing and reforming teams.  In this instance you may have variations in the total size of the team (as peaks and toughs in demand call in temporary support) and the work varies from maintenance of a set of legacy systems to new product development and other things, but you also have something really valuable: Continuity.

People have been making a big deal about the value in keeping working teams together based on the team effectiveness that grows over time.  I buy into that.  But I want to amplify the case for building work around teams rather than vice-versa by highlighting that the established teams also come with established capacity and estimating standards.

Take your team today for example.  Look back at your history and assuming you've collected the data you'll be able to work out the average size of a project (Days, T-shirt sizes, dog breeds, or my favourite - types of beer.)  You'll see that you team addresses X number of requirements per month.  You don't even need to be working in iterations.  You just have to be releasing software to get measurable start & end data.
  • How many requirements were addressed?
  • How many weeks work did it take?
Is this a reasonable sample size?  Once a team has hit a controlled rate of delivery, you've sufficient data to estimate for the future.

A caveat to my position: By team I include the person who is managing the requirements that flow into the team.  The quality and standards around requirements are probably the most variable aspect of many project teams, and it's just as important to normalise the requirements as the solution delivery work.

23 June 2011

More than 50 things you can put on a Scrum meet-up agenda

I'm involved in the Melbourne Scrum User Group meet-up.  I was wondering what other groups around the world are talking about so I scanned meetup.com, augmented this list with a few discussions I have had in recent weeks and created a list of more than 50 topics people are discussing.

You're welcome to take a look and use it, add to it, comment etc.

Timothy B. Lee: Industry Destruction

One of my favorite bloggers in the last year has become Timothy B. Lee. While I don't always agree with some of his libertarian viewpoints, this guy always makes me think. He did so recently with his discussion about how technology innovation cannot always be measured strictly in term of Gross Domestic Product (GDP).

The part of his article that most directly relates to those of us who work primarily in projects is this:
Self-driving cars are a good example of where things are heading. They will probably put millions of truck drivers out of work, lowering the cost of almost every consumer product. They’ll make taxicabs drastically more affordable, putting taxi drivers out of work and virtually eliminating demand for off-street parking. They’re likely to have significant environmental benefits, as consumers can order only as much car as they need for any given trip. They are likely to save thousands of lives by reducing accidents. They’re likely to transform the retail sector—how often would you drive to store if a self-driving Amazon-bot delivered your orders in an hour rather than 2 days? And of course they’ll have many other consequences we can’t anticipate.

Stop for a moment and think about what self-driving cars could do to whatever industry it is that you work in. I'll give you an example from my own personal employer and myself. First, my employer has hundreds of employees who do nothing but deliver food to local stores and thousands more who do nothing but deliver its product end customers. Imagine if, over the next decade, self-driving cars become cheap enough that only the hundreds of drivers who deliver food to local stores no longer have jobs.

Even if my company undertakes no project to build, from nothing, a self-driving delivery truck, we would need a project to implement the self-driving delivery truck someone else built into our organization. Imagine the look on the faces of the delivery drivers when they are told that we're going to test a product that could potentially end their jobs.

I don't think anyone would argue that, from the perspective of the drivers, that would be a disruptive technology. For the company, its a huge up-front investment, one which would probably require the replacement of its entire fleet of vehicles, but in the end, it would end up a competitive advantage to no longer need to pay drivers in this way.

Making it (more) personal

But what about me, as a BA? How would self-driving cars impact my life?

Given that I spend, on an average work day, 100 minutes in my round trip commute, a self-driving car would make me more productive. Consider that I average 9.5 hours of work per day (570 minutes), 100 minutes of drive time and another hour and a half of productive time in the evenings (housework, laundry, blogging, etc), I would increase my productive time from 660 minutes to 760 minutes, an increase of just over 15%.

What could you do with an extra 15% of productive time per day? I don't mean necessarily 'productive' as in 'doing work for an employer', but what about reading a book, listening to a podcast or even writing a book? Maybe I just shift some those 100 minutes into my at the job time and leave at 4:50 each day, knowing that I'll still be exceeding my normal output, even though I am 'leaving early' for the day.

With one simple change, at least simple in terms of me doing the cash outlay to purchase a self-driving car, I completely change what I am able to complete in a day. Sure, I could, in theory, just move 5 minutes away from work and would produce essentially the same result, but I don't want to live 5 minutes from work (not to mention this would make my wife's commute now around 160 minutes per day).

Never discount the possibility of a technology to be disruptive to your business (or yourself).

Agile extension to the BABOK

The IIBA are planning an agile extension to the BABOK.  As community minded folk, a few of us Melbourne people got together over some beer and talked though what we think is important.  The summary is below (I'll publish a link to a Google doc with the longer version shortly.)

This is all opinion, generated over been among a handful of people who think they know the business.  You are welcome to contribute to the conversation in the comments below.

The mission of the Agile extension to the BABOK
  • Demonstrate what elements and/or practices in the IIBA are applicable in agile development
  • To get BA’s doing Agile right
  • To (understand how to) do what is required for your team
  • To support Business Analysts in their pursuit of excellence in their field
The motivation behind the Agile extension is
  • To help analysts understand whether IIBA certification and membership is valuable to me and my organisation
  • To ensure consistent approaches are taken (within the frameworks adopted, and within the variations discovered and adopted by teams)
  • To achieve the delivery of business value with a reduction in project delivery risk
  • To support BA’s in their pursuit of knowledge
  • To clarify how a BA contributes to delivering value in an agile context
What Analyst need to know about Agile fundamentals
  • Understand story initiation
  • Learn about facilitating stand-ups and planning sessions
  • Continual learning is at the heart of agile
The core of the Agile BA role is
  • Facilitate the delivery of business value
  • Facilitate “team ownership” of the delivery of business value
  • Enable other team members to perform their duties (through the provision of clear requirements and goals.)
  • Facilitate mutual understanding of the problem or opportunity to hand
Some Techniques that are important for an Agile BA include:
  • Facilitation skills
  • Inception activities
  • Release planning
  • Sprint/Iteration planning
  • Formulating acceptance criteria
  • Coaching and mentoring
  • Problem analysis
You’re doing it wrong if:
  • Silos still exist and your iterations are mini-waterfalls
  • You become a bottleneck
  • You aren't a core part of the team
  • You are making crucial decisions on behalf of your stakeholders/customers
  • The team has different expectations
Lastly, we all felt that the extension should be written in a way that talks to what you should do to achieve excellence in this space, and what goals you are seeking to achieve by adopting agile practices rather that the draft content's typically reactive stance.

I'll publish a few of my independent thoughts in a separate post in a few days.

22 June 2011

Why Quality Is Important

MG Siegler on Apple:
Even Apple haters cannot deny the quality of the products. Bitch about price, bitch about control, bitch about the fruit logo — but quality is simply never a compelling argument. Because Apple wins.
Somewhat colorful language aside, I can't think of a bigger compliment anyone could receive in a project than to say that their quality product is the reason they are successful every time.

Ok, so what, you say. Why is this important? He continues:
Apple will remain in a position of power for the foreseeable future because they have nailed that model.
Apple knows what business they are in, they constantly evolve that model to not just anticipate the needs of markets but to create markets and they do it better than anyone else. When was the last time that any of us evolved the project model? When did any of us create an entire new market for projects to inhabit?

When we, and I speak for myself as the first person in this line, own the model, we'll win every time.

21 June 2011

Estimates are redundant. Here's why.

Estimates are redundant for many teams these days, although many persist in estimating work.  Let's run through some estimating canon and then talk about why estimating is in certain circumstances redundant.

Projects estimate the work effort up front to discover the balance between technical performance (i.e. scope & quality), cost and schedule.  This helps hire the right number of people, set stakeholder expectations and make portfolio investment choices.

Alternatives to up front estimating are to time-box the solution with a view to cutting or extending the investment on an as needs basis.  Another alternative is to fixed price (low value, exploratory) or fixed scope (regulatory compliance) the project up front.

Finding the balance

Estimating is done to help assess the balance between cost, duration and technical performance of the target solution.  It is used as a tool to negotiate the sliders on those dimensions.  One pass at up-front estimating is typically not enough for the smart money, as you'll have an all-or-nothing approach to the solution.  That is, in the process of estimating assumptions are made about how to prioritise fast, cheap, of "solution rich."  What you need to do in these scenarios is to revise the estimates until the sweet spot between the project performance factors is discovered.

Once an estimate is discovered it can be taken to portfolio management boards and assessed relative to other project proposals based on value generated, cost and risk. But, why on earth are we doing so many projects that deliver such marginal value?  Surely a project is worthwhile or it isn't?

  • Conclusion 1: Too many trivial projects are created where the work would be better managed as operations.
    • Question: What makes people 'projectize' work when it's not special, unique, and all that project 101 stuff? 
    • Hypothesis: Lack of systems thinking, expertise, complex taxation rules and accounting practices.
  • Conclusion 2: Ongoing estimating has to be the default mode of doing business.  If you aren't revising your estimates at every steering committee meeting there is something suspect in your reporting.

Fixed resource (money & people)

Much software development, especially operational work, is done in a fixed resource way - essentially fixed pricing the work.  In the fixed resource (cost) model estimating helps understand team capacity and plan releases.

If you have made the commitment to fixed resources you can park estimating activity and focus on short cycle times to ensure as much value is generated as possible.  Focus on flow to increase delivery and you'll get more out.  Estimate and you'll waste energy and time (a finite resource) on analysis that adds no value.  Improving your estimating won't help you ship more.
  • Conclusion: If you are fixed resource, there is no value in estimating.
I have another point as well, where you take a people or team centric view of the project, planning the work around existing teams.  We've gone on for long enough so I'll hold it over for a post next week.

Sketches go a long way in generating understanding

Here is an example. Notice the focus on human interaction as well as technical specifications.

20 June 2011

What does 'Priority' really mean?

Hello everyone from my multiple week hiatus. My deepest apologies for my prolonged absence. I was out one week on a family vacation and then had two weeks of hip (more like neck) deep work that piled up while I was out of town and had to get done before I got back to blogging. All of that is now taken care of, my batteries are recharged from some time away and I've got a whopper (I hope) of a first post for you.

Lets talk about priority. Yes, I know, I said I have a whopper of a topic and priority, well, doesn't seem to fit that kind of a heading. Hang on with me for a moment and I think you'll agree that priority doesn't mean what you think it means.

The traditional view of priority

While on the plane ride out to California, I listened to one of my regular podcasts, Back to Work, hosted by Merlin Mann and Dan Benjamin. It was episode 17 and Merlin spent a lot of time opening my eyes as to what priority really means.

If you're like me, when you hear 'priority', you might picture a large group of people sitting around a conference room table trying to determine which items on this big feature list they want done first. Its all about scarce resources and how to best deploy those resources.

Maybe you take a different viewpoint; maybe to you, its a notepad that contains a bunch of tasks that you have to get done today. You drop off your personal belongings at 8am and begin to complete those tasks in the order that your boss expects them to be completed.

In these views, priority is all about order and completeness. There is no thought that any of these items won't be done, its just a matter of how long until they are complete. To me, this had always been my thoughts on priority as well, even though it never really sat right with me.

My issues with priority

There are two things that always bothered me with this view of priority. During really large projects, I noticed a tendency for features that were either really difficult to implement or that were falsely labeled as important, almost always fell off the final deliverables list somewhere along the way. When we delivered a release, all of these things which people had given enough priority to be included in the initial scope just never made it to the finish line.

Stranger still was the rarity in which someone would complain about one of these items missing from the final product. Sure, the person who came up with the idea may grumble about it not being there, but when everything was said and done, the non-inclusion of these functions were non-issues.

For the really difficult to implement issues, they almost always fell apart not because the technology didn't exist or was too expensive, but that the business rules and definitions were always so vague or poorly defined that no one in the business areas even really understood what was being asked for. When those items failed to meet the final build, no one noticed because no one really understood what that thing was all about in the first place.

When it came to items that were falsely labeled as important initially, it was almost always to appease the ego of one stakeholder. Often times these items were tossed in to scope, even though they didn't really fit with the goals of the project, just to mollify someone who was offended that the genius of their pet project wasn't recognized by everyone else. Since no one ever saw this as a priority anyway, when it fails to be delivered, no one really complains about its absence.

What we're missing

What is missing in all this discussion of priority is a concept that, at first glance, seems like it doesn't really come in to play anyway. Yet, if we're really going to talk honestly about priority, you can't without it. Merlin nailed it when he discussed priority being nothing more than a way to quantify sacrifice.

Yes, sacrifice. When something is correctly prioritized, you're really discussing your value system showing what you will not do more than what you will do.

We need to reframe the discussion about priority. We need to change the thought from being "Here's a huge list of stuff, we're going to do all of these in this particular order" to "Here is the small number of things we're going to do and do really well, because these are the things that matter to us. Every other idea may be good, but we're going to sacrifice and not do them because they don't fit with what we really do want to do."

The outcome

Why would we want to change our viewpoint on priority? Isn't the traditional viewpoint better because it gives us a direction on what to go do after the current project?

No, it isn't. There is an assumption in an ordered list that we'll have the time and resources to continue completing items until the list is complete, but that assumption is faulty for many reasons. Projects are time bound activities and there is no guarantee that there will be a next project after this one, which fixes or adds in everything this first projected failed to include.

So is our alternative to just make all projects omnibus, where they contain larger and larger sets of requirements so that everything becomes a 'priority 1'? I don't really have to tell you the answer to that is 'No', because we've all seen those projects and we all know that even if they reach completion and deliver a final project, its never the exact product anyone wanted delivered.

The answer then, is smaller projects and a sharper focus on cutting out everything we can. We get that laser-like focus, we sacrifice everything we can live without in order to perfect the things which truly matter.

16 June 2011

The Future of Business Analysis #Rant

For a little while now I have been mulling over a blog post that says something about the remarkable reluctance of the business analyst community to join the lean-agile wave of change sweeping industry.  Yesterday and today I saw the tweeted Agile Australia conference (which didn't stand up against the #LSSC11 conference for tweeted conferences) and read a post at Laura's blog about BA's adopting agile practices which pushed me to get this post up.

Your responses are most welcome.

1. You seem to suck at your job.  Fix your attitude.
There is something very wrong when the solutions teams are becoming better informed about how business works, and better at developing and managing relationships than the BA community.  And it's happening at more and more places.  It's not wrong for developers and testers to do this.  It's wrong for Business Analysts to not be at the forefront of this aspect of doing business.

Business Analysts are supposed to understand business.  Culture, Structure, Process, Systems, Customers, Behaviours, Values.  In reality many people are 'order taking' and pushing paper from place to place doing busy work.

The BA community is changing, but it's at the edges, and the changes are coming slowly.  The middle of the pack - and that probably means you or your colleagues is just not doing their job well and are not adapting to the demands for quality, value and efficiency from all parts of the project community.

Pick up your game.  Starting now.

2. Not only do you suck at your job you're making work suck for other people.  Have some respect for other people.
Frankly the way you think about work is exemplified in the solutions you design for other people.  Your scientific management theories and your simplistic ways of thinking about workflow for example make you design systems that are hard to use and restrict a person's ability to do good work.  Hello Call Centres.  Hello back office processing centres.  Hello corporate websites.

When programmers groan about the quality and attitude that analysts display, that's just one vocal and educated aspect of your stakeholder community.  What about end users?  What is your idea of how work should be done going to do to the next few years of their working life?  What about customers? How are the systems you articulate going to shape their relationship with your company?

When you design other people's work via system interfaces and workflow remember to put the humans involved right in the middle of your thinking. There is plenty of evidence out there to help you work out that the best way to enable staff to help customers is to enable them.  There is evidence to show how tightly designed processes reduce everybody's satisfaction.  Go look it up.

And while you're at it, look up how to build in a continuous improvement program for yourself.  You don't just need an immediate step change; you need to build something into your work life that keeps you sufficiently educated to not be dangerous.

Remember: People in the centre of your design work.

Back to work now.  There's nothing more to see here.

Portfolio Management Simulation

I spent a good part of today in a project portfolio management simulation hosted by Computer Associates.  It was a fun exercise.

CA were naturally doing a promotion for their product Clarity, but it was a soft sell, and most of the energy was around three rounds of project delivery phases.  All the magic buttons were there; resource capacity management, schedules, budgets, risk and uncertainty and value based prioritization.

Of course the simulation ignored many real world factors such as levels of competence, ramp up and switching costs and so on.  But it was just a game and the purpose was to raise points for discussion rather than test or demonstrate real world competencies.

The fun bit for me was that I got to play the role of IT operations, and have to manage the scarce hardware resources and the competing maintenance operations.  Once I worked out what my role was and how to play it in the game I put up all my data on a whiteboard and everyone did the work for me.

Whiteboard beats PPM system (in a room of 10 people at least.)

Thanks CA for a fun day.

14 June 2011

Busy anyone?

Life is way too busy right now so rather than fully fleshed out blog posts I am going to dump some rough thoughts your way.  Bear with me.

BA World Bangalore
Was fantastic.  I pitched my story which seemed to go down well.  I met plenty of great people, none of whom I have gotten back in touch with yet. (If you are reading, I'll get to you soon!)  I want to go back to Bangalore in particular and India in general and I envy Glenn Brule who backed up his conference participation with a combined holiday and business trip around the country.

Agile Australia
Is tomorrow and Thursday, and I won't be there, but I will have my ears open and the twitter feed switched to #AgileAus so I can track what people are thinking about the content.  If you are at the event and would be up for a gust post here, let me know.

Is also coming up and if you are an analyst of project manager I'd like to recommend it as a development activity that I know you'll learn from.  You get the opportunity to learn new things from some presenters, to challenge orthodoxy when listening to others, and to really learn what the industry is doing in the hallway conversations.

I am repackaging the presentation I gave to BA World Bangalore for PMOZ in Sydney in August.  The refocus will include added information on what good Requirements Traceability looks like, and how done well, it can aid a PM in release planning and schedule management.

Melbourne Agile Business Analysts
I started up this group a few months ago and it's been a quiet and steady build up in terms of numbers and quality.

Last week David Joyce gave a great presentation on Process Mapping and properly understanding a system before jumping in and tinkering with it.  (Of course that flippant description totally misses the important points in the presentation. You should have been there.)

I've also just put out the call for a pub session to talk about and collate some ideas for the IIBA's Agile extension.  Come along if you are able and interested.

And next month we'll be doing a workshop on User Stories, which will also be fun.

Melbourne Scrum User Group
I have also been involved in the Melbourne Scrum User Group which has been doing some joint activities with ACS Scrum and Lean Leadership SIG.  That's also been interesting.  The challenge in this space is to develop a platform for both the (typically) ACS scrum newbies and the local experiences Scrum practitioners. If you have suggestions please get in touch.

RIP Eli Goldratt

On Friday, as I left a funeral for a family member who passed away at 64 I received an email via Eli Goldratt's  mail list that he'd passed away.

I didn't know him except through his writing so there is not much I can add to what people have already said, except to say that 64 is relatively young in our world, and he clearly had more to contribute to our community of finding better ways to do business.  It's a shame we'll hear no more from him.

RIP Mr Goldratt.

3 June 2011

What a Business Analyst thinks about TV

I have a recurring conversation with many of my friends and coworkers. It goes something like this:

"Hey, Ted! Did  you see what happened on show XXXXXXXX last night???"

"We've worked together for over 4 years now, and in that time, how many times have I ever answered 'yes' to that question?"

"Uhm... yeah, that's right. I forgot; you don't watch TV."

Yes, I am a weird-o. I don't watch TV. More accurately, I download a very limited set of TV shows, only one of which has gained any real mainstream popularity, and most importantly, my wife and I only watch the downloaded versions when we have nothing else to do. Its not that we have some kind of religious or spiritual aversion to the TV; its just that we receive very little enjoyment out of mainstream entertainment. To each their own.

How a BA looks at TV

Given my outsider status, I feel as if I have an interesting perspective on the television. Its not that I think its a tool of satan or something that rots your brain; just that it isn't for me. There are certain things that I want out of my entertainment medium and TV fails that on most every account. To put it in business terms, TV fails to meet nearly every one of my requirements. Are my requirements so esoteric that they're nearly impossible, at least economically, to meet? I don't think so, but my perspective is a bit biased.

Some of my objections to the current state of TV, at least as we have it in the US, is nothing more than my rejection of the values of the society in which I live. Minus my mortgage, I have no debt. I don't buy things I can't afford. I don't try to 'keep up with the Joneses'. Things like this just don't matter to me. TV, and its advertising sponsored channels, just don't have the same goal as I. That's not to say that one of the two goals is better or worse, just not what I value.

I see the same type of conflict happen between stakeholders on projects as well. Be honest with yourself and you've seen it happen, too. How often have the strict controls desired by finance and audit meshed perfectly with the flexibility desired by operations? When has the need for short call times within support matched up with the detailed analysis needed by engineering?

When our stakeholders do not agree, we either get them to some kind of acceptable compromise or one side's needs so far outweigh the other's that a decision is obvious. For me, I'm not going to ever let the needs of the other side (advertiser's and networks) outweigh my needs and any compromise that requires me to watch needlessly consumeristic commercial content in order to get a few chuckles is also abhorrent to my sensibilities. When faced with either of these two possibilities, I do what most project stakeholders are unable to do; I take my 'ball' and go elsewhere.

Making a better TV

So what would I do to make TV more appealing? I'm not the first to ask this question, which is why this idea of rethinking TV came to mind. Frankly, no solution that would meet my needs would allow TV as we know it today to continue.

The first thing that is important to me is the ability to make TV adhere to my schedule. Being able to watch what I want to watch when I want to watch it is primary. When I'm not at work, I don't plan my life around set slots of when I must be at some specific location to do a specific activity. If I miss a time window, or if I simply don't want to do an activity at a certain time, I shouldn't be punished for this. TV that requires me to watch on someone else's schedule is simply unacceptable.

DVRs, and tv-on-demand, have gone a long way to meeting this requirement. Tivo and other similar services help users time-shift programming to meet their schedules, yet they still have issues with my second requirement, location shifting.

Its not that I just want to watch TV when I want, but also where I want. Of all the screens in my house, laptops, iPad, netbooks, iPhones, desktops and TV, the TV is the one that is on the least. Even then, the number of movies played far outweighs the number of TV shows. Why is this? Simple; the mobile devices can go wherever I go, but the TV (generally) must be stationary.

If I go to the doctor's office and sit in the waiting room for 30 minutes, I don't want to be forced to listen to the soap operas or the afternoon talk shows when I can whip out my iPad and watch whatever I want. The problem with this model is that streaming TV over the iPad, especially when on a public wifi connection, makes for a poor experience. The only viable option, as of now, is to download the show in advance if you want to be able to watch later; a solution which really doesn't meet my need.

How many times, especially with the advent of cheap laptops and (more recently) tablets, have our users begged and demanded to have their data and processes available to them in a mobile fashion that doesn't equate to email? More and more, our users want their data available where they are, not just in the office. Just like I want my TV available where I am, our project stakeholders want to work where it makes sense for them to work, not where it is convenient for the project teams for them to work.

The last requirement I have is in regards to cost. Yes, it is absurd that I am unwilling to pay $1 for an episode of a show when I am willing to pay $3.50 for a hot chocolate from Starbucks, yet for some reason, I just can't bring myself to pay that for a show. The meager laughs provided by modern TV via download just don't seem worth it when the same content is available over the air for 'free' (advertising notwithstanding). Even just rereading this paragraph makes me realize how absurd my value system is in this area, yet I have a mental block that just refuses to budge.

This is the one that makes me cringe because I see it in myself. I know that my users are tired of hearing me say, "If only I had the time, people and budget, I'd love to do that for you, but as it is, I am completely constrained on all three of those fronts. Get me more of any of those three and I can help you out." Its the same thing with TV; I want it for (mostly) free. Yet my expectations of what it should cost to produce 30 minutes of quality programming and what it actually costs to produce 30 minutes of quality programming are far apart and unlikely to ever meet. When my stakeholders complain about me never doing anything for them, I cringe, because I know that I do the same thing when it comes to media companies.

Summing it Up

So what are my requirements? Simply put, I need to be able to view TV when I want, where I want and at a cost that doesn't feel usurious to my wallet. Those are not requirements that are unique to me. They are the same requirements that are asked of me on a regular basis (albeit with less militancy than I've expressed here about my own wants and needs).

Exercises like this, which outline our own requirements that are not being met, are useful not only to help us sharpen our skills, but to help remind us of the struggles our business stakeholders go through regularly. These are reminders that those of us who regularly work on projects need to have regularly.

1 June 2011

Breaking Down Stories - Concept to Sprint Ready

Last night Reg De Silva presented to a bit over 100 Melbourne Scrum people.  The topic was about readying stories.  It was introductory level, but Reg followed it up with a discussion which covered a range of more advanced topic.

The slide deck he talked to is below.  The meetup group is here.

A new Facebook Use Case

Recently, while looking through my Facebook feed, I realized there is a use case that isn't currently cared for by the site. Its something I had noticed in the past, but it never occurred to me that the site could actually resolve the problem for me (at least mostly resolve it).
As a result of 9 trips to France in an 18 month period that ended, coincidentally 5 years ago this week, I have a lot of former French coworkers who are my friends on Facebook. That same project also saw me make many friends who spoke Arabic and a few who speak Hindi (or other languages from the Indian sub-continent).
As my travels in France left me there, often with no other people who speak English as a first (or only) language, I learned what I called 'Menu French', which is just enough French to not starve when I head to a restaurant. But that little bit of French has, over the intervening half-decade, faded with disuse.
Enter my recent review of my Facebook news feed where I realized there was a post from one of my French friends that I could almost, but not quite, understand. Because I know my friends well, I know that they have French set as their default language in Facebook, even though they all know English. I know that I was not the intended audience for whatever it was they were trying to say, as it was in French, but I wanted to know what they were saying as I like knowing what is going on with them in their lives.
Sure, I could highlight the text, right click on it and then ask Google Chrome to translate it for me, but that's a pain. Given that Facebook knows their language, knows mine (English), and that they already have a UI element that could be repurposed for it, this would be an extremely easy thing for them to offer to auto-translate for me. Imagine another icon, just below the 'X' used to hide a post, that only appears when the text in a status update is in a different language than my default language. How awesome would that be?
Yes, I know, automated translation utilities suck. I get that, but frankly, I don't care. If the translation isn't perfect, that's fine as all I really want to know is the meaning (and maybe a small chuckle at how bad the literal translation actually is). What I want to know is what is happening with my friends. I don't need a legally binding translation, just enough of a help to keep up with their lives.
The technology exists. The is a known languages section in your profile that could act as a cue to Facebook that you might be posting in languages unknown to all of your friends. Why have they not stepped up to add this functionality?

Truth be told, its likely an edge scenario. I get that; I have to help business users prioritize edge cases all the time. Yet, its an edge case that can't by any means be unique, especially given the rapid rise in our world's population and the ability to connect with others in this world. These are two trends that will do nothing but continue to increase, so its is not that this is an area that will disappear with time. I am simply surprised that Facebook hasn't noticed it yet and implemented a resolution for the problem. It just seems right up their alley.

What about you? Could you use autotranslation, even if it is far from perfect, inside of your social networks? What other use cases is Facebook missing (besides useful privacy controls; I think that one has been beaten to death)?