Business Agility: What does it mean for IT

Over the last few years, I have been thinking about "Business Agility" and its meaning. While working with clients, I have always felt the presence/absence of business agility but articulating it clearly was a challenge. 

While I was proposing my talks for the Discuss Agile Conference 2015, Delhi, I decided to take a stab at distilling and articulating my idea of business agility. Hence, I proposed a talk titled "Business Agility: What does it mean for IT". Over the next few weeks, I went through all the projects that I have been part of, trying to recognise patterns that can help define business agility. I also researched on a number of companies, young as well as established enterprises, to look for patterns that can define business agility.

I was also looking for a definition of business agility liked the following two definitions, out of a number of definitions that exist,  as these capture the essence  of business agility

Wikipedia: Business agility is the "ability of a [business system] to rapidly respond to change by adapting its initial stable configuration”

Forrester Research: “… the transition to a digital business that allows an enterprise to embrace market, organisational, and operational changes as a matter of routine.” 

Technology seems to be playing an important role in enabling business agility. We are in data and information age and technology drives the possibilities. Almost all the successful cases of business agility have technology at the core of it. 

I identified the following patterns of business agility. First, business agility is enabled by IT being a business driver rather than just a business enabler. This is true for startups  as well as established enterprises. Second, leveraging technology for innovation that enables business agility. A number of business have been able to redefine themselves or have been able to scale at a very rapid rate because of technology based innovation. Third, IT leading and redefining customer engagement. In the present day world, customer engagement is driven via multiple channels and most of theses channels are technology enabled/driven. Fourth, IT leading revenue generation.  CTO's organisation is no longer a cost centre but is expected to drive the top line. 

The above mentioned patterns are distilled into the following, which according to me is "IT Manifesto of Business Agility"

Business Driver over Business Enabler

Innovation Leader over Enabling Efficiency Gain

Leading Customer Engagement over Supporting Customer Engagement

Revenue Generation over Cost Saving

Traditionally, IT has been focused on the items on the right and that has enabled businesses to grow and gain efficiency. While these will continue to be important, I think it is IT's focus on the items on the left that will define the existence and relevance of any business in the coming future.

Agile Business Analysis: An art neither well understood nor well practiced

More than a decade ago, when I started as a Business Analyst on my first agile project, I was not sure of what is expected from me. I had done analysis in a waterfall setup but I had no clue of analysis in an agile setup. One of my mentors, at that time, offered a definition of the role of business analyst and I am still exploring the depth of that definition. He said, "In an Agile setup, there is tremendous amount of churn between the customer, developers and quality analysts. The role of a Business Analyst is to manage the churn". Even today, whenever I get into analysis and story writing, I still think about this definition and learn few more things.

Over the last decade or so I had opportunities to interact and work with a number of clients who had embarked on the agile journey but the project(s) were not delivering the desired results. Some of the common complaints were

- We have completed development and are having some last minute testing

- Even though the developers complete the iteration's development in time, the customer takes a long time to accept the stories

- The developers are not able to keep pace with the changes that customer needs

In almost all these projects, analysis has been one of the weak links. The problems with analysis seldom show up within the analysis process. In most of the cases the symptoms of the problem are visible much later in the cycle, sometimes even post production.

I have had multiple attempts at generalising the solutions that have worked for me as a business analyst in the above mentioned scenarios but every such attempt of mine has failed. Hence, I believe that there are no rules for getting the analysis right esp. in an agile setup. It is an art that the practitioner needs to master. Thinking about analysis in terms of steps, rules, check lists etc, the takes us farther from getting better at analysis.

Having said that, based on my experience, I believe that the following set of behaviours can help in mastering the art of analysis and more so in an agile setup

1. Customer's best friend: The first and the most talked about responsibility of a business analyst is to be the proxy for the customer. In order to achieve this, the business analyst needs to be the best friend of the customer and understand the customer well. The business analyst should see his/her success and failure to be same as customer's success and failure. With this deep understanding and empathy with the customer, analysis and writing stories is simpler.

An example that definitely comes to my mind is when we were building a CRM solution for an investment bank. We were not only able to course correct some of the features but were also able to add new features and drop existing ones because we were focused on helping the business achieve its goal. It was not as easy because every time we wanted to drop a feature, there were emotional reactions from the users/sponsors who had proposed the feature. 

This also goes a long way in earning the respect and trust of the team as the business analyst becomes the real proxy and can make decisions rather than acting as a conduit between the team and the customer.

Something that a business analyst should always remember "A true friend is not the one who is always in agreement". 

2. Story Teller: The skill of writing stories is much talked about. In my opinion, a business analyst need to be a good story teller. It is not from the perspective of writing stories, but it is the ability to create appropriate interesting stories and narrate it to both the customer and the team. These stories help achieve two goals. First, collate your past experience and apply it to present customer's business context to evolve the best possible solution. Such stories go a long way in creating positivity around the proposed changes. Second, to help the team understand the business and its goals. A session to talk about business may not interest the team and there will be limited retention of the information shared during the session. Story telling is much more effective method of dissipating the business knowledge in the team.

When I was part of a team building an online store, I used to tell a lot of stories to the customer extracting my experience of being part of teams creating digital jukeboxes, trading solution for stock exchanges and financial systems. It was very easy for the customer to relate to these stories and appreciate the alternate point of view.

Similarly, as part of the team that was creating digital jukeboxes, we used to narrate a lot of stories around jukebox industry and the music industry and how the customer is trying to differentiate. These stories were narrated on a continuous basis resulting in the team gaining a much deeper understanding of the business and finally, simplifying the complex parts of the system.

3. Gate Keeper for the team: The first reaction of most people to this term is "Project Manager". While project manager may be expected to be the overall gate keeper for the team, it is the business analyst is better equipped to be the first gate keeper. Most of the scope changes are known to the business analyst much before those get bubbled up to the project manager. The business analyst need to own the overall scope and changes/negotiations on the same.

4. Delivery owner: This is not about doing away with the Delivery Manager role but the business analyst need to have the delivery owner mindset. The business analyst's role starts at the conception of a feature and ends at successful delivery to production. Only analysis of requirements or writing stories and then throwing them over the wall to the development team invariably results in a product that does not meet the vision and has too many defects/changes. As the requirements progress through various stages, there is a tremendous amount of feedback that comes from various team members. For a business analyst, listening and acting on that feedback is one of the keys to success.

5. Complement the development team: Last but not the least, the business analyst complements the team by bringing in the business understanding and helping the team at every step. The business analyst is part of the team and not an external entity. In my experience a very close alignment between the business analyst and the technical lead is a must have for the success of the project. Any mis-alignment between these two leads to a solution that is not true representation of business needs and goals.

Unfortunately, analysis continues to be not seen as an art and there is continuous creation of checklists, steps etc. For business analysis to be successful, it needs to be thought of as an art that needs to be practiced to get better at. 

Large Team, 6 week Release Cycle...... Transition between Releases

In the past 5 years that I have been working with Agile teams (10-25 members; 4-7 month release cycle), I never had to think too much about transitioning the team from release n to release n+1. The transition has been quite simple so far. A release typically consists of a number of iterations followed by a regression and/or UAT phase. During the regression period the team will be fixing defects and stabilizing the application for deployment to production. As we progress into the regression and/or UAT phase, the number of defects reduce. At that point of time, we could branch off for the release. A small part of the team would continue to fix defects on the release branch. The number of defects fixed after branching is not too big. With regular merges from branch to trunk, we could easily make sure that all changes from branch are available in trunk as well.

The current team that I am working with, is 190 people strong. We have been working on this code base for more than 2 years. We follow a 6-8 week release cycle i.e. a release is deployed to production every 6 - 8 weeks. The above mentioned model/process fails because of the amount of changes that that this team accomplishes per day. Since the team and code base are big, we may fix up to 30 defects per day. If I try to replicate the process/model mentioned above for a small/mid size team, the merge becomes very painful as the amount of changes on trunk as well as the branch are too big to be merged effectively. Most of the merges will result in some defects either getting reopened or some new defects getting introduced. In order to reduce this problem, we should branch as late as possible. At the same time, if we have the entire team fixing defects, it is impossible to find work for all the dev-pairs on the team. So, from this perspective, we should branch as early as possible.

In order to make the transition as smooth as possible, we needed to get a period where we could fix defects and stabiles the build and at the same time continue to develop new functionality without impacting the release. Rajiv and I started looking into our story backlog to check if we can find such stories. We soon found that such stories do exist. Any story that is impacting/changing a feature not going live in the current release falls under this category. In our case, the application has 15 portals. If a portal is not getting delivered as part of release n, then we can continue to make changes without impacting the stability of the application. Other easy example is if a feature is hidden behind a permission and will not be delivered as part of release n, we can play stories that change/evolve this feature. While identifying these stories we need to evaluate if the story has a potential to impact other features as well. If the answer is yes, then such story should not be played before branching.

This approach provides and optimal balance between the need to branch as early and as late as possible. Using this approach we can ensure a smooth flow of stories through the pipeline even when the team transitions from release n to release n+1. The team never starts from an empty pipeline and thus the entire system is geared to maximize the throughput.

In addition to the above mentioned approach, GIT has helped us to considerably reduce the effort and time required for merging from a branch to trunk or across branches. I will share our experience of working with GIT in my next post.