Every engineering organization or company has their own unique way of doing things. Companies tend to start with processes and tools that are well known (e.g. Scrum, Kanban, Github-Flow, etc.) and perhaps tweak them to meet their specific needs and/or temperaments.
Eldarion has done more than just tweak an established process.
We build sites and apps for ourselves and for our clients. We are globally distributed amongst a host of different time zones. Also, while there are full time employees, we are significantly augmented by contractors who can have a good bit of variability in their availability.
This is a challenge to deal with in terms of engineering efficiently due to the organizational variability. However, this model allows us to recruit and retain the some of the very best talent this world has to offer.
=== People Are Not Resources
We are not a "body shop".
There is certainly a time and place for technology staffing, but that is not what Eldarion delivers for clients.
We are structured around delivering value in the leanest and most agile method possible.
Each team member brings a unique perspective and set of abilities to the table. While no individual is ever irreplaceable, there is not a single person who will deliver value in quite the same manner—not better or worse, just different. As such, we take great care in planning and fitting a project team together for the best match of what needs to be accomplished, and this project team can vary from week to week depending on project needs.
When it comes to people, we embrace variability.
=== Structured Variability
With all the moving parts of what has been described thus far, it's important that we do have some structure in place to manage the variance. The most important thing to structure and attempt a reduction in is the variability of scheduling and availability.
Coupling so many timezones and availability constraints with our matrix of active projects (each having their own budgets and constraints) is not child's play. That said, we have devised a system that we believe works quite well.
Each week, the team leads and myself plan the following week. We start by creating a "pulse" for each project for which we have commitments. We then set a target number of hours for that "pulse" that we either think is required for the commitments and/or is in line with the client's budget.
This gives us an idea of what the required hours are going to be to roughly meet our goals for the upcoming week.
Looking at a grid of developer availability across four roughly 3-hour timeslots for each day of the week, we can get a sense for the final stage of the weekly planning—matching talent with project needs.
Generally most people have pretty consistant patterns of availability (e.g. Contractor Bob will be available for 2 of the 4 daily slots on Monday, Thursday and Friday). Except for ramping up a developer on a new project, we try to keep project switching to a minimum. So we usually will repeat a lot of the previous week. However, when there is variance, like a developer has more/less availabilty than last week, it's easy to spot where something might need to be made up and who is available to help.
A lot of this is made simpler and reduced down to just a few clicks through our internal project management and communication tool that we call Beacon. Weekly planning generally only takes us 30 minutes or so to have everything planned out.
When we fail to plan a pulse for a project or assign the time slots and instead just plan to wing it, we end up wasting a lot of time. This is very similar to how not budgeting one's financial resources can lead to a lot of wasteful spending. It's better to allocate and spend your time on paper before that time evaporates.
=== Achieving Focus
These four 3-hour time slots per day that I mentioned in the previous section, are what we call "containers". The concept of a "container" is nothing new and a lot of the inspiration for them comes from the Pomodoro technique, but instead of 25 minute blocks of focus for small tasks, these are larger 3-hour blocks of time (often split into 1 or 2 segments) for focus on creative activity and problem solving.
A typical container is giving the developer permission for heads down uninterrupted time to focus. There are no meetings, no expected response to Skype or IRC messages, no email. No interruptions, period.
Ideally, the container is at least broken into 2 segments, if not 3, with a small 5-10 minute break to walk around, stretch, get a drink of water, etc. Not so much of a break that you lose momentum, but enough to avoid cramping or repetivie stress injuries.
Multiple containers should be seperated with longer breaks between them, maybe to go sit down with someone and have a meal, go for a run, take care of some email or catch up on Twitter and IRC. Developers just need to take care that if they are ramping up for another container after their break, they shouldn't allow activities like requests via email and IRC to steal their focus (of course there are always warranted exceptions).
The container's purpose is to keep Maker time sacrosanct. Manager and other admin time can be done at the edges or in place of plannend containers.
=== In Summary
Our focus is small, high-quality, incremental change. This ethos is at our core in how we approach any work that we do, whether it be for ourselves or our clients.
We accomplish this by starting with the very best Makers in the industry, giving the the freedom and permission to deliver excellence, and manage the variance in scheduling and project requirements with time-chunking in our pulse planning and container allotment.
This is how we help you go from Idea to Launch, Faster.
Contact me today at [[mailto:paltman@eldarion.com|paltman@eldarion.com]] so we can discuss how Eldarion might help with your next project.