Lean Startup : Useful Pointers to get started

I started reading the book “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses” about an year back. For sure, it is an impressive thought process. From that time on wards, I have been reading, discussing, practicing ( some form), Selling Lean Start up ideas 🙂

The Lean Startup is a business approach coined by Eric Ries that aims to change the way that companies are built and new products are launched. he Lean Startup relies on validated learning, scientific experimentation, and iterative product releases to shorten product development cycles, measure progress, and gain valuable customer feedback. In this way, companies, especially startups, can design their products or services to meet the demands of their customer base without requiring large amounts of initial funding or expensive product launches.

Via : http://en.wikipedia.org/wiki/Lean_Startup

I found an interesting place where you can test your knowledge on lean start up.
I scored 195 points 🙂

If you are new to the concept of lean start up, here is a list of useful pointers which can help you get started

Lean Startup – Book Summary

Principles of Lean Startups

Lean Startup: How to Learn fast about Customers, their Problems and Solutions

How to Lean Startup? A Flowchart

Using Lean Startup Principles

Lean Startup Cycle

Customer Development Engineering

Combining agile development with customer development

How Development looks different in a lean startup

Lean Startup (PHP World)

Implementing Minimum Viable Changes as Part of a Lean Startup for change approach

Iterative funding of start ups- an entrepreneur’s perspective (Check the Image)

Contrasts between Agile and Lean Startup

Continuous Value Delivery

Happy Learning!!!


The case for Explicit Risk Management in agile projects

Risk is a fuzzy term — it can mean different things to different people.

If you search for “Agile Risk Management” in Google, though you may get lot of links there are very few links which will be helpful for you. I am sure, if you take any of the agile projects that are being executed, you will not see anything related to risk management defined explicitly.

Why is that?
Agile was created keeping a single team in mind. Agile is focused on producing a working software every iteration by automating any repetitive tasks. This leads to frequent customer deliveries. Transparency and Visibility are the core values. Risk Management is implicit in agile teams and happens continuously (or should happen) within duration of the development. That’s why in most of the agile projects you do not get to see any form of explicit risk management.

Is this the case today? If you are from a Services company, i am sure its not the case. Even, if you are from a captive center, its not the case. We do (or say that), we practice agile in distributed environment, where multiple teams are involved. In some places there are even multiple companies involved. In a smaller environment, where there is only one team, Stakeholders are from single company and the project size is small its Okay not to have an explicit risk management. If you have a large team, a project running for more than 3 months, you will be in a much better place by doing explicit risk management.

Wait a second. Isn’t this what we did with traditional software development (waterfall). It was just a list and someone maintained it. I am a Project Manager/Development Manager who is extremely busy. What benefits will i get by doing this?

Well, in one way, its more or less the same thing. You need a list. But earlier, it was created/maintained/managed by the Project Manager. Activities happened mostly during the initial stages of the Project. It was never revisited.

In an agile environment, you revisit this, take necessary actions every iteration. This may improve your success rate.

Apart from that, today the Delivery teams might be from different companies. Though your product owner might be aware of the Risks, but your Product Owner is not the only stakeholder. As a Project Manager, its your responsibility to keep all the stakeholders up to date with the Risks, Owner of the Risk item, the plan to address, steps that been taken to address (Ignore, Accept or Mitigate). In case if your project doesn’t succeed, this may be another document which might help you CYA and CY Team’s A.

In an agile environment, Risk Management as a process – no one person owns the risk management. The whole team is responsible for risk management with a clear owner defined to address each risk item.

Okay, Sounds like a good story. If this is so important, why do we not see this happening?

Most of the Projects will have common risks. The challenge is to identify Risks which are project specific. If you know how to identify risks, i am sure we will find a way to mitigate them. Its a lot of effort and makes you thinking. Probably that’s on of the reason why you don’t see this happening.

I am planning to write couple of more posts in this. Will try to address the following as part of the next posts.

  • Risks Vs Uncertainty, Known Vs Unknown
  • Risk Management Process
  • How to Identify Risks?
  • Risk Response Planning, Tracking (Risk Burn down Chart, Risk Profile)

In the past, whenever i tried writing a series of posts, it never happened. Hope this time i will have some more energy to complete what i started in this post.

Happy Learning!!!!

Experience working with an ‘a’gile xp team

People are more important than any process. Good people with a good process will outperform good people with no process every time. — Grady Booch

Its been more than 7 years since i have worked with a team practicing XP. I recently started consulting with a startup firm where they are practicing xp and its definitely a very different experience. Thought i will summarize some of the very good things i am seeing in the last few weeks.

Hiring: People who have worked with me know the way my teams used to hire. Our interviews used to take 3 to 4 hours at the maximum. Now i am seeing people having interviews for a total duration 7 to 8 hours (Law of attraction!!!!)

Generalists : One of things i have always struggled is to sell the idea of generalists. People always wants to work in specific things which make them specialists. I am seeing for the first time in a services company that some one has even thought of promoting the concept of generalists.

Pair Programming: First time in my career i am seeing people practicing pair programming religiously. Its a very difficult proposition to do it from a small services firm and i guess these guys haven’t compromised on the quality aspect.

TDD, ATDD : Though, i had sold these very agressively, sure its very difficult to implement them. Very happy to see people write tests 🙂

Am forced to refresh my agile knowledge after i started consulting these guys.

Happy to start practicing ‘a’gile again 🙂

Are we there yet?

Are we there?Whenever I take my son and daughter for a long drive, one question they always ask me in between is are we there yet? How much more time it will take?

If you are a business stakeholder sponsoring a project one of the questions you will ask your project or program manager is that are we there yet? When can we go live?

How many projects today we execute are in the state where you can say that it will take approximately this much more time to complete? If the question is simple and all the project/program managers know this answer then every PM should be able to answer this right. Still, why don’t we get an answer?

Let us take our travel scenario. If you are travelling from Place A to Place B, then you would know approximately the distance between these 2 places. and i am sure you will know the speed in which you are driving and how much covered in what time. When someone asks you a question, how much more time it will take you will probably be able to say, we will be there in an hour or hour and a half. This may not be accurate, but atleast you will able to reach there in that time, unless there is a traffic jam or you completely under estimated the distance to cover (which is very unlikely today with google or bing maps).

So, what are all the things that helped us in calculating the time to reach? Distance between 2 places, Average speed in which you are travelling, Distance covered, Time taken to cover the distance, Remaining Distance etc, Expected # of stops in between, Approx. time for a stop …

Definitely not rocket science. huh?

If it is possible in a travel, what is stopping us as project or program managers to do the same with our projects?

Of course, calculating the size is not easy in project management. Infact, there is no way you will be able to get the exact size. But, you can always get the size in some approximate number (Story Points, Use Case Points, Function Points, Gut Feel Number).

If you have a team which delivers, as a Project or Program Manager, one should be able to know how much they are delivering. Over a period one should be able to judge the team’s velocity (Average Speed) and the average time it takes to complete a Story/Feature.

Oh! We dont estimate, We follow Kanban. Great, you can always calculate the cycle time. Over a period, you will know the Cycle Time for different feature categories.

If you know the average velocity/cycle time (Speed), and if you know the features completed (distance covered), you will be able to say what is remaining and how much more time (approximately) you will take to complete the remaining work.

Agile methodologies were created to help the customers and provide business value. It doesnt mean that because we follow agile, we cannot or should not provide the needed information to business. Finally business needs to know where do we stand and how much more time is required to complete any work. One may not be accurate, but atleast should be able to give more or less correct information.

Prakash, you are from services business and it may happen in services business. Not in our environment. Be Honest. I have worked with different kinds of companies across the globe and i am sure we all know the reality.

It is very important to create the project management ecosystem irrespective of whether you follow traditional, iterative, agile or any kind of methodologies. If your project or program manager is not capable or interested in creating/providing the ecosystem, it is time for you to look for a new person. Dont expect the PMO to create a ecosystem for you. You cannot train people to do all these. It is like training a experienced developer how to program. If someone is interested, he would have learnt it by himself, anyways.

Check this article from Johanna Rothman’s blog Are We There Yet?: Creating Project Dashboards to Display Progress

The other argument, i generally hear from people is that this project was estimated by someone else and there is no way in the world this can be executed in that time. Sure, i understand what you are saying. Everyone is human. People make mistakes. But, as soon as a project comes to a Manager it becomes his/her responsibility. You may not be able to deliver something within the time frame what the other person has estimated. But at least you should be in a position to say how much more time it would require to deliver. Is that really that difficult?

If you are a manager and your organization is not supporting you to do all this, then it is time for you to look for a new job. It is upto you whether you want to be a Project/Program Manager or a Post Man/Cowboy.

If you are a developer, you take pride in being a good developer writing high quality code. If you are a Project/Program Manager, you take pride in being a manager doing all what is required.

Happy Learning!!!

We all know about Best Practices in Software Development: Why do we see them only in power point presentations?

Have you ever thought about this? Everyone today in Software Industry knows the best practices in Software Development. Agile is no more a buzz word today. But, why do we see them, hear them only from some consultant’s presentations (either during a start of a project or when a project is in trouble). Don’t take me wrong. I also do consulting quite often and I also prepare presentations 🙂

Why they are never implemented?
I guess there is no single answer for this. I believe there are multiple aspects to this problem.

90+% of the time, a project is sized without proper analysis (from few liners of requirements to a few page requirements to few days analysis). Why does it happen? If you are in a services company and if you don’t do it, one of your competitors will say i do not need this initial exercise and get the project. If you are in a captive firm, always there is this feeling, I know it better.

Even doing the initial analysis has time and money associated with it. Then irrespective of whatever is the proposal, there is always a negotiation and the age old trick of reducing cost is the same. Cut the testing effort. Reduce some %age in development effort and we are good.

Reason, the priorities for different people are different at each stage. Money is the most important thing in the Business. For a services company, getting a business is important. For a sales person bookings are important. For a software company reducing cost is important.

This reducing cost, is it done using some parameters? In a RFP response, even though a company might be well qualified, but if their cost is high, the contract goes to the company which is quoted less. This evaluation, do they always happen analysing multiple parameters. Do we do ROI Calculation to take a decision? Not necessarily.

Agile has given a new way to look at things. The IRON Triangle has been reversed in Agile. True, but what we didn’t understand is that the IRON Triangle didn’t disappear. It will not till the time we this business. Scope, Time and Cost are proportional to each other. If there is a change in the scope then Time and Cost increases proportionally. Because the Triangle has been reversed, we are not completely out of it.
Agile - Inverted Triangle
Let me explain with some examples:
If we do not have time to write requirements (In some form of Minimum Marketable Feature, User Story, Use Case or XYZ…), When will we move to capturing acceptance cases per requirement? If it is all about time, then this may require an additional person which in turn translates to Money. If we do not even capture requirements, capture acceptance cases, how can we think about doing Accpetance Test Driven Development or Specification By Example?

If you need to write Unit Tests, whether you want to agree or not, you are going to spend some additional time (Pure agilists may say its not going to increase time. But, in reality it takes some additonal time). Time translates to money. If we are still following the age of trick of cutting testing efforts, how do you expect this to be followed? If we do not have an understanding of the scope completely, given an estimate, in my opinion there is no way in the world you will do all this.

Take the example of Continuous Integration , You need to have build integration, maintain your builds and integrate your tests and run it everyday. Building, Maintaining have some effort involved which again translates to time and money.

If we are not in a position to do Continuous Integration, how will we do Continuous Delivery? We are talking about an utility which will take the build, automatically deploy it in an environment and run the test cases and say your code is working?

The point which I am trying to make here is any effort has time & cost attached to it. You cannot do 101 things with whatever limited budget and resources you have. Implementing these best practices has some work involved and it has to be considered within your scope.

There is no Free Lunch.
Agile - Schedule, Cost and Scope
To start a project, it takes years. But the moment we are in, the schedule pressure kicks in. Scope Creeps, Team changes, additional integration happens. We continue to add Technical debts. Because of the schedule pressure, we continue to ignore them. Our product owners do not understand the meaning of technical debts, design debts etc. etc.  We become either ignorant of all the issues knowingly or unknowingly. Teams becomes frustrated to fix, add features but continue to work on the same code base.
Because of all these, we are promoting a community who knows what it means, but don’t want to implement them.

Have you not seen these implemented in some place?
Yes, I have seen this implemented in some of the projects in my own experience. Companies like Thought works are doing it. I have seen this implemented in some small companies. I have seen an implementation of a Continuous Integration Server written by set of people 10 years back and they are still working on FoxPro. But, the point is they have spent considerable amount of effort in that, which in turns translates to money.

Secondly, it is about making it as an organization culture. If you look at how Thought works, Google and other companies have done it, they all have brought it inside their DNA.

What is this culture all about?
When you are habituated to a set of things, doing things in certain way, it becomes a culture. Again, I am not talking about 1 or 2 teams implementing in a 100,000 member company. I am talking about doing it as a whole.

Why is it important to do it as a whole? So that everyone in your company is in the same page. Your sales guy will not give gyan to reduce the testing effort. You do not have to argue on why it takes a longer time to hire a talented resource (I am sure you understand what I am saying here).

So, what are your suggestions to implement all these?

  1. Communicate the effort and cost involved in bringing all these practices. All these in Writing. Get an Approval or Disagreement in Email, before initiating the new project.
  2. Get the right level of leadership at all level (Program/Project Manager, Product Owner, Architect etc…). Understand that it’s not easy to get the right level of leadership. You cannot add people whoever is available. It requires a much more level of filtering.
  3. Start any project with a decent set of requirements. Track the requirements and document changes (I am not talking about bring our old Change Control Board here). Whatever we do, at the end of day we should know how much have we spent for any particular work and to track that you need to know what you have done in the project.
  4. Start the project with couple of resources who can implement all these practices (may be couple of sprints). Slowly add new members to the teams who can fit with your culture. When they come in, make sure they understand the culture and adapt to it. It becomes a habit. If someone is not culturally fit, do not hesitate to move them out.
  5. Slowly introduce additional practices.
  6. Track Technical, Design Debts. Prioritize them. If you don’t pay your debts today, you will end up paying them after sometime with interest.
  7. Review the 7 Software “-ilities on a regular basis. Not just at the time when the project is in trouble. Invest in tools which can help you get better statistics.
  8. Make sure you review with your stakeholders about the practices and efficiency of these practices throughout the project.
  9. Make changes as needed.

The whole exercise requires one thing. You need commitment from all your stakeholders on what you are doing and the willingness to spend.

Can these be done in Fixed Cost Projects? Agile Gurus (Ken Schwaber and others) have mentioned that fixed bid projects are always the way to get to lose-lose situation. If reducing cost is the only thing you are looking for, all these will definitely not work.

Finally, we are not in the business of making popcorns. How to make the best popcorn could be done in 7 steps, but not software development. In this whole business, every project is complex in its own nature. There can be no bullet points.

Doing all these, can they guarantee success? May be, but at least you will be in a better position with your code base. May be decision of getting to a “Look-a-Like” Migrations can be delayed for another 5 years.

Till all that happens, the best practices are always going to be only in presentations (at the start or end of the project).

Happy Learning!!!

Do you have the right product owner with you?

Most of the product companies have a role called Product Manager (or Vice President, Product Development) who is responsible for the Product Management Functionality.

Typically a Product Manager in a Software Product Company is responsible for
1. Defining the product strategy and Road map. Typically Product Manager’s Conduct Surveys, analyze the current trends of the industry/competitors and decide the road map for the Product.
2. Visualize the Product, Delivering Requirements in Some Format (PRD/MRD/Use Cases/User Stories), Prioritize the Features, Release Planning, Write the Acceptance Criteria.
3. Working with external third parties to assess potential partnerships and licensing opportunities etc…
4. Taking care of the Pre-sales Demonstrations, Meet Potential Customers, Run beta and pilot programs with early-stage products and samples.

When a new software development initiative is made, the Product Manager typically will be made as the Product Owner for the New Product Development (Could be a rewrite of the old product or a new Product).

Even though the Product Manager is responsible for Defining and developing the requirements, most of the times it takes the last priority. Meeting Potential Customers, helping sales team (apart from the strategic planning) becomes more priority than writing requirements. Product Manager’s time is very hard to find and development teams has to wait for his availability. Its justified by the business that we need to have more business so that we can accommodate all these development etc…

After working with product development companies for all these years, this question has come to my mind some time back.

Who is the right person for the Product owner role? Can a Product Manager be the Product Owner? Is it possible for the Product Manager to play both the roles and add value?

In my opinion, a Product Manager cannot be a Product Owner. If you have a Product Manager as the Product Owner, you will definitely understand what i am talking about. I am sure, you are working on one-liners as requirements.

In my opinion the Product Owner is Responsible for the following.
Product Owner is a person who owns the development of the Product. He / She own the Iterations or cycle period, available for the team when required. Primary responsibility is to write stories or requirement in some format and work with the developers and testers to define the acceptance criteria for the stories. He / She should understand technology a bit, so that he will be in a position to understand the technological constraints. Once a feature is complete, the product owner should spend time in verifying the feature and provide his acceptance.

If the Product Owner you have is not doing all the above, its time to look for a new profile. Finally, your whole development team is dependent on this person and his time is more important for the development teams.

Some useful Pointers
Agile Product Owner Vs Enterprise Product Manager
The Product Manager – Role and Responsibilities
How to be THE ULTIMATE Agile Product Team / Agile Product Managers and Agile Product Owners Living Together in Harmony

Happy Reading!!!

Agile Software Development, Status Reports, Review Meetings: What to expect?

If you would have ever written a work order, you would have seen that there is a section for Project Governance and Communication. Every Template will have this in some form or other and its mandatory to fill this section. Typically what happens in a services company is that, someone writes a work order and someone else executes a project.

If the person who is going to execute the project doesn’t contribute to writing work order, then whatever is written in that document becomes meaningless to him/her (unless someone else has set is as a culture in the team and a new person takes over).

In most of the companies, there is some process group which will mandate the Project Managers to fill in the Status Report Templates and you know what happens.

No one reads the documents. Why? I can tell you from my experience that if you send a word document as an attachment no one will open it. Ok, people have seen this problem enough. So, there is this concept of on-line dashboards etc… and i am sure we all know how many people really look into it on a regular basis.

Why is this problem? When we all know the importance of reports (in atleast an offshore/onsite environment), why does it happen in this way?
a. It becomes as a ceremony.
b. Status reports contains too many Micro Details than what needs to be given.
c. My Product Owner/Contact Point knows exactly what we are doing. We interact daily.
After couple of weeks, people decide its ok to skip this. When a Project Manager doesn’t get any response/question for any of the status reports he/she has sent, the motivation factor goes down. Over the period, either the PM sends it as a formality or starts ignoring this.

How do we address this?
1. When you start a project agree upon the
a. Review period and who will be the members for the Review Period.
b. Expectations on the Status Reports (Cycle and Contents)
2. Typically the contents for the Status Report should be
a. Base Schedule, Cost, Scope
b. Where do we stand in terms of the above
c. What changes has been introduced (in terms of scope) since the last review.
d. Work Accomplished since last review (Talk about the features not tasks here).
e. Impact of the Changes in terms of Schedule, Cost and Scope.
f. Updated delivery date and cost
g. If you have defined Critical Success Factors of the Project, have an overview of how we are doing against each success factors.
h. Velocity Chart (Refer this article Are we there yet? from Johanna Rothman
3. Send the Status Report to all the stakeholders before the Review Meeting.
4. Do the Review Meeting only with this.
5. Make sure all your stakeholders are attending this meeting.. In typical engagements the senior management from both sides get involved for first few times and after that they will slowly move out. If you do not see the senior Management (from both sides) joining the call, please send a RED FLAG to everyone. Finally, someone is spending money for doing something and if they do not have time to see what has come out, it means that the Project is Not Important for them. Its better to stop it there than taking it forward and getting into a messy state.

In my opinion, plan this meeting once in 2 or 3 weeks. It will help you to show some progress from the last time and it will be easy for everyone to judge where we stand and whether there are any progress.

In offshore development, providing visibility is very important and provide the visibility to all the stakeholders as many ways as possible.

We are talking about Status Reporting. Why the title has Agile Software development?

Now you may say that, Boss we have moved to Agile Software Development long back. This is a very old story. You don’t seem to understand Agile. Why do we need all this in Agile?
True, I am not saying No. But what you have to understand is only your execution environment has changed to Agile (You, Your team and may be your Product Owner and Architect on the other side). The remaining people has not even understood what agile means. For them, all that matters is Money. The Rest goes in the backseat. Business is not done with TRUST/HEART. Its done with Brain and Money becomes the most important thing.

Other thing i keep hearing is boss, we do not know what we want. Thats why we do agile development. We may not be able to define the base scope, schedule and cost If you are into such thing, for god’s sake please stop the work immediately there.

In an offshore setup, you will never know when a project becomes into RED. Its not always the delivery which causes a project to goto RED. There could be n number of reasons. But, believe me. Irrespective of all, the default thing to be blamed is delivery.

Apart from helping the customer to get business value, its the responsibility of the Project Manager to protect his team, himself, his company and his contact person (product owner or Vice President or Architect… whoever it is) on the other side.

Learn this lesson and you will have better life as a Manager.

As a manager, one of the most important goal one should have is to reach a smooth end to every project.

Happy Learning !!!