Forget CMSs lets talk about what Drupal is… Drupal is a platform to build anything and everything! no jokes… for the web, mobile, tablets and Smart TVs!
Drupal in a nutshell comes with a core set of modules on installation what Drupalistas call Drupal Core then there are contributory modules and custom modules… its like a car it comes with a minimum set that you can use to drive out of the showroom and go anywhere you like but if your budget allows you can get any amount of accessories added on.. with one difference in Drupal you can build modules to do whatever you want it to do… then you can share it with the Drupal community so others don’t have to repeat the effort or you can hog it!
Drupal’s strength as a framework to build anything comes from its OS nature, an active community and a large set of contributory modules which means most things you can think of doing on an application you can utilise someone else’s efforts in the community to hit the ground running.
So Drupal though started life as a content management system (CMS) it has eveolved to also be a framework…. much like .NET or Joomla or Codeignitor or YAF that can be used to develop any web application for any device.
Adding more than just Drupal capacity: moving from virtual skills in-sourcing to virtual embedded talent
Whilst virtual skills in-sourcing is the evolution of outsourcing in an Agile world the move towards an embedded team is a step beyond this basic evolution of an age old model. Embedding external talent in an internal team is nothing new; what we are doing at ikonami’s Drupal practise is taking tried and tested methodologies and applying them to the new world view. It’s a methodology and tool mashup that is needed for a community based open source world out there!
Our embedded Drupal teams work seamlessly because managers by design and necessity are removed one or more degrees from the work being undertaken, their job is to support teams on either ends by ensuring they have control over their work, have the tools they need and have clear goals rather than trying to control software development by decomposition and monitoring of activities. Surely the manager is better utilized in ways other than baby sitting development teams.
This calls for direct and open communication lines between the Drupal developers at the client end and ours. It does not make the role of the manager redundant, it allows the manager to work ‘on the project’ as opposed to ‘in the project’.
This has to be one of the lightest posts on our blog so far! but the banner Nauman has created for a Drupal developers campaign we recently launched is simply too awesome (in my opinion) not to make it to the blog and be immortalized in the blogosphere!
there is a PHP developers campaign banner too (below) but my current flavor is definitely the Drupal developers banner up top! Awesome work Nomi. And yes I have shrunk the PHP banner so it does not distract from the awesomeness of the Drupal developers banner… yes I am Drupal biased! only a tiny bit.
more of the usual business like posts to follow… soonish.
Every team has its own preference of tools and the key is the ability of the in-sourced talent to be able to hit the ground running with the tools already in use for anything else will cause unnecessary disruption that negate the benefits of in-sourcing and embedding for a capacity boost. The cavalry should arrive and join the melee in true cavalry style!
Our engagement methodology is in that spirit, though we have our own tool kit that includes Redmine, Basecamp, Harvest, GIT, SVN, JIRA, Skype, G+ Hangouts, NetBeans and Visual Studio… but we also ensure our Drupal developers are familiar with and comfortable in the use of popular tools like Huddle, SharePoint, BugZilla, Mercurial and Eclipse.
And yes there will always be instances where the tools in use are unfamiliar to our teams, in which case our learning curve will pleasantly surprise you.
This ensures that our Drupal and Php developers can join and embed in your team from the get go, minimizing the on-boarding time significantly.
A Drupal capacity Boost: the approach
Back in the summer of 2011 a London based digital agency short on internal Drupal capacity and tired of the promises of recruitment agents approached us to explore how our on-demand Drupal capacity burst would work for them… with plenty of reservations of course.
We started off by taking their resource requirements and presented a number of our resource profiles to them from our Drupal developer resource pool and presented the process and cloud based tools we used by the teams to interact. The very next day their technical director conducted a number of interviews of our selected staff over Skype and was taken aback by the depth of their knowledge of Drupal and their communication skills.
The tipping point was when we demonstrated how using cloud based tools the Drupal developers would be managed entirely by the agency’s own project manager and would work with their existing team. And how simple it was to do so using tools like Basecamp, Jira, Git, Redmine etc. and communication over Skype and Google+ hangouts took care of the distance barrier. The agency was already using Git, Basecamp and Skype whilst working with contractors and members of the Drupal community… it was a no brainer.
Two members of our staff were selected to start the following week for a 1 month trial period. Our in-sourced Drupal developers hit the ground running and within the first week were put on time critical tasks, the following week the agency requested that three more Drupal developers be added to the mix and the agency has held on to the five for almost a year now. Our use of Google+ Hangouts has been an awesome hit!
Ok… you’re thinking that’s a nice story but where’s the meat!…. remember the editors orders! Short posts… so you’ll have to wait.. and the details will follow.