It’s Agile week at Productivity Land. Steve decided to explore agile project management and come up with a beginner’s guide for his blog post earlier. Therefore, I decided to go more in depth and build a more comprehensive guide on agile methodologies.
I wanted this to be a one-stop learning guide for everything related to agile methodologies, their core values, principles, roles and responsibilities, and more.
After going through this guide, you should be able to:
- Understand the 6 most common types of agile methodologies,
- Distinguish between the 6 commonly used agile methodologies,
- Understand team roles and responsibilities when it comes to agile project management
- Have more context about the history of each one of them
Types of Agile Methodologies
Agile methodologies comprise a variety of frameworks that focus on a broad range of project management chambers – streamlining collaboration through Kanban, simplifying complex projects through SCRUM and improving software quality by employing Extreme Programming.
Each agile methodology functions on the 12 main principles concocted by the Agile Manifesto, with technical disparities in their characteristics, features and the model on which they function.
Here are the 6 most commonly used Agile methodologies we are going to explore in this blog post:
- Extreme Programming (XP)
- Adaptive Software Development (ASD)
- Crystal Methodologies
- Dynamic Systems Development Method (DSDM)
Created and first conceived of by Jeff Sutherland and Ken Schwaber, Scrum is a lightweight process framework that utilizes and applies agile project management in its most rudimentary form, that is, Scrum focuses on breaking down complex software development into small iterations called Sprints.
What are Sprints in Scrum Project Management?
A Sprint is a time-boxed period that lasts between two to four weeks. Each Sprint is marked with milestones that are the team’s top priority which they work to achieve. These milestones are an effort to release a working, error-free product at the end of the cycle.
Scrum operates on a handful of artifacts that are designed with a single objective of maximizing transparency and providing opportunities for adaptation and introspection. These are:
A Product Backlog is most commonly understood as a defined list of items, values, and requirements that are needed to be added or improvised to the product under development.
A Product Backlog is continuously revised and updated in parallel to the project life cycle.
As the product grows and enters a new stage of development, the requirements, improvisations, and priorities grow with it. This entails regular additions, and changes to be made to the product backlog.
The product backlog provides the Agile project management team insight into what are the key essentials that the product needs to be competitive, useful and satisfactory in the eyes of the users.
A Sprint Backlog is the set of product backlog needed to for a specific Sprint in question. Its main purpose is to demonstrate what the goal of the Sprint is, what needs to be achieved and incremented during those 2-4 weeks of a Sprint.
The duration of the sprint backlog lasts until the Sprint itself comes to an end. The Team working on the Sprint, continuously updates the backlog in accordance with the progress being made during the sprint.
The team enlists the number of items from the Product Backlog, that it will complete or has completed in the sprint and adds it to the Sprint Backlog.
The product achieved at the end of each Sprint is called an increment. As each Sprint aims on delivering the product in an incremental value, the increment should be a working, usable solution gathered at the end of the Sprint cycle, and should be ‘Done’.
An increment comprises of all the priority checklist items present in a Sprint Backlog.
Scrum Team Roles and Responsibilities
For faster product delivery and efficient collaboration, Scrum functions on pre-defined roles. These are:
1. Product Owner
Product Owners are keepers of the product under development. It is their job to understand the market and business value of the product to ensure the right kind of metrics and requirements are being followed.
Responsibilities of the Product Owner
- Prioritizing the kind of work the development team needs to perform in a given sprint
- Update and define the product backlog to keep the scope and objective of the product in alignment with the rest of the team
- Partner with customers and clients, collect their feedback and convey it to the rest of the team
- Optimizing the work completed in each sprint
- Deciding when is it viable to plan product release considering frequent delivery and product quality in mind
2. Scrum Master
The Scrum Master acts as the coach that helps the Product Owner and the team to understand the value and techniques involved in the Scrum Project Management process.
It helps streamline the workflow to align within the guidelines of Agile Project Management. In many ways, the role of the Scrum Master is the backbone of the project.
The Scrum Master works to deeply understand the nature of work being done by the team, and what is required to get the job done successfully.
The Scrum Master is the only role in the Scrum framework that wears multiple hats and has its feet dipped in more than one aspect of the project.
Responsibilities of the Scrum Master
- Helping the Development team understand the values, theories, practices and techniques of the Scrum process
- Assisting the Product Owner update, fine check and document product backlog
- Ensuring that the scope and objectives of the product are clearly understood by everyone on the team
- Ensuring the Scrum events are conducted properly and successfully
- Reducing team conflicts and other impediments that hinder on-time product delivery
- Steering the development team towards the right direction to achieve maximum productivity
- Planning Sprints and keeping a record of how successfully each Sprint is implemented
3. Development Team
The development team consists of various departments – developers, engineers, testers, etc.
The Scrum development team is self-organizing, cross functioning and works collaboratively to help each other in bringing each increment to the ‘Done’ state.
The Scrum development team must share their work with each other with each Sprint to keep each other updated and informed about the progress.
Scrum Development Team Responsibilities
- Teams are self-governing. They are not micromanaged or dictated by the Product Owner or the Scrum Master on how to produce an increment at the end of a Sprint
- Teams are not sub-divided into subordinates. Each team member work as the only expertise
- Scrum development team members are not accountable to any authoritative role
- Teams are cross-functional, that work together to determine the plan for each Sprint and assess the progress that is being made during each iteration
The Scrum Framework
The Scrum framework works on a set of prescribed and regulated events. Each event itself is timeboxed much like the Sprints in which the entire product development is carried out.
Each event in the Scrum life cycle relies on the success status of the objective for the stage.
The Scrum framework is divided into the following components:
Types of Scrum Meetings
1. Sprint Planning Meeting
The Sprint Planning is the first stage that takes place before the start of the project. In this stage, the product owner devises a product backlog and enlists the top priority items that need to be implemented first and foremost.
Whereas, the team plans in what way each of these checklist items will be implemented, what deadline to give and what measures to take for executing them proficiently.
It is during the Sprint Planning that the goal of the Sprint is also decided to centerline the objective.
2. Daily Scrum Meeting
Once the Sprint Planning session has taken place and the work on the Sprint Increment has commenced, the development team meets for daily meetups called Scrums.
These are short meetings of <15 minutes in which the development team assembles to share their progress, concerns, issues and feedbacks needed for meeting the Sprint goal.
The daily Scrums are in some ways inspection of how the collective work is progressing. It is a self-organizing mechanism that empowers teams to be their own managers and enhance their communication by sharing roadblocks, new solutions and strategies.
3. Sprint Review Meeting
At the end of the Sprint, the entire Scrum team gathers for a comprehensive demonstration of the increment achieve at the end of the Sprint.
The demonstration typically includes stakeholders and clients that assess how useable and market-worthy is the product at this stage of the life cycle.
The Product Owner enlightens the stakeholders on what part of the Sprint plan has been ‘Done’.
From this point onwards, the team and clients collectively review and brainstorm on what needs to be done next in terms of product release, with relative focus on budget, timeline and resource capabilities available.
4. Sprint Retrospective Meeting
Before the next planning session of the Sprint, takes place, the SCRUM team performs a sprint retrospective. In the Sprint retrospective, the team discusses:
- The action items that have been implemented successfully
- The action items that have not been achieved
- Rectifying measures to be taken for improvement
2. Extreme Programming (XP)
Like Scrum, Extreme Programming (XP) is another lightweight agile project management methodology, that focuses on adapting change to accommodate client and customer preference.
It was created by Kent Beck in 1999 as an incremental approach to software development with the fundamental emphasis on how the code is written and tested.
Beck’s fundamental idea that classifies XP as an agile methodology is the teamwork and iterative based system where coding, testing and design are taking place asynchronously as the project develops.
Much like Scrum Project Management, there is maximum team collaboration and interaction involved, which however minimizes the need for extensive documentation.
Values of Extreme Programming
Extreme Programming is not simply a methodology operating on a multitude of steps, Kent Beck conceived a group of values to help guide team behavior and understand how to implement Extreme Programming within the paradigm of Agile project management.
The 5 key values of Extreme Programming are:
- Simplicity – workload is divided into smaller compartments to allay the complexity. The team focuses on and accomplishes the given portion of the work at a given time only.
- Effective Communication – Teams work on a collaborative basis, discussing each outcome, drawback, requirements in daily meetings known as standups.
- Consistent Feedback – Teams center and adapt their workflow around feedbacks and changes coming in from clients or customers.
- Respect – Each member of the team is acknowledged for their input and amount of effort contribution made. Regardless of a hierarchy, management respects the developing team, and the developing team respects the customer demand.
- Courage – Teams are encouraged to accept the failures during the project life cycle instead of covering them up with prevarications and lies. The true status of work progress is displayed and shared without any fear of reprimanding accountability.
Rules of Extreme Programming
In 1999, Don Wells published the first XP rules to elucidate the main disciplines of software development in Extreme Programming.
The rules outline the step-by-step activities that are a part of the working XP model.
- Customer creates user stories. These are not overly technical or extensive.
- The duration of each iteration is decided
- A release schedule is formulated
- Project Manager establishes a workspace for his team to start work in
- Project Manager defines and measures project velocity as the project unfolds
- Daily standup meetings are conducted
- Individual performance is monitored and reassigned if any technical or conflicting issues emerge
- Incorporating change if XP methodology does not mesh well with the team members
- Start with a simple design to avoid delays in completion
- Addition of functionality to the design should be reserved for later stages
- Use CRC cards
- Implement Collective Code ownership. Any developer can make changes to the code, identify and fix bugs or refractor.
- Use a system metaphor (where everyone on the team, including the customers and clients can tell how the system works)
- Teams works in pairs of two to write code and send it for production. This is called Pair Programming
- Code integration is done every few hours and stored in the repository
- Run frequent acceptance tests
- Unit testing is performed regularly before code is released
Why is it called ‘Extreme’ Programming?
The practices involved in this lightweight Agile project management methodology are thrust to an extreme.
|Planning||Rigorous customer/client planning before each iteration|
|Simplicity||Each code, design and test is strictly simple|
|Test||Unit testing and persistent regression|
XP Team Roles and Responsibilities
An XP team is made up of 5 roles besides a manager. It is preferable that each role is designated to separate team members.
- A Programmer who writes the code, implements user stories and Unit Tests
- A Coach who oversees the team and makes sure everyone understands the nature of work assigned
- A Tracker who monitors the progress of the development and searches for any roadblocks if any, by visiting each team member and gathering updates on what part of the work has been done and what is pending
- A Doomsayer who keeps an eye out for potential risks and issues and informs the team to prepare accordingly
- A Tester whose job is to test the incremented product during each cycle, report the results and share them with the rest of the team
Kanban is a Japanese word meaning ‘ssignboard. It originated in 1940 by a Japanese engineer Taiichi Ohno working in Toyota Production Systems, to incorporate control over each production phase.
Therefore, Kanban is best recognized as a scheduling system, which grants supremacy over production inventory.
Kanban confines the amount of unfinished work, enabling businesses and teams to prevent a clutter and chaotic confusion that results in loss of inventory track record. Kanban utilizes the just-in-time production approach that enables project managers to keep a track of their resources usability.
Principles of Kanban Project Management
The Kanban method works on 4 core principles that define what the process of Kanban entails and prescribes:
Start with what you do now
Kanban does not work in a procedural manner starting with a first stage and ending in the last step. It can be implemented on any workflow from anywhere in the project’s life cycle. Kanban can be implemented on a project that is already under progress.
Agree to pursue incremental changes
Kanban is designed to support incremental change management. Workflow and team collaboration that employ Kanban approach are encouraged to make small evolutionary changes a part of their work process.
Preserve the existing process, roles and responsibilities
Unlike other methodologies that prescribe a set rule of roles and framework within which a project has to function, Kanban does not mandate the abolishment of old existing process. Teams can continue to work in their existing roles with the same responsibilities as before Kanban was adopted.
This allows harmony to exist between, old working ways that bring value to the business as well as the incremental agile framework of Kanban.
Acts of Leadership at all
The flexible and buoyant model of Kanban allows transparency in the work frame. Since there is no such thing as classified information in Kanban approach, every member of the team is cognizant with the ups and downs of the project that is visually accessible on the Kanban Board.
With this mode of power available for grabs to each team member, Kanban encourages leadership authority at all levels. This requires teams to foster a mindset of continual improvement at individual level.
For successful implementation of Kanban, David Anderson, identified 6 practice steps of Kanban. Practice steps are not sequential steps that need to be followed one after another, rather these are guidelines on how to make the best use out of Kanban.
1. Visualize Workflow
Kanban excels at illustrating team projects and tasks within the projects for quick and efficient insight into the workflow.
2. Kanban Boards
One of the chief components of Kanban, as the original meaning of its name implies, is the Kanban Board. The Kanban Board is a visual representation of the workflow at every given stage of a project’s life cycle.
The board is compartmentalized into three sections: in-progress, completed and requested.
This serves as a real-time inventory that is being continuously updated for any roadblocks, issues and impediments that may be either on-way or a potential threat.
3. Kanban Cards
Each column or a section on a Kanban Board is made up of Kanban cards, placed inside each column. The card holds information such as the details of the task, their progress, who is it assigned to and its due date.
The cards serve as information hubs that are accessible and visible to the entire team. One of the most impressive agile aspect about Kanban is the ability it provides to move cards from one section to another with the help of seamless drag and drop functionality.
4. Limit Work in Progress
One of the best uses of Kanban is to limit the WIP (Work In Progress). Tasks (or in this case Cards), are given a maximum limit that can be reached in a stage (which in this case is the column on a Kanban Board).
The number of tasks In-Progress cannot outnumber the number of tasks completed or requested. To keep the cards running through the Kanban System from one stage to another, teams must work together to limit the work in progress.
Limiting the WIP gives an insight into available resources with no priority tasks at hand, which means those resources can work on completing the pending tasks on an urgent basis.
5. Manage Flow
The flow of the work through the Kanban System should be smooth, uninterrupted and free of any blockage.
A cascading workflow that transitions from one stage to another in a consistent manner signifies the absence of bottlenecks and roadblocks, and is proof that team performance and work metrics are not only productive but generating business value.
6. Persistent Improvement
Implementing Kanban does not entirely promise success. To gain consistency in meeting deadlines and finishing urgent deliverables, teams need to keep working on their weaknesses and solidifying their strengths.
7. Periodic Feedback
In Kanban, feedback is a vital part of the way teams work. Feedback is obtained and shared between team members and their managers, during daily standup meetings.
These meetings ideally take place in the light of the Kanban Board, where each member enlightens the rest of the team on what has been achieved so far and what will they be working on tomorrow.
4. Adaptive Software Development (ASD)
Adaptive Software Development is a framework built on a set of adaptive practices, collaborative principles to help organizations adopt an adaptive process when building large and complex products.
In 2000, Jim Highsmith published a book, on Adaptive Software Development. In his book, Highsmith explained that ASD is a modified version of Rapid Software Development.
The best practices of ASD emphasize on accommodating change in adaptive, incremental manner, so when unforeseen precarious conditions emerge, teams can evolve and acclimatize to the new dynamics without risking product release and other essentials like resource availability and budget limitations.
Adhering by the hallmarks of the Agile framework, ASD supports vigorous communication and interaction between developers, testers, engineers and the team lead.
Characteristics of Adaptive Software Development
ASD does not instigate on a pre-planned phase or ideology. However, a mission statement, precise and well-defined, guides the team towards the end goal of each iterative cycle.
The mission statement does not affect the exploration practices on part of the team to discover new more effective strategies and solutions to build the product.
However, it narrows team focus on achieving the result in alignment with the proposed preferences.
The ASD approach focuses on tangible results. Does the increment at the end of the iteration contain working features? Does the product release contain customer-demanded functionalities?
Development is chunked and fragmented into time boxed iterations, so the product is re-visited, re-tested and improvised from the first stage of the development.
Each iteration deliverable is given a due date to ensure on-time delivery of the product version.
The workflow keeps any potential risks into account so that the team is prepared to adapt to the change in workflow dynamics due to a problem.
Welcomes change at any level of the working team and at any stage of development, mostly for modification and improvement in the practices or the product itself.
Adaptive Software Development Lifecycle
Adaptive Software Development works in a cyclical manner. The life cycle is divided into three main phases:
In ASD, teams must acknowledge the likelihood of uncertainty and unforeseen interruptions, throughout the process, it is for this reason, the word Planning is replaced with speculation.
Speculation endorses planning but in a more explorative and experimental manner. Speculation is split into:
- Create a Mission Statement
- Estimate the size of the project
- Enlist the guidelines parameter of the project
- Determine what the users require from the product
Adaptive Cycle Planning
- Establish the time box of the first iteration
- Assign tasks and components to each iteration
- Create an objective list for each sub-task within the cycle
Collaboration in ASD is considered a concurrent feature development. Whether it is a large-scale project or small, teams work concurrently work together on various components of the application and communicate their results and findings with customers and within the team.
The Learning phase has two purposes: Enhance Team Knowledge and Product Success. At the end of each cycle, it is then time for learning activities. Learning activities are implemented in:
- Technical review of the latest version of the product is made by the customers and the team itself
- Developers assess what part of the objectives as per the mission statement have been achieved
- Team collectively analyzes the status of the project, and if there are any features left incomplete, then re-planning efforts are considered
5. Crystal Agile Methodologies
Alistair Cockburn, one of the co-authors of the Agile Manifesto, presented the collection of Crystal Methodologies starting 2004. He described Crystal as lightweight, adaptive, incremental and people-focused.
The Crystal Agile project management methodologies are color coded starting from clarity and ascending to darker nuances.
The range of colors signify the complexity of project management required. The larger the project, the darker the Crystal Methodology applicable.
Types of Crystal Methodologies
- Crystal Clear – for short term projects that need a small team of 5-6 people.
- Crystal Yellow – for projects that rely on not more than 20 people.
- Crystal Orange – relatively mediocre size teams consisting of 40 people
- Crystal Red – for large scale projects with a multitude of teams ranging up to 100 people
- Crystal Sapphire – projects worth multi-million dollars
- Crystal Diamond – Globally-stretched diverse projects lasting 8-10 years
Characteristics of Crystal Methodologies
Crystal Methodologies work on 3 characteristics that both differ them as well as relate them to the remaining agile frameworks:
The most imperative priority of Crystal are the people. Workflow process comes in secondary. It is vital that the human activity which is the real and only source of the software development comes first and the process is modeled on the needs of the team, not the other way around.
It emphasizes self-organization and self-management in team members, to formulate an empowered atmosphere where everyone feels competent enough to streamline the workflow on their own.
Crystal framework does not imply the use of any one procedure or set of techniques. It gives its users the benefit of incorporating the technique of their selection, whatever suits the business, whatever works for the business.
It is for this reason, Crystal is also referred to as the “stretch-to-fit” methodology that encapsulates any methodology within its own framework.
In Crystal approach, the focus is foremost on human activity, then secondarily on the process and then least of all to documentation. It limits the requirement of extensive reporting, lengthy documentation and overhead management.
Transfer of information is predominantly done through face-to-face interaction between the team members.
Properties of Crystal Methodology
Fast, incremental delivery of the product that is regularly tested and coded throughout the project’s life cycle.
Allows room for constant improvisations that can be made to the product to meet customer expectations. Teams can test new ways and strategies to bring the product to a fully functioning version as per client demand.
Osmotic Communication that is attained by the entire team seated in the same room, is a cost-effective means of communication and transfer of information. All discussions take place within the ear-shot of the entire room and enters every ear present in the room via background osmosis.
Teams must be able to share and collaborate without any limitations such as difference of opinion, opposing train of thoughts or a difference in leadership.
All team members are aware of the tasks assigned to them, the responsibilities entrusted to them, to avoid any misunderstandings and overlapping job role conflicts that may hamper team performance.
Direct Input from Users
Crystal enables users to be an active part of the system. It encourages early and regular feedback from users to anchor team work in the right direction.
6. Dynamic Systems Development Method (DSDM)
Dynamic Systems Development Method (DSDM) is one of the most outstanding and praiseworthy methods of agile project management. It was created in 1994 as an extension of the Rapid Application Development by a consortium of vendors in United Kingdom in the field of Information Systems (IS).
DSDM caters specifically to Information System Projects that are obstructed by abstemious budgets and impossibly tight deadlines. DSDM was designed to address the common problems that most often lead to the failure of IS projects, such as:
- inefficient delivery of the solution,
- lack of user engagement,
- management issues,
- monetary concerns, etc.
DSDM is different from other agile methods in another aspect, and that is it focuses on product delivery than on team activity. Team cooperation however is just as important in DSDM as in any other Agile methodology.
Key Concepts of DSDM
The core principles and features that formulate the structure of DSDM, are:
- The users should be actively involved in the development of the product to monitor the accuracy of the decisions made before work can be started or improvised.
- The team must have the autonomy to make ad hoc decisions necessary for the progress and health of the project, there should be minimum hindrance of red tape and from the higher management in the impromptu decisions that the team takes.
- Product must be released frequently from the early stages. Early and rapid delivery of the product will ensure that the users get to receive a demonstration of the product and give their feedback.
- Development of the product is carried out in iterations to maximize user feedback and product improvement.
- Development of the product must follow an revocable pathway, so if any changes required, the development can implement the change,
- The high-level, indispensable scope and requirements of the project must be defined before the development starts, during the Pre-Project phase.
- The workflow process proceeds with integrated testing at its pivotal center. The product is repeatedly tested during and after every stage of development that it is hurled through.
- Effective communication and cooperation between all core teams, management and stake holders is essential for the development process.
Phases of the DSDM Development Lifecycle
The DSDM framework is principally built on three phases:
- Project Lifecycle, and
The middle phase, Project Lifecycle is the most extensive stage of the entire framework. The roles, responsibilities and activities specific to each stage are described below:
The Pre-Project Phase
The pre-project phase occurs before the project starts. The management outlines and defines the requirements of the project. The vision along with the concept of the project is materialized to fit the budget which is also finalized.
The Project Lifecycle Phase
Once the concept of how the project will be initiated and all the necessary details have been decided, the project enters what is called the lifecycle phase. The lifecycle phase is itself implemented in two stages:
- Feasibility Study, and
- Business Study
These are sequential steps that take place in the prescribed order.
In the feasibility study, the team sits together to assess and find answers to questions such as: will the established ground rules and project plan thrive in producing a working product in time? Will it thrive in the constraints of the appointed budget?
Since DSDM is applicable to IS solutions where time is a scanty commodity, the feasibility as well as the business study stage is conducted as quickly as possible.
In the business study stage, the management along with its team, speculates and conducts a quick brainstorm survey on the business aspect of the project.
- What is the user demand?
- What specifications should be kept in mind to preserve the business value of the project?
- What technology will be used to fulfill the business quality of the product?
- What expertise and skills will be needed to test and deploy the product?
Once the pre-requisites have been cemented into a solid backbone, the development of the IS can begin.
The developing team commences by building functional prototypes. A functional prototype of the product is a preliminary version of the functions that the finishes working model of the product must contain.
Prototyping is conducted in a cyclical series of steps:
- Researching the functionalities
- Refinement of the prototype
- Consolidate the prototype
The prototype is subsequently reviewed for:
Design and Build
In the design and build stage, the product is designed. A design model is created that is first coded as per the mission statement and is then tested and reviewed. The design and development of the product takes place in iterations.
After the product increment is reviewed and tested, it is pushed into the last stage where it is documented.
A review document is also created where the requirements of the product are compared with the point and functionalities achieved.
The developers demonstrate a tutorial to users on how to use the completed version and the users provide their feedback.
The Post-Project Phase
The post-project phase ascertains and verifies that the end version of the product works effectively and efficiently.
The team uses DSDM principles of iterative maintenance to ensure the working quality of the product.
If there is a need for enhancements or fixes, then the product is sent back into the previous stage for further development.
Techniques Used in DSDM
The DSDM Consortium advocates the employment of certain tools and techniques, most prominent among them are:
The MoSCoW Rule
DSDM facilitates projects that do not possess the luxury of vast timeframes and abundant funding. Therefore, it endorses that blocks of work in the development stage should be prioritized to make the best use out of time.
The MoSCoW rule is implemented to weigh the importance of the functionalities:
- Must Have – the things that are essential
- Should Have – things that are important for the business solution
- Could Have – things that are useful, but do not pose liability issues if relegated to second priority
- Won’t Have To – tasks that are of little importance and can wait till later
Instead of devising milestones on a project roadmap, DSDM applies the use of time boxing.
An iterative cycle is formulated – usually between 3-6 weeks – during which an entire checklist of tasks and objectives are completed.
Prototyping is the backbone of DSDM. If a team is not making generous use of prototyping as part of the incremental development process, they are not following the DSDM approach.
- User involvement and feedback
- Continuous product delivery
- Incremental release of product
DSDM categorizes the activity of prototyping into four groups:
- Business Prototype – Assess the version from business value angle
- Performance Prototype – Ensure the solution functions as per users requirement
- Usability Prototype – Is the user interface free of errors and bugs?
- Capability Prototype – Is there room for further enhancement of the product?
Team Roles and Responsibilities in DSDM
- Project Manager – monitors and manages the process of prototyping and development
- Advisor – information expert with practical knowledge about the areas that need to be automated or revised
- Scribe – member whose job is to document all discussions, plans, results and objectives of the project
- Senior Developer – a senior level developer with exceptional skills and knowledge about software development to help build a deliverable code
- Technical Coordinator – in charge of taking care of the technical aspects of the project. Makes sure everyone understands the technical details and how to execute them.
Top 6 Agile Methodologies Compared
Essentially all Agile methodologies work on a similar framework, that principally focuses on:
- Expedited product delivery,
- Enhanced team collaboration, and
- Continuous product review and assessment
From a more analytical perspective, and to gain a lucid understanding of where each methodology is best applicable, there are a multitude of disparities that must be realized.
An evaluation of the differences of all 6 Agile methodologies are tabulated in the comparison table below:
|Sprint Cycle||2 to 4 weeks||No sprints – continuous delivery||4 to 8 weeks||Leaves the choice on the team||1 to 6 weeks||80/20 principle|
|Project Size||All types & sizes||All types & sizes||Small size teams||All sizes||<20 members||All sizes|
|User Involvement||Involved via Product owner||Depends on Team preference||Through frequent releases||End of each iteration||Highly involved throughout||Through frequent releases|
|Documentation||Lightweight; mediocre documentation||No documentation||Basic documentation||Lightweight||Basic documentation||Requires documentation throughout|
|Practices||Daily scrums, backlog management, sprint retrospective||Limiting WIPs, drag-and-drop workflow of cards from one stage to another||Speculation, learning and adaptive cycling||Focus on what the team needs||User stories, refactoring, pair programming, test driven development||Prototyping, business and feasibility study|
|Meetings||Daily standups||Daily group meetings in front of Kanban board||Daily face to face meetings||Daily face to face or individual meetings||Daily standups||No personal meetings|
|Approach||Iterative increments||No prescribed workflow, teams can follow any incremental approach||Incremental||Leaves the choice on team||Iterative increments||Iterative|
|No defined roles. Teams can keep project manager on need-basis||Project sponsor, programmer, coordinator, unit testers||Supports uniform leadership throughout the team||Programmer, coach, tester, doomsayer, tracker||Project Manager, Senior developer, adviser, scribe, technical coordinator|
Check out these other useful articles
- Agile Project Management Explained – A Beginner’s Guide
- 6 Project Management Lessons from Game of Thrones – 2019 (Spoilers)
- The Best Project Management Software of 2019 (Free & Paid)
- Best Free Timesheet & Time Tracking Software to try in 2019
- The 5 Best Kanban Apps of 2019
- The 5 Best Gantt Chart Software of 2019
- The 10 Best To-Do List Apps of 2019 for iPhone and Android