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.

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?

Task Based Time Tracking

Found another interesting post today, Task Based Time Tracking: Redux. Just wanted to mention it on my blog as our app (see the recent Basecamp integration) aims at a similar goal – simplifying task based time tracking by making it visual. Also I think this term “task based time tracking” is quite handy.

-Enjoy

Simplicity in adding todos enables better project management

A while back I posted a digest/review of a research paper on the theory of project management. It was an attempt to make it easy to read but I think it may still look like it is too much to digest. So I want to pick it apart more and discuss here just one problem:

The current model is basically represented by a non-cyclical network graph in which each activity connects directly into its immediate successors.  Such a model fails to account for uncertainty in production process, which affects time as well as interdependencies between tasks.

So the the non-cyclical network graph model (think MS project / GANTT chart model) is a big flaw by itself. So much of our work on projects is cyclical actually. You worked on a task and then you worked on it more, and then someone found a bug, and you worked on it again.

The bigger challenge is the fact that new tasks come about every day and the graph constantly changes. The creative process of working on a task or collaborating with others will produce more intermediate tasks, guaranteed! To make your project status visible and clear you have to somehow keep capturing all these new tasks. I don’t think there are very good solutions available for this.

As these new tasks come and go, a bunch everyday, the key to capturing them would be the simplicity of entering them into your PM system. Very few systems made it simple for people to do that. One good example is probably 37signals’ Basecamp, their motto is simplicity and I think it really helps in capturing these “newly born” tasks. Although this works only if your whole team is very disciplined, as it still requires a login into the project portal every time you need to register a new todo.

I believe a better way would be a close email integration. So many of these “newly born” todos are communicated in email to begin with. So, that is where you need to capture them right away, without requiring to log into the project portal throughout the day and typing the same data one more time. I even think MS Outlook/Entourage got it, as they have implemented ‘follow-up/todo’ flag for email messages which turns them into tasks. But I am quite unhappy with their implementation. I don’t like one-to-one message-to-task relationship. Plus once they have created all these tasks they have not provided a convenient way for people to plan and manage them, in my opinion (well, they really want you to use MS Project for that).

I think you need to have a desktop app to implement the convenient email integration. Basecamp does not offer much in this regard as they are purely web-based plus their view on email integration is different.

What we have done with Yoxel PCM is we first have separated the following two concepts: requests and tasks. Requests are what is communicated in emails (people asking you to do something or you ask them to do something, deliverables really), and tasks are personal todos (what you think you need to do to satisfy the request, what you plan to come up with request commitment dates).

You really want to manage a whole conversation (email thread), not isolated messages (not every email is a request requiring a task), to identify requests in it and track them. Conversations usually go though these stages: started, exchanging ideas, request identified, owner identified, planning&committing, work collaboration, done. Neither MS Outlook nor Entourage allow you manage the whole conversation from start to finish. I think Google Wave was on the right path though. Then you link your personal tasks to the conversation (to the request discussed in the conversation for which you’re responsible). Well, this makes more sense to me. It makes it easier to trace from task to request/deliverable to conversation and back. Also as you focus on conversations rather than individual email messages this allows to organize them better and move the multitude of the messages exchanged under the umbrellas of the conversations (think GMail email threading).

I dont believe email is going away, I personally like the distributed email model very much. I just think new generation email management systems need to be developed to provide better collaboration experience.

-Cheers

Continuous Re-Estimation

If estimate is a guess then we are for continuous re-evaluation of the guess. What I do is continuous re-estimation of my tasks. Usually as we work on a task it becomes clearer what really needs to be done, we get more familiar with the problem, so every day we can mark what is done and re-estimate the remaining work. This means that for all your tasks at any given time you will have the best guess. Can you do any better than that?

Working On Tasks In Between Meetings

Whether meetings are harmful or an alternative to working they do take place. We all probably have one or two meetings this week, entered in our calendar by ourselves or someone else. My observation though is that most people do not track these scheduled meetings when estimating time required to complete tasks. Although I think it would be quite useful. Functional team members work on their tasks in between meetings so the more time is taken by meetings (let alone the time spent on context switching) the less time you have to work on your tasks. So at minimum every meeting pushes out your schedules.

What each of us on the team does for estimating tasks is he uses our visual work-hours calendar. The calendar defined by your work-hours time profile (i.e. Mon-Sat, 9am to 5pm, minus 1hr for lunch) shows only your available work-hours. Additional per day adjustments to the initial time profile make it quite flexible:

1. Any meeting hours scheduled in your Google or Outlook Calendar are cut out from your work-hours calendar automatically (you don’t work on your tasks in the meetings).
2. Some days you work more hours than the 8hr time profile, and some days less. So any day in the calendar you can be adjusted by +-Nhr. You usually do the adjustment for the day that is ending (at the end of your work) to reflect how it actually went.

Keeping the accurate trace of how many work hours were and will be available could add more clarity to estimating and communicating on schedules and commitments. It could also serve as an explanation of why schedules are slipping, the next time your manager asks you (because he set up all these meetings). Plus, next time a person setting up a meeting for you may find out that his own task shifts, because it depends on your deliverable. Just another reason to think if requesting that meeting is really necessary.

Not yet another web-based PM tool : “early adopter” build #184 is available

There is abundance of web-based project management tools on the market. Most probably your organization is using one of them right now. How successful though? Have you noticed that most of the project collaboration in your organization is still done through email? That people are reluctant to log into the web portal every time a new task has popped up?

Seems like email (and chat) is what people prefer to use for communicating deliverables and concepts. It is email’s flexibility and accessibility that allows people to be more productive.

So Yoxel PCM is not yet another web-based PM tool forcing somewhat rigid web-based collaboration model on teams, it is a desktop application (Rich Internet App – RIA) that leverages the flexibility of the email and provides enhanced experience more suitable for managing projects.

We have just released the next “early adopter” build with a very useful “multi-owner” request capability. That is when you send a request (email basically) to a group of people and several of them can become responsible for the request. Yoxel PCM now can track progress status and commitment dates of all the owners. This is a capability you will not find in your MS Outlook and it has been asked for by a number of our users.

Read more about this build here.

Enjoy.

Integrating email into your project management processes

Last couple of months we have been working with a number of early adopters of our new Yoxel PCM product. The feedback that is coming is extremely useful.

The updated version of Yoxel PCM (build #100) with the following enhancements is now available for launch from http://yoxel.com:

1. Simplified configuration of new email accounts:
   • Auto detecting IMAP/POP/SMTP account settings for addresses hosted by GMail, Yahoo, Hotmail
   • Retrieving MS Exchange account settings from existing Outlook configuration
   • SMTP accounts now added/edited in the Email Account editor
2. Requests View:
   • GMail-like ordering added (by last comment received in the request channel)
   • Flag icons added to show requests associate with tasks
3. Request Channel (Email Chat):
   • “Need response” mode added
   • Highlighting messages in the chat window to differentiate senders
4. Improved time profile editor:
   • Day editor allows changing default number of work hours
5. Calendar View look&feel:
   • Various decorative effects added for cursor, tasks, checkpoints
   • Day time profile correction information is made visible
6. MS Exchange integration:
   • Identify “follow-up” flagged messages as ‘incoming requests’

Now, that the version is more stable we’re opening it up more:

• The free “IMAP-only” version can be launched right away from the download page.
• It is also easy now to launch the evaluation “IMAP+MS Exchange” version from our support portal.

Take project related email under control

Here is another video tutorial for Yoxel PCM that shows how you could start managing requests communicated via email. Let Yoxel PCM pick them up from your Inbox and track; associate with tasks and figure out an accurate completion date; communicate a commitment date back to the request originator (http://yoxel.com/task-management.html).