International Defense Security & Technology Your trusted Source for News, Research and Analysis
In the dynamic world of software development, the need for efficient and effective project management methodologies has never been greater.
Traditional waterfall approaches, with their rigid processes and limited adaptability, struggled to keep up with the ever-evolving demands of the industry. However, the emergence of Agile and Scrum methodologies has revolutionized software project development, becoming the driving forces behind modern software projects. In this article, we will explore how Agile and Scrum have reshaped the landscape of software development and why they have become the dominant methodologies in the field.
Traditional Software Development
In the middle of the 1990s, the common way of developing software was a heavyweight software development methodology with a sequential life cycle approach called “the Waterfall,” comprising of writing complete requirements, documentation of design and architecture, followed by coding, and then the whole product was tested, based on a detailed test plan.
Someone, usually the business analyst, first wrote a business requirements document that captured everything the business needed in the application. These business requirement documents were long, detailing everything: overall strategy, comprehensive functional specifications, and visual user interface designs. Technologists took the business requirement document and developed their own technical requirements document. This document defined the application’s architecture, data structures, object-oriented functional designs, user interfaces, and other non-functional requirements.
This waterfall software development process would finally kick off coding, then integration, and finally testing before an application was deemed production-ready. The whole process could easily take a couple of years. It was the general notion that this was the only way of keeping projects on schedule and out of trouble, and if projects were facing problems, the belief was that all would be well if the methodology was strictly followed.
However, due to the rigid nature of the Waterfall approach, time estimates were often unreliable, as they did not accommodate for any unexpected events or changes. This approach also put great emphasis on documentation. This resulted in overly detailed requirement documents that would not be read, and when they were, they often resulted in a misinterpretation of the information. High effort and costs for writing and approving documents for each development phase. The waterfall model increases lead-time due to that large chunks of software artifacts have to be approved at each gate. Extremely hard to respond to changes, When iterating a phase the iteration takes considerable effort for rework.
Big-bang integration and test of the whole system in the end of the project can lead to unexpected quality problems, high costs, and schedule overrun. The final result was products that did not reach their full potential and projects that finished late, due to unrealistic time estimates or changes in the project that could not be avoided.
The customers rarely or never used over 60% of system features and functions. Lack of opportunity for customers to provide feedback on the system. This can be explained by the fact that requirements were based on the initial customer needs and were not changed throughout the process. When the system is put to use the customer discovers problems of early phases very late and system does not reflect current requirements.
Innovation and product development is the cornerstone to organizational growth in the market environment today. But for new product development the stakes are high, requirements increasing and there is a demand of delivering faster in order to beat the competition to the market. New product development is a complex endeavour, which can often be difficult to handle and challenging to see in advance what the end result will be. There is great uncertainty and unexpected things happen along the way, which affects the scope and direction of a product development project. Therefore these projects can often be difficult to plan, and plans become obsolete soon after their creation.
Agile methodology
From those principles was born the agile methodology for software development. Agile is a framework that can be customized to meet the needs of organization.
Agile methodology is an iterative and incremental approach to software development that emphasizes flexibility, collaboration, and adaptability. It values individuals and interactions over rigid processes and tools, focusing on delivering working software that meets customer needs. Agile methodologies embrace change and encourage continuous feedback and improvement throughout the development cycle.
Agile Software Development became a collective term for the new methods, which are all based on iterative and incremental development, self-organizing cross-functional teams, and rapidly responding to change. Agile Software Development is based on an iterative life cycle. This means that in one iteration cycle, an increment of the software is analysed, designed, built and tested. By the end of the iteration, the software increment is fully usable. These increments build up over time to form the final product.
This method allows for quick and economic reactions to changes and errors that come up throughout the process. The incremental deliveries of a “finished” product ensure that there is always a potentially useable version of the functioning product available. Halfway through the Waterfall process, there is no usable code or product ready, while the Agile methods would have 50% of the final product finished and usable. This is related directly to when testing is performed in the process. It emphasizes the importance of testing continuing throughout the process, as it allows for proactive measures when it comes to errors and software bugs.
Agile engineering saves companies not only time, but also money in the long run. The agile method in product development has a higher startup time and initial cost, but the cost per final product is low.
Another benefit of agile engineering is that it encourages teams to fail quickly. By failing faster, teams learn and improve at a faster pace than those that do not. Learning from failure through prototypes helps companies quickly build better products. By validating assumptions and collecting data, these products are made in a more accurate, evidential way. Plus, the end product is shaped by market demands, ultimately yielding greater profit.
An agile software development process always starts by defining the users and documenting a vision statement on a scope of problems, opportunities, and values to be addressed. The product owner captures this vision and works with a multidisciplinary team (or teams) to deliver on this vision. Agile processes always begin with the user or customer in mind.
Above all, Agile is a mindset and it’s a set of values and principles. Agile is a way of thinking and acting. Agile is all about short cycles, iterative and incremental delivery, failing fast, getting feedback, delivering business value to customers early, and about people, collaboration, and interaction. Agile is a mindset that is all about transparency, inspection, and adaptation.
Scrum, Kanban, and other agile frameworks
These methods have received good reviews from the industry and many large companies use them in their development today. Many agile frameworks that provide specifics on development processes and agile development practices, aligned to a software development life cycle. The most popular agile framework is called scrum, and is currently being used by companies such as Yahoo!, Microsoft, Google and more.
Scrum
Scrum is described as “an iterative, incremental framework for projects and product or application development”. The Scrum Guide defines Scrum as a framework for developing, delivering, and sustaining complex products.
The three pillars of Scrum are: Transparency, Inspection, and Adaptation. Transparency means that we make the most significant aspects of our work visible to those responsible for the outcome. Everyone must be transparent. This includes everyone from Scrum
Team members to senior sponsors, and even our users. In terms of transparency outside of the team, being transparent with all stakeholders, including customers, sponsors, and management builds a level of trust between everyone involved.
Inspection refers to conducting timely checks towards the outcome of a Sprint goal to detect undesirable variances. This means that we’re always checking in on our progress and deliverables so that we can detect any undesirable changes.
Adaptation means that we’re continuously searching for ways to adjust our project, product, or processes to minimize any further deviation or issues. Although adaptation includes immediate fixes to problems, it may also be about implementing a change so future projects don’t repeat past mistakes.
The five values of Scrum are: Courage, Commitment, Focus, Openness and Respect
In order for a team to succeed, it is incredibly important that every team member follow these core pillars and values.
Scrum Roles
There are three roles in Scrum, the Product or Project Owner, the Scrum Master and the Team. Together these three roles form the Scrum Team.
The product owner is the voice of the customer, prioritizes the sprints, and prioritizes the backlog. The product owner accepts the work and approves releases. The Product Owner is the person that is financially responsible of the product, someone who is required to be the voice of the customer, including any internal stakeholders.
The Product Owner ensures value is delivered to the business and accepts the work the team delivers. That person prioritizes items according to the needs of the product and the stakeholders.
Product Vision: That person distills all the insights, ideas, and feedback to create a product vision. These product visions are often short and straightforward, but they nonetheless paint a picture of who the customer is, what values are being addressed, and a strategy on how to address them. His or her responsibility is to define this vision and then work with a development team to make it real.
Product Vision
The Product vision describes the purpose of a Product, and the problem the product is solving. It describes the future state of the solution or what ambitions it tries to fulfill. The Product Vision must support the strategic enterprise objectives. The Vision contains detailed information on the highest priority features and functionality.It also describes the customers and market being served and any capabilities planned for later releases. The Product Vision addresses the needs of the customer and describes how the product will make the customer’s life better. Additionally, price points may be described.
Product Backlog and User stories
To work with the development team, the product owner breaks down the product vision into a series of user stories that spell out in more detail who the target user is, what problem is being solved for them, why the solution is important for them, and what constraints and acceptance criteria define the solution.
The Product Backlog is a listing of all the capabilities, features and functionality that will be built into the product, or solution. The capabilities and functionalities in the product backlog are broken down to very clear, very testable, very well understood user stories that can be quickly built, quickly tested and quickly delivered.
The User Stories are ranked in the Product Backlog based on business priority. The Sprint Backlog is also the Sprint Plan. It is the set of selected User Stories prioritized for the sprint. it is a subset of the Product Backlog. The sum of the estimated story points in the Sprint Backlog must equal the team’s Velocity, or Capacity.
Some of the lower priority features and functions will be a little more coarsely defined. But as the higher priority user stories are delivered, the team actually begins to look at the stories that are listed lower in the backlog and begins to break those down into deliverable user stories.
The Release Backlog is similar to the Sprint Backlog, or Sprint Plan. It is a set of select User Stories that make up a planned Product Release. The idea is that the user community expects certain features to be part of a product release. The User Stories make up the features in the planned release.
User Stories: User stories are widely used within Agile Software Development. A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects:
• A written description of the story used for planning and as a reminder
• Conversations about the story that serve to flesh out the details of the story
• Test that convey and document details and that can be used to determine when a story is complete”
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.
These user stories are prioritized by the product owner, reviewed by the team to ensure they have a shared understanding on what is being asked of them.
In agile user stories are further broken down to tasks. The acronym SMART is sometimes applied to determine if a task or work product is a good size. The letters in SMART can stand for many things, but it generally means that a task should be:
• Specific (the task should be clear and should not overlap with other tasks)
• Measurable (the task should have a definite way of being marked as finished or done). The acceptance criteria is a way of determining that the story is working correctly.
• Achievable (one person should be able to do the task) : Commitments are what you agree to deliver. Commitments are where negotiations can happen. Based on both estimates and targets, a commitment can be negotiated. Story points were developed as an alternate system for estimates. Instead of estimating how much time work will take to finish, story points are an assigned value that look at how long it will take to finish a piece of work in relation to other pieces of work
• Relevant (the task should be within scope of the project)
• Time boxed (the task can fit within a certain time frame)
These days, a lot of brands of Agile and Scrum are actually moving away from breaking stories down into tasks. But very very often now, teams are encouraged to break the stories down so small that they don’t need to be broken down into tasks. Therefore, we see especially these days, task breakdown is optional.
In Agile or in Scrum, there are enablers called spikes. A spike is a team activity or a team-member activity where it’s a work effort, but no stories are implemented, they are learning activities. Team members may have to do their own research, they may have to try a few things, they may have to go to formal learning. All of this learning activity is the spike, this is the value add.
The Scrum Master is the coach of the Scrum process. The Scrum Master is a person with experience in Scrum and he or she supports the Product Owner and the Team in complying with the Scrum rules.The Scrum Master facilitates the Scrum meetings, motivates the team and supports the team to meet their goal. The team’s ultimate goal is a working solution increment at the end of the sprint. The Scrum Master also protects the team from external interruption, in order for the team to be focused on their work. Scrum Master also has a variety of soft skills including creativity, dealing with conflict, persuasion, being a great collaborator, and adaptive and emotional intelligence.
Scrum team is a group of approximately seven people that executes the prioritized tasks and develops the final product. The Scrum team performs the analysis and design of the User Stories. The team collaborates on solution design and approach.
In agile, the development team and its members’ responsibilities differ from those in traditional software development. The Scrum team is cross-functional and self-organizing. Cross-functional refers to the fact that all members of the team can assist each other in some way if needed.
Teams are multidisciplinary, composed of a diverse group of people with the skills to get the job done. Because the focus is on delivering working software, the team has to complete end-to-end functioning applications. In addition to developers, software development teams can include quality assurance (QA) engineers, other engineers (such as for databases and back-end systems), designers, and analysts, depending on the type of software project.
The self-organizing aspect means that the team members collaborate among themselves to assign User Stories and other tasks to the team members. The Scrum team also builds the product and attends and participates in the Scrum meetings.
Some Scrum team responsibilities:
- Breakdown the User Stories in the Product Backlog.
- Collaborate the with the Product Owner and Scrum Master.
- Collaborate with other teams if needed.
- Architect and design how the product is built.
- Build the Product User Stories.
- Integrate team work using DevOps.
- Test the User Stories Built.
- Deploy the Product.
Sprints Events and Meetings
A vision planning /Epic meeting, is a the whole project, whole deliverable, completed product meeting where the vision is described, what the solution is, who the customer is, all known capabilities and the backlog. This is really where the team is introduced to the overall product, the vision of the solution or the future state. From here, the team begins to look at the prioritized features and begins to break them down into the user stories. The Vision/Epic meeting results in several follow meetings called Backlog Refinement meetings. The Backlog Refinements meetings is where the User Stories are written, and estimated. The User Story acceptance criteria is added during Backlog refinement.
The development work is performed in cycles called Sprints. Each Sprint can be from 1 to 4 weeks long, and are iterated without a pause. The sprint begins with a meeting called the sprint planning meeting. This is where the team, the Product Owner and Scrum Master validate the User Stories to be built. The team also validates its current capacity during this meeting.
Scrum meeting structures include the following:
- Planning — where sprint priorities are identified
- Commitment — where the team reviews a list or backlog of user stories and decides how much work can be done in the sprint’s duration
- Daily standup meetings — so teams can communicate updates on their development status and strategies
The Daily Stand Up is conducted everyday of the sprint. The spring end meetings are the sprint review and the sprint retrospective. The next sprint begins after the current sprint concludes.
Sprint planning: The Sprint Planning meeting is held on the first day of the sprint, before any work begins. This meeting is facilitated by the Scrum Master, and the time box is typically 2 hours. When a sprint is planned, the team has had or should have had through working on the vision.
Every sprint planning meeting agenda should include discussions about the ultimate objective of the sprint, “How can we deliver a working solution increment by the end of the sprint”. At the start of a Sprint, the team commits to what work items they will complete by the end of the upcoming Sprint.
Prioritization: The team chooses from a list of items, called the Product Backlog that has been prioritized by the Product Owner based on business priority. This prioritization is based on input from all stakeholders of the product.
Many features can be prioritized by the Product Owner without analysis. There are industry standards, customer expectations, competing products, and other factors. The MoSCoW method of Backlog Prioritization in based on: Must have, Should have, Could have Won’t have (this time).
The difficulty comes when features seem about equal in business value. Agile gives us a way to look at these about equal features and prioritize them for the best economic outcome. The technique is called Weighted Shorted Job First, or WSJF. With WSJF we can sequence features for the optimal economic outcome. When using WSJF, we want to prioritize the features that are valuable, but are short in delivery time. This way the we can the business benefits sooner.
But during the sprint planning meeting, the team validates the prioritized stories that there’ll be working on, puts a plan together, estimates the stories if needed, and really decides how they are going to go about completing and delivering that working solution.
Velocity and Capacity : The first order of business is for the team to validate its capacity.
Velocity: A team’s velocity is the number of story points that a team can complete in a single sprint. Velocity is not productivity, or a team’s rating. Velocity is used for estimation. Velocity is influenced by product, work type and team size. Velocity is measured as an average.
Teams typically use Capacity from sprint to sprint. The team’s capacity is very similar to the team’s Velocity. The difference is that the team accounts for the team’s current availability for the sprint. Team members may not have the same availability sprint to sprint.
Additionally, in an initial PI Planning, it is likely that some of the teams will be new and will not have a historical velocity to use in order to predict their capacity for the iteration. The approach below can be applied in these situations: For every full-time developer and tester on the team, give the team 8 points (adjust for part-timers) Subtract one point for every team member vacation day and holiday in the iteration
Next the Product Owner discusses the currently prioritized User Stories. The team reviews each of the prioritized User Stories, and makes sure each one is clear, estimated and has acceptance criteria. Once the User Stories are selected, they are formally entered into the team’s sprint plan.
Effort Estimation
In Agile, and Scrum, User Stories are typically estimated in Story Points. Story Points estimation involves estimating the time, complexity, the volume of a User Story, against the other User Stories in the Backlog. Story points are a relative estimate. Collaboration is the base technique in estimating stories. The team needs to discuss and agree on story estimates. Planning Poker is an exercise that where the team must collaborate. Planning poker is also very efficient
When using Story Points, the scale follows a pattern called the rounded, or modified Fibonacci scale: 1, 2, 3, 5, 8, 13, 20, 40, 100. The rounded Fibonacci scale provides advantages when it comes to uncertainty. Any User Story estimated at 13, or below is considered to have a high level of certainty. Any User Stories estimated 20 points or higher, is considered to have significant levels of uncertainty. Agree on the relative comparison: The team needs to reach that consensus when comparing stories.
The total estimate User Story load should match the team’s capacity. Once the Sprint Planning meeting adjourns, the Scrum Master can build the sprint’s Scrum board, and prepare for any report generation.
The daily stand-up meeting happens every day. During a Sprint 15-minute, Daily Meetings are held. This is a way for the team members to communicate to each other what their status is.
The purpose of a Daily standup meeting is to learn the current progress of every team member that works on Scrum User Stories, tests, or other tasks. Each team member communicates the following; what they have done since the last meeting, what they are going to do now, and if there are any impediments in their way. This allows other members to offer their help, but further details will continue after the Daily Meeting.
All other technical or more detailed discussions can be taken up after the meeting. Daily stand up meetings align team members around company goals and let them address any short-term challenges that prevent team members from effectively performing their sprint tasks.
When a Sprint has started, no changes can be made to the committed task list, nor can the Sprint be elongated. The Sprint will finish on a set date whether or not the Team has completed what it had committed to. The idea is that a working product increment will be ready by the end of a Sprint. That is, a part of the final product is done or finished. The definition of “done” is of high importance, as in the case of software development, the product has to be fully tested and integrated and ready for use to be considered “done.”
The team’s progress is continuously and openly tracked by Scrum Boards, and Scrum reports. The sprint also involves integrating the work of each team member typically using good DevOps practices. A sprint is developed and tested in a parallel fashion. This means that testing is not a separate phase but an integral part of the development process. The main aim of the testing team is to ensure the early identification of bugs, issues, and defects.
The Definition of Done: The Definition of Done (DoD) is an agreement between the Scrum Team and the business that certain items will be completed before a User Story can be considered done. The minimal DoD is building the User Stories and testing each User Story. More sophisticated DoDs can, not only, include testing, but also include Product Increment documentation, running regression tests, and checking code into team repositories. The Scrum Master and the Product Owner will validate that the DoDs are met for each sprint. The DoDs are reviewed in the Sprint Review meeting.
Backlog Refinement: Backlog refinement (formerly known as backlog grooming) is when the product owner and some, or all, of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.
The main goal of the Backlog Refinement meeting is to ensure there are ready User Stories for the next sprint and sprints beyond the next sprint. Therefore we are looking to make sure there is no downtime between sprints due to lack of ready User Stories.
The Backlog Refinement meeting occurs at least one time per sprint. The meeting is facilitated by the Scrum Master, with the Product Owner leading the discussion on the Product Backlog and User Stories. This is the team’s one formal opportunity to look ahead to User Stories in the next sprint, and sprints after the next sprint.
The agenda for this meeting is for the Product Owner to review each of the User Stories prioritized for the next sprints. The time box is 1 to 2 hours. The team asks questions about the User Stories, splits the User Stories, estimates them, and makes sure acceptance criteria is added, or assigns someone to add acceptance criteria.
Splitting Stories: Before a user story is ready to be scheduled for implementation in an upcoming sprint, it should be “small enough,” the usual rule of thumb being “a story that can be completed within the sprint”. However, many user stories start out larger than that. “Splitting” consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.
Workflow paths: Split the Story by workflow path. Implement 1 path at a time.
Interface: Build the stories based on interface, web, android, and iOS.
Collaboration: Discuss with the team how to split the story.
Sprint Review and Retrospective: The sprint ends with a demo meeting where the functionality is shown to the product owner, followed by a retrospective meeting where the team discusses what went well and what needs improvement in their process.
At the end of a Sprint, a Sprint Review is held that focuses on the product. One part of the Review is a demonstration of the finished product part to all stakeholders. However, the main purpose of the Review is an in-depth conversation about the product between the Team members and the Product Owner, on the status as well as getting advice. The time box for this meeting is 1 hour to 90 minutes. During the Sprint Review meeting, each User Story is demoed, along with any knowledge gained from Spikes. This is the formal chance for the Product Owner to accept the User Stories, and/or request that the team change something that was implemented during the sprint.
An important part of Scrum is “inspect and adapt”. The retrospective meeting focuses on inspecting and adapting the process and is facilitated by the Scrum Master. There the Team can identify how the process can be improved. After reviewing the previous retrospective action items, the meeting focuses on the following questions: What went well? What did not go well? What can we improve in the next sprint? The best way to do this is to gather answers in a round-robin so that everyone has a chance to express himself or herself. A final question is suggested to gauge team happiness: What is one thing that will make you happier in the next sprint? This question will often find people’s deep-seated concerns about the project.
Scrum reports
Burndown charts reveal how quickly your team is working by displaying how much work is left and how much time remains to complete the work. The Burndown chart has an estimation line, and an actual values line. Actual data above the estimate line indicates the team is running behind plan. Actual data below the estimate line means the team is running ahead of plan. If the team is consistently running behind plan, the Scrum Master needs to work with the team to move some Stories to the next Sprint. The team needs to recalculate how they will deliver a working solution from the Stories they can complete.
The main uses of a Burndown chart are to keep the project team on top of targeted completion dates and make them aware of scope creep if it occurs. In the Daily Scrum, the Development Team updates the Sprint Burn Down and plots the remaining work of the day.
Burnup Charts: Burnup charts, or reports deliver and track data on work completed during the iteration. The completed work and total work is shown on the vertical axis in whatever units a project team feels works best: work-days, story points, or any other work unit. The horizontal access displays time, usually in days, weeks, or sprints. Burn up charts allow Scrum Masters and teams to quickly see how their effort is progressing.
Velocity Charts: The Velocity chart tracks the number of points a team delivers per Sprint. The Velocity chart also averages Velocity per Sprint to report the team’s average velocity. The Velocity Chart typically includes the team’s estimated Velocity. Therefore the team can measure its estimation accuracy.
A Cumulative Flow Diagram (CFD) is an area chart that shows the various statuses of work items for an application, version, or sprint. The horizontal x-axis in a CFD indicates time, and the vertical y-axis indicates cards (issues). Each colored area of the chart equates to a workflow status (i.e. a column on your board). The CFD can be useful for identifying bottlenecks. If your chart contains an area that is widening vertically over time, the column that equates to the widening area will generally be a bottleneck.
And it provides a concise visualization of the three most important metrics in your workflow cycle time. So you can see here how when an item enters the workflow, and when it leaves and begins the next workflow, throughput, and we can see also work in progress.
The Defects Trend Chart plots Total Defects, Open Defects, and Fixed Defects. The X-axis is time (ie. Sprints), Y-axis is the number of defects.
Agile practices
While agile frameworks define process and collaboration, agile development practices are specific to addressing software development tasks performed in alignment with an agile framework.
Visual Management: When the sprint has started, engineers need a tool to communicate within the team about what task they are working on (in case there are dependencies), as well as their status. A dashboard is an effective way to track tasks and communicate status. You can use sticky notes on a wall, but you can also use Excel or digital tools like Trello, Axosoft and Jira. The tasks, written on post-it notes, move across the board’s columns during the Sprint. These columns are often labelled “To Do”, “Work In Progress”, and “Done”.
Planning Poker: Planning poker is not prescribed in the core literature on Scrum but is also a widely used technique for relative estimating of stories or work items, using points as a relative unit, Some teams adopt pair programming, where two developers code together to drive higher quality code and to enable more senior developers to mentor junior ones. More advanced teams adopt test-driven development and automation to ensure the underlying functionality delivers the expected results. Many teams also adopt technical standards so that the developer’s interpretation of a user story doesn’t lead to just the functionality desired but also meets security, code quality, naming conventions, and other technical standards.
Kanban
Although scrum dominates, there are other agile frameworks: Kanban is a workflow management method for defining, managing and improving services that deliver knowledge work. It aims to help you visualize your work, maximize efficiency, and improve continuously.
Kanban works as a fan-in and fan-out process where the team pulls user stories from an intake board and funnels them through a staged development process until they are completed. Some organizations adopt a hybrid agile and waterfall approach, using agile processes for new applications and waterfall for legacy ones. There are also several frameworks to enable organizations to scale the practice to multiple teams.
You can start building your Kanban system by setting up the most straightforward Kanban board with three basic columns – “Requested”, “In Progress” and “Done”. When constructed, managed, and functioning correctly, it serves as a real-time information repository, highlighting bottlenecks within the system and anything else that might interrupt smooth working practices.
One of the main goals when implementing a Kanban system is to create a smooth, healthy flow. Instead of micro-managing people and trying to keep them busy all the time, you should focus on managing the work processes and understanding how to get that work faster through the system. This would mean that your Kanban system is creating value more quickly. One of Kanban’s primary functions is to ensure a manageable number of active items are in progress at any one time. If there are no work-in-progress limits, you are not doing Kanban.
Lean Project Management
Lean project management is the application of lean manufacturing principles to the practice of project management. The goal of lean project management is to maximize value while minimizing waste. The Project Management Institute sums it up: “To be Lean is to provide what is needed, when it is needed, with the minimum amount of materials, equipment, labor, and space.”
Organizations that use lean project management can expect: Reduced lead times, Lower inventory and storage costs, Decreased overall costs, Improved productivity and efficiency, Greater quality, and Higher customer satisfaction.
First published in 1996, the book Lean Thinking by James P. Womack and Daniel T. Jones introduced five key principles that can be used to apply the lean concept to project management.
- Specify value: What is the project’s value in the mind of the customer?
- Map the value stream: A “value stream” map shows the entire process for creating the product or project. Once this process is mapped, it can be analyzed for waste, such as unnecessary steps that tax resources or compromise quality.
- Make value flow by eliminating waste: Creating an improvement plan will eliminate the waste identified in the value stream. This plan represents a “future state” for the project’s process.
- Make value flow at the customer’s demand: The ideal scenario is to move the project forward or create the product when requested by the customer. Get as close to this as possible to reduce inventory and save resources.
- Embrace continuous improvement in pursuit of perfection: Regularly reassess the project process to eliminate waste and maximizing productivity and efficiency.
Benefits of Agile and Scrum:
Increased Adaptability: Agile and Scrum allow development teams to respond quickly to changing requirements, market conditions, and customer feedback. The iterative nature of these methodologies enables teams to continuously refine and adjust their approach, resulting in more relevant and valuable software.
Enhanced Collaboration: Agile and Scrum promote collaboration among team members, stakeholders, and customers. The daily stand-up meetings and regular sprint reviews foster open communication and transparency, leading to better alignment and understanding of project goals and progress.
Faster Time-to-Market: Agile and Scrum methodologies promote incremental delivery of working software. By breaking the project into manageable sprints, development teams can release functioning features or modules earlier, reducing time-to-market and enabling quicker feedback cycles.
Improved Quality: The continuous feedback loops and regular testing in Agile and Scrum contribute to higher software quality. By addressing issues promptly and conducting frequent reviews, teams can identify and rectify defects early in the development process.
Industry Adoption and Success Stories:
The dominance of Agile and Scrum methodologies in software project development is evident from their widespread adoption across the industry. Numerous organizations, ranging from startups to large enterprises, have embraced Agile and Scrum, reporting significant improvements in productivity, customer satisfaction, and project success rates.
Success Factors in Deployment and Sustaining of Agile Methods
Pikkarainen et al. (2012) presented a study on successful Agile deployment focusing on strengths and barriers. They stated the following in regards to management support and tailored process models: “The analysis revealed the importance of management providing the necessary goals and support for agile development. It also indicated the significance of defining a tailored process model and giving developers the freedom to improve their own agile development process continuously during agile deployment.”
They further gave four recommendations to managers the following that should be taken into account when planning an Agile deployment, which were:
1) Make sure that the management is committed and gives continuous support for agile deployment
2) Make sure that both team, management and all stakeholders has a clear vision, understanding and awareness of agile methods
3) Give the needed freedom to the teams to tailor the agile methods to make [them] better fit to their specific needs
4) Make the continuous tailoring of the agile based process model also in the organizational level”
In regards to sustaining usage of Agile Methods, Senapathi and Srinivasan identified and presented nine critical factors that have impact: Management Support, Attitude, Motivation, Team Composition, Training, Agile Mind-set, Technical Competence and Expertise, Agile Engineering Practices, and Methodology Champion. They conclude that their findings indicate the following: “Our findings also indicate that the right balance and combination of various factors with an emphasis on continuous improvement will be crucial for achieving true agile sustainability in organizations.”
Water-scrum-fall
One model that makes waterfall and agile get along is the Water-scrum-fall model. Business analysis and release management teams follow the traditional waterfall methods, while the development and testing team scrum methods in a limited way. Water-scrum-fall method employs the traditional waterfall approach for planning, requirements gathering, budgeting and documenting the project’s progress. When there are enough details to begin development, the team switches to a timeboxed, iterative version of Scrum for product development. This method uses agile principles and scrum communication techniques in day-to-day activities related product development.
Organizations use water-scrum-fall model when they want details in the planning phase so they can make accurate estimations of the budget. If a project initial phase is carried out in a plan-driven way, it is more likely to convince management about the idea and they will feel secure when allocating funds. Another reason for adopting water-scrum-fall model is the tendency of developers and testers to instinctively turn to agile practices during development. This happens because agile practices empower them and give them opportunities to collaborate as required by the limitations of the project.
Agifall
Agifall approach was first presented at Vancouver Digital Project Managers Meetup Group. It combines the best of waterfall and agile by injecting the agile into a loose waterfall process. The aim of Agifall is to increase the speed, decrease the cost and improve the quality. Agifall approaches planning in a user-centric manner and use quick prototype tools. It carries the planning and requirements activities of waterfall in an agile manner by breaking them into user stories and prioritizing them in the sprint. In the Agifall method, you don’t wait for one phase to complete before starting the next phase; rather you begin the next phase as soon as you can. This means that you can begin independent development of some modules or components while the planning phase is still in progress. The development phase follows the usual agile principles. Agifall model suggests graphic designing and testing in parallel with the development phase.
Hybrid can go right or wrong:
The agile-waterfall hybrid model is far from perfect compromise. The elaborate documentation and completion of each phase required by waterfall methodology would be rather a burden to complete during a single agile sprint. The evolution of techniques such as backlog management instead of comprehensive documentation is one of the best examples of successful adoption of hybrid model. The hybrid model is best suited for projects which demand the team to deliver constantly changing requirements within a limited time frame. When a test team manager or lead has to adopt a particular method during the planning phase, the best way to proceed is to select the method that best suits the project needs. Moreover, the team needs to have a clear understanding of the hybrid model and implementation methodology, otherwise there’s a real possibility that it will make a mess of the project, and no benefits would be reaped.
Overcoming Challenges:
While Agile and Scrum offer numerous benefits, implementing and adopting these methodologies can present challenges. Resistance to change, lack of proper training, and difficulties in maintaining stakeholder involvement are common obstacles. However, with proper planning, training, and a commitment to continuous improvement, these challenges can be overcome.
Conclusion:
Agile and Scrum have emerged as the driving forces behind modern software project development. Their emphasis on adaptability, collaboration, and continuous improvement has transformed the industry by enabling faster delivery, improved quality, and increased customer satisfaction. As software development continues to evolve, Agile and Scrum methodologies are likely to remain at the forefront, shaping the future of project management in the digital age. By embracing these methodologies, organizations can position themselves for success in an ever-changing and competitive landscape.
