Brightmoon Consulting & Training

Have you ever questioned why so many large software projects failed one over another?

The main reason is they are using SDLC/ waterfall, which is widely known as Software Development Life Cycle. SDLC dictates the sequential steps in gather requirements, design, develop, testing and implementation. Each step must be completed before commencement of next step. When something goes wrong, the particular step is reworked and wasted. Thus, it means Software Dooming Life Cycle.

Doom Grooming Ground
SDLC has been part of college education syllabus, and many has showed the success stories. Many happy students scored distinction in their final year project by using SDLC. It gives further assurance the usefulness of SDLC in software project. Therefore, many projects nowadays are wholeheartedly adopt SDLC without second question. When the project size is still small, they tasted the sweetness of SDLC success.

Dooming Life Cycle Started
The dooming life cycle starts when the complexity and uncertainties of a software project getting higher. The obvious complexities are stakeholder and communication. Human always struggle to express themselves 100%; and unable 100% decipher the message. Such situation contributes to misunderstanding. This is primarily due to individual perception, exposure, personalities and education. Such cycle is endless and many projects are trapped in there.

The Realization
Many have noticed the risk of using SDLC in large project. Even the creator of SDLC, Dr. WInston W. Royce cited the usage of SDLC in large software project is inviting risk and failure. Such realization can comes from painful experience or learned from others. Some wise men have proposed two approaches in handling large software project:

1. Divide & Conquer - Split one large software project into several smaller software projects
   Pro - continue use all-time favorite SDLC
   Con - need to manage dependencies of these smaller projects
2. Be Agile/ Scrum - have smaller SDLC cycle (i.e. iteration cycle)
   Pro - able to adapt changes faster
   Con - need to adjust traditional way of planning & working

Recommendation
After knowing the risk of SDLC in large software project, my recommendation is to Be Agile/ Scrum:

1. The rate of uncontrollable changes is getting higher and more frequent. The more adaptive a project team is, the better chance of a project success.
2. Small projects can grow big after several phases. It's advantageous to be agile now than later.
3. Knowledge and experience of agile can be adapted to different projects or industries.

We wish your projects are successful since day-1 with the right foundation.

Intended Benefits of Scrum
Scrum is gaining popularity due to its benefits in making a team more adaptive and responsive to its ever-changing environment, such as volatile user changes, technology advancement & etc. In the nutshell, Scrum is to make a team be self-organized. An self-organized team able to deliver results with higher customer satisfaction and better client engagement.

Introducing Scrum Role
More and more organizations introduce a role named Scrum Master (SM). This role is a Scrum evangelist in the organization. He/ she does not have any authority over the team and only facilitates the team to be self-organized. The first expected benefit is the team won't cause any headache to the management team, particularly in managing their works in a team. The communication within the team is open and transparent. Thus, everyone has a happier life.

The Reality
Back to reality, many organizations pro-claimed they are using Scrum or have roles of SM/ Product Owner (PO). However, these roles expects the team can deliver faster under the flag of Scrum, despite the fundamental working arrangements are status-quo (i.e. prior introduction of Scrum). The SM/ PO holds responsibilities of typical team lead or manager. They dictate how the team doing their works, which is contradicting to Scrum approach - make the team self-organized. Due to various reason, they refused to claim they failed in using Scrum, they said they "adapted" Scrum.

"Adapted" Scrum - The Destroyer
Let's have a quick reality check, whether your organization or team has "adapted" Scrum in a counter-productive way:-

1. The team size is too small - ideal team size is 3 to 7 person.
2. Someone dictate of how a job is done - definition of done should agreed up front.
3. Estimation of each work is done by someone - estimation should solicit from the team as they know their stuffs well.
4. Someone assigns the works to each team member - as self-organized team, the team is empowered with commitment to their taken jobs.
5. Sprint Backlog is owned by someone and not the team - Sprint Backlog is ownership of the team and their prioritize their works to meet the ultimate goal.
   
6. Changes are frequently interrupted a sprint in progress - this hinder the concentration of the team and their progress.
7. Daily Scrum (a.k.a. stand up meeting) is omitted and replaced with lengthy project status meeting - daily Scrum is an avenue to make the communication crisp and transparent.

Concluding Remarks
Scrum is designed to make the team self-organized. Such self-organized team won't happen overnight and it takes time to nurture them. Once they are matured, an organization can harvest maximum benefits of such self-organized team.

When the "adapted" Scrum unable to make your team self-organized, it must be something wrong. Take a step back and look on what you really want from Scrum. It requires change of mindset and ways of working. A proper transition plan is needed to ensure everyone (beside the team) understand how to make Scrum works. It should follow-up with a monitoring stage to ensure the organization/ team practice Scrum to its fullest.

Your Agility Ticket - Scrum Workshop
Please refer to attached flyer (3 images) for greater details.

Who We Are
Allow us to briefly introduce ourselves - Brightmoon Consulting & Training. We have combined experience of 30 years in Software Development and Project Management. We are certified with two leading Scrum advocates - ScrumAlliance and Scrum.org. Our passion is to nurture the success of others in delivering successful software projects via Scrum.

In Need of Practical Knowledge in Scrum
Many companies are aware that they need to be highly agile to meet market dynamics. Thus, many of them introduce scrum/ agile into their work. However, many are unable to reap much benefits of scrum. Primary factor is they don't have practical knowledge and skills to make scrum work for them. Most of the existing trainings emphasizes on certification and not much on its practicality and usage. Therefore, it inspires us to share our passion in Scrum to you.

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.

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 !!

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.

Those days... Many people have been suggesting on adapting and using agile in their works of different industry. Not many of them are recognized internationally. With a valid fear of too many chefs spoil the broth, many organizations are skeptical on practicality of agile.

Fear not! Now more and more international Body of Knowledge (BoK) bodies are incorporating agile into their BoK. Among of them are PMI Agile Certified Practitioner and Agile Extension to the BABOK® Guide.

Are you ready to embark into this new way of working?

Have you heard of Agile?

This is not the latest buzz word. It has been around for many years. Recently, more and more attentions are moving towards Agile. This is true particularly in software industry. The primary reason is it deliver workable deliverable rather than thick non-productive documentations. And, it is clearly articulated in Agile Manifesto.

If your software development project is moving no where, give Agile a thought. You will be amazed by how it works. 

To accelerate your result, please contact us for more details. We love to share what we know with you directly.