Yoxel Personal to synchronize your tasks

 

 

Our user has commented nicely about Yoxel Personal sync in this Basecamp Answers thread (see last comment)  https://answers.37signals.com/basecamp/2534-outlook-task-integration

Just want to add here that we can do the same now for Zoho Projects: http://yoxel.com/zoho-project-management.html  Huddle connector is also coming.

Plus, we’re testing our contacts sync for Highrise and Google app: http://yoxel.com/highrise-synchronization.html

 

 

 

 

 

 

 

Is Your Inbox Overflowing?

I ran into this article today, It’s time to deal with that overflowing inbox, which re-iterates what we all experience with email today:

1) The growing number of e-mails, she explained, is hampering productivity among so-called knowledge workers who rely heavily on e-mail to get their jobs done and to stay on top of their personal lives.

2) “People with more than 100 messages in their inbox are less satisfied with the quality of their projects, more behind on them, and less likely to know what they need to work on at the start of a workday,”  …

 

And another interesting fact, pointing out that corporate knowledge workers use email alot for project collaboration:

Right now, the average corporate employee spends 25 percent of his or her workday on e-mail-related tasks, according to Radicati, compared to 14 percent on face-to-face meetings and 9 percent on the phone.

The article suggests to clean-up your inbox regularly and delete email.  But that, I think, is the option you’re left with when using your traditional email client. Email may contain valuable data and so removing it regularly just to make yourself more productive is not the best approach. I believe, organizing email better in ways that make it easy to find and know what is important at the moment, is the way to go.

You’ll probably need an additional app for this, or a new generation email client. GMail is a good one, but how do you manage your MS Exchange email with it? Xobni is an app that could help you with that though.  We’re also developing the Yoxel PCM app that will help you manage email threads/conversations better for more productive project management.

Cheers

Email or Email Client?

Great article from 4spires,  Email Is Flawed For Managing Work – Transformation Is Coming.

Despite our collective understanding that email is flawed as a workflow management tool, we are firmly entrenched in its use.  What is needed is a generic solution that mirrors the simplicity and flexibility of email but adds better workflow tracking and management reporting features.

As I wrote in my earlier post, Email vs. social networking in your workplace, I would separate the term “email” as a messaging system/infrastructure (as defined by RFC822, RFC2821 (smtp), RFC2045 (mime), RFC3501 (imap), …) from “email” as email client software for reading/sending/managing email messages, implementing only a specific use model, usually dated 10-15 years ago. And so when it comes to the email clients I really agree with the article, most email clients are outdated and have not kept up with the workflow management requirements so it is obvious that new generation email management apps need to be developed.

Email as the messaging infrastructure is actually quite solid in my opinion and can be leveraged quite successfully by those new generation tools. I am probably quite “old school” but I love email. BTW, see the comment for that article about the recent Skype outage, could this have ever happened to email and paralyze millions communication channels? What I believe is that simple and open wins and email is simple and based on open standards so there could simply be a better email client that is also designed to enhance the workflow management.

I have to admit though that I am quite biased in my opinion because we’re working on a tool like that ourselves. We simply want to leverage the email based collaboration model that most organizations use today (many of which are MS Outlook based). I think most organizations have chosen to use email for a good reason (flexibility, simplicity, ubiquity, you name it …), so lets just go with what already seems natural and enhance the experience.

SCRUM over Email (without a project server)

Here is how you could implement basic scrum story tracking without signing up with any project server, simply using email. You’ll need to use our desktop app Yoxel PCM which scans your email inbox to help you track conversations and identify requests communicated in them.

1. Install Yoxel PCM, connect it to your email account (i.e. GMail), see how here
2. Flag/Star those email threads that represent scrum stories in your email client (or start new ones directly from Yoxel PCM)
3. Yoxel PCM starts tracking conversations that you have identified and also presents them to you as chats
4. As a conversation progresses, requests and responsible persons are identified.
5. Each responsible person marks his/her ownership of a story and attaches personal tasks to it, all in their own Yoxel PCM. All this info is shared with the rest of the To/CC list and everyone is aware of who the owners are.
6. As the owners progress on their tasks they mark their status (active, inwork, complete). As the matter of fact the app can tell the 1st two states automatically. Others, monitoring the conversation, see all these updates.

With this server-less model you dont get to see gantt or burndown charts but you can track all stories simply over email and empower individual functional members to plan and track the tasks associated with them.

Enjoy.

Email vs. social networking in your workplace

You must have seen the Dec 6 article in the SF Chronicle entitled “Transformation of e-mail is under way“, talking about Facebook’s move into email. The last few paragraphs of the article really summarize the message:

That consumer-driven demand is part of the reason Facebook’s first stab at a unified messaging system is noteworthy, said analyst Rob Koplowitz of Forrester Research Inc. Facebook has more than 500 million users, and they are increasingly bringing social networking into the workplace, a trend that has accelerated in the past five years.

With a business communications system built around a social network rather than just e-mail, employees can learn about projects their co-workers are doing or check profiles to find who might have the expertise they seek.

“It’s surprising how much we can share that we don’t share today,” he said. “The tools we have were all designed to think security first, share later.”

The need for e-mail, though, won’t go away, but a program that just does e-mail may not be around in 10 years, he said.

“You’ll still have a messaging engine, but that engine will probably be wrapped around other communication and collaboration technologies,” he said.

This and other articles often talk about email, that as a messaging system it may not survive. I think these articles are really talking about email applications (email clients) that are indeed quite obsolete (MS Outlook, Thunderbird, KMail, Yahoo Mail, take any of them …). Although you probably wont say that about GMail, on the contrary, it is quite refreshing – email threads presented almost as chats to encourage dialogs. I am actually very surprised that Google killed its project Wave which was taking GMail even further in the direction of email integrated with work place social environment.

Anyway, those are mostly email clients that are being blamed for their non-social implementations. And quite understandably, as most of them are >10yr old now. BUT the underlying email messaging system and infrastructure (as described by such protocols as RFC822, RFC2821 (smtp), RFC2045 (mime), RFC3501 (imap), …) are very solid, in my opinion. Many probably don’t realize that the whole web world has pretty much adopted MIME for content definitions, which was originally a standard for email message bodies. And what about the message transmission infrastructure, millions of SMTP servers across the Internet facilitating mail delivery, built to work around line failures and offline situations? I can’t believe we want to scratch all that.

As far as the email client apps go I definitely agree that they need to be updated and re-designed to accommodate new social collaboration needs, we are even building one app like that ourselves at Yoxel. But I am very intrigued with the question of the underlying infrastructure.  It is basically the question of “de-centralization” vs “centralization” . Do you like the idea of being locked in their cloud (Facebook, Twitter, Google, …) for all your messaging and collaboration needs or would you prefer a little more democracy and freedom where you continue to rely on the SMTP based Internet infrastructure not controlled by any one big company allowing a choice of alternative UI solutions (desktop and web-based)?

-Cheers

PS: For those who read the whole SF Gate article: It seems the Bugzilla bug-trackers I used in the past were a new generation social email apps because they sent email notifications inviting me to login and collaborate so I can easily say that they “layer enterprise social-networking on top of e-mail”.

Easy Time Tracking To Enable Activity Based Costing (ABC)

Many large companies are concerned about measuring their business performance. It is not always obvious which departments, projects, products, and customers are more profitable and hence where the company’s focus should be. One approach that is helping the large organizations figure out their profitability is called Activity Based Costing. The model translates resource expenses into costs of basic activities constituting higher level projects and processes and from their derives product/service/customer costs. Such an analysis compared to the revenues generated by the corresponding product/service/customer helps to decide how resources should be used more effectively to maximize profitability.

You can find more detailed explanation of ABC on the Internet, here is just one interesting quote from http://www.asaresearch.com/articles/abc.htm:

Many experts believe that the best method for measuring a business may be “Activity Based Costing”. Some accounting software products such as SAP, Syspro IMPACT Encore, and Deltek offer strong ABC accounting.

The ABC model has a number of problems though that make its adoption quite problematic:

… the process of calculating activity expenses through interviews, observation and surveys has proven to be time-consuming and costly to collect the data, expensive to store, process and report, difficult to update in light of changing circumstances, and theoretically incorrect, by suppressing the role for unused capacity when calculating cost driver rates.

So an alternative approach for estimating an ABC model, called “time-driven activity-based costing,” addresses the above limitations. It is simpler, less costly, and faster to implement. Here is a great paper explaining TDABC and how exactly it is better than the original ABC model: Time-Driven Activity Based Costing. One of the key elements is how you measure an activity, and TDABC seems to be doing this by estimating time required by an activity:

The one new information element required for the time-driven ABC approach is an estimate of the time required to perform a transactional activity. As discussed earlier, an ABC system uses a transaction driver whenever an activity − such as setup machine, issue purchase order, or process customer request − takes about the same amount of time. The time-driven ABC procedure uses an estimate of the time required each time the activity is performed. This unit time estimate replaces the process of interviewing people to learn what percentage of their time is spent on all the activities in an activity dictionary. The time estimates can be obtained either by direct observation or by interviews. Precision is not critical; rough accuracy is sufficient.

I really liked the TDABC paper but I am sort of confused by these two statements:

1. This unit time estimate replaces the process of interviewing people to learn what percentage of their time is spent on all the activities in an activity dictionary.
2. The time estimates can be obtained either by direct observation or by interviews.

I understand that if you have the estimates you do not need the interviewing process. But, how exactly do you obtain these unit time estimates? The 2nd statement says, by interviews. So, do we get rid of the interviews or not? I am not sure what direct observation means exactly.

In any case the TDABC model makes alot of sense to me, and I like the idea of using time measurements instead of purely transactional measurements (10% – activity1, 20% – activity2, … = always 100%). I even think that you can do better than just the estimates. Organizations that use project management tools capable of time tracking could be collecting actual time measurements quite easily (depends on the tool of cause) all the time. Anyone tracking their tasks for PM reasons would automatically be logging time spent on the tasks. All that needs to be done additionally is proper categorization and directing that data into one of those TDABC systems (i.e. SAP, AcronSys, …)

So I am thinking the time measurements earlier generated by interviews could actually be a natural by-product of the PM task tracking process and will not be time consuming at all. A PM product that makes it very easy for people to track time could basically enable ABC/TDABC models for measuring business performance.

What do you think?

 

Here are two more links with more information on TDABC:

http://blog.acornsys.com/The-Acorn-Blog/bid/47380/Why-is-Time-Driven-Activity-Based-Costing-Such-a-Game-Changer

http://www.entrepreneur.com/tradejournals/article/168435559.html

 

Desktop Disadvantage

Mobile applications flourish, and it makes a desktop UI developer jealous. Desktop applications are supposed to have more system resources: big screen size, full-sized keyboard, a mouse, and a fast CPU.  So what?  Two decades after a mouse became widely available it’s still considered an optional device on a desktop. The same applies to every other aspect: screen resolutions vary from 1024×768 to 1920×1200, and screen sizes vary from 10” to 30”. This directly affects user feedback. When recently I made an app that used 48×48 icons, I had complaints that the icons are too big. Come on, iPhone 3 icons are 57×57, and iPhone 4 icons are 114×114! On a desktop, we are still mastering the techniques of making readable 16×16 icons. Another thing I am jealous of is touch gestures. Zooming and scrolling is just natural in touch-screen UI. On a desktop, we have ugly scrollbars and primitive non-standardized zoom controls. Desktop apps must be 5 times cooler than mobile apps because they have 5 times more resources! It’s time to reevaluate the window-based concept of desktop UI. It’s not user’s job to move windows around.

App integration also deserves mentioning. There is no simple cross-platform app integration mechanism on a desktop. Software installation, upgrades, and removal is a pain that users shouldn’t deal with. It’s one of the reasons, I think, why web applications ate the market share of desktop apps. Java and Flex try to address this problem but they have a long way to go. Clearly, it’s the OS to blame here. Linux, Windows, Mac OS all suffer from these issues. I hope the wisdom of iPhone and Android will rub on a desktop someday.

SCRUM meetings – how agile is that?

I have been quite a fan of agile methodologies, I see clearly the benefits of developing products in iterations and taking healthy customer feedback regularly. All in all this really helps you to focus on the product value.

But there is another aspect to these methodologies, which bothers me. Lets take SCRUM for example, and its morning stand up meetings. The more I hear about these, how much pressure they put on team members, how focused they are on making people deliver on their stories ASAP, the less I like them. It feels the main goal here is elevating stress level and pressuring people. The “war room”, the battle culture, everyday. Do you like playing rugby at your workplace? Well, what do you want from a methodology with such a name:

The word “scrummage” is a modification of “scrimmage” (the form of the word previously used in rugby and still used in American and Canadian football), which in turn derives from or is a reflex of “skirmish“. The term was used in the laws of rugby football for a long time before being permanently contracted to just “scrum”.

I can see how this “war room” could be very useful in certain critical short-term situations where you need to focus and deliver something quickly but I suspect that when used all the time this constant pressure will affect productivity negatively. People will get burnt out and start hating their jobs. I hear SCRUM is becoming more popular among all kinds of teams (marketing, sales), not just development. Is this a new way of the corporate management achieving greater productivity? As though I hear them say, “You guys wanted agile, we’ll give you agile. We’re doing SCRUM morning stand-up meeting now!”

To me it smells once again like the old “command-and-control” style of management. Get everyone in one room, make sure they are working on their “sh$t”. And do it everyday as they are so stupid they won’t figure out on their own what needs to be done without this morning “whip”.

I have a feeling this SCRUM thing is killing initiative and creativity in teams. Management in the 21st century is about productivity, but with the focus on productivity of individual knowledge workers, so de-centralization is the word! The workers are smart enough to figure out what and especially how things need to be done. Are these stand-up morning meetings helping them be more productive?

Just hear what Peter Drucker, the guy who invented management, said in 1999:

“The most important, and indeed the truly unique, contribution of management in the 20th Century was the fifty-fold increase in the productivity of the MANUAL WORKER in manufacturing. The most important contribution management needs to make in the 21st Century is similarly to increase the productivity of KNOWLEDGE WORK and the KNOWLEDGE WORKER.”

Providing Commitment Dates To Customers

My customers mostly were very reasonable, they would ask to provide a commitment date for a deliverable right away but would also be ok if we postponed the date later, as long as we communicated the change of plans to them early enough. Their own plans depended on our commitment dates and they wanted to be sure we were not forgetting about our agreements (I am only talking about bugs and enhancement requests here). Sounds like it should be quite easy to satisfy your customer, file all these customer requests in your internal request/bug tracking system and keep the customer informed on the progress. And yet it was really difficult to keep up with this seemingly simple process of providing commitment dates and timely updates.

The first problem was getting a date from R&D. Most R&D organizations are not driven by due dates, they are driven by release plans (where promises to customers don’t always win strategic marketing targets and other priorities). So, you can get commitment dates for the requests scheduled for the next release (1,2,3-6 months from now, depending on the methodology used) but only once the release planning has happened, which means  you get the opportunity to find out  ETAs of your customer requests only once per 1,2,3-6 months. Well, customer is already not very happy, has to wait for so long just to get the commitment. This vendor release based scheduling does not go along with the customer request/commitment based scheduling. Plus, you have waited for 1,2,3-6 months for the release planning to happen just to find out that only 1 or 2 of your 10 customer requests have been scheduled for the release. Well, I am quite disappointed also, I don’t have the commitment date for 9 out of 10 requests and my customer was hoping to find out the dates for all 10.

You could say your R&D needs to use a SCRUM/agile methodology, run 2weeks to 1month sprints/iterations and then they will be able to provide commitment dates more often (every 2weeks to 1month). Agreed, but, how many iterations ahead can you plan without defeating the purpose of the “agile”? Probably not more than 2 or 3, so again the chances are I will still be only getting a commitment for 1 of my 10 requests per 1,2,3-6 months.

So this is the reality, you only know more or less what features you will deliver in your next product release (iteration, if you use agile). As 37signals say “planning is guessing” and your next release is probably your best guess. Beyond that, who knows how requests will be prioritized?

But how do you reconcile this with the customer’s desire to see commitment dates for all its requests even if some dates are meaningless and will be re-negotiated in the future? The customer basically wants our best guess date for all its requests, including those that do not get into the next release. That is a challenge, don’t you think? One may say, “then give them arbitrary date” for those ‘beyond the release’ requests. And may be that is what we should do. Not giving any date is an option too I guess. But I am thinking, can we do anything better for our customer?

So the idea is the following, may sound quite crazy, but I still want to throw it out there. Usually once a request is filed in a request/bug-tracker it is assigned to a developer right away, in most cases to the right developer who will actually be working on it once the time comes and either “blocker” urgency or the release plan says, “go”.  At the moment planning is a prerogative of a few chosen product/marketing managers who plan for the whole team and it may become quite complex, so they can’t deal with more than a bunch of most important requests. But how about empowering everyone on the team to plan? Lets say we give everyone a powerful work-hours calendar (that predicts time-off, meetings, maybe additional statistically derived unavailable time) to plan his/her own tasks. Come on, the requests are all already assigned to the developers, don’t you think they would not be able to stack them up in this smart calendar with their best guess time estimate for each to come up with a reasonable ETA for all the assigned requests? The chosen ones can help the developers with priorities (they know the business goals better) but,  in theory, all requests (and I mean all that you find in your bug-tracker or better all that have ever been asked to be scheduled, not just the subset selected for the next release) can be scheduled easily as long as you de-centralize the planning and let everyone schedule his/her own work. And the ETAs will be more accurate this way, I am pretty sure, because everyone knows their own stuff better.

Now, consolidate all these individual schedules, and pick the top N requests that you want in your release, see where your release deadline draws the line. The best thing is that any request “beyond the release” has been scheduled also and has the best guess ETA. I would really be happy to relay that to my customer, that is the best guess he was asking for all along. What is even better, every time there is a new request in the system it trickles down into developer’s personal work-hours calendar where he/she plans it right away (may be reshuffles a few other tasks to accommodate changed priorities). We have all requests re-estimated and re-planned, we have our best guess for all of them, and the commitment date can probably be shared right away with the customer. Actually the scheduling developer sees right away which commitments he breaks when adding a new task to his calendar. At this point maybe we can re-negotiate the priorities with our customer? That is the power of de-centralization!

I would call this “continuous re-estimation” or ”continuous re-planning”. You don’t wait until the next release planning session, developers re-plan their tasks as soon as priorities have changed or new tasks got assigned. May be you don’t even need release planning with such a model, because you always have your best guess schedules ready and up to date.

What do you think?

Re: one todo list to rule them all?

Just to be more exact in responding to this post “one todo list to rule them all?” , let me list what our app has and does not have:

1. Desktop app syncing to a site and allowing offline work – yes
2. Item prioritization – yes. Ant it is visual, in a unique work-hours calendar, so estimation happens right away also.
3. Main and sub-categories -no. Unfortunately at the moment it is just main categories (task lists)
4. Cross-platform desktop software – yes. It is a java app.
5. Sharing between users or just public access to the lists – yes, if you connect it to Basecamp (in the futute we’ll have our own way of make tasks visible to others)
6. Mobile support – no.

Other bonus points for the app is that it is closely integrated with email and allows tracking of requests communicated in email conversations so it is really easy to manage a thread, identify a request and attach a personal task to it which you can quickly plan/estimate in the work-hours calendar.

Enjoy!