point
Menu
Magazines
Browse by year:
March - 2009 - issue > Management
Overcoming Blinkered Vision
Srinivas Konidena
Saturday, February 28, 2009
Background
Products are of varied nature. Some of the factors that bring about the variation are size (build size, functional breadth, workflow complexity), the market they address (shrink wrap, Web offering, enterprise solution) and their revenue models (one-time sale, pay-as-you-go, act as media). Each of these factors comes out in different magnitudes and a combination of these determines the nature of a product. In addition to these, aspects like geographical distribution of teams that contribute to building the product play a significant role. One of the most critical components that go into making a successful product is achieving efficiency in software product development with the often talked about goal of 'delivering within time, quality, and budget' Software development has matured over the years and in the process has produced several development methodologies. This has enabled the development owner to choose an appropriate methodology considering the various factors and the context of development.

These methodologies look at the big picture, split the entire process into sub-areas, and provide detailed processes that optimize them.

Challenge -Blinkered Vision One of the key decisions that the development owners make is about choosing the right development process and structuring the groups accordingly. This involves striking a good balance between keeping focus on the big picture and obtaining efficiencies in the sub-processes. While it is easier to manage when the group size is smaller, it manifests into a bigger challenge as the development groups, including marketing, service, and so on grow larger.

In large development teams, there is a strong need for clear team structure. On a practical note, one would see in organizations team leads, managers managing three or four teams, and even senior managers getting to manage a number of these large teams. While one may argue over the need for several layers of management or about the need to have a flat structure, we see this elaborate structure exist more often. For teams that need to continue for a fairly extended period of time, unless there is enough leadership bandwidth, it is difficult to sustain the passion and motivation to consistently deliver. In many cases, especially in large organizations, structures with several layers already exist and it may not be possible to dismantle the existing structures, even if it is desired, and form ones that are more ideal.

To ensure that all the teams perform to their optimal levels, team goals are set and tracked on a continual basis. The teams are led by the leaders who themselves are strong contributors and have evolved to this role due to their excellent abilities in managing their deliveries. They also are specialists in their areas of work (like development, business analysis, and testing) and constantly look at improving efficiencies in their teams for optimal deliveries. As desired, these teams work towards the goals and put in their best to make sure that their goals are met or exceeded. In an ideal scenario, each of these team goals should roll up into the overall product goal, although it is very difficult to achieve.

As the teams get focused on meeting their targets and excelling in their own areas, they exhibit a strong sense of ownership of their targets and work towards outperforming the goals. This, and probably the very nature of 'team spirit' create a kind of 'competition' among the teams. Unintentionally and unfortunately, this 'competition' slowly translates to a 'blinkered vision' among the teams and their leaders thus miss their focus on the end delivery. Due to strong plan focus, each leader works towards ensuring that any changes to the delivery parameters due to their team issues are accommodated within the team. Meeting the plan is considered to be always 'good thing'. While it is good, plans are plans and certain tasks take more resources and others less, than expected. Unless these gains are constantly realized and used in other areas where they may be needed, they are lost.

Our Endeavor We embarked on developing a declarative development framework that was further used to develop and deliver a highly scalable financial services solution to a multinational bank. This involved building a declarative programming tool and a run-time engine that interprets and executes the solution defined with the declarative tool. The framework was an implementation of distributed server architecture on J2EE platform and depends on the platform to deliver persistence, database independence, and scalability. Business logic is componentized and enabled as Enterprise Java Beans that can be deployed on any EJB container. Extensive support for building complex User Interfaces is provided. Capabilities include built-in templates for capturing, editing, enquiring, and reporting of the underlying business entities. Actual screens are dynamic in nature and driven by configuration. The term configuration encompasses various configurable capabilities of the interface like different UI technologies, look and feel, validation on captured data (both business and standard), dynamic rendering of UI components, various screen layouts, and so on.

Development and delivery of framework and solution spanned over 7 years with about 300 person year effort that went through all stages of a product development life cycle from inception to production. This also involved close to 100 associates spread across two locations working in different teams of client support, implementation, business analysis, project management, development (declarative tool, runtime engine, and application), and testing.

We adopted an incremental software development approach, and as the groups grew larger we started experiencing issues of 'Blinkered Vision'. Discussions like 'we have been sticking to our plan but the other team is always exceeding their plan due to which we have to squeeze our efforts and schedule' became common.

Approaches that Worked for Us
To overcome the challenge and to achieve our end goal, we had several brainstorming sessions within the leadership team that resulted in adopting the following two approaches.

* Improving collaboration among the leaders and their teams
* Constant go-live focus Effective collaboration is a key to success in any large organization. This is covered in great length in all leadership trainings. Building strong relationships among the leaders and associates across the organization is critical to have effective collaboration. Regular meetings and involving all leaders in issues that may come up in any team were some actions that helped build strong relationships. At the team level we took some measures to make it more effective. This involves simple (but sometimes hard to do as it affects the team morale) steps like co-locating associates working on the same functionality. This helped breaking the typical grouping - like testers sitting at one place, business analysts at a different place, developers at yet another place - and brought a coherent view of issues and requirements. As a result, the number of testing rejects and developers closing the issues as 'non-reproducible' have significantly come down, thereby reducing the cost of poor quality.

A daily email update on the status was sent to all associates apart from an executive summary (6 parameters and qualitative view of where we are with respect to go-live) to the senior management. This enabled clear and transparent communication to all stakeholders, a critical element of collaboration.

The concept of 'go-live focus' was brought in to ensure that all participating teams worked towards getting the product into the customer's use. The following are some of the significant items that helped us deliver our product earlier than scheduled.

* All enhancements and issues should be taken up for development only, otherwise fixing them will stop go-live. Each of these issues or enhancements should be validated by the users only and not by others like the business Analysts or testers. Criticality and priority levels are generally defined (rather inherited) and are used to determine which items are to be taken up for development. These are typically assigned by the business analyst or test lead since they understand it from a functional viewpoint. However, generally these perspectives are focused on the product, usually from a long-term perspective. Getting a validation from the user about the need for this is essential and we have seen that our views were corrected or modified by them several times. This also brings in confidence, to both the user and product team; about the value that we are delivering.

* Every effort should be made to bring the go-live date forward. This helped us to continuously look for gains in the execution, and in one of the deliveries we went live a couple of weeks earlier. Due to the constant focus on beating the plan, chances of overshooting the date are very low and when we do deliver before time it demonstrates to the customer that we are working towards their success, thereby significantly increasing their confidence.

* Daily go-live status meeting where all leads, not only managers, meet for 30 mins for status review help a lot. This includes implementation specialists and delivery managers from the client's side. This greatly enhances confidence in each other about the commitment to the go-live plan.

* Any item that misses the planned date will have all the associates working on it present in the meeting. This brings in enough seriousness into the group about resolving the issue by working amongst themselves.

* Incentives for any gains made by each group. Like all good things in life, these two approaches look simple but a sustained implementation over a long period of time across large groups requires quite a bit of effort, focus, and dedication across several levels of leadership. These also have undergone several changes during the implementation based on the feedback and effectiveness of some of the activities.

With a strong commitment and great dedication of the participating teams, the solution was delivered in several phases. While the first delivery took longer than expected (with 6 to 8 months delay), the subsequent deliveries were done at a regular interval of three months with the changed model. Success of the above deliveries reinforced our belief that collaboration and go-live focus can break the 'blinkered vision' in large development groups and optimize efficiencies towards the end delivery.

Twitter
Share on LinkedIn
facebook