Agile

Waterfall to Agile : Experiences from Trenches

Image credit – https://vitalitychicago.com via https://i1.wp.com/vitalitychicago.com/wp-content/uploads/2017/11/how-to-successfully-transition-from-waterfall-to-scum_methodology.jpg?w=1024&ssl=1

There have been a lot of agile success stories but mostly are around project challenges and how teams overcame them. In those high level details, the experiences from the trenches get hidden or get overlooked.

There are still many projects and people, who are transitioning from waterfall to Agile. It’s interesting for such people to hear the experiences from similar people (who moved waterfall to Agile) around their role, i.e. how for a developer role things got changed and similarly for tester/BA/Scrum Master roles as well.

This post is based on the real interviews of team members of such a project in a large enterprise. The team members shared their perspectives around their role. For everyone in the team, this was their first ever Agile project.

#NoStandup – Remote Team Collaboration Patterns

by ShriKant Vashishtha 2 Comments

What happens when each team-member of your team works from a remote location (possibly from a different time-zone and country).

How do you sync-up in such a team?

Agile vs DevOps : Demystifying DevOps

by ShriKant Vashishtha 4 Comments

Organisations are embracing DevOps which is great. However the whole adoption is causing a lot of confusion as well.

Some of you might have heard the term “Agile and DevOps”. With that it looks like Agile and DevOps are different. To over-simplify further people assume Agile is all about processes (like Scrum and Kanban) and DevOps is all about technical practices like CI, CD, Test Automation and Infrastructure Automation.

This is causing a lot of harm as some organizations now have Agile and DevOps as two separate streams as part of their enterprise Agile transformation. Agile by definitions disrupts silos and you see, in this case people are creating new silos in the name of Agile and DevOps.

With that background in mind, let’s try to understand what exactly DevOps is all about.
[Read more…] about Agile vs DevOps : Demystifying DevOps

Why “Definition of Ready” is Mandatory in Distributed Agile?

by ShriKant Vashishtha 1 Comment

In one of our earlier posts I discussed the elements and benefits of “Definition of Ready”. However it’s quite common to see totally opposite views of purists as they believe that Definition of Ready is not required at all.

I agree to their views to some extent if it’s all about collocated teams supported by dedicated product owner in the same time zone.

However, distributed Agile is a different beast altogether. It’s quite common in India to work with customers in opposite time-zones. Distributed communication essentially is an overhead. So the clarification which you receive in minutes face-to-face with collocated product-owner may require multiple iterations of distributed communication. Multiple iterations essentially mean multiple days.

So a READY user-story which could be finished in 2 hours now takes days to complete because of to and fro communication between distributed team-members to resolve unresolved queries.

Definition of Ready in such cases helps in bringing clarity and in keeping team members and product owner on the same page. Any absence of clarity essentially complicates the cycle time and throughput of a sprint.

More on Backlog Refinement, Story Points and Agile Estimation

This post is a part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series.

Jira and Agile : Using One Backend for Multiple Platforms

by ShriKant Vashishtha Leave a Comment

It’s common to have applications available for multiple platforms (web, Android and iOS) these days. In most cases, common backend services are used irrespective of the interface.

In such cases, it is tempting to have separate teams for backend and front-end interfaces. Unfortunately temptation in this case doesn’t help the business. It becomes very difficult to see the functional progress while having separate backend and frontend teams. On the surface, it looks like everyone is busy but in reality, the outcome can be frustrating with no production ready features.

The solution is to have functional cross-functional teams which could work on a vertical slice end-to-end. For instance, it’s ideal to have a team focused on iOS platform comprising both iOS and backend developers.

Makes sense, but then how to handle the redundancies as the same service may be useful for web as well?