Tag: consulting

Working Two Clients

I find myself in that not-great-but-necessary position where I’m working with two clients at the same time.

The deal is – one project, A, is winding down.  There’s an (unknown, but getting clearer) picture of the amount of testing that needs to happen.   And my other client, with project B, really needed something changed (prior work) before June 4th.   At the time we said yes, it looked like A would finish in the middle of May …

Here I am.  Both clients know that I’m working with them part-time, and that I have the other client whom I’m also doing work for.   Both are excellent business partners and are easy to work with.   No problems!

However, I’m left with having to juggle tasks between the two of them.  How and when do I switch?

My answer is, I use a modified Franklin Covey Planner system.  I thought I could easily find a link to something that explained it, but I couldn’t, so I’ll just lay it out.

image

  • I divide the page into my two clients.
  • I make a list of everything I can think of that needs doing, whether urgent or not.
  • I figure out the A priorities.  These are things that are critical, MUST be done today, or at least very time sensitive things.
  • Then the “B”’s – important stuff, like do-this-week kind of stuff.
  • Everything else is “C”s, or (gasp) D’s, which I might never get to.
  • At this point I deviate from the Franklin system, and I add some other prefixes:
    • W = things I’m waiting on.  
    • Q = things that can happen quickly, like in a pomodoro. 
    • T = things that happen at a certain time.  Ie, i don’t have a choice of when to do them.
  • I then go through and assign priorities.. A1..N, B1..N, etc.
    • In general, if its more risky, i’d give it a higher priority.
    • If it affects more people, I’d give it a higher priority.
    • I’ll put the Q’s before the non-Q’s.   Because crossing more things off my list is better.

Then, here’s the two client bit:

  • I always do A’s cross-client, switching context as I need to.
  • Then I settle down on one client till my next big break, like lunch, perhaps .. work on its stuff.
  • Big break – lunch – or visit the Gym just down the street.
  • Resume with other client.

I don’t try to hide from one client if I have an “A” to go work for the other client.

Another hack I’ve found is, instead of using Pomodoro’s with an alarm, I’m using them with 25-minute playlists (from either Spotify or Amazon Prime).  When the music stops playing, its time to wrap up the current thought and take a micro-break.  I have tried Richard Franklin’s “Music to Code By”, but I seem to be doing more EDM now – stuff like Gold Panda, Tycho, etc.     Thank you Amazon Prime Electronic Betas for Work Playlist.

Developing as a Team

Update: This entry was re-posted on my company blog, here:   http://ignew.com/2013/02/16/developingasateam/  — with some updates.   

In October, I started on my current project as a solo affair. In November, we went up to 2, and then shortly afterwards 3 developers, and we had to figure out how to work together effectively.

I’ve had some good experiences in the past working as a team, and some bad ones.   I was eager to try to craft a good working experience, and with the help of my colleagues, I think we mostly succeeded.  We just did an internal presentation to my company on the subject, so now it feels right that I can blog about it.

We started collaborating on Campfire

At one person on a project, well, there’s just myself and myself.  Not much to do there; I can email the customer questions, I can save the emails I get back for stuff that’s important.

At two people, I can communicate with my teammate over IM (if they’re in), or yell across the hall.    Maybe try to maintain a wiki, and forget to do it.   Very often, one person takes primary in client communication, and the other person takes secondary.

At three people, things get a bit different.  Multi-person IM can be a pain.   One primary and two secondaries leads to a lot more communication overhead for the primary.

Enter Campfire.   http://campfirenow.com/

With Campfire, communication can be asynchronous – as long as everybody agrees to check the history of campfire to see what they missed.   We can work on different schedules.  (Its still more fun when we’re on at the same time).

  • Campfire became the place to start asking “I wonder if the customer meant this or that”
  • Campfire became the history of the project
  • Campfire became the place to state what we were working on, and to trade pieces of work (“while I’m in there, I could take care of xxx”)
  • Campfire became the place to let everybody know if one was working from home, or the office, or other
  • Campfire became the place to paste code for a quick code review
  • Campfire became the place to share cute jokes, and side technical things, as we got to know each other more

Note:There are many alternatives to campfire; that’s just what we used.  IRC is how we could have done it in the old days, although it would take some setup to get the history to save.

We centralized our communication with the client via Basecamp

If we had a question to ask the client, we would use a basecamp discussion.

  • We would create a discussion in basecamp, with a subject of “Question: xxxxx”, and the body being the question.
  • We would “loop the client in” (specifying their email addresses) to the discussion.  The client folks would get an email with the discussion thread.  We would also add ourselves to the discussion.
  • When the client responded, it got automatically added to basecamp, and we got notified by email.
  • Once the question was answered, we would rename the subject to “Answered: xxxx”.

This gave us:

  • A central place where we could see “what decisions had been made”
  • An easy way to figure out “what has not yet been answered”

I would recommend this even for a single person working on a project, because of the second bullet point.

Once again, I’m sure there are alternatives that could be used here; although I’m not sure which ones would provide a way to log customer responses with such ease, while presenting the questions in a format that they would easily understand: email.

We collaborated on Google Documents for Digesting Requirements

Wen we received the equivalent of 15-20 pages of requirements to digest and estimate, with links to external resources (mockups) and other “stuff”, we floundered for about 2 hours.  This was our (eventual) solution:

  • One of us pulled ALL the information into a SINGLE document, in Google Docs.
  • We individually went through the document, adding comments at places that we had questions, highlighting things that we found interesting, etc.
    • In reality, we did this together in almost- real time.  Maybe not on the same page, but I could see my teammates putting in comments, and I could even respond to them, as we all looked at the document together.
  • We then sat down face to face (although we could have done it over a phone call), and walked the document from top to bottom – everybody talking about the stuff they found interesting, how they thought it would affect the architecture, etc.
  • We then created a spreadsheet, and started filling out the “details” of the work.  We all collaborated on it as we were typing it up:
    • By the time we left that document, I *knew* that we all agreed on the same way to do the work, and the architecture.
    • The breakdown was more rigorous than I could have done myself (everybody’s rigor got UNION’ed together)
  • During the collaboration process, we also figured out the how to divvy the work up.  In this case, we decided to have one spearhead doing UI work, and another one coming up behind and connecting the UI to the underlying layers.

Google Docs is just what we had available to use at my company; One could also edit office documents in SkyDrive in a similar way.  As long as you can see what everybody is doing in real time, this works.  

We Used Planning Poker and Google Spreadsheets To Estimate

Example planning poker cardsOnce we had a work breakdown, we would use the planning poker process to figure out Low-end and High-end estimates on the individual items.

  • We did this face to face with a real planning poker deck, once.   (Thank you Microsoft)
  • We did this online, in a google spreadsheet, once.
    • We hid the numbers with white-on-white, and ran through the spreadsheet, and called out “done” when we were ready.
    • We revealed all the numbers
    • And then visited line by line to find any differences.
    • Sadly, our estimates were way off – high – but I don’t think it was because of the process.

Beware, with multiple people, you will get a higher number. This is because those who are more sure and bid lower, give in to the folks who bid higher.

We started collaborating on Google Documents for Demo Notes

Our process involves a weekly demo to show the client where we are at.     These demos were on Friday’s at 11am.   Thus, usually on Thursday night (Depending on who got to a stopping point first), or on Friday morning, we would create a “Demo Notes” document

  • We had a “team level” update which was usually put together by the “most chatty” of us. (me)
  • Each of us had a section, which we would fill out – of the stuff we wanted to show the customer, that we had gotten done.
    • We each had a different level of detail.  That’s fine, and in time, comes to be something we celebrate.
  • In each section, we had questions set aside like this, of stuff to ask the customer.   It was clear that there was an answer missing, there was a spot to type in the answer.
    • Question:  Why did the chicken cross the road?
    • Answer:
  • We could have added a section on “pending questions”.  Our client was excellent in responding, though, so we didn’t need to.
  • At the end of the document, we added a “Decisions” section.

During the demo:

  • We would openly share the demo notes document, using it as an agenda.  Whoever’s screen was being shared with the client, the client would see the demo notes somewhere in there.
  • As one person presented, if the client had feedback, or answers, another of us would take notes on their behalf.
    • It gave all of us a job.  With three of us on the call, we had two people listening in and ensuring that anything that was important got captured.   We helped each other.  We came to trust each other in a very “you’ve got my back” kind of way.
  • When the client stated something that was even a bit complex, we would type it into the demo notes, highlight it, and ask: “Did I capture this correctly?”
  • If decisions were made, we added them into the Decisions section.

Soon after the demo:

  • We would scrub the document (a little bit), to clean up the mess that sometimes happens during the demo.
  • We would export it as a PDF and email it to the client.

After the demo:

  • If something was noted that we needed to take care of during the demo, we would add it as a “TODO: xxx” in the demo.
  • When it was done, one could go back to those demo notes, and change it to “DONE: xxx”.  (we didn’t all do this; maybe it was just me – but that’s the beauty of a live document, it can represent “now” rather than “at that time”).

We started sharing administrative tasks

In a past team environment, I made the mistake of “volunteering” to be the only person who did administrative tasks, like merges, status updates, etc.  I was “team lead”, after all, wasn’t I supposed to do this?  In doing so, under the guise of “protecting” my teammates, I signed up for all kinds of pain.

In this incarnation, we’re going with the philosophy “Everybody is capable of, and willing to do, everything”.

The first part, “capable”, meaning:

  • If there’s something that one of us doesn’t know how to do, we’re willing to learn
  • We don’t have to be awesome at it.   As long as we can get it done well enough to move the project forwards.

The second part, “willing”, meaning:

  • Nobody has to be saddled with exclusive pain.
  • I know my teammates have my back.  They are capable and willing to take on my pain.

So, we’ve ended up at this:

  • We have a round robin order, for the weekly administrative tasks:
    • Preparing and sending the Weekly Status Report
    • Sending the Demo notes
    • Updating the Project Burndown

Additionally, we started doing automatic merges from the parent branch into our branch.   At first, we tried a “weekly” approach to it – but that ended up being WAY too much pain in a week.   So, if we hit that again, we might be doing a “its your turn today” round robin approach instead.

We started using Google Docs for Status Report Documents

The person saddled with the status report, would create the document, and look through our time tracking system / the commit log to see what people did, and take a first stab at the contents of the report.

Then, they would invite the rest of us in to the report.  We would update our individual sections, and add a “sign off” at the bottom of the document.

Once the document had everybody’s sign off, it got sent.

There’s More To Learn

Even with all of the above awesomeness, we have room to grow.    My teammates will probably either groan or cackle with glee when they read this, but here’s what I’m thinking:

  • There are other admin tasks we were lax on.   These could be added in to the admin-task-monkey’s list of stuff to handle.
  • We might start writing test cases together.
  • We might start running each other’s test cases [more often]
  • We might use a better way of breaking down the available work – in such a way that more than one person can get their feet wet in a feature.
  • We’ve now invited the client into some of our collaboration – might learn some things there.

The underlying thing is that we were willing to do what was necessary to have a good team working environment, and we did it.   And for that, I am grateful.

Software Estimation Review #1

One of my recent projects had this burndown:

At the start of the project, the “desired” hours were coming down at the speed of the “high” estimate.  If I had used the first 5 data points to predict the end of the project, it would have been near T=7, at a cost of 6N or so, and the estimate was only for 5N.   Not good.

Luckily, things started to sort themselves out as the project progressed.   However, I wanted to understand what was going on.

At work, I track every slice of time at a project and “top level task” level.   I also note down what exactly I’m doing (and usually its outcome – success, interrupt, break, etc – especially useful if there is fragmentation, you can see how interrupted you were – a metric to show pain).

I exported this detail into Excel, and created an item by item grid of time taken for each line item  in the original estimate.

In the process I found several items that I worked on that didn’t have a home in the estimate, and I got “actual hours worked” for each of the line items.   It was shocking.  Here is an abridged version:

  • I saw tasks much larger than the original estimate.
  • I saw some tasks much smaller than the original estimate.
  • I missed several features.
  • I left out entire categories such as refactoring (as the project grows), documentation,  styling and usability.

Possible Interpretations

I did well.

The project was done within the time allotted.  This was a success.  Perhaps the individual line items were not, but the overall project was – I was lucky that I overestimated several items.  If I had tried to squeeze every line item, I would have been in trouble.

Could more Up Front Design yield a better estimate?

The Waterfall thought would be I didn’t do enough up-front design.  However, I spent longer putting this estimate together than I should have – because in this job, putting together an estimate is not billable time!  If I had spent more time on it, I would have had more line items – yielding a higher estimate – yielding a greater risk that the client would not approve the budget – and I would have still gotten it done on time – perhaps even less time.

I have done this before = takes less time

I had previously done a similar project.  As a result,  I estimated several items fairly low. Examples:

  • 5 to 8 (actual: 23)
  • 5 to 7 (actual: 12)
  • 5 to 7 (actual: 14).

This is equivalent of an handyman stating: I’ve built a house before, so hanging drywall won’t take as long.   Incorrect!   It takes time to build software, even if you know exactly what you are doing.

 “Sure that Technology will be easy to integrate”

My coworker (on loan to me for two weeks) spent a lot of time trying to get a grid to work correctly.   Actually, the grid worked fine, the helper classes to interface it with MVC did not.     Trying to get them to work took the majority of the hours on one of the pages.

In the end, he scrapped the helper classes he had downloaded – they worked only in specific circumstances – and rolled his own – and coded the rest of the page in record time.

I’m not sure which way to go on this.  Perhaps having a bucket of “research” hours?    Timebox the items that we research to save research budget in case its needed later?   It seems every project I’ve been on, there’s been one or two things that took some time to get the approach figured out.

I left out parts of the project from the estimate

There were several items that I had not estimated up front that are a part of any project.  See below for a running checklist.

I skipped parts of the estimate

Some functionality turned out to be trivial, or unnecessary. For example, we went straight from a grid of Endor to editing Endor without a stop at a detail page for Endor.   Or, one of the setup pages – thought to be three seperate pages – collapsed into a single grid.

These “mistakes” are what saved the project.

Overall Analysis

I think my mistake was trying to specify everything in the estimate at a line by line level.  As DPR207 at TechEd 2010 pointed out on slide 16, there are different levels of uncertainty as a project progresses.  I was estimating at too granular a level too early – guaranteeing I would miss items, as well as specify some items that were unnecessary.

Doing it Differently

In this particular project, how else could I have estimated it?

Agile, Story Points, etc.

Using Story Points and approaching a project in an agile way (Scrum-like) are my favorite ways of handling project estimation and management.  However: In my role as consultant, with clients pre-approving blocks of hours (based on a high end estimate), I don’t get to do that.   So I’ll pass on that solution.   I HAVE to have a number of hours up front, or I need to find a very understanding client.

Estimate at a higher level

Rather than estimating at a very detailed level, I could estimate in bigger chunks like this:

Level 1: Systems “A Website”“A Batch App” 50,100,150,200,300,500 hours
Level 2: Functions / Features / Pages Grid of FooEditing Foo

Selecting Bars for a Foo.

Reading in an xxx file.

Validating xxx information

 10-20, 20-30, 30-50 hours

Fibonacci Numbers

I will definitely continue using Fibonacci numbers for estimation.  It saves me brain power – Its either a 5 or an 8.  I don’t have to argue with myself whether its a 7 or an 8 or a 9.

I use a slightly modified sequence:   0.5, 1,2,3,5,8,15 … somewhere in there, I jump into adding zeros:  5,10,20,30,50, etc.

Going Forward

Jim Benson (@ourfounder) gave a presentation at CodePaLousa: “We are Not Engineers“.   (I tried to find a link to a powerpoint, and then I remembered, it was truly a powerpoint free presentation. I did find similar materials here)  The gist of the presentation was:  “Humans are horribly designed for doing estimation”.   If I estimate based on gut feel, I’m going to be wrong.   Thus, for my job, I either need to stop estimating, or start to build a toolkit.

This is the toolkit so far:

Keep track of all time and match it back up against the estimate at a line by line level.

It takes about 15-30 minutes to export from Harvest and match things up in Excel.   Its a form of instant feedback.

Estimate in larger chunks.

Rather than counting the number of fields on a page (which is what I did previously), I need to find the average time to write a page, and then double it if it’s a big page.    Try not to estimate in anything smaller than, say, 10 hours, for a chunk – a page, a file processing feature, etc.

Keep a checklist

My checklist at the moment:

  • Initial project setup
    • Machine setup
    • Project setup – layers (DAL, etc) – into SVN
    • Stub version of project that can be deployed
  • Test data strategy (in support of integration testing)
    • Test data creation and deletion
    • Setting up automated integration tests to run automatically
  • Individual Items (Project specific)
    • Larger chunks
    • Include testing time for each item – writing unit or integration tests, and testing by hand.
  • Growing pains
    • Refactoring is inevitable (and not specific to any particular item)
    • Configuration and Deployment (as the project enters different environments)
    • Merging between branches if branches are called for (any time there is a phased release, or a separation between UAT, QA and DEV)
    • Necessary Documentation (after complicated things get done)
  • Project Management
    • Dependent on each client. 10%  of a 35 hour week = 3.5 hours of email, status updates, demo prep, and demoing – which is about right for a good client.  Other clients, the number has been closer to 20%.
  • Research bucket
    • For the unfortunate item(s) that will pop up that just don’t work
    • Also can be used to take extra care to simplifying something so it stays more maintainable.
  • Usability, Look and Feel
    • Cross browser testing
    • “Making it Pretty” – fonts, colors, grids
    • “Making it more functional” – renaming things, page organization, number of clicks to do something
  • I18N and L10N
    • Dependent on client and project.

The Request

How do you estimate your projects?  How close do you get?   I truly want to know.  Shoot me a comment or write it up and add a link.

What do I bill?

My first client in the consulting world at my current gig was a big company.   They welcomed me spending all kinds of time, including overtime, to get their product built faster.  They were also using somewhat older technologies – VS2008, VB.Net, WCF/SoA, a hand written DAL, no BOL – to get the work done, and as a result, I knew pretty much what I was going to do.  There was no “play” time needed.

My second client, is a small company.  Every hour counts.  The less hours, the better.  Its also entirely up to me how to build it – so, how new do I go?

  • I could use all the cutting edge stuff that I don’t know fluently, charge the client for me learning the hard way.
    • This seems unethical.
  • I could stick to older stuff that I do know.   Only sell the client the skills I’m awesome at, and spend time to bring some skills up to awesome.
    • It takes a lot of extra time to become awesome at things.
    • As I have a family i like.. this is impractical.
  • A mix of the above.
    • How?
My Employer’s Solution
They have set it up so that I am “salaried” at 36 hours.. and I have an extra 4 hours to do a self-directed project.   During this time, i can become awesome at stuff I don’t yet know!  And it doesn’t have to be related to any current or future project, just stuff I want to figure out.
(I have a huge list of things I want to play with and get working…)

My solution

I have partitioned my list into three sections:

  • BUCKET A: The stuff I know how to do fairly well
    • Architecture decisions
    • Project management
    • Console app, Parsing command line options
    • Setting up diagnostics in various places to make the utilities easier to use
    • Database design
    • Setting up local test data environment
    • Research into options available
  • BUCKET B: The stuff I don’t know how to do yet, that I will definitelyhave to learn.  I do charge for this, and try to get it working as fast as I can.
    • Fluent NHibernate + NHibernate
    • MVC3.  I am NOT going webforms, sorry.
    • Dealing with ENUM’s in PostgreSQL  and mapping those to enum’s in C#.
  • BUCKET C: The stuff I need to play with to figure out &  use, but if I don’t figure it out immediately, I can get by without it.
    • SpecFlow / BDD
    • fastest way to setup- and teardown  data in the database for functional/integration testing
    • Selenium

Then, its not that I stay away from Bucket C, its more that I focus most of my time on Bucket A… till I feel i’ve been productive..  then B, and then maybe C.

I also timebox bucket C.  For example, i researched Specflow today, figured out that yes, i want to use that.. and then I cut that off at 0.5 hours.  The rest of my specflow “play” time will be “on my own” – until I get it working enough that I can move it down into Bucket A.

This gives me a clear conscience – I’m not charging the customer for playing/learning  stuff that was not required – instead, i realize that with any new technology, there’s going to be some “settling” of it into my toolbelt, and that does take time.  I cannot “rush” that time – so I’ll do myself a favor, and not pressure myself into learning it quickly.

For that matter, I timebox bucket B as well.   For example, I could not get C# enums to save as PostgreSQL ENUM’s in about an hour of trying.  I had a workaround – save as TEXT.  I went for it – can revisit this at another time.

How this works at home

Hanging out with my wife is one of the joys of my life, and I do not shelve that easily.  Luckily, synergistically, My wife had dinner with friends today, so I was able to make tonight into “tech playtime”.   I combined playtime with  bringing my VMWare work image home on an external hard drive – and that worked beautifully as well.

My next chance for evening tech playtime, unfortunately, may not be till next week. But, if I can get ahead of my required hours at work, i might convert some work time into play time.    Getting in to work early means I can do playtime starting at 3 or 4 pm!