Agile in product development

Reading Time: 7 minutes

Agile development has been around in the software development for many years. It re-imagines the conventional production flow for products, basing its methodology around frequent deliverable, cross-functional teams, and focused planning around strict timelines rather than strict specifications. The two important frameworks within Agile are SCRUM and KANBAN. Both are very effective, and they are suitable for different scenarios. Microservices based architecture are designed for rapid product development and it goes very well with the ethos of Agile development methodology. This blog will not go in details about what is Agile but talks about adoption in product development, particularly on microservices based architecture. However, these learnings are generic and applicable for product development using any underlying architecture.

Agile development is a culture and thought process of the team

From my experience, I see Agile is more of a culture and thought process of the team. If an organization really embraces agile, then it boosts the success rate of the products. If Agile is implemented in the true spirit it helps organizations create high performing teams that are independent, self-motivated and highly productive.

We have already seen the advantage of microservies architecture in earlier blogs. Each microservice is independent, Scrum teams follow a similar guideline. Every scrum team is independent and consists not more than 7 (Based on my experience) team members . Agile Scrum is a good fit for product development teams. Kanban is well suited for teams working on production support.

Following are some of the important areas the management should focus on to make Agile a success

Team formation

Team formation

Team formation is a very important step for the success of Agile. “Tuckman Stages of Group Development” states every team will go through Forming, Storming, Norming, Performing and Adjourning phases. I followed these stages and it is very effective to track the team progress and maturity. Emphasis should be on team building during the initial phase. There will not be enough progress from the team during the initial phases. Platform is set during the first 2 phases (Forming & Storming), focus from the management during this time is very important.

The role of development manager in an organization is very important. He/she should mentor and create right culture in the team. If the development manager is authoritative, it impacts the team culture. In my view, development manager should not show authority unless until there are situations or people in the team who are damaging the team culture.

Culture & Team building

Team building

Building the right culture is very important for a team’s success. Scrum is based on a cultural mindset that is often different from the current culture in the organization. Once the team gets into the right culture meetings become more open and productive. Team members start asking questions without fear. Team members are willing to take risks and be more innovative. More meaningful conversations happen with product owner and scrum master with a customer centric approach. Team starts showing collective responsibility instead of acting as an individual. The best part is once we could create right culture in one team it starts spreading to others. If we could make it successful in one team it can be easily replicated across other teams.

Changing in culture is a continuous process. Management should dedicate efforts to maintain culture in an organization

Independence & Ownership for SCRUM teams

I believe ownership and independence always come together. If we want the scrum teams to be accountable for delivery timelines, they should have the flexibility in technology decisions. Team members can work with the architect and decide on the technology choices. Since a microservice is completely owned by the team, they are responsible till the features is released to production. Product owner should pass on the feedback directly to team members. Our developers and testers used to be silent listeners in the calls when product owner is seeking feedback from a customer. This proved to be very effective since developers started thinking from a end user perspective while developing features. It brings a sense of responsibility in the team members.

Team that got the best accolade from customer is awarded in quarterly all hands. With in two quarters teams have become more customer focused and started competing to get kudos from customers. An effective development manager can design the team KRA’s in line with the business goals. It helps in transparency and team motivation to achieve the goals.

Effectiveness of retrospection (Accept failures)

Sprint retrospection

Agile is about continuous improvement. As humans we can never be content with what we have today. We always strive to get better and better. The same thing applies to Agile. This can happen only when the team understands what went well and what can be improved. Role of a Scrum master is very important in conducting a fair and transparent retrospective. An effective retrospection helps in building the team culture and improve productivity.

Management support

Software industry has evolved over the last three decades. Things really started speeding up in the current decade. This calls for unlearning some of the practices adopted by managers earlier. Architectures have become complex; business needs have grown, and we need different approaches to deliver effectively. Things that worked 10 years back may not work in the current scenarios. The core ethos might be same, but we must adapt to the changed environment.

Agile is waterfall in 2 weeks. This statement is wrong. If someone says this, be sure they don't know Agile.

A manager should encourage team members and listening to them before giving his/her views. Authoritative teams may solve a problem, but they can never be innovative and productive over longer period. In my view, majority of the time Agile fails due to the competency of the management and not the team members. Management should allow the teams to take risk. Risks will not payoff always, It is important the team has support from the organization when they fail. Failing fast will save lot of resources for the organization.

Agile antipatterns

Ineffective retrospection meetings:

The objective of retrospection is not to identify an individual who did mistakes. It is important team members are open and share their views during team retrospection. The responsibility is on every team member and more so on the scrum master to conduct transparent and effective retrospection's.

No product owner:

If there is no product owner for longer duration of project execution, the team is bound to suffer. Alternatives must be planned, or a product owner proxy role can be created to work closely with the Scrum team.

Interfering product owner:

Too much of interference by the product owner during sprint execution leads to scope creep. Once a user story is defined the scope must be limited to it. Scope changes in between will impact the sprint planning.

Poor backlogs:

Poor product backlogs leads to ineffective sprint planning and rework. If the user stories and “definition of done” are not clearly defined, then it leads to lot of rework and dissatisfaction. Team members have the right to reject user stories if they are not defined properly. If there is drastic change in scope in the middle of the sprint raise your voice and redo the planning.

No metrics to track the team performance:

Agile advocates tracking team not individual performance. The best stats to measure team’s performance is velocity, Sprint burndown. Team can improve only when the performance is measured.

Scrum board is not up to date:

This is a common problem seen in many Agile teams. Scrum board should always be up to date, to give an exact picture of the sprint progress. Burn down chart will not reflect the status unless the dashboard I up to date. If the Scrum team is spread across geography, then this becomes even more critical.

Changes to sprint:

Changing the stories that could impact the overall sprint goals is counterproductive. It is good to completely cancel the sprint in case this happens. If it is happening often then product owner needs a strong retrospection.

Stories to be delivered:

Plan the sprints with stories that can be delivered into production. Every story completed in a sprint should add some business value. Stories should be delivered with production ready quality.

No compromise on the quality goals.

At the end of the sprint the features should be production ready. Quality goals in a scrum team are paramount. Unit testing & integration testing should be considered in the sprint planning.

Daily status turning into some sort of a status reporting:

Daily Scrum call should be time bound and discussion should happen only on what is done, what is planned and any impediments. Turning this into a status reporting meeting will make these meetings ineffective. Always team members should come to this meeting after the dashboard is updated with the latest progress.

Variable sprint lengths are counterproductive:

If a team did not achieve the goals within the sprint end date, varying the sprint end date does not help. Sprint should end on the planned date and a retrospection meeting will help understand the reasons for failure. If these symptoms are repeated, then there is a problem that management should address.

Special external forces exerting authority:

Once a sprint is defined changes avoid changes unless it is mandatory. One common mistake teams commit is, they accept changes but do not uncommit the scope. Since the time is limited any additional scope needs changes to the planning and uncommitting of some stories. External authority interfering into a SCRUM team would impact the team performance.

This article is a continuation of the microservices architecture series. Please use the below links to read the previous articles in the series

  1. Microservices Architecture
  2. Introduction to Microservices Architecture
  3. Resilient Microservices Patterns


0 0 vote
Article Rating