Engaging Entrepreneurs as Employees

It excites to see a colleague (or an employee), take the needed lead in her/his area of the business and sort of self-manage.

It further excites when these sorts go to the next steps in execution and decision making within their scope of influence.

With their enhanced speed of execution and risk-taking within a given context these "thought leaders" may/will reach a point where they start hitting a certain edge up to which their decision making and/or execution is possible.  Obviously this happens much ahead of the normal progression expected/planned for their job function.

Then starts the phase of limited growth [suffocation] marked with increasing frequency of situations when they get limited (usually not due to execution or decision making abilities).

Acknowledging them as above-par their job function doesn't provide the needed impetus anymore to the entrepreneurial behavior that helped the business growth (in its own part).

Specially in a knowledge based, creative environment, this can manifest very differently. 

Expectation management with such sorts has to be specific and clear to enable a conducive environment for their entrepreneurial abilities to thrive. 

The rules of engagement have to be clear in terms of how the situations on "the edge" can be dealt.

As evident this cant be a part of a formal employee engagement handbook(s). Being able to act as "the catalyst" can make the key difference in enabling these "employee entrepreneurs" to continue performing both to quench their own desire to excel and be at peak while staying equally integrated and aligned with the business.

This is not about the "blue-eyed Top Performers" alone. This needs to extend to the next group who have the potential and out-perform themselves continuously.

Unlike the type and level of risks that an Entrepreneur takes, this breed also handles a certain level of business risk (At the Tactical/Operational levels coupled with swift execution abilities) which can otherwise have either short-term and/or medium-term impact on the ongoing/future business.

Watch out for the Louis Hamilton's driving taxis in your organization. Those capable of steering your organization to its next peak, wouldn't want to be limited to a taxi wheel.

the Recipe (Software) & the Quantities (Estimations)

Software Development & Software Engineering are a bit like Cooking & Recipes.

 

For the Chef(s) (any category of experts ranging from street food joints to house hold cooks), their experience helps think & act in a Blink.

Further in most cases, its an individual cook who is at the helm of affairs. 

When its a bigger group to be catered, the Cooking Team members assumes different responsibilities to deliver the taste on-time, on-quality and sufficient quantity.

Software Development by a group of specialists is a different game versus by a group of individuals (Diverse/Cross-Functional Teams).

To ensure the combined knowledge is uniformly adopted and put to the best use, Software Engineering (aka Recipe for Software Development) creeps in.

 

 

From the seemingly "Unwanted List" of elements of Software Development (from what is otherwise a sort of a creative endeavor), lets discuss Estimations (the Quantities in the Recipe).
 
Like the recipes get perfected over generations, the process of estimation takes a couple of cycles/years to mature.

The process evolves gradually starting with:

 

Estimation Level & Unit(s)

Based on the phase, the level of estimation is different. With a basic understanding of the overall concept to be built, the level of estimation is of relatively higher degree (possible variance in the range of +/- 50%).

As the concept gets broken down into Requirements, the level of estimation starts to move closer to the possible effort needed (variance comes down to probably +/- 25% range).

At the time of detailing of the individual Requirement(s) into work break-down (Tasks), the level of estimation is closest to the possible effort needed in realizing the requirement (variance around +/- 5%).

If the 5% variance appears as a surprises, lets not forget it is an estimation. 

At each phase of detailing i.e. Concept -> Requirement -> Task, there is an increase in understanding, uncertainty is lesser hence the approximation process is better.  

To be able to map the estimations across the various phases, the unit of estimation has to be agreed.

The unit (Day/Hours) has to remain same across all phases, the approximation improves.

The actual planning and execution cycles have to based on the this unit as well.

Estimation Approach

• amount of detail needed across the various phases of the software development life-cycle is different
• estimation at various levels is done based on the understanding and expertise of the concept, skills and other parameters involved in the building and delivery process
• effort needed (Estimate) and duration to get the software built (Duration) are two different aspects
• unit of estimation (Days/Hours) must not be mis-interpreted
• sum total of All Tasks across All Requirements has to add up to the estimate of the Total Concept

Accordingly different teams approach estimation process differently based on how much detail they are working with

Normalizing Estimation(s)

 

The estimations can be different per individual team member given the relative skill match. However for the combined endeavor, the overall estimation has to be based on the average skill of the team involved in building the software. This calls for Normalizing the estimates to ensure, they stay applicable for the whole team. 

 

The process of Normalizing is often based on the build-up of the functional/domain knowledge and the involved technical skill-set. The case of a team member with [High Technical Skill + Moderate Domain Skill] is different than [Moderate Technical Skill + High Domain Skill] or any other applicable combination of these factors.

 

Based on the team composition, the applicable Normalizing has to be applied to keep the estimations reference-able. (The impact due to the newness to domain or the technical skill in terms of applicable learning curve is a matter of planning.)

the Quantities (Estimations) thus have a crucial role in the Recipe (Software) to lead to a tasty delight.

bon appetit !!!

Experiencing the Manifesto as you grow Agile

In some (if not most) of the transitions to an agile way of building software, the awareness of the manifesto happens after having started on the journey. The trigger to adopt agile probably varies in any given situation.

While some take a structured approach to adopt one of the agile software development frameworks, there are many who are looking to find a solution for a specific situation bothering them for a (maybe relatively) long time already.

In cases where the start is a specific situation either "taming the backlog of work" or "incremental software development" or any similar situations, the idea about existence of the manifesto and/or the values it promotes is more a matter of discovery than probably a master plan.  

Aah, there you go.

In the field of Software development there is always some parameter which limits you from re-using an existing piece of software and being able to make a predictable plan of the re-use scenario. 

Barring few instances, most cases involve researching, adapting to a certain degree and dealing with certain unknowns. Making a comprehensive plan in such situation(s) asks for (some) room to maneuver. 

To relate, let me know share two cases to illustrate the point.

Case 1: A software development organization having experienced success with a set of components that worked in tandem wanted to weave them into an integrated system. The idea was to deliver enhanced business value in a seamless manner. This grand ambition off-course lead to meticulous planning and drained all the available capacity to execute and deliver on this multi-year plan. Apart from the delays and impact due to the re-work of the design and re-planning, as more and more resources got absorbed into the plan, work started piling-up, concerning the support of in-production versions of the components and a huge technical debt. Without an end in sight, something needed to change to get things back in control.

Case 2: A software development organization set off to build a completely new product as a stand-in replacement for the existing product. The idea was to use the latest and emerging technologies of the day to stay current with the times. This new product was en-visioned to be a very flexible, and a highly configurable product. In dealing with a product of such complexity, years went by, the team size grew from a select few engineers to almost everyone (barring few entrusted to maintain the existing product). At the end of this period, there was nothing tangible to show to the customer. A different approach was needed to get the development to move further on building value for the customers apart from making a robust software.

As evident in both the above cases, these ambitious endeavors shared space with the other regular bits of work related to maintaining the existing product(s) and component(s). Building these new software in silos and attempting to build them in a start-to-finish manner was apparently not working in the expected way and probably caused frustration across the organization.

These situations lead to looking for a different approach that can help piece the half-baked portions together in a time bound manner. This was off-course "Responding to change over following a plan" in action.

The choice was to adopt Scrum. 

As a first step, instead of "start-to-finish" approach, step-by-step approach was adopted to incrementally get the half-baked portions to shape up into a working software that delivers value to the customer. 

Rather than focusing on detailing all the steps into a plan or finalizing the complete software architecture, it was a brush with working software over detailing.


The new approach did not promise a quick turnaround for all the problems. It helped prioritize the issues and deal with them in an iterative manner. To ensure we stay on course, it was decided to work with the potential users of the software. 

This lead to earlier feedback and to keep the software fit for business use rather than having to defend the quality of the software using the contractual clauses.

kicked off and "Responding to change over following a plan" was happening.

A start-to-finish plan and a completely detailed architecture enforced rigidity into the approach. 

All the internal learning while building the software could not get the required attention due to the rigidity in the plan and not enough scope to re-work and improve.

With the move to Scrum, there was more room to process the internal feedback as much as the external inputs. This helped create an environment of collaboration within the teams. Building the software right took as  much precedence as building the right software. There was increased involvement from all the stakeholders as the software started to shape-up.

became the order.

This was a process of discovery of better ways of developing software. This was a multi-year period of learning the nuances of Scrum and improving upon the way software could be built better. 

The tenets of the manifesto, kind of naturally comes as you start to thing outside of the fixed paths to solve some of the issues.

The paradigm from Manifesto as a goal to Manifesto as a result becomes interesting as it actually matches the whole notion of Agile and the Manifesto itself i.e. change over plan and learn as you go along.

Accepting the change is more important than just sticking to a plan. The world of tomorrow will be different than the world today and hence the plan most likely less relevant. Plan sets a direction and is not set in stone. It needs to be adopted as the execution proceeds further.

When the complexity levels are high, tackling change becomes difficult as all the consequences may not be seen through. Responding to change in such situations might even blur the sense of direction. As you make further steps in this journey, you will come to realize the benefits of working software over detailing, DO over THINK, SHOW over WRITE.

While there was a promise of a certain value in the existing practices, there was more value in the tenets of the manifesto and the Principles behind it.

Author Review - Malcolm Gladwell

How much of advertisement of a product is sufficient to generate enough sales (to meet the revenue expectations)? Can there be a single answer to this question? (which product, what is the target market?). Anyway, let’s look at this story. A group of youngsters wanted to be different than the crowd. For the weekly partying at the local pub, they wanted to make a style statement. They chanced upon an old generation brand trying to keep up with its new generation competitors but unable to match. The choice of their shoes gave a much needed lease to the brand to re-establish itself in the new market. The trend of youngsters using that brand spread up from the local pub to the city and eventually caught up across the country. Hush Puppies was back. Apparently Hush Puppies achieved its tipping point with the new mode of publicity created due the youngsters choice of their products. The phenomenon of tipping point happens in many spheres from product marketing and sales to epidemics. Tipping point represents the point where the activity catches up the momentum and drives itself bigger and bigger. In the case of a disease this represents the spread where it becomes an epidemic. In the case of a product marketing it represents a state of branding where people seek the products without any additional need to advertise.

Some people seem to have a very advanced understanding of certain activities, events, trends or specific situations. They seem to be able to make snap-judgment. They are connoisseurs in specific areas (especially in Arts) who get so good at identifying, analyzing specific situations or trends. A reputed museum housed a piece of a famous statue made in marble. They had in-house experts who helped immensely in the selection and procurement process to guarantee the genuinenity of the piece. The statue was scientifically analyzed for its age, material, origin and other critical parameters qualifying it be showcased to offer the visitors a truly rewarding experience of Italian art in the US. One of the visitors happened to have seen a similar statue elsewhere and was surprised at the possibility of this museum being able to obtain another original copy. This led to some background investigation by the museum curator. The special team from the museum paid a visit to the city of its origin in Italy. There they met one of the artists who expertise’s in the carving of this form of statues. His examination of the copy in the museum revealed some differences compared to the original form. One striking feature that stood out was the nose of the museum piece as compared to the original form of carving. Was the museum piece a well-made fake? This thought spend a chill down the spines of the curator and the museum staff. The statue was procured for a hefty cost and a detailed check to make it worth a certain US$ per visit. What explains the age of the statue? What explains the color degradation of the marble? The Italian carver offered the details on how fake’s market achieve this. The Italian carver was able to think without thinking in a Blink. This ability of rapid cognition happens in many spheres of life by people who have gained such experience to be able to deliver snap-judgments.

In a selected group of youngsters for a sport, some seem to have an advantage due to their date of birth helping them qualify for the group but gives them an advantage of almost 11 months compared to the others in the group. This advantage of almost 11 months (close to an year) in age and probably physical growth can affect their performance considerably. Like in this case with certain persons lie outside of the regular group, this situation occurs in other spheres as well. The term Outliers represents certain things, events  or phenomena that lie outside the normal experience. The situations and/or events leading to the Outliers phenomenon analyze the individuals circumstances combined with the personal drive of in the involved individuals that have either lead to success or trouble.

The above stories have a certain mystery being unveiled. Malcolm Gladwell likes and specializes in unearthing the possible reasons behind these happenings. He has written a series of book focused on topics which seem to re-occur in the daily life around most of us but don’t seem to have a clear explanation.  His books Tipping Point – How little Things can make a Big Difference, Blink – The  Power of Thinking without Thinking, Outliers – The Story of Success bring these stories with their hidden facets either of the individuals involved or the circumstances.

 You can follow more of his work, books and his blog on www.gladwell.com. Happy Reading!!!

Enabling Offshore Product Development (OPD) - Notes and observations (Part-III)

Having a defined set of objectives for the various phases of the OPD helps in setting clear goals and managing expectations of all the involved stake holders.

From a Software Product Development and associated services stand point, the OPD could help in:
- Extending the Product Development stream (Release and Research initiatives)
- Extending the Product Engineering stream (Support and Maintenance)
- Extending the Service Delivery stream (Custom Software and Project based delivery)

Each of the above streams involve a different mix of technical skill(s) and experience background to provide the needed jump-start in the initial phase and sustaining the setup in its journey to the subsequent phases.

To limit the number of variables at play, it is advisable to agree on the various work processes and workflows that will be used in the OPD.

With OPD in its nascent stage, trying hands at experimenting on processes may add further stress in stabilizing the operations.

The existing set of work procedures have proven fit and have undergone the needed refinement over the period and are best fit for roll-out in the new unit. Established practices help in gaining momentum and can be adopted to suit the needs of specific team constructions and/or other aspects of distributed development.

To achieve a jump start, having a good number of senior members with some medium experienced members is advised.

However as the OPD embeds itself into the organization and moves into the stabilization phase, it is good to get a fair mix between senior, medium and junior profiles across the various functions to ensure that a majority of the members have a clear growth path in the organization. Not everyone on board will retire in the current organization :). Identifying the key members and grooming appropriate members to pick up the various operational and leadership roles is a critical part during the stabilization phase to create a sustainable organization.

Knowledge management is another crucial aspect to establish so that the leave of certain members does not create knowledge gaps and impact on the work continuity.

The distribution of work across the two sides must also be balanced in terms of mundane/routine and challenging/interesting nature. Living with the idea that the counterparts on the other side get to do all the new/interesting work will surely hamper the motivation of the smart workforce that we hired :).

Having said that, it is not before the OPD builds up the required level of knowledge on the various technology and functional aspects that these aspirations can be met. Working in collaboration with the parent teams, over the period, the OPD teams must be able to independently function on the stable aspects of work before aiming for more leading edge nature of work.

Matching the interests/expectations of a mixed workforce is not practical. However being able to retain the critical mass to ensure continuity of work, the required level of knowledge retention and sustainable capacity is needed. The crucial factor then is to prepare for a certain level of churn out and its impact on knowledge and capacity.

After the strategic phase of narrowing down to having an OPD, there are a number of operational elements that need to be timely managed to shape up the OPD to match its vision, get it embedded in the parent organization and collaborate, contribute to the success.

In this series, I have drawn the above observations having worked closely in setting up and running both captive and hosted offshore development setups over the course of last seven years. I have tried to touch base upon various elements at play from the operational aspects of establishing, managing an OPD.

Enabling Offshore Product Development (OPD) - Notes and observations (Part-II)

Every initiative to scale-up comes with its own specific set of opportunities and constraints. Multiple elements are involved in getting an OPD to work:
~ people & objective
~ knowledge & process
~ cultures & mindset.

Some of the above elements need preparation and planning. Some aspects like the objective should be upfront shared in the existing organization and needs acceptance to enable participation and support at the different layers in the organization that will have a role in the formation and operationalizing the OPD.

The other aspects of Organizational Preparedness are:
* Executive level support for the OPD endeavor - to ensure that the people responsible for this initiative on both the Parent Organization and the OPD sides are sufficiently empowered to make timely decisions and are not left to defend and justify all their actions and decisions. This is best enabled by having an executive level member entrusted as the Single Point of Contact on the parent organization side.

* Organizational focus from all involved departments in setting up the OPD - to ensure that the needed support from the different functions across the organization happens in a coordinated manner without having to chase all the stake holders to pitch in for their part.

* Acceptance at the employee level to adopt, mentor and work with new setup without the typical fears associated with outsourcing - by keeping the employees informed on the background and objectives the chances of being motivated to participate and support this endeavor are high.

* Organization culture enabling participation (openness, transparency, trust) - to ensure that both at the parent organization side and especially at the OPD side people feel comfortable to discuss the real issues and realistic options without the fear of being shot down for identifying/reporting improvements. There can be no perfect plan to enable an OPD. A lot of improvisation has to happen as the OPD starts rolling out. Hence a culture that enables participation, delegating responsibility and building trust between the existing and new units is a big enabler.

Some of the elements can be tamed and amended to suit the needs. However some of them cant be solved (for e.g. culture, it existed much before this endeavor, your best bet would be to get the different cultures to work together). The overall approach should be to in-source solution(s) and not out-source your problem(s).

In the next part, I will share my experiences on the aspects of working with smart knowledge workers and setting the right expectations from the OPD.

Enabling Offshore Product Development (OPD) - Notes and observations (Part-I)

Among the various alternates to scale, if the option is having an Offshore Product Development (OPD) setup to prepare an organization to handle the expected growth, a decision to establish one is a good starting point. However establishing an OPD center requires some ground work and preparations to realize the vision.

From inception to embedding it as an integral part requires an Organization culture enabling participation (openness, transparency, trust). As the OPD embarks on its journey making the first steps, it needs continuous support in shaping up to its vision. An OPD transforms from a start-up to a partner in progress over a period through the nurturing in its growth phases and embedding in the overall organization.

The critical success factors (CSF's) for an OPD are the build-up of the required levels of knowledge and the formation of a stable and critical mass to be able to independently operate and deliver its value, establishing collaboration with the other counterpart units of the organization.

During the ramp-up phase, a defined approach for knowledge build up is needed. The approach should enable applying the technical/domain skills on the various product areas and build a good understanding of the various work processes. Apart from the initial training, establishing team based mentoring helps in Team formation (new recruits becoming a team) and Integration across geographies (distributed development, cultural integration, co-existence), balancing skills, experience levels to give a head start and enable team collaboration.

After the initial ramp-up as the OPD moves into its stabilization phase, the CSF's change to managing the additions in people, assimilation of knowledge, settling down with the chosen way of doing work, balancing aspirations with growth opportunities apart from knowledge management and knowledge retention. In this phase, there is a need to prepare for some churn out and its impact on the short-term and medium-term plans of the OPD.

In the next part, I will share my experiences on the aspects of Organizational preparedness for establishing, working with an OPD and working with smart knowledge workers and their influence on the success of the OPD.

Winning with Scrum Teams

Scrum as an Agile Development methodology focuses on the providing much frequently needed agility in the development process to better respond to changes i.e. 1 opportunity per Sprint versus a Fixed time slot (when and how much) approach in the traditional development methodologies.

Scrum also puts The Team in the drivers seat to plan best to the team's collective abilities and deliver on the commitment.

Apart from these the Scrum Team also get empowered due to their Size. Ideally a Scrum Team must be around 7 to 8 persons. The team must be multi-skilled i.e. all the needed skills must be there in the team (for Software Development this translates to Developers, Testers, Functional Designers, Technical Writer).

With clear roles and non-overlapping responsibilities for each team member, a clear ownership gets established and helps the team function as a unit towards the team targets and deliverables.

The daily morning time-boxed Standup meeting with specific questions helps cut down all the un-necessary communication lines. It brings out all the known dependencies, bottlenecks and facilitates making an effective daily plan of actions by priority.

Furthermore with ScrumMaster designated to move the bottlenecks, it leaves the team to focus on the commitment.

This underlying power dis-invested in a Scrum Team maximizes the return to the development process and the department.

The Approach of Scrum Teams and Sprint based execution needs some organizational preparations. However the return on such investments is improved team effectiveness, productivity and brings in the much needed Predictability.