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.

Agile Transformation: 8 Mindset-Shifts You Make In Your Agile Adoption Journey

by Avienaash Shiralige 17 Comments

1. Senior Management

Agile is a silver bullet that will fix all issues is a myth. But Senior Management perceive this as fact. Agile and its frameworks have a great knack of bringing forward hidden organization issues like tendency to command and control, developers/testers taking short cut to quality, less focus & preparedness to test automation etc. Agile need for cross-functional roles and collaboration within the company can create issues in strictly functional organization structures. Companies need to adopt matrix structure

2. Senior and Middle Management

Their affinity towards metrics to compare productivity between different teams or an attempt to measure productivity at individual level may derail your agile efforts as it can be easily misinterpreted by teams and can work against Agile values.

3. Project Manager

Given focus on transparency and on pushing responsibility to the team, the Project Manager will be less of a task manager, and more of a problem solver, and will have to “let go” of a lot of previously held control. There is an increased emphasis on honesty, openness, and trust that may feel very different. Operating in an adaptive planning environment will feel very uncomfortable to many.