Is your organization really that fast-paced?

High-tech companies (and other companies too) publish some indicator numbers from time to time. Those indicators can be very meaningful to shareholders, financial professionals, investors and so on. However, these numbers mean (almost) nothing to the company’s prospective employees. Knowing the stock prices won’t tell you anything about company internals.

Let’s say you’ve got to choose between two job offers. To take money and challenges off the table, let’s just assume that both companies are paying around the same and the work you have to do, seems pretty nice at both places. How do you choose? The only thing you can really rely on is the information you gathered during your interview rounds. Maybe helpful, but way too subjective. What if there were some truly objective indicators out of which you could guess how well-organized the team you’re about to join really is? Would it help you if you were provided numbers like:

  1.  How many days does it take, to get your environment up and running? It can take enormous amount of time to get all the access rights, accounts and many others. Which also means, that during that time you may be completely blocked – trying to get past your 8 working ours per day being bored is sometimes more tiring than actually doing some busy-work.
  2. How long does it take for a new employee to become productive? Most of us like to produce solutions as fast as we can. It could pretty much destroy one’s self-esteem to wait for 2-3 months to actually get something done. Going one step further, this metric would even be able to reflect on some aspects of internal processes (for sure, with pair-programming one catches up much easier with the new technologies and architecture).
  3. How long does it take to test a release? Is it just running a comprehensive test-suit that takes at most a few hours, or do testers have to manually click through the different test cases over and over again?
  4. How long employees stay with the company/team? 

To me, these information would mean much more than the usual “Forbes 500”, “Dynamically growing”, or “fast-paced” stuff. Too bad such metrics are almost never collected. Some companies could easily drop the high part from the high-tech attribute.

The super TDD pen

Today I have introduced my colleagues the “Super TDD Pen”. As I’ve mentioned earlier, most of these guys have never met agile, test first, scrum, kanban etc. before, so they need to practice and practice and practice even more. The most important thing before we start implementing business logic, is to catch up a bit with test driven development. In order this to happen, I take different approaches: organize code katas, discuss agile design values, send them articles to read, and the newest: The super TDD pen. It is nothing particular, just an ordinary marker we use to annotate tasks solved in TDD. I also updated the DoD (definition of done) to contain a reference to the red pen.

I considered it important to present the pen at the time only GUI mocks and prototyping tasks are present on the whiteboard. Of course, one can argue there is not much TDD involved in this phase of the project, but anyway; I hope they get a bit frustrated by the lack of red pluses, so they start writing code test first.

On the other hand, it will be a good marker how widespread TDD is in our project. I also plan to analyze task PostIts on a regular basis, so we can see the progress we make. I hope to see we are getting better at it, so we can place more emphasis on other important things too.