• The product owner defines the project objectives, develops the optimal schedule for the project parameters, adapts the project implementation process to the changed requirements and sets priorities in the product specifications;
• Scrum master sets priorities for task to be executed by the project team and eliminates difficulties that could prevent their execution;
• Team members execute most of the assignments, carry out daily management, create progress reports, and monitor the quality of the product.
Agile Model
AGILE methodology is flexible and enables changing project parameters easily, which is important for service-oriented projects such as software development or graphic design. But this methodology is not suitable for projects with strictly defined parameters and requirements.
Project management requires quick adaptation to changes, tracking recent development trends and ability to benefit from them. The human resource is equally important. Therefore, the ability to create a dynamic project team based on cooperation and flexibility and the possibility of finding a compromise are necessary. Stakeholders are also very important. They monitor and check each stage of the project, while the team members, in turn, promptly correct the project, creating high-quality products or services that meet consumers’ needs and demands.
AGILE design is better applicable for projects that require intensive interaction in real time and are implemented by highly motivated teams that do not need additional control. The AGILE methodology is distinguished by high interactivity and enables quick adaptation to the project. One of its main benefits is possibility to quickly identify controversial issues and make the necessary changes at an early stage of development, without waiting for the verification. AGILE is a design ensuring the use of recurring processes, risk reduction, prompt feedback, quick turnover and reduced complexity.
AGILE’s strengths are its flexibility and adaptability. It can be adjusted to almost any conditions and processes within the organization. That is what ensures its current popularity and the large number of systems in different areas created on its basis. One of the AGILE’s principles is “Reaction to changes is more important than following a plan.” AGILE covers new, innovative open end products. The proportion of uncertainty when developing such projects is high, while the product information is revealed as the project progresses. Such conditions make “waterfall” implementation impossible since there is no planning information. The second strength of the approach is the ability to “make mistakes” and correct them quickly without a significant impact on the status of the project as a whole.
AGILE’s weakness is a necessity to create individual management system by each team, guided by the AGILE principles. This is a complex and long process that will require changes within the entire organization, including procedures and basic values. This is a thorny path and not all organizations can do it. It requires changes in knowledge and perseverance, as well as serious administrative resources and expenses. Besides, there is a floating estimate of deadlines and budgets, uncertainty in the planning of goals and objectives, insufficient documentation and, as a consequence, increasing the likelihood of divergence of tasks and actual implementation, complexity of a project retrospective analysis.
SCRUM project management methods
SCRUM project management is a classical method within AGILE framework describing all planning, control and analysis at all stages. The methodology for implementing AGILE development involves an interactive approach. Scrum sessions (30-day sprints) are used to prioritize tasks. To simplify the job, the project manager’s responsibilities are transferred to the scrum master. Independent solution of specific tasks require small teams. The achieved results are assessed during the meetings with the scram master, followed by the determination of priority for outstanding tasks. The main features of this technique are:
• Meetings and sprint analysis;
• Small team;
• Restriction on certain periods of time (sprint) to run WIPs;
• Work in Process WIPs.
Following Agile principles, Scrum splits a project into parts to be used immediately by the Customer to obtain values, called “W” – product backlog. Then the product owner, i.e. the customer’s representative in the team identifies the priorities of these parts. The most important “pieces” are selected first for sprint performance – this is how 2—4 weeks Scrum iterations are called. At the end of the sprint, the customer is presented with a working product increment – the most important usable “pieces”. It can be a partially functioning site or application. After that, the project team proceeds to the next sprint. The duration of the sprint is fixed, but the team chooses it independently at the beginning of the project, based on the project and its own performance.
To ensure that the project meets the customer’s requirements, which tend to change over time, the incompleted content of the project and amendments are reassessed before each sprint starts. This process involves everyone including the project team, the project team leader (Scrum Master) and the product owner. Everyone is responsible for this process. Scrum Master is supposed to help project participants better understand and accept the values, principles and norms of Scrum practice. He is the leader and intermediary between the outside world and the team. His has to ensure that no one interferes with the team to work independently and comfortably on assignment. The team is responsible for ensuring that all the necessary tasks are done and the deliveries are completed at the end of the sprint. The main structure of Scrum processes is based on 5 main meetings:
• Backlog;
• Sprint planning,
• Daily meetings;
• Sprint review;
• Sprint retrospectives.
Backlog Refinement Meeting (“Backlog Grooming”) is a meeting similar to the planning phase in classic project management, and held on the first day of each Sprint. It reviews what has been done within the whole project, what remains to be done and what decision is made to do next. The product owner determines which tasks are of the highest priority at this stage. This process determines the Sprint effectiveness, because this is what the value the customer will receive at the end of the sprint depends on.
Sprint planning: Once the priorities have been determined by the product owner, the team jointly decides what exactly they will do during the upcoming iteration, how to achieve the goal set at the previous meeting. At this stage, teams may apply different planning and evaluation tools, as long as they do not contradict Scrum principles and logic. Sprint planning is carried out at the very beginning of the iteration, after the Product Ordering Meeting.
In a perfect world, Daily meetings are held every sprint day, at the same time. Team members spend 15 minutes to share information about the status of the tasks and the entire project. These meetings are not intended for discussing problems or decision-making. If some questions arise or conflicts occur after the briefing, the Scrum Master and the participants involved discuss them separately. The meetings are needed to share information and keep all team members up to date with the state of the project.
Sprint review is a stage to examine and adapt the product being created. The team presents the results of the activity to all interested parties. Its main task is to ensure that the product of the stage meets the participants’ expectations and is consistent with the project objectives.
Sprint Retrospective is carried out upon the sprint review and before planning the next sprint. The team finds out how clearly and smoothly the stage was implemented. The challenges occurring in operations, methodology and interaction are studied. This stage allows the team to conduct a reflection and to implement the next Sprint more effectively.
SCRUM strength is that it was developed for projects in which “quick wins” are combined with tolerance to changes. This framework is suitable for situations when not all team members have sufficient experience in the field in which the project is being implemented – constant communication between team members compensates the lack of experience or qualifications of some employees due to information and colleagues’ assistance. In my opinion, the main Scrum’s benefit is that one is allowed to “make quick mistakes.” Instead of preparing an expensive and long release, Scrum deliveries every two weeks are quite small. But they are easy to track and, if something goes wrong, fix it quickly.
SCRUM weakness is that it is very demanding for the project team. It should be small (5—9 people) and cross functional, which means that team members should have more than one competency required for the project implementation. For example, a software developer must be a tester and business analyst at the same time. This is done to keep all the team “busy” at different stages of the project, and so employees would help and replace each other. In addition, team members must be “team players”, be able to take responsibility and self-organize.
To hire such a mature team is very difficult! Scrum is not suitable for all teams and organizations because the process proposed may not be suitable for the development of a specific product – for example, an industrial machine or a building.
KANBAN Project Management Methods
KANBAN is also a flexible, iterative-incremental approach to project management based on Agile ideas. It is the opposite of the “SCRUM” method. The main features of the technique are:
• Each project participant assumes a limited number of assignments independently, without the manager’s direction;
• The assignment is registered in Sticker;
• The number of “unfinished” work (WIPs) is limited for each stage;
• A new assignment is taken only upon completion or “extension” of the current one (LEAN);
• More attention paid to management of change, visualization of gaps, incomplete work, etc.
• Limitations on WIPs number and their status.
LEAN looks a bit abstract, but being combined with KANBAN, it is much easier to use to build your own project management system. KANBAN is very similar to the industrial production flowchart. A piece of metal entering the process in the very beginning becomes the finished part at the very end. The increment of the product in KANBAN is transferred from stage to stage, resulting in the ready item for delivery. The main principle is to keep in store only stuff required by the customer. Therefore, KANBAN allows leaving an incomplete assignment at one of the stages, if its priority has changed and there are other urgent tasks to do – all this is OK for KANBAN.
KANBAN is much less strict than SCRUM since it does not restrict the time of sprints, or has any roles, except for the product owner. KANBAN even allows a team member to carry out several assignments simultaneously, while SCRUM does not. In addition, meetings on the project status are not regulated – one can do it in a convenient schedule, not to do it at all.
Working with KANBAN requires identification of workflow stages, which are presented as columns where assignments are indicated by stickers. The stickers are transferred from stage to stage, as parts are transferred from machine to machine within the factory. The completion level on each stage increases. The output is a product element ready for supply to the customer. A board with columns and stickers can be physical or electronic since KANBAN does not restrict its users. KANBAN system can be as flexible as you want it to be as KANBAN is a visualization of AGILE idea of in many ways.
KANBAN has four pillars to support the whole system:
• Stickers: Each assignment has an individual sticker, containing all required information on the assignment. Therefore, all required information is available at all time.
• Limited number of assignment per stage: The number of stickers per stage is strictly regulated. Thanks to this, a “jam” in the workflow is clearly visible and promptly eliminated.
• Continuous flow: Tasks from the backlog get into the flow in order of priority. Thus, the work never stops.
• Continuous Improvement (kaizen): The concept of continuous improvement was first implemented in Japan at the end of the 20th century. Its essence is the constant analysis of the production process and the search for ways to increase productivity.
Strengths – Like SCRUM, KANBAN is well suited for a well-knitted team with good communication. But unlike SCRUM, KANBAN does not have a clear timeframe, which is more appropriate for motivated and experienced teams. If adjustment and management are proper, KANBAN can be of great benefit to the project team. Exact calculation of the load on the team, the correct placement of restrictions and concentration on continuous improvement – all this allows KANBAN to save resources, stay within the schedule, and budget. And all above-mentioned is spiced up with flexibility.
Weaknesses – one can often hear that KANBAN, unlike SCRUM, suits nearly any team. But this is a false statement. KANBAN is best suited for teams whose members have overlapping skills. So, they can help each other overcome difficulties in solving problems. Otherwise, Kanban will not be as effective as it could be. As mentioned before, KANBAN is better suited in cases with no strict deadlines. The project with strict deadlines is better managed by classical approach or SCRUM.
Hybrid Project Management Methodology
Even though many teams prefer either a waterfall methodology or AGILE design, the benefits of both approaches have led to the emergence of a hybrid methodology where the stages of planning and definition of are carried out according to the waterfall methodology, and the design, development, implementation, and evaluation phases correspond to a flexible approach. This methodology is an attempt to apply the strengths of each main approach, as well as reduce the negative impact of weaknesses. The hybrid methodology can be well-applicable to IT since the project has well-defined goals at the managerial level, is well documented, and provides the ability to monitor the project status to report to the leadership. During implementation, the project assignments are well detailed and understandable to the developers due to the high communication level between business representatives and executors. The opportunity of on-job learning, making mistakes and improving the product to the current business requirements is equally good for developers and businesses. Of course, everything has to be paid for. This approach imposes requirements on both the technical level of employees training and their personal qualities.