Archive for the ‘Process Transformation’ Category

Do I need a Leadership Coach?


The ride is not always smooth for company CEO’s as the journey they have embarked on is full of challenges. They need lots of courage, resilience, perseverance and grit in order to survive and captain the ship in the rough waters. The new leaders has another challenge as they are increasingly operating in the VUCA world today. They need to not just be Servant Leaders, they are expected to demonstrate a Fluid Leadership style. The good news is, they have help in hand. All they have to do is, be willing to seek guidance and support from Leadership Coaches.

Here are some tips for when and why you or your organization needs Leadership Coaching;

Tip 1: When your organization is undergoing radical (transformational) change, you need a Leadership Coach.

Tip 2: When your organization has a new leader, you need a Leadership Coach.

Tip 3: When your organization need to bring about a cultural change, you need a Leadership Coach.

Tip 4: When your organization has witnessed a merger or acquisition, you need a Leadership Coach.

Tip 5: When your organization is missed your quarterly earnings, you need a Leadership Coach.

Tip: 6: When your organization’s customer complaints have exceeded your threshold limits, you need a Leadership Coach.

Tip 7: When your organization’s senior leaders lack listening skills and lack empathy, you need a Leadership Coach.

Tip 8: When your organization needs to thrive in the VUCA world, you need a Leadership Coach.

Tip 9: When your organization’s leaders fail to see the big picture, you need a Leadership Coach.

Tip 10: When your organization does not figure in the Top 5, in your industry, you need a Leadership Coach.

Hope this helps you decide on hiring a leadership coach.

P.S. Vasanthan Philip is an enterprise leadership and change coach with over 30 plus years of experience having worked with Fortune 500 companies around the world. You can visit his website at 


Emotional Leadership

Read my article on Emotional Leadership published here in an Global HR magazine’s Jan-2018 issue.

Scaling Scrum

Worth reading on Scaling Scrum from the founders….

Ken Schwaber's Blog: Telling It Like It Is

Jeff Sutherland and I have helped hundreds of organizations scale their projects, enable their entire product development, and thread Scrum through their organizations. For sure, none of them were easy, and each had its own unique challenges. Each had its own structure, culture, goals and strategies, challenges, current practices and infrastructure, domains of competence, existing software, and people.

We assert that only a systematic, emergent, managed initiative to scale succeeds. Every initiative to scale is unique. Nobody knows what your organization needs to scale Scrum. And, nobody knows what your organization will look like as you scale.

To get a good feel for what scaling Scrum feels like, I refer you to Eliyahu Goldratt’s “The Goal” (or any of his later books), or Gene Kim and Kevin Behr’s “The Phoenix Project.” You will see the difficulty of teasing through symptoms to root causes, the effort to find solutions, and the…

View original post 374 more words

Another one on calculating an Initial Velocity

This is adapted from

Velocity is a very simple method for accurately measuring the rate at which teams deliver business value. To calculate velocity, simply add up the estimates of the features successfully delivered in the last sprint or iteration. What about the initial iteration?

Terms to understand when calculating initial velocity:

[1] Number of Developers – How many developers will you have doing actual work?

[2] Capacity – What is the maximum amount of work one person can accomplish in an ideal situation during the iteration?

[3] Number of Iteration Days – How many work days are in the iteration?

[4] Load (Capacity) Factor – The ratio of the actual work output over a period of time and the output if the developer had operated at full capacity over that time period. e.g. 1/3 = 2.4 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours

[5] Velocity – How much Product Backlog value a team can deliver in one iteration.

Because you don’t know team velocity for the first iteration, plan initial velocity at one-third of total capacity in order to account for coffee breaks, design, email, meetings, rework, research, etc. As an example, with seven (7) developers and at one-third (1/3) capacity, a total of 2.1 ideal developers are available. Multiply the number of ideal developers by the number of work days to arrive at the total of ideal work days. These ideal work days will be applied against your estimated features, to arrive at an initial velocity.

(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]

Happy Scruming….


Initial Velocity

There are occasions when one needs to predict team velocity when there is no historical data available. Here is a good example of how we can establish an initial velocity. This has been adapted from Crisps Blog pages.

“This is how you can get started. Take a well known task/story as your standardised benchmark. If this a rather small story, set it to two story points so you have room for smaller stories. Estimate the rest of the stories relative to this.

Before our first planning meeting we need to know our velocity so we know how much we can commit to. But we don’t have that since we don’t have a history.

To get an initial velocity for our first sprint, we estimate the selected standard story in ideal man days. Let’s say the story is 2 story points and 4 ideal man days, we then know the team can handle 1/2 story point per ideal man day. Use the focus factor to convert ideal man day to calendar days. The focus factor is typically between 50% and 70% depending on the amount of support and interruptions. If the focus factor is 50% we can handle 1/4 story point in a calendar day (1/2 * 50%). If the team consist of five people and the sprint is 14 days we have 70 calendar man days in the sprint. 70 * 1/4 gives that we should be able to bring 17 story points into the sprint. Finally we have our initial velocity.”

Hope you liked it.

Cheers!!! Happy Scrumming.

Adaptive Leadership

December 12, 2013 Leave a comment

What is Adaptive Leadership? Today we talk a lot about Agile, the buzz around it, and how it is helping organizations transform. It is Agile that introduced the term Servant Leader, right? In the context of leadership, these terms are used interchangeably. Lets look at Adaptive Leadership.

1. Adaptive leadership is the practice of mobilizing people to tackle touch challenges and thrive.

2. Adaptive leadership is specially about change that enables the capacity to thrive.

3. Successful adaptive changes build on the past rather than jettison it.

4. Organizational adaptation occurs through experimentation.

5. Adaptation relies on diversity.

6. New adaptation significantly displace, reregulate and rearrange some old DNA.

7. Adaption takes time.

Good leaders should distinguish between technical problems and adaptive challenges. Adaptive challenges can only be addressed through changes in people’s priorities, beliefs, habits, and loyalties. Technical problems can be solved through the application of authoritative expertise and through the organization’s current structure, procedures and ways of doing things.

The adaptive leadership process consists of 3 steps, Observe, Interpret and Intervene. One must be willing to experiment and willing to take smart risks. The adaptive leader shall also engage above (intellectual, emotional, spiritual and physical) the next, and below the neck (mind, heart and body).

Finally the adaptive leader is connected to purpose, choosing among competing, legitimate purposes, sacrificing many in the service of one or a few, in doing so making a statement about what you are willing to die for, and therefore what you are willing to live for.

Have a great day.

Visit me at (or)






Envisioning the Product

September 26, 2013 Leave a comment


Recently I was reading a chapter in a book. The title was “Envisioning the Product”.  It’s important that Scrum Team members know and understand what they are working for. I will mention a few snippets from the chapter.

1. The Product Vision: Understand the product vision. The vision describes why the project is being undertaken, and what the desired end state is. Asking question like, “Who is going to buy the product?”, “Who is the target customer?”, “Who are the target user?”, and so on will help pen down a vision.

2. Minimal Marketable Product: To create a vision, the Scrum team has to peek into the future and state what it believes the future product will roughly look like and do. As our ability to predict the future is limited, our best chance of success is to envision the minimal marketable product, a product with minimum functionality that meets the selected customer needs. The key is identifying a narrow set of customer needs, and full-filling them. Read the book “Software by Numbers” by Mark Denne and Jane Cleland-Huang’s for more insights.

Once the vision is available, it is turned into a shippable product by leveraging customer and user feedback; the feedback is collected by demoing product increments in the sprint review meetings and by releasing software early and frequently. Working this way allows the Scrum team to find out quickly if the right product is being developed.

Keep the following in mind.

a. Simplicity – Simplicity facilitates creating a product with the minimum functionality that is easy to use. Don’t mistake simplicity for creating simplistic products. As Leonardo da Vinci said, “Simplicity is the ultimate sophistication.”

b. Ockham’s Razor – Using simplicity as a guiding principle. Ockham said “given a choice between functionally equivalent designs, the simplest design should be selected”. Simplicity is not only about the aesthetics of a product. It means focusing on the product’s essence, building only what is really needed, and being able to adjust and extend the product easily.

c. Less is More – “The simplest way to achieve simplicity is through thoughtful reduction. When in doubt, just remove”, says MIT profession John Maeda, who is an expert in Simplicity. A company called 37Signals says “Do less than your competitors to beat them … Take whatever you think your product should be and cut it in half … Start off with a lean, smart app and let it gain traction. Then you can start to add to the solid foundation you’ve built.”

d. Simple User Interfaces – Google says “Our hope is to evolve products in new directions instead of just adding more features.” Google doesn’t set out to create feature-rich products; our best designs include only the features that people need to accomplish their goals”.

3. Customer Needs and Product Attributes – These are at the heart of the vision and deserve close attention. Selecting the relevant customer needs tells us which market or market segment we are going to address. By focusing on the needs, we view the product as a means to an end—serving the customer or user. Product attributes, on the other hand, are the critical properties the product must have in order to meet these needs. Once we have identified the product attributes, it’s often useful to prioritize them; attributes serving several needs are important and should be high priority. Prioritization is particularly helpful when attributes conflict.

Techniques for Creating the Vision:

a. Prototypes and Mock-ups

b. Personas and Scenarios

c. Use cases and User Stories

d. Sequences and Storyboards

e. Vision boxes and Trade Journal reviews

f. Kano Model

Product Road-map – The new product versions still need goals. A product road map allows the Scrum team to capture the goals of upcoming product versions; visioning now forms a part of creating and updating the product road map. A product road map is a planning artifact that shows how the product is likely to evolve across product versions, facilitating a dialogue between the Scrum team and the stakeholders. A road map allows organizations to coordinate the development and launch of related products, for instance, a product line or a product portfolio.

Minimal Products and Product Variants – As a product matures, it might address a growing number of customer needs, for instance, by serving customers in different segments and different regions. Dealing with many diverse needs makes it more difficult to create product updates with minimum functionality; more and more features are required to support an ever-growing number of customers and users. To solve the problem, we take advantage of product variants. Each variant addresses a specific customer group and market segment.

Common mistakes to avoid:

a. No Vision

b. Prophecy Vision

c. Analysis Paralysis

d. “We know best what is good for our customers”

e. “Big is beautiful”.

Reflection: Ensure Scrum teams have a shared vision. Think big, but start small.  Put the vision to the test by inviting customers and users to sprint review meetings and by quickly releasing a product increment. Then evolve your product based on their feedback.

Hope this article has provided some perspectives on Product Development.

Have a great day.

Visit my website at