Unit-5 | Industry Trends | Agile | Gndec Helper

Market Scenario and Adoption of Agile

• After the Agile manifesto was published in 2001, Agile software development gathered a fair bit of attention, and was widely discussed by experts in the media. 
• The iterative and incremental framework that promised to cut development time and costs, and yield better results for all stakeholders started to really gain traction in recent years, with adoption seemingly picking up worldwide.
• Few key business scenarios that I see as a reason for growing usage of Agile methodology.

1. Go-to-Market Strategy has become one of the key ingredients for a business to ensure success. A business has to address the end users’ requirements in a short span of time. This helps it for better market penetration of its products/services, which in turn leads to increased reliability and trust factor among users and helps the business increase their brand value.
2. Competitive Advantage in today’s business environment is short-lived due to low barriers to entry and rapid advancement of technology. To maintain a competitive edge, businesses need to keep improvising their services and that too as quickly as possible.
3. Disruptive Market Strategy is another approach businesses are looking at widely of late, which I feel is due to the constant new service demands of end users from the products/services they use. Additionally, rapid technological advancement has set off companies in inculcating these into their business and become the front runner in capturing the target markets.

• Previously, majority of businesses used the rapidly declining popularity of waterfall framework, which was comfortably interacting between the then market trends and the business requirements. However, businesses gradually witnessed the short comings of waterfall framework as compared to the present business scenario and how new business entrants are capitulating the market by adopting the agile framework.
• Agile fits right for today’s market trends and I strongly feel this has started resonating among most of the established and new businesses across the globe. Some of the highlights of Agile framework are as follows;

1. Quick turnaround time of catering to the current market demands by following the incremental model or Rapid and short development cycles.
2. Small elements of the useable application are developed, thereby contributing to the full application when put altogether after an agreed timeline.
3. This approach helps in ensuring robust testing for any faults (bugs) and fixing them immediately.
4. Quick inclusion of user feedback or new feature demands

Agile ALM

• Agile application life cycle management (agile ALM) refers to the process of using or complementing agile development techniques within application life cycle management.
•  It is a software development technique that aims to improve a product's quality over its life cycle while keeping the development time as low as possible.
• Agile ALM is primarily used to add up agile values, frameworks and strategies within the application lifecycle.
•  It is designed to provide an integrated approach to ALM by improvising the people side of application development and increasing collaboration among stakeholders.

Roles in an Agile Project

There are several roles, which have different names depending on the methodology being followed, common to agile teams. Roles are not positions, any given person takes on one or more roles and can switch roles over time, and any given role may have zero or more people in it at any given point in a project. The common agile roles are:

• Team lead. This role, called “Scrum Master” in Scrum or team coach or project lead in other methods, is responsible for facilitating the team, obtaining resources for it, and protecting it from problems. This role encompasses the soft skills of project management but not the technical ones such as planning and scheduling, activities which are better left to the team as a whole (more on this later).
• Team member. This role, sometimes referred to as developer or programmer, is responsible for the creation and delivery of a system. This includes modeling, programming, testing, and release activities, as well as others.
• Product owner. The product owner, called on-site customer in XP and active stakeholder in AM, represents the stakeholders. This is the one person responsible on a team (or sub-team for large projects) who is responsible for the prioritized work item list (called a product backlog in Scrum), for making decisions in a timely manner, and for providing information in a timely manner.
• Stakeholder. A stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.

Agile Applicability

• Product development where a software company is developing a small or medium-sized product for sale. 
• Custom system development within an organization, where there is a clear commitment from the customer to become involved in the development process and where there are not a lot of external rules and regulations that affect the software.
• Because of their focus on small, tightly-integrated teams, there are problems in scaling agile methods to large systems. 

Agile in Distributed Teams

The majority of agile teams are geographically distributed in some manner. 

Benefits of distributed teams:

1. Access to a larger pool of skilled people. Many organizations struggle to staff their IT departments solely with local people, particularly when specific skills are needed.
2. Lower development costs. On the surface savings are the result of the wage differential between countries and sometimes even cities within the same country.  However, these savings can be quickly lost due to the increased overhead associated with geographic distribution – you must consider total cost of ownership (TCO), not just hourly programmer costs, when calculating the cost savings.  It is still possible to gain cost savings, but you must be sufficiently disciplined to earn them.
3. Quicker time to market. The opportunity for quicker delivery times exist when your team is disciplined enough to take a “follow the sun” approach.  The basic idea is that a globally distributed sub-team will do their work during their day time, then hand-off the work to a team that is several time zones away.  This team will then do some work, then hand it off to the next team.  This is very difficult to make work in practice, requiring a solid architecture, high quality code, development standards, automated regression tests, and sophisticated configuration management.  We’ve seen it done successfully, often with either 2 or 3 teams in the overall cycle, although most organizations struggle to make this strategy work in practice.   However, one of the challenges is access to a Product Owner (or a proxy Product Owner) as the “single source of truth” twenty-four hours a day.

Risks in distributed teams

1. Communication challenges.  The most effective means of communication between two or more people is face-to-face around a shared sketching space such as a whiteboard or piece of paper.  Of course, this requires you to be in the same room together.  As you become more distributed you begin to rely on less effective communication strategies, as you can see in Figure 5, but which provide better persistence of the captured information.  When you’re not face-to-face you are unable to observe body language which embodies a lot of valuable communication cues.
2. Temporal challenges.  When people are in different time zones it becomes harder to find common working times, increasing the communication challenges.  To combat these challenges you will find that you need to create more documentation than you normally would, as implied by Figure 5. More on this later.
3. Cultural challenges.  As the team becomes more distributed the cultural challenges between sites often increases.  Different cultures have different work ethics, treat intellectual property differently, have different ideas about commitment, may be less inclined to embrace self-organization, have different holidays, different approaches to things, and so on. Something as “simple” as what it means when someone says “yes” can be very challenging in practice.

Business benefits of Agile

1. High product quality
2. Higher customer satisfaction
3. Increased project control
4. Reduced risks
5. Faster ROI
6. Shorter development cycles

Challenges in Agile

1.  Inadequate experience with agile methods
2. Little understanding of the required broader organizational change
3. Company philosophy or culture at odds with agile values
4. People’s behavioral change
5. Lack of skilled product owners from the business side
6. Lack of dedicated cross-functional teams

           

Risks and mitigation

Types of Risks

1. Budget Risk: the risk of projects going over budget. Perhaps the most common risk in software development and often tied to other risks.
2. Personnel Risk: the risk of losing or absence of project team members. Even if for a short period, this can result in delays and errors.
3. Knowledge Risk: when there are knowledge silos or the transfer of information is imperfect. The process of relearning results in additional labor, time, and resources.
4. Productivity Risk: this risk is common in long projects, mainly when deadlines and goals are long-term. This environment creates a lack of immediacy which results in a lack of urgency of work.
5. Time Risk: product delays are all-too-common in software development, typically the results of poor planning, unrealistic timelines, and the inability to adapt to changing product requirements.

Risk Mitigation methods:

• Recognition of threats and opportunities within a project in order to balance the desire for reward against the risk incurred in its pursuit. This requires not only a thorough understanding of risk appetite and tolerance within a project, but also an appreciation of the risk inclinations of individual team members and the impact of social and cultural influences on risk management.
• Identification and prioritisation of appropriate risk response strategies (e.g., accept, mitigate, exploit) based on risk exposure and in a manner that is consistent with Agile practices (e.g., inclusion of risk-related tasks in a product backlog or use of a risk-modified Kanban board,⁵ which is a planning tool in which activities are moved between lanes representing the phase of development in which they find themselves [e.g., Planned, In Progress, Done] and user story maps as described later in this article).
• Ability to judge whether or not risk is being managed in an effective and efficient manner through the monitoring of risk. This also includes awareness of the residual risk at the iteration level and how these impinge on the overall riskiness of the undertaking.

Agile projects on cloud

Combining agile development and cloud computing brings the best of both worlds. Different organizations are using different methods for computing. It makes software faster than before. The cloud has provided quality. There are different advantages when we combine both agile and the cloud

• Distributed application development

The cloud assists conveyed application advancement with groups scattered topographically. Any colleague can have rights to get data about the application at any minute

•  Data sharing

Assets are obliged to share a colossal measure of information between diverse machines for some applications. The cloud assumes a significant part by giving a medium to share a great deal of information according to the prerequisites.

• Prioritizing tasks

It is important to consistently organize and prioritize errands. In a conveyed framework, there is a necessity to redesign devices. This expends vitality and requires some investment

• Transparency

Straightforwardness is important. In a cloud-based agile model, the engineer can be straightforward and live up to expectations.

• Infrastructure

Dexterous programming advancement obliges the infrastructure to be set up from the beginning. The cloud helps by providing a base 

• Benefits for business users

The cloud encourages spry practices with a specific end goal to meet the clients' prerequisites faster. The cloud underpins the idea of “pay per use” 

Balancing Agility with Disciple

• While agile methods have become popular in commercial software development organizations, the engineering disciplines needed to apply agility to mission-critical, software-reliant systems are not as well defined or practiced.

What Can You Do Next about Balancing Agility and Discipline?

• Start with a self-assessment

 • Key Stakeholders: Users, customers, developers, suppliers, strategic partners • Key Trends: 

• Increased pace of change and need for agility 

• Software dependability and need for discipline 

• Ability to quickly satisfy stakeholders’ evolving value props

 • Increasing gap between supply & demand for Cockburn Levels 2 and 3 people • Ability to cope with existing and emerging technical challenges (COTS integration, web, mobile, etc.)

Agile Rapid Development Technologies

• Rapid application development (RAD) is an agile project management strategy popular in software development.
• RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even in place of design specifications.
• RAD is especially well suited for (although not limited to) developing software that is driven by user interface requirements. Graphical user interface builders are often called rapid application development tools. Other approaches to rapid development include the adaptive, agile, spiral, and unified models.