The past 12 months has been exciting for Ideyatech. We’ve faced new challenges and have experienced sustainable growth. From a 3 person team, we now have 20 full time developers. We’ve also outgrown our old office and moved to a bigger 200 sqm space. More importantly, our project list and pipeline has been consistently full and we’ve managed to keep everyone busy.

Keeping a Healthy Ecosystem

Our business is an ecosystem where the employees do client work, client pays for the work, and the management keeps the employees and clients. By understanding this ecosystem, it is easy to understand how to keep it healthy. The first act of kindness is for management to keep the employees happy, if employees are happy, they deliver quality work and make client happy. If client is happy, they pay well and makes management happy. If management is happy, they continue to keep the employees happy. This makes up the healthy ecosystem.

At Ideyatech, we value the time of every individual - we allow work-from-home, offsetting, and even pay for overtime. This allows everyone to manage their own time and in doing so, everyone respects time by ensuring every hour spent is productive.

By applying agile methodologies and release schedule, we are able to keep up and manage client expectations. The agile methodology is known to be effective in early software releases without sacrifice to quality. In short, we have established an agile process that works and our clients are happy with it.

Aside from our regular team-building activities such as bowling nights, wii nights, etc. , we also believe and promote “passion at work”… we believe that everyone must come to office with excitement to face daily challenges. We don’t want employees to get “sick and tired” of their 8 hour work. Life is too short to go to waste.

Employee empowerment is also something we practice at Ideyatech. I’ve been constantly giving everyone the opportunity to decide on matters at hand and delegating more responsibilities to them. By doing so, everyone gets to learn new things and become more responsible.

All these efforts and investments are directed towards one single goal, and that is to keep employees happy and that takes care of the entire ecosystem.

Offshore outsourcing is a brilliant business strategy for many businesses. Gartner analysts predict that offshore outsourcing will rise by 8.9% in 2008, and the trend will continue on to 2009. However, it is not (yet) a perfect solution to various business issues and requirements. Before engaging the services of vendors, whether by offshore or onshore outsourcing, it is important to know that outsourcing has its own sets of issues.

The bright side of the debate is that if a business understands the issues surrounding outsourcing, these “cons” can easily be turned into “pros” that will add up to profitability and result in better quality of products and services. Below are some of the risks that you must understand about outsourcing:

• You are putting parts of your business in someone else’s hands. Realize that you are inviting a third party into your own operations. Business matters that used to be kept within your company’s walls are being laid open to the scrutiny of the vendor, or as some say, consultant. While trust must be established between the company and the vendor, it is absolutely necessary to form security measures from contracts to security audits. And be hard-headed in the implementation of these contracts. In most security breaches, the weakest points are not the systems put in place to prevent data leaks, but humans, the staff themselves, who fail to understand the enormity of keeping corporate information secure.

• Business experts and visionaries are still a weak spot among outsourcing destination. Offshore outsourcing vendors can provide highly skilled workers who can perform volume tasks. However, management is often a weak spot among vendors. This means the lack of familiarity or knowledge of established processes by your company, lack of enough knowledge about your business or industry. In cases like these, it is important to know the people who will lead your outsourcing team. In many situations, middle- and junior managers receive months-long trainings on-shore before getting their feet wet with actual project delivery.

• Unfavorable business conditions in offshore destinations include economic and political factors. If you think that you are giving away control of parts of your businesses to companies located outside your country, consider how much less control you will have if you factor in the political and economic upheavals in that country.  Any upheavals at all poses risks of operational disruptions. You must make sure that there are business continuity measures put in place in case it is business unusual offshore.

• Businesses only consider outsourcing in terms of cost-savings instead of value to the company. This weakness happens on both ends of the outsourcing spectrum. Both business and vendor only see outsourcing as a way to cut costs instead of adding value to the company’s product, services, customer relationship, among other things. Instead of concentrating on the outsourcing relationship in terms of money savings alone, it is important to add long-term product or service innovation and process improvement in the mix. The money saved today can be reinvested into bigger endeavors tomorrow.

Outsourcing, especially offshore outsourcing, has been constantly cast in a bad light for its perceived ill effects on the job security of thousands of workers from developed economies. However, it is interesting to ask this question: If outsourcing’s negative effects far outweigh its positive results, then why does it still flourish? Is it all about the money? Apparently, the answer is “No”.

This is not to say that outsourcing does not have its bad side. In this two-part blog post, let us explore where outsourcing works, and where it should improve.

• Outsourcing allows small and medium size businesses to have more workers. Small and medium-size enterprises do not have the luxury of permanently employing large armies of workers to work on projects, such as software development, QA, accounting systems, documentation, or customer management. However, outsourcing allows them to engage as many workers as their projects need—or as they can afford—temporarily. At the end of a project’s lifecycle, a lot of companies find it easier to halt relationships with vendors than with employees.

• Outsourcing allows companies to focus on their core competencies. This is one of the most popular and oft-repeated responses to outsourcing critics, and it is worth mentioning many times over. By outsourcing processes that require low or mid-level skills, companies can focus on parts of their operations that need high levels of skills gathered from extensive industry experiences. Basic Java development can be handled by offshore workers, while software architecture and design are best handled by onshore resources.

• Outsourcing offers staffing flexibility. With hundreds of thousands of available workers in application development, customer management, and support services available in low-income service providers, companies have the flexibility to hire on project basis. At the end their projects, it is easier to decide whether to retain talents or hire new ones, even new vendors.

• Outsourcing saves money. Offshore workers in an emerging economy, such as the Philippines, can provide the same quality of work at a much lower cost. Outsource workers in emerging markets are college graduates and most have job experiences relevant to outsourcing requirements. For example, IT workers in Manila are college degree holders who have also received formal trainings in specific programming languages. On top of that, IT vendors also arm their workers with trainings in consulting, customer management, communication, and methodologies. Over time, the smaller amount paid to low-wage outsource workers increase in value.

For the past two months, we have been having our weekly T3 (Tuesday Tech Talk) sessions. It’s a 30-minute discussion about any technical topic the presenter would like to discuss. Presenters are randomly selected from the development group.

So far, we have received nothing but benefits from this activity. Here are some of its benefits and advantages:

1. The presenters get an opportunity to talk, express themselves and practice their presentation skills. More importantly, they steer away from the developer mindset for a while, get out of their shells, and think of good topics to discuss.
2. The attendees learn something new. Everybody seems to know something others don’t.
3. Everyone begins to understand the specialization and span of knowledge of their colleagues. In this way, it becomes easier to know who to ask regarding particular topics. Subsequently, the developers become experts and specialists in their own way.
4. This builds camaraderie within the team. Everyone relaxes and opens up their minds for new knowledge.
5. The topics discussed are usually not something we do or use in our daily routine at work. So, everyone gets to learn more than the usual stuff.
6. Everyone realizes the things that they do not know and starts to seek for more information about it.
7. The organization strengthens its corporate IQ as people share their ideas and knowledge with each other.
8. After a couple of sessions, everyone began appreciating the activity and now looks forward for new things to learn.

How do stand-up meetings help? Are they really helpful?

Here at Ideyatech, we have been practicing stand-up meetings religiously ever since our first project. So far, this short, daily routine has kept everyone up-to-date on status of their projects. By reporting daily activities, issues and bottlenecks are quickly identified and resolved. Everyone gets accountability on the tasks that are reported, and the team becomes more responsible of the project as a whole.

Here are some tips to make stand-up meetings effective:

1. Be religious. Make it a daily habit.
2. Keep it short. Do not exceed 15 minutes.
3. Avoid autocracy. Let team members take responsibility and accountability.
4. Break long conversations. Take it offline and discuss after the meeting.
5. Use a small object as a token indicator of the current speaker. We use a ball, which occasionally brings some fun during meetings.

In addition, here are some common problems we encountered during our stand-up meetings:

1. Some members (especially the younger ones) tend to report to the project leader, instead of reporting to the team.
2. Some members wait for the stand-up meetings before bringing up their questions or issues.
3. Most of the time, the members report only their accomplishments, and tend to forget about the problems or their pending or next tasks.

At the end of the day, these stand-up meetings serve as a medium for communication between project members. For best results from these stand-up meetings, some procedures may need to be applied and laid out.

As defined in Wikipedia:

Agile Software Development is a conceptual framework for software development that promotes development iterations, open collaboration, and adaptability throughout the life-cycle of the project.

True to its meaning, Agile is a concept that can be implemented in several ways. So, there is no correct way of getting it right… Nevertheless, here are some tips we’d like to share based on our experience:

1. Agile team members must be matured and responsible. Team members must be pro-active and have the drive/determination to take charge of the task at hand. Self-organizing teams are hard to develop, especially for junior programmers. It takes some level of maturity and experience for a team member to identify the tasks and execute them.
2. Agile projects must be contracted as “Time and Material” rather than as “Fix Cost”. This is because agile practice is susceptible to “scope creeps”. The concept of being able to adjust/change requirements during each release indicates that scope must be flexible. As such, contracting on “fix cost” will either limit scope changes or lead to tedious change control processes.
3. Pair programming should be limited. It is effective only on certain circumstance such as “master-apprentice” pairing or critical components. Otherwise, it will lead to inefficiency where two people are producing half the value of their time.
4. Tools are essential for unit testing and continuous integration. It is almost impossible to implement unit tests and continuous integration without the proper tools to support the build and test process. It is important that the tool is able to run builds on pre-determined schedules and send configurable alerts. Moreover, choose a tool that can understand the unit test results and do notifications as necessary.
5. Take the Agile Manifesto with a grain of salt. Not everything in Agile works… it varies on the organization, software and project type. For organizations that are new to this concept, start by shortening your iteration release - at least to monthly. This can take you a long way going agile…

I’ve recently come across unfuddle(http://www.unfuddle.com) which is a project tracking tool and hosted source repository. This site is built on RoR and behaves similar with Basecamp. I’m currently using Basecamp for my projects… it’s pretty good but I find it a little too limited for other things such as defect and issue tracking. Currently, I have a separate service for issue tracking and source control.

Unfuddle seems to be the all-in-one solution as it provides a number of useful functionalities such as messages, milestones, ticketing, and even source control. With unfuddle, I’m considering giving up basecamp and my VPS-hosted repository. I’ll probably be able to save a few bucks but more importantly, I’ll get a streamlined process of managing projects from source control to issue tracking. Hopefully, unfuddle can get an integrated defect tracking software that allows linking between source code commits and issue resolution and possibly a platform to support continuous integration.
Thanks to the people at Unfuddle for making software development and management fun and exciting!

We have seen successful roll-out of Just-In-Time concept in manufacturing. This technique was popularized by Toyota with their car manufacturing process. With proper coordination, they are able to adjust their production line easily when certain demand increases. For example, if report shows increase in demand on a specific model or color, they call their suppliers and receive the parts quick enough to fulfill the demands.

Dell is also good example of a successful JIT execution. They achieved a 4-hour production cycle to support build-to-order process. This means they manufacture computers based on actual orders… no stocks, nor left-overs. This saved the company millions of dollars by eliminating the need for warehouses.

We have also seen the same concept applied to compilers such as Java JIT compiler. The JIT compiler reduces overhead of translating bytecodes by dynamically recompiling bytecodes into its native language. This results to about 40% performance increase in many Java applications.

The principle behind JIT is quite simple, be lightweight with minimum overhead. This results to efficiency in production and agility in adapting to the market demands.

There is a substantial amount of information from the JIT experience that can be applied to software development projects - especially web projects. Web projects are first-to-market, and flex-to-market. First-to-market is netscape, hotmail, yahoo, amazon, and ebay. They are revolutionary. Captured the market because they were the first. Flex-to-market is google, friendster, firefox, and gmail. They are evolutionary. Captured the market because they adopted to the market needs.

JIT Development is key to web projects. It is lightweight. It is agile. It is extreme. It is more with less.

To achieve JIT development, keep the following 5 principles in mind.

Prepare minimum and progressive plan. There is no need to create a full 30+ page project plan. Keep it to minimum but support a process for change.

When planning, start by finalizing the timeline, a.k.a. release plan. Identify the scope and resources afterwards. Keep in mind that projects are time-critical. Time is determined by the market, not by scope nor resources. Scope can be managed by priority. Resources must be flexible and adaptive, build the support structure to achieve this.

Prepare a work breakdown based on deliverables. Make sure all tasks are associated to a deliverable. Keep it lean and avoid fats. If a task does not have a deliverable, remove it - that is overhead, fat. Streamline your activities by ensuring concrete deliverables for every task.

Lastly, support progressive elaboration. A plan is a living document. It breaths within its environment. So make room to breathe air by putting an integrated change control process with your project iterations.

On time, on time and on time. The project triangle is the dependency between time, scope and resource. When triangle changes, keep the time fixed. Flex on resource or scope but always be on time.

Identify the priorities of your requirements by importance based on market demands. In case of delays, drop the least important, do not sacrifice quality over functionality. You can always add new requirements in the next iteration.

Resources must be flexible, your agility to ramp-up or scale-down resources is the key. To do this, find consultants, look for partners or outsource. Develop service level agreements that will meet your quality. Do this before you need them, scrutinize their skills, processes and methodologies. Make it fit to your demands. Establish business relationships.

Document less. Reduce time for documentation. This is overhead, fat. However, business operation requires documentation. So, document only as needed.

Requirements does not need to be well-documented, only well-analyzed. Requirements can be represented in many forms - use cases, site map, diagrams, prototype and others. As long as client and stakeholders understand and agree to the requirements, you are fine. Prepare a good document only after successful implementation. Your process will make up lack of requirements by adopting to changes. Considering that requirement defects has the highest amount of rework needed, might as well implement few requirements rather than wrong requirements.

Forget detailed diagrams, oftentimes they are wrong. It is only during actual coding that the correct details are discovered. Get well-rounded and multi-skilled people that can do design, analysis, coding and testing. Perform peer-reviews. Document only what is necessary (framework, integration) and when necessary (stable code).

Frame the work. Establish standard using an application framework. Look for the most suitable framework from open-source solutions. Use struts or smarty, use hibernate or activerecords. Whatever it is, reuse a framework. This ensures a standard coding process that leads to productivity and efficiency.

Invest in architecture and framework. Setup a core group responsible in establishing standard development strategy. They are responsible in ensuring consistent coding strategy, developing libraries/reusable codes and deploying scaffolds.

Start with a standard then seek for efficiency. With standard codes, refactoring is controlled and performance is consistent. Changes Implement peer reviews.

Iterate. Release weekly if possible. Look for quick wins. Get feedback early. Iterate over the previous process, release it then improve it. Time is critical and there is no need to over-emphasize this.

The end result of JIT Development is a lean process for developing web projects. An opportunity for first-to-market, and flex-to-market.

Here are some tips that you may find useful when preparing project plans.

• Identify business need and project objectives. Ensure that there is a business need, and how the project fulfills that need is clear. This will get your project higher priority and better visibility. This will also guide you and your business analysts when making project decisions.
• Acquire project approval. Ensure that the project is officially approved by an executive sponsor. This ensures that the resources needed by the project will be available as planned.
• Get stakeholders’ buy-in. Commitments from stakeholders (e.g. domain experts, technical staff) are equally important. Know your stakeholders and their needs, as this will keep them interested in pursuing the project.
  
• Review historical records. Look for past projects in your organization that are similar to your project. Review the successes and failures of the project or interview the people involved. You can use these information to make a more substantial, relevant and feasible plan.
• Manage project risks. Identify the project risks and make sure that mitigations are performed. Also consider preparing contingency plans for when the risk occurs.
• Start with the minimum. Prepare the minimum project plan, you will have time to add plan on other areas as project progresses. My recommended minimum planning areas are:
  • Project Scope - Note that this is not the scope of the product, rather the scope of the project which discusses about the activities needed for the project.
    
  • Project Team Structure - Project team organizational chart, roles/responsibilities and assignments, # of resources and skill levels.
    
  • Milestone and Schedule - Milestones with due dates, deliverables and owners.
    
  • Communication Plan - meetings, status reports.
    
  • Risks and Issues Management Plan - List all known issues and risks.
    
• Support progressive elaboration. Changes are inevitable as project progresses. You must be prepared to adjust the plan to these uncontrollable factors and make sure that proper change control process is in place - that is, ensure stakeholders are aware of changes.
  

Status reporting is an important function needed to be performed in any project. It is the primary tool used by project managers to communicate with their clients and stakeholders. Creating status reports may be a simple task, however, preparing one with valuable information takes some management skills and process maturity.

Here are some points to be considered when creating status report

• Start with the summary. Most executives do not have the time to read the entire report, so make sure that the first page summarizes the project status.
• Use graphs and visual cues to represent the status. For example, a line graph showing your actual progress against baselined plan will explain the progress of project.
• Keep it short and simple. Use bullets and numbered items instead of paragraphs.
• Report critical issues and risks, but write down resolutions and mitigations as well.
• Make sure you have basis on all the numbers represented. (e.g. % complete must be based on some earned value or delivered work)
• Be honest. Do not be afraid to report delays, it will save you in the long run.

Below is the minimum information needed to be reported:

• Project Name, Project Manager
• Reporting Period - specify start and End date
• Summary - provide visual cue like green, yellow, red depending on status.
• Planned Status vs. Actual Status
• Accomplishments - tasks completed within the reporting period.
• Issues and Risks - critical issues/risks needed to be escalated.
• Next Actions - plan for next reporting period.

Larger projects may require more information such as:

• Earned Value. PLN(Plan), ACT(Actual), ETC(Estimate to Complete), EAC(Estimate at Complete)
• # of defects reported, # of open defects, # of closed defects.
• # of new issues, # of open issues, # of issues closed.
• Resource utilization
• specific project details

Preparing a simple report containing all these information can be difficult. Good thing is that you will always have room for improvement. Get feedback from your stakeholders on the report format and improve it afterwards. Caio!