Our transformation from simple web development to agile web development company

 What Is Agile?   

                      

The Agile movement proposes alternatives to traditional project management. Agile approaches are typically used in software development to help businesses respond to unpredictability. “Agile is one of the big buzzwords of the IT development industry”.

But exactly what is agile development?             

                                                                                                             

Agile development is a different way of managing IT development teams and projects. The use of the word agile in this context derives from the agile manifesto.

Our transformation from simple web development to agile web Development Company

 A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often, and there had to be a better way.  They came up with the agile manifesto, which describes 4 important values that are as relevant today as they were then.  It says, “we value:

·        Individuals and interactions over processes and tools.

·        Working software over comprehensive documentation.

·        Customer collaboration over contract negotiation.

·        Responding to change over following a plan.

When to use Agile model:

§  When new changes are needed to be implemented. The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced.

§  To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it.

§  Both system developers and stakeholders alike, find they also get more freedom of time and options than if the software was developed in a more rigid sequential way. Having options gives them the ability to leave important decisions until more or better data or even entire hosting programs are available; meaning the project can continue to move forward without fear of reaching a sudden standstill.

Making the Choice Between Agile and Waterfall

 Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart –you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

·         You don’t realize any value until the end of the project (when you deploy) (See: a benefit of Agile Software Development)

What’s Problems We faced?

·         It’s easy to see the problems with the waterfall method. It assumes that every requirement can be identified before any design or coding occurs.

• Unlike the waterfall model in agile model very limited planning is required to get started with the project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT world. Changes can be discussed and features can be newly affected or removed based on feedback. This effectively gives the customer the finished system they want or need.

·         Could you tell a team of developers everything that needed to be in a software product before any of it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. Your company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?  Today very few organizations openly admit to doing waterfall or traditional command and control. But those habits persist.

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches. The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features. The most commonly occurring issue in this type of scenario (in my experience) is bottle necking. For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing. Another common symptom of this type of approach is over-commitment.  It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way.  You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined. For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases. It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development/Agile Development

This approach carries far less risk than Waterfall approaches. It focuses on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature. With that said, we still plan our work in iterations and we will still release at the end of each iteration.

So, how do we choose? First, we change the game a little (which is what most software development organizations do) by defining our own process. At Trihari, it’s called our Process Framework, and it’s a variation on the traditional Waterfall methodology. Our modifications include use of prototyping where possible to provide the customer a better view of their finished product early in the design/development cycle. This helps to improve the team’s understanding of requirements and communication with the customer. After the primary framework of the application is completed per high level requirements, we continue to develop and also to reach out to the customer for refinement of requirements. In this way, we strive to be as iterative as possible without compromising our overall system architecture.

 These are characteristics which is given below that are common to all agile methods, and the things that I think make agile fundamentally different to a more traditional waterfall approach to software development.  They are:

(10 Key Principles of Agile)

1.     Active user involvement is imperative.

2.     The team must be empowered to make decisions.

3.     Requirements evolve but the timescale is fixed.

4.     Capture requirements at a high level: lightweight & visual.

5.     Develop small, incremental releases and iterate.

6.     Focus on Frequent delivery of products.

7.     Complete each feature before moving on to the next.

8.     Apply the 80/20 rule

9.     Testing is integrated throughout the project lifecycle- test early and often

10.                       A collaborative & cooperative approach between all stakeholders is essential.

What is Scrum?

Scrum is the most popular way of introducing Agility due to its simplicity and flexibility. Because of this popularity, many organizations claim to be “doing Scrum” but aren’t doing anything close to Scrum’s actual definition. Scrum emphasizes empirical feedback; team self management, and striving to build properly tested product increments within short iterations. Doing Scrum as it’s actually defined usually comes into conflict with existing habits at established non-Agile organization. Scrum has only three roles: Product Owner, Team, and Scrum Master. These are described in detail by the Scrum Training Series. The responsibilities of the traditional project manager role are split up among these three Scrum roles. Scrum has five meetings: Backlog Grooming (aka Backlog Refinement), Sprint Planning, Daily Scrum (aka 15-minute standup), the Sprint Review Meeting and the Sprint Retrospective Meeting.

Why Agile?

Agile development provides opportunities to assess the direction throughout the development lifecycle. This is achieved through regular cadences of work, known as Sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited. When a team stops and re-evaluates the direction of a project every two weeks, there’s time to steer it in another direction.

This “inspect-and-adapt” approach to development greatly reduces development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, stakeholders have recurring opportunities to calibrate releases for success in the real world. Agile development helps companies build the right product. Instead of committing to market a piece of software that hasn’t been written yet, agile empowers teams to continuously replan their release to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace. Agile development preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

What is Agile model – advantages, disadvantages and when to use it?

Agile development model is also a type of Incremental model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is used for time critical applications.  Extreme Programming is currently one of the most well known agile development life cycle model.

Diagram of Agile model:

Advantages of Agile model:

§  Customer satisfaction by rapid, continuous delivery of useful software.

§  People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.

§  Working software is delivered frequently (weeks rather than months).

§  Face-to-face conversation is the best form of communication.

§  Close daily cooperation between business people and developers.

§  Continuous attention to technical excellence and good design.

§  Regular adaptation to changing circumstances.

§  Even late changes in requirements are welcomed

Disadvantages of Agile model:

§  In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

§  There is lack of emphasis on necessary designing and documentation.

§  The project can easily get taken off track if the customer representative is not clear what final outcome that they want.

§  Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.