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 www.vasanthanphilip.com






HR’s Role in Agile Transformation

In many of my training programs, I am usually asked about the Role of HR when it comes to performance evaluation of Agile Team members. I recently found an interesting read that I thought I’ll share with you. 

Check this article out, as it provides some insights.


We know that the Agile Project Manager’s role is important here. The Agile PM needs to motivate teams rather than individuals. He or she also need to change the Performance measurement criteria so that it compliments rather than contradict Agile values. For this to happen the Agile Project Manager shall need to trust and empower the teams’s self organization and also work with the team to determine metrics for team evaluation. The focus should always be on team rewards rather than individual rewards.

Have a great day.


Agile Coaching

August 5, 2012 1 comment

Often I get questions about what Agile Coaching is all about. How is it different from being a Scrum Master or an Agile Project Manager, or for that matter, even a Agile Consultant.

An Agile Coach plays a significant role in the success of projects. Usually it is a matter of how much time a coach can spend with the team into making it a high-performing one. With delivery commitments that the teams have, it is a fine balance the coach will need to seek in an attempt to change team behaviors and practices.

An important aspect of coaching is observation. The coach needs to observe how the team is collaborating and communicating as these are two important aspects of getting things done in Agile project. Collaboration in Distributed teams is often a challenge and the Coach plays a vital role in helping teams collaborate better.

The other aspect of coaching is to provide constant feedback. The coach will observe how daily-standup’s happen, how the sprint planning/review happen, keenly observing these meetings and will provide valuable feedback on what improvements can be made to make these ceremonies effective. The feedback will be on individual as well as team level. What transpires as an outcome of this feedback is mentoring.

People who resist change are the one’s who require mentoring. The coach has to make this happen without rubbing the egos of individual who require mentoring. He/she will need to identify areas that need mentoring, and must schedule one-to-one mentoring sessions in improving those outcomes.

The other aspect of coaching is training Scrum Master or Agile Project Manager to transition into the role of Agile Coaches. Here the skills, behavior, problem handling & conflict resolution abilities of the Agile coach is to be observed to improve their own qualities that will make them as Agile coaches in future. So, as a coach you are being modeled.

Other expectations include teaching the teams in applying specific agile software engineering practices such as Test Driven Development (TDD), Refactoring, Pair Programming, etc., These practices help the teams be more productive over a period of time.

All said and done, if the teams have not shown measurable improvements in the course of your coaching journey, you may need to ask the question, “Where did I go wrong”.

I found this resource useful. Visit AgileCoachNet

You may also take a look at my website vasanthanphilipdotcom

Will keep you posted…


Food for thought…my imagination running wide

If CxO’s today, do not change how they think, plan, strategize or execute, they would be in for a surprise. What is thought in Management schools and at Executive Education Program may not be relevant 5 years down the line. We talk about Web 1.0 and today about Web 2.0, and tomorrow it could be Web 3.0, but have we thought if Web would be web tomorrow.  Like the 2000 bubble burst, there could be a Web burst soon. GenX would pave the way for the Baby boomers. Think about it. Are you game?

Organizations have to re-structure to new set of roles and responsibilities, The CEO roles would be transitioned to Exceptional Executive Officer(EEO), or a CFO would be called Exceptional Finance Officer (EFO), and so on, purely based on their ability to think differently, according to the changing dynamics of the economic environment. Regulatory compliance would be challenged through Mandatory compliance, with different levels of compliance, starting with a baseline requirement. If the baseline is not met, you would not get funding, cannot put resources, or even come up with a business plan. For this purpose you would not have auditor as in today, but Conformity Offices or CO’s who will need to give a “GO” before anyone can start operations. There would be a new set of officers called Acceding Office (AO) under whom the CO’s would operate with.  The roles of Managers would transition to that of Mentor(s). For example, a Project Manager (PM), would henceforth be called a Project Mentor (PM), or a Quality Manager might be called a Quality Mentor (QM), and so on. I would even go further to say that Human Resources Management (HRM) may transition to something like Exceptional Talent Management (ETM) and the Sales and Marketing (S & M) would transition to something like Profiting and Gaining (P & G).

Taking stock of these changes, one would agree than the required skills  for these positions will not be the same. For example, the new EFO would not require the skill of a strategist, but more of a manipulator. He would come with not plans but with blueprints to manipulate the diversity of challenges faced in order to compete. So the challenge is how could someone acquire these new skills that are not thought in business schools. I would create a role called “Futurist” who keeps looking at the rapid pace of change and would suggest the type of skills and competencies required to survive and to move into the future. There should be schools who teach people on how to acquire these new skills and competencies and would even go to the extent of certifying candidates who enrol in such schools as “Emirates” (1 to 5), with 5 qualifying for a ExO positions.

Ultimately it all boils down to execution, so that blueprints are translated into Profits. And profit may not be the ratio of total cost to the sales achieved but would rather be something like Risk Mitigated to that of the Total Spent.

Hope you enjoyed the post.


Vasanth (The Futurist)

Why should you go for Agile.

April 20, 2012 1 comment

Whether you are CMMI/ITIL compliant or ISO certified, there is always scope for improving your s/w development efficiency and programmer productivity. It is sad many companies today see that the only measurement for production of good software is “Defects”. If there are less on no post production defects, they assume all is fine. Also, customers are not so demanding these days.Maybe the perils of the economy and global recession has made them complaisant.

So let’s come to the point of why Agile makes a HUGE difference in giving more for less. First of all, it all starts with business agility. If you are Agile, your business would respond appropriately to rapid changes in the business environment. To adapt to these rapid changes businesses should keep changing their strategies or adapt new strategies. But if your business is highly regulated you need to get control of your business processes and be aware and aligned to your compliance requirements. Therefore the control and management of enterprise-wide business rules becomes paramount for enabling good decision making. So start with the TOP. Check your level of agility and make those necessary changes to the layers of management and come up with a new governance structure that will be an enabler for Agile adoption. The second most important thing is taking stock of your current IT infrastructure and applications including software tools that are used. Usually there is no enterprise-wide consistency in the usage of such software and tools. There might also be expired or un-renewed licenses and unused tools. Thirdly, look at the way you have been managing your risks. Agile helps you to manage risks in a much better way than in the traditional waterfall approach. Since in agile, big projects are divided into smaller project that are build on each other, it enables people to employ shorter feedback loops, to learn quickly and change plans as new information emerges.

But, the BIG Leap is Agile Project Management. It creates an environment of agility. It re-defines the role of the project manager, where he/she becomes a visionary leader. It promotes collaboration among stakeholders. It empowers project teams which become to make informed decisions. It encourages creativity and innovation, and it help manage risks proactively. But more importantly the upper management trust the team to deliver on commitments.

Finally, with respect to applying better engineering practices, Agile encourages practices such as Continuous Integration, Continuous delivery, requirement prioritization, emergent design, pair programming, collective code ownership, automated builds and acceptance testing.

 Should you think more to adopt Agile?

 Have a great day.



Coaches Corner – Part 1 – Managing Conflicts

February 23, 2012 Leave a comment

Speed Leas author of many books on conflicts, offers us a framework for managing conflicts. The model goes through 5 Levels of Conflicts. They are:

Level 1 : Problems to solve
Level 2: Disagreement
Level 3: Contest
Level 4: Crusade
Level 5: World War

He say’s that the key is to know at which stage the current conflict is layered at, by noticing the strength of the conversations among the team members and applying a appropriate successful response action. He goes on to say that at level one the key is to collaborate and seeking consensus, at Level 2 it is, providing support and safety, at Level 3 it is accommodating (yielding to other’s views), Negotiating and being factual, at Level 4 it is establishing safe structures using “shuttle” diplomacy and at Level 5 it is Doing whatever is necessary to prevent people from hurting one another. The team has to constantly be asking if they are balanced between “Continuous attention to details enhances Agility” versus “Simplicity – The art of maximizing the work Not Done is essential”.

Have a great day….

~ Vasanth

Categories: Process Transformation Tags:

Agile Knowledge Areas

February 23, 2012 Leave a comment

The other day I was reading a blog that caught my attention. As Agile professionals what skills or in what areas do be need to posses knowledge and skills that enables us to be experts. This one by Mike Cottmeyer was interesting.

  1. Rational Unified Process
  2. Lean
  3. Theory of Constraints
  4. Traditional Project Management
  5. Capability Maturity Models
  6. Systems Thinking
  7. Learning Organizations
  8. Conversation Theory
  9. Change Management
  10. Covey’s 7 Habits
  11. System of Profound Knowledge

Knowledge in the above areas help us be better professionals.

Have a great day.