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.

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

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?

Streamline Your UAT and DevOps – Kanban Boards

by Avienaash Shiralige 4 Comments

In my earlier post, we discussed using planning boards to improve your backlog planning and eventually to improve your planning flow. Main project workflow remained same.

Note: People landing on this post directly, please read earlier post to get context of the problem.

This team was using 2 week sprint model for execution. Often stories got completed(tested), but left on the scrum board UAT pending. All real users were on-field consultants, hence not easily available for UAT. This reduced team throughput(velocity). Team decided to change their approach and modify their definition-of-done. They decided to have a done column before UAT. Post demos relevant stories were moved to done. In-fact they did multiple demos to product owner all through out the sprint as stories got completed. They configured their execution scrum board as shown below.

Mind the gap: Engineering Teams in 21st century, Management in 20th century

by Avienaash Shiralige 3 Comments

Quite often I get to see engineering teams – upto middle management being new to agile, are ready to give it a try. But they have real problem on hand that is – coaches asking them to:

Embrace change from business and at technical practices level
Question traditional approaches of development
Do some planning not much
Do some analysis not much – leading to analysis paralysis and list goes on…

But engineering teams have to give their management:

Long term plan
Have to commit to project estimates at the start
Accept all the scope changes keeping time almost same and goes on….

Saying “NO” to unrealistic expectations, scope and time is biggest cultural change. We see it so often. You can read more about this in my earlier post Sustainable Pace: Does Culture Play Any Role At All

One of the biggest myths in the industry or mis-understanding is: “Agile is for engineering teams”. It is engineering team who has to adopt to agile way of working to deliver sooner than they were doing earlier. It is them who have to accept changes from business. This kind of agile implementation fails miserably. Even business must be ready to accept surprises or changes from the engineering team. If engineering teams hit a roadblock and unable to deliver few stories(assuming product team was informed timely) then management should try to accept this. Business must be flexible to accept change.

Hence embracing change is both ways. Management can not be practicing traditional school of thought like “I want everything by this time” – “command-and-control behaviours” and expect their teams to be fast, agile and flexible.