Tag Archives: Agile


The Scrum Way: A Definitive Approach to Building Things

Scrum as an agile framework is the collaborative effort of a number of self-organizing and cross-functional teams who work along their end users and customers.

The method makes use of adaptive planning, development, delivery and continuous improvement along with flexible and rapid response to change.

When using the agile framework for developing software, a team of 3 to 9 developers gather as main users and divide their work into smaller schedules. These schedules are time-boxed iterations, known as ‘sprints’, which can be tracked and re-planned depending on evolving user requirements.

One way of continuous tracking is with the help of a 15 minute meeting known as Daily Scrums. In order to coordinate the work of multiple scrum teams in a larger organization it requires them to use Large-scale Scrum (LeSS), scrum of scrums and Scaled Agile Framework (SAFe).


 The Key Idea Behind Scrum

 Scrum provides a context in which companies are given an opportunity to address complex adaptive problems, while delivering products of highest value whilst making use of their resources productively and creatively.

It is a highly effective team collaboration tool for managing complex products.

Ken Schwaber and Jeff Sutherland, the creators of Scrum in their resource ‘The Scrum Guide’  explain the working model and usefulness of Scrum clearly. Some of its characteristic features include:


  • Light weight
  • Simple to understand
  • Difficult to master

It might sound complicated, but Scrum is rather simple. It is not a methodology. Rather, it implements the scientific method of empiricism. With the help of a programmed algorithmic approach, it makes easy for people and self-organizations to deal with unpredictability and complex problems.


The Scrum Values

 Scrum values were added to the Scrum Guide in July 2016. Some of the Scrum values include: focus, courage, commitment, openness and respect.


Roles of the Scrum Team



A distinct Scrum Team is composed of a Product Owner, a Scrum Master and the Development Team.

The self-organizing teams decide how to do their work as a self-sufficient group rather than taking instructions from people. On the other hand, cross functional teams have a wide variety of elements in it so that it can complete the work on its own.


 5 Formal Scrum Events For Inspection and Adaptation

 Scrum is modeled to work by optimizing flexibility, productivity and creativity.

 For companies who regularly use Scrum in order to reduce the need of conducting meetings. All of the events are time-boxed for saving productivity time. Once a Sprint begins, it is impossible to slow it down or stop it. There is no way that a Sprint can be stopped or its time length can be altered.

These five events are:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
  • The Sprint


1. Sprint Planning:

During Sprint Planning, the work allocated during Sprint is done and everyone in the team contributes to it. The time allotted to sprint planning is a maximum of 8 hours for deciding the goal of one Sprint lasting 1 month.

If the Sprint is shorter, lesser time is allocated to Sprint Planning. It is the duty of Scrum Master to ensure that every one of the Scrum Team is present in the planning process and understands the necessity of this drill. In addition it is ensured that the Scrum Team sticks to the allocated time frame.

Some of the answers that are sought during a planning session are:

  • What can be delivered by the upcoming Sprint?
  • How will the work be done in order to achieve the goal?

2. Daily Scrum

Daily Scrum is a daily 15-minute time boxed event in which all the members of the team meet and make plans for the next 24 hours in order to meet the ultimate Goal.


3. Sprint Review

After the end of every Sprint, a Sprint Review is set up for investigating whether the Goal was met in the stipulated time period, any bugs detected and to decide how to clear the Product backlog, if there is any.

Based on a Review, the team decides what steps need to be taken in order to optimize the value and decrease the incidents of Products backlog.


4. Sprint Retrospective

This event gives an opportunity to the Sprint team to inspect itself and create a plan that can be implemented next time for the next Sprint. This event occurs after Sprint Review and the time allotted to it is a maximum of 3 hours. If the Sprints are shorter, this event gets further shortened. Following points are considered during the event:

  • What went well during the Sprint
  • What factors can be improved


5. The Sprint:

Sprint has a defined time-box during which the job needs to be done. The time period fixed for a sprint is usually one month or less. As soon as one Sprint is over, another begins automatically. They have consistent duration throughout the project. Some of the features of Sprint are as follows:

  • No changes can be made that have the ability to endanger the Sprint Goal
  • Quality goals cannot be reduced
  • Scope can be clarified and re-negotiated between the Development Team and the Product Owner as the project progresses


The duration of Sprint is fixed to one month because if longer time is allocated to it, complexities might arise and therefore risks might increase. They help in increasing predictability and reducing risk.

Finally, Scrum is driven by feedback mechanism and stands on the three strong pillars of inspection, transparency and adaptation. It is all about humanizing the entire process of software development that can be optimized to create better products.


Defect Management in an Agile Environment


The purpose of defect management is to identify bugs or defects of the software and provide information to improve the development process.

In Agile, the process of detecting defects works in parallel to the software development process, and once mastered, can prevent a lot of potential problems.

Scrum per se as a framework does not explicitly show you how to handle defects. With scrum you can bring more accountability to the entire project, however  one lacks clarity on how the teams should operate in the process of delivering the software. Some questions that arise are..

…When a bug is found does it become part of the sprint backlog

…What if adding it to the sprint skews the burn-down and makes it harder to meet the sprint goals?

…What by adding defects to the product backlog delays an important fix?


 Defect in Traditional Environment

Conventional Waterfall development consists of a system that can be included in the definition of ‘Done’ when it is analyzed, designed, and coded. Development needs to pass the quality testing phase. Bugs and issues detected during this stage are called defects. They are researched and re-tested by the developers before sending for finalization.

However, this method lacks the ability to preven

t the bugs. Developers are required to break down software code and check results. Once completed, they move on to another project and defects in the previous one causes unnecessary delays in the workflows. This adds stress and instability resulting in an impeded development process.


Problem Management in Agile Environment

Whenever an error occurs in the user story of a current or past sprint, it should be immediately identified and resolved to maintain  quality. The methodology may vary from one scenario to another. And so here we elucidate few scenarios:


Scenario 1: When a Defect is Detected During Acceptance Testing of a User Story:

In most of cases, it is better to detect and fix a problem as soon as it is discovered in the QA testing. When this isn’t possible, the user story should go back to the developer for resolving the defect. It is re-tested several times until the complete resolution of a defect. In this scenario, recording of a defect can also help. The teams stay abreast of the waste that takes place between the phase of development and testing. And metrics can be used for a better problem management.


Scenario 2: When the Team Conducts Regression Testing on the Functionality of Software:

Sometimes, developers may conduct a regression testing on the user stories that are already accepted by the product owner. In this story, there can be a defect that needs to be properly tracked and unraveled.

It is always a possibility to create a defect for such issues. However, you should resolve it immediately instead of creating a defect to be tracked.


Scenario 3: A Story is Noted as Done Despite Some Known Defects that are Deferred:

In a deferred defect, there lies a sub-feature of a user story that needs full implementation. Here, it is important to create a new story to fix the defect. These may include defects having requirement specifications. In Agile environments, such defects are sized and prioritized according to other factors.


Scenario 4: A Defect Found in the Demonstration of a User Story:

In every 2-3 weeks, developers demonstrate user stories to the stakeholders. If something is found to be broken during this demonstration, a defect is created, prioritized, tracked, and resolved for it. However, the issues in the unaccepted stories can’t be marked as Defects. In this scenario, the story isn’t complete and defect can’t be created.

As a matter of fact, follow a well-defined problem management practice to resolve the defects in the software.

In the end, the best way to manage problems is to prevent them from happening.


Agile Development: Unfolding 18 Reasons to Active User Involvement


Agile methods are lightweight software development processes that employ short iterative cycles, involve users to establish, prioritize and verify requirements, and rely on knowledge within a team rather than documentation (Boeham and Turner 2004).

Within the spectrum of agile web development, user involvement has evolved from being informative and consultative, to a participative approach. A significant need that weaves together this story is: customer focus. What matters to project teams is:

  • All actions provide tangible business value.
  • The customer is not defined as the project stakeholders of the company, but the end users as well.
  • The degree of alignment between different user roles (an entity that will be using the software directly or indirectly) and their expectations in the development of the software project.

Read more to understand the 7 Core Principles of Agile Development

However, it is not always possible to advocate interactions that involves external customers directly in the development projects, and that’s when active involvement from project stakeholders become a necessity throughout the journey.

Here are 18 reasons why!

#1 Requirements are clearly communicated with upper management and important stakeholders showing how goals are aligned with the vision at the outset.

#2 Market mechanics help shape ideas.

#3 Perceptions and expectations are obtained from internal and external practitioners in a realistic setting.

#4 Face-to-face interviews, user visits, meetings, brainstorming sessions, and open communication channels such as phones, faxes, emails and focus group discussions drive involvement.

#5 Requirements elicitation are discussed (security, portability, scalability, and scope).

#6 Decisions around time-frame ensure optimum benefit of the involvement.

#7 Collaboration with developers in resolving issues pertain features to be implemented.

#8 Evolving project plans without the need of lengthy documentation.

#9 Responding and providing inputs to product prototypes created by development teams.

#10 When end user groups are involved: liaison between users and IT teams by consulting or interacting to extract their ideas, needs or problems.

#11 Influence practices such as User Centered Design, Usability Testing, User Stories, Putting Usability First (PUF), Usability Engineering (UE) and Participatory Design (PD).

#12 Resolving issues as they come up with different stakeholders.

#13 User stories created at the start of every iteration, and then prioritized to ensure they are completed within the time allocated for that iteration.

#14 Development can be monitored on an ongoing basis.

#15 There is complete transparency.

#16 Both sides of the teams are accountable as they share progress openly every day.

#17 There is complete commitment to the project.

#18 There is a sense of joint effort as responsibility is shared.

At Terra, we embrace agile. Our methodologies are based on iterative development, requirements gathering, and creating solutions that evolve through collaboration between self-organizing cross functional team.





Agile web development principles

7 Core Principles of Agile Development

Unproductive paths make it harder for companies to evolve with market needs and detect weaknesses in their product before it’s too late.

Businesses have been experimenting with their IT development processes for over two decades. Most managers either struggle to bring in projects on time or on budget. An unpredictable schedule or deliverable, with an added pressure from the bossed only find teams become self-pitying factories – and that can actually hurt product-development efforts.

What started for PMs as an attempt to weave together numerous fragmented tasks and data processes — has led to a widely adopted reality in software management – known as the ‘agile’ methodology.

As many tasks in product development are unique, project requirements constantly evolve. Agile development embraces this need and isn’t defined by specific development techniques. Instead, it emphasizes on close collaboration, faster delivery cycles, and improved customer experiences.

Compared to traditional engineering, agile developers work with non-linear and dynamic workflows that lead to outcomes such as, more control, tighter feedback and continuous improvement.

Let’s look at some of the core principles underlying this approach –


1. Active Customer and User Involvement Be rational with agile development

Active user involvement in the form of direct and indirect participation is a given imperative when working in an agile project.

To maximize a product’s value and team’s work, the involved representatives play a leading, supporting or participative role.

At every stage, users are actively involved leading to improved visibility and a positive impact on the overall output.

2. An Empowered Team to Manage Ownership

Agile development redefines the roles of managers, customers, and the product team.

While product ownership is established at a management level, the project team is empowered to make decisions that support the complete delivery of the product.

In an agile environment, the team establishes the project scope, prioritizes tasks involved, agrees to deliver them and estimates the time and cost resources involved together.


3. Keeps Requirement and Documentation Lightweight

project management documentation

Gathering and producing effective requirement is fundamental in any product lifecycle. An unstable foundation can create confusion and increase the lifespan of a project.

In agile, changes are usual part of the project. That means, product owners don’t get caught up in the rigmarole of spec’ing out every detail but depend on a shared understanding of the customer.

User stories a simple and a narrative document is used to represent customer requirements. There are no tedious procedures as documentation is kept lightweight and easy. All this drives conversation forward, and not backward.


4. Quick, Small Incremental Releases

Analyze, Develop, Test; Analyze, Develop, Test.

This iterative approach focuses on doing each step for each feature, one feature at a time instead of developing all known elements of the specs first, and then testing.

This approach drives visibility on what has been accomplished to date, rather than having to wait for features to be ready. There is more flexibility to adapt to next steps after gathering feedback, plus increased value an be realized.


5. Frequent Delivery of Products

In our digitized world if 100 days is a lifetime, what is termed ‘frequent’?

Scrum, which is a popular method that manages agile tasks, says to break the marathon of software development into 30-day sprints or less.

The project team utilizes brief iterations to deliver new product features that has immediate, short-term demand as soon as possible.  This means customers can validate working features quicker, and adjustments can be made where necessary.


 6. Early Testing

Testing is an integrated approach practiced throughout the lifecycle of the project.

Each block of output is continuously tested to fix defects and possible overheads without a separate test phase as such.

On a large-scale project, such as oil and gas, government projects etc. full regression and developer testing is achieved at each iteration stage.


7. Close Cooperation and Collaboration among All Stakeholders

Any changes that occur in the market inevitably leads to changes in customer needs.

At the outset, agile development principles embrace this reality and pivot the priority towards customer satisfaction through early and continuous delivery of software.

Close collaboration between all team members and stakeholders is particularly important to be ‘on the same page’ while detailing specifications and carrying out and while tackling all granular tasks.

With the ability to respond to a rapidly changing competitive landscape, we at Terra ATS are guided by these core agile principles to bring in clarity of purpose, an accountable project management team, and an ability to deliver measurable outcomes for our clients.

To speak more on how we can help contact us here.