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.

Scrum has proven its benefits in software development. These projects are having transparent communication, high adaptability, better client engagement, and many more. Thus, this create an impression that Scrum is only for software development and nothing else.

Many other industries are eyeing on how to harvest such benefits of Scrum in their context. Let's take a step back - PRINCE2 was originated for IT projects, PMBoK was initially meant for construction projects  Now many non-IT, non-construction industries are using them.


Scrum is a Framework
Virtually all industries are able adopt Scrum without having to make it industry-neutral. Scrum is a framework and not a methodology. Allow us to have quick look on their differences.

Framework - it outlines the principles and generally answer "Why & How" and often challenges status quo.
For examples:

1. Why we need lengthy meetings? How to make meeting value-add to client?
   
2. Why client not satisfy with our hard works? How to increase client satisfaction the simplest way?
   
3. Why team are not performing? How to make the team self-organized?

Methodology - it prescribes the working mechanisms of an activity/ deliverable, i.e. "What" need to to be done by "Who" via "How" approach in the timing of "When".
For example:

1. What are needed in a Project Charter? Who is responsible to create/ review/ approve it? When it is needed before next activity can start?

Framework is for Adoption and not Adaptation
As a framework, it must be accepted as a whole. Any changes on it, may invite chaos if not catastrophe. When the Scrum framework is adhered, you can come out your own working mechanism based on your preferences.

Just like a house - its framework is solid foundation of everything in it, which make the occupants comfortable living in it. You can decorate it without worrying its safety. Any removal of the framework entails unexpected risks.

Concluding Notes
When you are planning to introduce Scrum in your team/ organization, it will be better to have someone knowledgeable in Scrum to be on your side. This is to ensure the Scrum framework is maintained and not omitted.

On the other side, if your Scrum does not deliver expected benefits, you may want to consider to re-inspect its framework. Hopefully after the inspection, you can restore the framework and reap its intended benefits.

Have fun decorating your Scrum framework.

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.

Scrum framework focuses on producing incremental deliverables in short and regular intervals (e.g. 2 - 4 weeks). Thus, it is well received in many software development projects. Subsequently, other industries are adapting Scrum framework to combat uncertainties and remain responsive to deliver better customer satisfaction.

Now the question is - what is the possibility to implement a PMO by using Scrum?

Roles

• Product Owner (PO) - Appointed from business that responsible to prioritize deliverable, clarify requirements and ultimately accountable for the success of PMO implementation.
  
• PMO Team Members (Team) - SMEs (subject matter experts) or consultants that are tasked to develop and implement PMO services, processes and tools.
  

• Scrum Master (SM) - Recruited to the team as a facilitator to ensure Scrum framework is practiced correctly and consistently. For matured Scrum practicing organization, this role is optional.
  

Events/ Activities

• Sprint Planning - PO explains his/ her requirements based on Product Backlog; the Team clarify and estimate the duration needed. Upon agreement, each Team member get the tasks they can performe. Thus, the sprint starts.
  
• Daily Scrum - SM and the Team have daily meeting (15 minutes max) to discuss:-
  1. What has been done yesterday?
  2. What is planned for today?
  3. Any road block or challenges faced?
• Sprint Review - At the end of sprint, the deliverable is demonstrated to PO for acceptance.
  

• Sprint Retrospective - This is the time everyone evaluates the working processes and agreement (a.k.a. lesson learned):-
  1. What worked?
  2. What did not work?
  
• Backlog Grooming - PO sought second opinion from the Team to breakdown Product Backlog Item into smaller and manageable deliverable.

Artifacts

• Product Backlog - Owned by PO and it's a road map of PMO.
• Sprint Backlog - Owned by the Team and it's their work package of a sprint.

Critical Success Factors

• Product Owner has:-
  1. authority and accountability on PMO's direction.
  2. appreciation on the values and benefits of using Scrum.
  3. the trust on the Team's capabilities and competencies.
• Team has:-
  1. formed their own working agreement and adhere to it.
  2. mutual respect to each other despite they may have difference in opinions.
  3. accountability for their individual deliverables and performance.
  
• Scrum Master to:-
  1. educate both PO and Team to use Scrum framework consistently and effectively.
  2. protect the Team from anybody including PO on possible re-prioritization or addition of new features mid-ways.
  3. seek to resolve the challenges faced by the team.
• Ensure Entire Scrum framework is adopted and adhered to to gain intended benefits of it.
• Regular Inspection and Adaptation - When something is not working, everyone goes back to retrofit on how things are done (i.e. working processes and agreement) and not finger pointing on anyone.

Conclusion
As cited in The State of Scrum (June 2013), Scrum has gained its popularity and earned its successes outside of software industry. The approach to use Scrum to implement PMO is truely ground breaking and need a lot of courage to bring this to fruition. Thus, everyone in the team plays their role to make this a success.

May the Scrum Forces be with you.