Agile Transformation

In Conversation with Tim Ottinger Series: Should We Really Care for Agile Maturity?

We keep facing real world challenges in Agile world. For some challenges, the rule-books provide straightforward answers but empirical evidences show the contrary. That’s where Tim steps in and helps us in understanding the nuances and demystifying the problem space.

In recent past, we have had many such conversations with Tim on our Slack group “Agile Commune”. All those are full of insights and very helpful. We’re making some of them public as part of “In Conversation with Tim Ottinger Series“. Looking forward for your comments and experiences on these topics.

Shrikant: Hi Tim. The tools (like Scrum, Kanban, TOC, XP etc) are to solve business problems. They themselves are not the goal. How do you define agility?

Tim: To me “Agility is a means to an end, not an end unto itself.”

I would say that agility is a process goal, not a business goal.

To be able to change direction at the drop of a hat is powerful — provided your organization plans to do some pivoting.

Agile methods have the goal of creating some agility in the business, or at least the conditions making it possible.

Some methods are better at using agility than others.

But remember that a skateboard is more agile than a freight train, but a freight train is bigger and faster than a skateboard.

Be sure you know what you want.

From Branch Merge Hell to Trunk-based Development – A Bank Agile Case Study 2/n

by ShriKant Vashishtha 1 Comment

Lots of organizations are desperately trying to bring agility in their enterprise IT. In many such cases, enterprise IT stands on the worn pillars of traditional Waterfall process and legacy products.

The business in such orgs sees IT as a black hole where no business need can escape from inside it. The reason being, traditional process, and legacy systems take months of cycle time to deliver almost any business need.

This results in frustrated and desperate stakeholders who threaten to try anything or everything under the sun to get tangible outcomes.

This case-study is a story of a bank which was almost on the verge of outsourcing its entire IT. The bank since has moved on to become one of the pioneers in banking innovation space. The bank focuses to serve its customers with innovation and agility in its offerings.

In the first part of the case-study, we looked at the difficult conditions the team lived in. That was more to do with technical processes they used for handling multiple projects at the same time. This part focuses on how they moved on from the branch merge hell they lived in.

The Branch Merge Hell Team Lived With – A Bank Agile Case Study 1/n

by ShriKant Vashishtha 4 Comments

Lots of organizations are desperately trying to bring agility in their enterprise IT. In such cases, enterprise IT stands on the worn pillars of traditional Waterfall process and legacy products.

This results in a frustrated and desperate stakeholders who threaten to try anything or everything under the sun to get tangible outcomes.

This case-study is a story of a bank which was almost on the verge of outsourcing its entire IT. The bank since has moved on to become one of the pioneers in banking innovation space. It focuses to serve its customers every day with innovation and agility in a faster paced competitive ecosystem.
[Read more…] about The Branch Merge Hell Team Lived With – A Bank Agile Case Study 1/n

Agile : The Dilemma of IT Service Organizations

by ShriKant Vashishtha Leave a Comment

I spent a big amount of my IT journey in working with IT Service organizations which Product organizations call as vendors.

While product organizations can decide how exactly they would want to work, teams from service organizations are mere extension from a customer enterprise IT strategy standpoint. Whether to work in Agile or not, Agile or AgileBut, all that is driven by the customer. If customer continues to work in Waterfall, you may not use Agile in isolation.

For service organizations, money comes from the headcount and the billing rate. As long as that’s improving while keeping the status quo, sometimes management may not see any specific value add in focusing on things which are not burning. That includes innovation, adopting Agile, TDD or focus on long term quality.

In short, customer drives the show. If customer is quality conscious, vendor follows the suit. Otherwise maybe not.

Service organizations play the software development service provider role in the enterprise development value stream. They focus on optimizing what they essentially work upon from Agile and DevOps standpoint which translates to improvising technical practices, automation and some DevOps technical practices.

While doing so, the trouble is – they don’t get the awareness of the whole, the whole enterprise landscape. That perspective is important for enterprises implicitly but not necessarily out of question for service organizations. It’s not easy to get such awareness. That’s the reason it becomes easy to miss.

In some Indian Agile conferences, where audience are majorly from service organizations, sometimes, people find anything beyond their technical scope as less useful. There, it seems like, automation and DevOps technical practices are the panacea of software development world. These practices are easy to talk about, difficult to implement and are definitely not the low hanging fruit for any enterprise.

There may be many other low hanging fruits which bring a lot of value add and reduces the cycle time without spending a lot of time, money and resources.

I understand the dilemma, however without understanding the whole or the big elephant, it becomes difficult to provide the real value add to the customer.

Good people in such orgs who really want to work in Agile environment find themselves helpless unless that’s the part of customer IT strategy. Employees may then get frustrated because of lack of opportunities.

What if service organizations are ahead of the curve and help customers in looking ahead? That requires spending on innovation and research which not many orgs do as of now. But you see, the focus on innovation has become important for survival these days.

Use Planning Board for Product Backlog Grooming

by Avienaash Shiralige 4 Comments

In our earlier post – Improve sprint throughput we had discussed about how important it is to have stories ready for play before team picks it as part of the sprint. In short, if half-cooked stories are pushed to sprints for execution, then team will spend lot of time analysing, re-working and this eventually reduces team throughput. To address this challenge, few of my teams thought of creating a separate planning board in Jira to track planning readiness. This board was used by PO primarily to keep a tab on the backlog and also by team members during backlog grooming session.

Team was using Atlasssian Jira, I will show here how we modified the workflow and boards within Jira. Some of the issues teams had faced with the backlog not being ready were:

Insufficient scenario analysis in user stories
Lack of functional and technical impact analysis
Not much details/mocks within the story
Team doing sizing estimate during sprint planning – this was the first time team was seeing those stories and hence made sprint planning long and inefficient

Hence a workflow was designed to address above issues. Take a look at the workflow below(pasting it from Jira).