Giới thiệu cơ bản về Scrum
Scrum is a very popular Agile Project Management Methodology that can be used to manage projects, programs and portfolios of any size or industry or complexity. The purpose of this article is to give you an overview of Scrum.
What is Scrum?
Scrum is an Iterative and incremental project management framework that can deliver Significant Business Value quickly and throughout the project to the Customer/Stakeholder. Scrum is fast, adaptable, flexible and also very effective.
Each Iteration is called a “Sprint” or a “Scrum Cycle”. A Scrum Project involves a collaborative effort to create a new product or service as defined in the Project Vision Statement. As you might be aware projects are impacted by the following:
- Organizational Capabilities and
- Other Limitations
Key Participants in the Scrum Project
There are 3 Key Participants in any Scrum Project. They are:
- The Scrum Team – This is a cross-functional, self-organized and high-performing team that works on the Project Deliverables.
- The Product Owner – The Product Owner in a Scrum Project is the liaison between the Project Team and the Business Stakeholders. He maintains a list of project features/requirements that are ordered based on priority. His key purpose is to make sure the project team understands the requirements properly and validates the finished product for its “Fitness for Use” once the cycle is complete. He or she is also responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer
- The Scrum Master – The Scrum Master is the equivalent of a Project Manager to a regular project. He ensures that the Scrum Team is provided with an environment conducive to complete the project successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project and ensures that Scrum processes are being followed
There are other participants in a Scrum Project like – Business Stakeholders, Scrum Guidance Body etc.
Why Use Scrum
Below are some of the key reasons why you should consider Scrum for your Projects:
- It is Adaptable – The Project can Incorporate Changes much more easily than regular projects.
- It is Transparent – One of the founding principles of Scrum is transparency. All the information about the project is shared and easily available to all participants thereby making the whole process Transparent.
- Delivers Quick and Continues Value to Stakeholders – Scrum Projects not only deliver value quickly (The first cycle deliverables), it continues to deliver value continuously throughout the project duration.
- Customer Centric – With an iterative process, the customer is engaged continuously throughout the project and hence his needs and requirements are met better making scrum very customer centric
- Collective Ownership – Each participant in a scrum project has his own set of responsibilities and are together responsible for the successful completion of the project. This cultivates collective ownership.
DO WE HAVE GOLDEN TRIANGLE IN SCRUM/AGILE?
A project usually has competing demands from these 3 aspects – Scope, Time and Cost. When there is change in one aspect the other two sides of the triangle need to adjust in order to keep the project under control. But, that’s for a traditional waterfall type project. Do we have a Golden Triangle for Scrum? That is the question we are trying to answer in this article.
Does Scrum Also have the Golden Triangle?
All projects Agile or Waterfall or whatever be the methodology they follow, will have competing demands from these 3 aspects – Scope, Time and Cost.
Let me ask you a question: If you have 5 members in your team and have a 3 month schedule, do you think I can keep adding more and more scope items to the backlog and you will still finish on time?
You may think of an answer like, I can if I add 2 extra developers or if I get 1 month extra time but you already answered my question – No, you cannot. If you fix the team size and the schedule, the amount of software features the team can produce is limited (assuming you don’t make your team work 16 hour days)
Get the picture? But, I haven’t explicitly answered the question, have I?
Does Scrum also have the Golden Triangle – Explicitly No.
In Scrum the Product Backlog is not a fixed entity like waterfall. The scrum team makes a best effort attempt at building as many features of the product (in priority order of course) but there is no commitment that the team will build all of the features in the backlog. We have a dedicated Product Owner who takes the responsibility of adjusting the product scope based on priority and the teams velocity. Hence we don’t have a Golden Triangle in Scrum. We only have a Time vs Cost Trade-off in Scrum because scope is always variable.
The Time vs Cost Trade Off (With Scope Being the Evolving Constant)
The easiest way to reduce a project duration is by adding more people – this has been the motto of managers since project management became a profession (this is also the reason why software developers hate project managers)
Anyways, in most organizations, every product has a roadmap of features and also has timelines to hit the market with those set of features. So, Time aspect of development is almost always fixed and does not change unless something drastic happens. When time cannot change (and scope is evolving), cost has to change to adapt to the situation – there is no other choice. We add more people to the project in order to meet the projects’ needs.
For example, suppose a project would take 1 year for 1 person to finish, adding an extra person could probably result in an overall schedule of around 7 months. Adding another person may bring the schedule to around 4-5 months and adding more people may further shorten the schedule but not exactly by a mathematical factor because we also have to take into account overheads on communication and coordination between the different parties involved. Anyways, adding more people means the project becomes more costlier and this where the trade-off between schedule and cost comes into picture.
In real life, Senior Managements across all businesses & organizations push for lowering of cost or expenses. So, it may not be practically feasible to have an endless budget. But, having said that, a company that wants to bring a product to market cannot be solely focused on the cost of building it because, releasing the product with maximum features and within committed timelines is much more important that saving cost. If you are wondering why, think of this – Todays market is highly competitive and a few weeks delay could be the difference between a product being a success or a failure. If our competitor releases a similar product a few weeks ahead of us wouldn’t clients choose their product over ours?
This is why, experienced scrum masters will try to get the various different stakeholders in the scrum project like Architects, UI Designers and so on to work seamlessly together to keep the delays due to overhead as minimal as possible and keep the schedule as short as possible. Even in organizations where cost is not really an issue, scrum masters still try to optimize the team size and not depend on endless hiring just to meet the competing schedule or scope demands.
What is your experience with regards to handling competing scope or schedule needs in your agile projects? Sound off in the comments section…
ITERATIVE SOFTWARE DEVELOPMENT IS AN AGILE?
A few years back, I was asked to take over as the Scrum Master for a team that was already familiar with Agile/Scrum concepts. I was quite excited because, for a change, I was joining a team that already knew what Scrum was and I did not need to train the team in Scrum Methodology. After a few days with the team, one thing became very clear – they were doing Iterative Waterfall and not Scrum.
Confused? Read on, to find out more…
Before we Begin: The Waterfall Methodology of Software Development
Software Development for many years used to follow the Waterfall Methodology where teams first gather requirements, designed the system, built it, tested it and then finally packaged it for delivery. The term Waterfall was used because each stage had a clear-cut start and finish and happened one after the other just like water flowing/falling over a bunch of steps. Look at the picture below:
Is there really an Iterative Waterfall Methodology?
I used the term Iterative Waterfall at the beginning of this article. What exactly is Iterative Waterfall? Is there such a thing as Iterative Waterfall?
Actually, Iterative Waterfall is not a formal software development methodology but is one of the most widely popular/used methods. In fact, most people who claim to be doing Scrum are actually doing Iterative Waterfall.
A typical Iterative Waterfall project would do any or all of the following:
- They have a Functional Specifications Document (FSD) instead of a Product Backlog of Features
- Scope is Fixed and all features have to be built by the Delivery date
- The first few iterations are spent in planning (and sometimes design too) for the overall delivery
- The Product Owner just translates sections of the FSD into a User Story which results in huge user stories that typically take 2 or 3 or more iterations to finish
- Development and testing for a user story happen in different iterations; i.e., Development finishes in Iteration N, while Testing completes in Iteration N+1 or later
- Team have a clearly defined Tech Lead who does Task assignments and tracks progress
- Each Sprint/Iteration does not result in a potentially shippable product.
- One big-bang round of Testing is done toward the end of the project to ensure good quality software product
- Team does Analysis à Design à Develop à Test à finish for each story assigned to them.
- Daily Stand-ups are more like Status Update Meetings.
Are you part of a scrum team that does any or all of these?
Is Iterative Waterfall or Iterative Software Development Really Agile?
Of course Not.
Iterative software development is extremely popular because, people who are very used to the waterfall model of development, find it very hard to give-up on their practices and just include the Sprint/Iteration thing into their project and claim to be doing Scrum. They also, split user stories into smaller pieces just so they can calculate a Velocity and show progress. Team does development in Sprints, requirements are captured in stories, estimates are done in story points, velocity is calculated etc. Isn’t this almost like Scrum?
Like I said at the beginning of this section, No Iterative Software Development is not Scrum. In Scrum each user story is an incremental feature of a product and in each sprint delivers a product that could potentially be packaged & shipped to the market. The past many articles have covered various different concepts about Scrum and we have pretty ignored all of them as part of this Iterative Waterfall. Haven’t we?
What is your experience on Software projects? Have you come across any Iterative Waterfall projects? Do Share your experience with other readers…