104. Evolution to Agile

Welcome back.

I just brought the business and the development teams together into one team.

This team work to build great software in small nations called sprints instead spending weeks or months on each phase of development.

Agile focused on doing all these faces during a single sprint.

You'd start with a small requirement called a user story and then take it through the various cycles of development.

Now you might be wondering how does this help.

How did agile enhance the communication between teams.

As we discussed earlier agile brought the business and the development teams together the business team is responsible for defining what to build.

What are the requirements development team is responsible for building a product that meets the requirements.

When I say development I include everybody that works on design coding testing and packaging software.

In agile.

These two teams are brought together by bringing in a representative from the business called a product owner the product owner is always available for the Agile team.

This would ensure that the Agile team understands the business objectives.

Clearly the result of this is that the final product that the team builds is something that the business we want.

Now we talk of the fact that agile enhance communication by bringing the business and the development teams together.

What are the automation areas where the agile teams focused on the primary focus of agile teams was on finding defects as early as possible while developing software.

There are a variety of defects functional defects means the product does not meet the expected requirements technical defects like code quality errors make the maintenance of software difficult in general agile teams were focused on using automation to find technical and functional defects as early as possible agile teams focused on writing great units to test your methods and classes.

Agile teams also focused on writing great automated integration tests to test your modules and applications.

Code quality checks were also introduced by using tools like sonar to assess this static code quality of your application.

Now is it sufficient if you have great units great integration tests and great checks on your code quality.

No right.

You'd want to do these checks continuously as soon as I can meet some code into the good repository.

I'd want to run my unit tests.

I would want to do my code quality checks.

I would want to package the application I would want to run my integration tests.

This is what is called continuous integration.

The most important Canis integration tool during the early agile time period was Jenkins.

Now the next question is how did agile promote getting immediate feedback.

The most important factor is that business did not need to wait four months to see the final product at the end of every sprint.

The product is demoed to all the stakeholders including the architecture and business teams.

All feedback was taken in prioritizing the user stories for the next sprint.

The result of this was that the feedback from architecture and business teams was used to enhance the product.

Every Sprint and therefore the final product that the team built is something that the business would be really happy with.

Another factor which enables quick feedback is continuous integration.

I commit with some coding to version control which has a defect.

What would happen.

A unit test would fail and I would immediately know it.

What would happen if I write some piece of code which does not meet the code quality standards.

The bill would immediately fail and I would get an email until we looked at how agile help teams to communicate better to get immediate feedback and to automate things.

Now you might be wondering was agile really successful.

I think yes.

By focusing on improving the communication between the development and business teams and focusing on finding a variety of defects early agile took software development to the next level.

I personally had a wonderful experience working with some amazing teams in the agile model does that mean the journey stopped.

Not new challenges emerged.

We started moving towards a micro services architecture and we started building a number of small API is instead of building large monolithic applications.

So what was the new challenge.

The challenge was that operations became really really important.

Instead of making one monolith release a month we were doing hundreds of small micro service releases every week sometimes every day debugging problems across micro services and getting visibility into what's happening with the macro services became really important and it was time for a new buzzword in software development dev ops.

Let's discuss what is the next step.