Brightmoon Consulting & Training

To avoid any confusion , surprises and more importantly ill feelings, it is important to define upfront (usually during sprint planning) what does a complete work means to ensure all scrum team members as well other stakeholder are aware and are on the same page. In another word, teams should come up with the definition of done. It does not have to be a perfect one. Definition of done can be continuously improved as the team and organization matures.

Below is the list that you can start with :-

i.   All acceptance criteria for a user story has been met (all items in a feature has been coded).
ii.  Code is commented, meets the agreed coding standard and checked into the source-control.
iii. Code has been reviewed or coded using pair-programming.
iv. Code is compiled or built without errors.
v.  Unit test case written and code has passed the entire unit testing by another developer.
vi. Integration & Regression test case written and code has been deployed & integrated into test environment testing by another developer and passed testing (or automated testing).
vii. User Acceptance Testing test cases written and code has passed UAT.
viii.Performance and load testing completed and passed acceptance criteria.
ix.  Deployment steps including configuration changes documented.
x.   All other related & required documentation completed.

This list can be continuously adjusted and improve to suit your own organization.

Date: 21 & 22 October 2013
Venue: MIA Training Room
More info: http://goo.gl/psLrXK

This program gives participants an insight on how to increase the likelihood of project success, and covers fundamental elements of the project management. It uses a case study of a system implementation to put into perspective of common challenges in project management. Thus, it is suitable for participants who are new to Project Management.

Many companies do not have Project Management Office (PMO). The primary reason is they enjoy various games in their projects. The actual list of games is extremely long and only few popular ones are highlighted here.

Hide & Seek
This is known as "sweep under the carpet." When the project sponsor asking for statuses, the Project Managers present a heavenly report. Everything is on track and on budget. Their plan is perfectly planned and executed. All stakeholders love the project. After project status meeting, the Project Managers will step out from the heaven and go back to the reality - chaotic hell. Everything is totally opposite on what the report says.

Without PMO - the visibility is manipulated and impaired.

Duck, Duck, Goose
This game is also known as "back stabbing." When something goes out of hand, the group of Project Managers will start solving the problem by finding the "goose." The identified "goose" will start finding another "goose." This cycle continue endlessly. Thus, the fun is endless as everyone is living in an illusion that they are working very hard to solve the problem. In actual fact, nothing is solved.

Without PMO - nothing is really get solve at its root cause.

Skipping Rope
Time is cost, and cost affects profitability of a project. To increase profitability, time has to be reduced. Thus, this game is famous and known as "fast and furious." When Project Managers need to follow a recommended practices, time is wasted in documentations and thinking; nothing really get done on the ground. To accelerate the whole cycle, they assume every projects are the same and copy-and-paste from other projects. When the documents are ready, they happily executing the real work. In reality, they have buried countless mines in their projects - from other projects.

Without PMO - good practices are skipped at the expense of project success .

Conclusion
When one day your Organization decided to be a grownup. That's the time PMO can answer that call. With right PMO, all these childish games will come to an end - for good. Other children will soon realize they cannot continue be childish and decided to grow with your Organization. At that very moment, your Organization has stepped up in its maturity level. Congratulations!

Now the decision is yours - you can decide to continue playing these games or otherwise.

Agile methods recognizes and readily enables a project or development team to build in quality in their software product. It has introduced many methods to further improve the software development experience. Pair programming is one such method.

 It basically means 2 persons will work on the same piece of software at one time.  An extra set of eyes and brain will surely help. They will help to identify each others' blind spots. They can be instant discussion partners for difficult and complex code.

It may take a while for new comers to productively bring this into practice, may be a few iterations. But once the team becomes used to it, the productivity gain may exceed the cost of having 2 persons working on the same code.

Code reviews can be greatly reduced or totally eliminated. Testing effort may be reduced as well as it is expected the pair- programmers have built a good piece of module or software.
 
Other side effects of practicing pair programming are each other can learn one or things from his/her partner. And guess what ?? If one programmer became unavailable due to any reason (has to be assigned to a higher priority project or leaves the company), the other person can still continue with almost no effect to project schedule !!

PMO stands for Project Management Office; in same cases it means Programme Management Office. As per the illustration on the left, PMO can exist in various levels in a company. Some companies have it formally established with dedicated personnel and budget. While some have a person to perform some duties of a PMO, such as Program Director, Project Director and Senior Project Manager.

PMO duties generally comprise of:-

• Monitor and control the health of each maneuver (i.e.: Project, Programme)
  
• Define the standard Project Management methodology (i.e. processes, tools, templates & etc.)
  
• Ensure the projects are adhering to the methodology to deliver predictable outcomes
  
• Continue improve and propagate Project Management methodology
  
• Provide guidance and support to team members (e.g.: Project Managers, Team Leads)
  
• Manage dependencies among projects
• Serve as a communication platform across projects

Below is the Agile Manifesto , according to  http://www.agilemanifesto.org/,

If you notice the 3rd sentence of the 2nd paragraph, it highlights the fact that customer collaboration is more important & valued compared to contract negotiation. Contract negotiation in this context refers to waterfall project type of contracts whereby every features (requirements & scope ) are expected to be discussed, agreed and signed.

Once signed the client is bounded by the agreement even though as the project progresses, the customer may get more insight into what he really needs. If he wants to modify the requirements, he needs to go through another negotiation process as part of change request so that his "new" requirements is added into the project. Guess what !! The client have to pay for it.

Agile contract works in such way that as the customer gets more insight into his requirements, he can continuously modify the requirements accordingly.

So how does the contract look like? How do you as the client engage the agile software developer or vice-verse ? How do you incorporate the manifesto in your contract ? What should be contents on the contract ? And most importantly what are skill sets that the client should have so that their interest is protected as well to ensure smooth and successful negotiation and eventually the project implementation ?

Do connect with us for more information.

Agile software development means that :-

1. All stakeholders accept the fact that all requirements to meet strategic demand & roadmap cannot be fully and clearly understood upfront. These requirements will change and project team especially developers should anticipate and welcome the change as the project progresses.

2. There will be many short releases on weekly/bi-weekly/monthly of small increments (working software features or modules). The short cycle and small increments forces project team and customer to prioritize most valuable/important features, thus enables customers to start using the system much earlier. It also ensures money is spent first on the most important features thus reduces financial risk in case project comes to an abrupt end. The shorter release cycles enables faster customer feedback on the features and greatly reduces risk of misunderstood requirement. The cycle will repeat until all requirements are implemented (all backlogs are cleared).

3. There will be continuous integration and testing at each cycle. Continuous integration and testing forces the increments to fully comply with systems requirements thus reduces any technical risk.

4. Customers have active role to ensure successful completion of the project (successful development and delivery of the software). This is because there will be higher visibility throughout the project. Any deviation can be quickly corrected. Deviation risk is limited to one cycle time whatever it may be weekly/bi-weekly/monthly.

If you need further clarification on agile software development can be adopted by your organization or how it can benefit you, do connect with us.

Many organizations are good at planning. They are equally good at implementing their plan. Unfortunately the process ends there for most organizations. They are often busy and occupied with the current work and issues that they don't usually check what they are doing and how they are doing them. In other words, they hardly do audit on the activities.

Audit are important as it will uncover mismatches between what is documented with what is actually being done. It will help to uncover the deviation between what is thought to be happening or out to happen with what is actually happening. Most of the time, the deviation is intentional. The original (documented) process may be not practical or relevant anymore so the guys down there (implementers) will modify and tweak the process to suit their work.

A good audit process will also be able to gather what are the deviation and why they occur. It will help to solicit the pain points. It will also provide a relevant recommendation as to how those mismatched can be addressed.

It is good that all processes, procedures, templates and tools are continuously reviewed and improved every 3 to 6 months. if you need any help to perform audit for your project management and software development activities, please connect with us.

Requirements, one of the most important, if not, THE most important artifact in any project. Managing them is most probably one of the toughest task (second to managing PEOPLE, of course !) that any seasoned project manager will attest to. Many projects failed or often gets delayed because requirements are not managed properly.

It is simple yet complicated. It is known yet unknown. It is understood yet misunderstood. it is documented yet undocumented.

At best, managing requirements is a misunderstood activity. Often, gathering requirements stops at talking to business folks. Often, it stops at explicit requirements.

At worst, managing requirements is a mishandled activity. Multiple or no requirements owner. Not documented, initially may be but as the project progresses, the requirements document are not updated accordingly. Not properly prioritized. No unique identification. Not traceable to the originator nor to the implementation.

But worry not, requirements can be managed successfully. The first step is to realize and accept the common pitfalls as mentioned above. Second step is to identify and develop suitable procedures, process and templates as well as identify suitable tools. Third is to get everyone aware and trained on those procedures, process, templates and tools. Fourth, to implement auditing and reporting to ensure the procedures, process, templates and tools are being practiced as intended. Last but not least, those procedures, process, templates and tools should be continuously evaluated and improved.

If you would like to know more on the process, procedures, templates or tools, please connect with us.

A quick check list

1. Do you struggle to keep up with changes happening around you ?
2. Does your employees resist when you try to introduce changes ?
   
3. Does your projects completion gets delayed often due to changes in requirements and resources ?
   
4. Do you find it hard or even impossible to manage requirements for your projects ?

If the answer for any one of the questions is YES, connect with us.