What Makes an Agile Team Success

Before you and your team can crush it, there are certain things you’re going to want to fight for to help set yourselves up for success in agile process to make project run in happy path

Co-location

1.  Dramatically improve the productivity of your team, it would be to have everyone sit together.
2. Co-located teams just work better. Questions get answered fast. Problems are fixed on the spot. There is less friction between interactions.
3. Trust is built more quickly. It’s very hard to compete with the power of a small co-located team.
4. if co-located teams are so good, does that mean if your team is
5. Distributed teams are becoming a way of life for many. And although a
6. tight co-located team will always have an advantage over a distributed one, there are things you can do to close the gap.
7. For one, you can reserve some budget at the beginning of your project to bring everyone together. Even if it’s just for a few days (even better if you can swing a couple weeks), that time spent getting to know each other, joking around, and eating together goes a long way in turning your ragtag bunch into a tight, high-performing team. So, try to bring everyone together at the start.
8. every communication tool and trick in the book
9. team seem like a co-located one even though you’re not.

Engaged Customers

1. There is a lot of software that still gets written today by teams that don’t have engaged customers. It’s sad, and it ought to be a crime.
2. How can teams be expected to build compelling, innovative products if the very people they are building them for aren’t part of the process?
3. Engaged customers are those who show up to demos, answer questions, give feedback, and provide the guidance and insight necessary for the team to build compelling software. They are core members of the team and full-on partners during delivery

Self-Organizing

1. Agile teams like to be given a goal and then have everyone stand back as they collectively figure out how to get there. To do that, agile teams need to be able to self-organize.
2. Self-organization is about checking your ego at the door and work  with your team to figure out how you as a team (with all your unique skills, passions, and talents) can best deliver this project

Accountable and Empowered

A good agile team will always want to be held accountable for the results they produce. They know customers are counting on them to come through, and they won’t shirk from the responsibility that comes with having to deliver value from day one

Cross-Functional

A cross-functional team is one that can serve their customer from end to end. That means having the necessary skills and expertise on your team to take any feature your customer would need and be able to

deliver it fully.

Comparing Agile Methodologies

Purpose of this post is to  compare  different Agile methodologies and compare their respective strengths and weaknesses.

Scrum

Strengths

1. Can be used together with an existing practice
2. Accommodates feedback opportunities in teams that are self-motivated
3. Supports customer involvement and direction
4. Focuses on the business value of a project
5. Contains a certification process

Weaknesses

1. The only process supported is project management
2. No technical practices are defined
3. Time-consuming, especially when customizing priorities for requirements

DSDM

Strengths

1. Demands a high level of testing – a minimum of one tester is required on every team
2. Focus is on business value
3. Clearly defines the importance of every requirement in an iteration
4. Stakeholder expectations defined at the start of every project – specifies that every requirement may not be able to be fulfilled

Weaknesses

1. Very heavyweight and demanding
2. High level of user involvement required
3. Requires a high level of documentation and specifies various work products for every project phase
4. Reference material monitored by a consortium – fees are charged to access resources

XP

Strengths

1. Requires rigid technical practices
2. Estimates owned by develops
3. Features owned by customers
4. Supports regular feedback sessions
5. Popular, especially in the US

Weaknesses

1. Customers needed onsite
2. Minimal record keeping - Verbal communication and code are used to document feedback and progress
3. New users may find this method difficult to understand in terms of software architecture and design

Lean

Strength

1. Can be used together with an existing practice
2. Main objective is the project ROI.
3. Keeps project waste to a minimum
4. Supports cross-functional teams

Weaknesses

1. No technical practices are defined
2. Metrics collecting is constant
3. Theory of Constraints can be difficult to understand and implement

AUP

Strengths

1. Contains multiple artifacts and disciplines
2. Can be adapted to large projects
3. Supports a distributed team environment by using good documentation practices
4. Bases priorities on levels of risk

Weaknesses

1. Too many guidelines can slow project progress
2. Team dynamics are neglected
3. Documentation is very formal

FDD

Strengths

1. Accommodates the need for multiple teams
2. Monitors all project elements according to its features
3. Contains design by feature and build by feature aspects that are simple to implement
4. Can be adapted to suit large teams and projects

Weaknesses

1. Does not support shared or team ownership of code; rather, individual code ownership is encouraged
2. Iterations are poorly defined
3. Model-centric aspects can impact systems if no models are in place

Crystal

Strengths

1. Can be scaled according to project size and criticality
2. Supports life critical projects
3. Cross-functional teams created in proportion to the project size
4. Considers the "human" element of the project support structure
5. Demands a high level of testing – a minimum of one tester is required on every team

Weaknesses

1. Each project has to be tailored individually, according to its size and structure in order to fulfil Crystals requirements for that particular type of project
2. Does not support adaptations mid-project – not upward or downward compatible

What Is Agile?

“Agile” is a collective term for methodologies (and practices) that have emerged over the past two decades to increase the relevance, quality, flexibility and business value of software solutions. These adaptive management approaches are specifically intended to address the problems that have historically plagued software development and service delivery activities in the IT industry – including budget overruns, missed deadlines, low-quality outputs, and dissatisfied users.

Although there is a broad range of Agile methodologies in the IT industry – from software development and project delivery approaches to strategies for software maintenance – all Agile methodologies share the same basic objectives:

• To replace upfront planning with incremental planning that adapts to the most current information available (i.e. the “apply, inspect, adapt” mindset)
• To build in quality upfront and then relentlessly confirm the integrity of the solution throughout the process
• To address technical risks as early in the process as possible to reduce the potential for these resulting in cost and time blowouts as the project progresses
• To minimize the impact of changing requirements by providing a low overhead structure to accommodate variations to the originally-identified requirements throughout the project
• To deliver frequent and continuous business value to the organization by focusing staff on regularly delivering the highest-priority features in the solution as fully functional, fully tested, production-ready capabilities
• To entrust and empower staff to continuously deliver high business-value outputs
• To encourage ongoing communication between the business areas and project team members to increase the relevance, usability, quality and acceptance of delivered solutions.

Agile methodologies are common-sense approaches for applying the finite resources of an organization to continuously deliver low-risk, high business-value software solutions