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!