Customer Development

Unfortunately, when I started developing LiveSource, I wasn't aware of the importance of Customer Development. Only some months ago I began studying how to do customer interviews and only a month ago I actually started doing it more seriously.

Normally, as soon as people start doing  Customer Development everything immediately changed. Couldn't be different for LiveSource.

One of the first things that were cleared for me after interviewing few real persons, is that LiveSource is too complex and to be used, it needs to be introduced by something more simple.

So I decided to write another blog to guide people on the process of developing innovative software and consequently a way for softening the introduction to LiveSource.

Here it goes... If you are involved with innovative software, this blog is for you:

eXtreme Lean Business

by Alline Watkins

User Driven Development

When we develop software, how do we know which features users will use and which will not? User Driven Development is a methodology that helps answer this question early on in the development process, so you don't waste time and money on useless work.


User Driven Development is the Agile Development practices revised to incorporate the best Lean Startups principles, like the Build-Measure-Learn loop and the concept of Minimum Viable Product, inside an enterprise.



Check:

http://UserDrivenDev.com
by Alline Watkins

Why Stand-up Meetings are a waste of time

A Stand-up Meeting is a reporting meeting.

Reporting things doesn't actually make you think. And just to hear a report that is not necessarily your business is also quite boring. Even if it is for just 15 minutes. Who has participated regularly in Stand-up Meetings understands this sentiment well: It's Not Just Standing Up: Patterns for Daily Standup Meetings

The three standard questions for a standup meeting ("What did I do yesterday? What will I do today? What are my obstacles?") doesn't oblige us to pro-act. I suggest changing them to just one question:

"What am I going to improve next?"

The idea is that each developer will now have to think about: "What I am going to do to solve the problem I am facing at the moment?". It is much more interesting to listen to (and discuss about) proposals for solutions rather than problem reports.

It is common the development team having a lot of opinions on how to solve the company's day-to-day problems. But, unfortunately, most often what happens is that developers just don't talk about it.
The company's environment needs to be accessible to the solutions proposed by the employees. If the development team is not encouraged to offer solutions and doesn't have the authority to implement them, the interest on keep proposing these solutions is rapidly lost.





Improvement Board    x    Task Board

The concept of improvement here in this context has two aspects:

First, the development team is usually aware of  the best solutions for the software problems, because the developers are the people who have the deeper contact with the source code. So, it is very important for a Lean development environment to promote a proactive mindset in developers, instead of "Here we have the Task Board that the developers are running as if they were robots."

The second aspect is that, on the other hand, besides guaranteeing that solutions proposed by the developers are being heard, in a Lean software development is also very important that the end user is directly involved in these discussions. Because if a task simply does not add any value to the end user, even if it is a great solution, still usually is just a waste of time and money.

Attending meetings lowers IQ:
http://www.telegraph.co.uk/health/healthnews/9108790/Attending-meetings-lowers-IQ-research.html

Method to Develop UNCERTAIN Software

Eric Ries is brilliantly teaching us how to deal with uncertainty in the business world. It is about time to take advantage of these Lean Startups techniques and learn how to apply them to the whole software development process, not only for Startups.

Product Backlog no more!

"You gotta start with the customer experience and works backward to the technology. You can’t start with the technology and try to figure out where you are going to sell it." (Steve Jobs,  WWDC 1997)

The Pareto Principle, unfortunately, has being fully applied to software development. In fact, still today 80% of the developed software is being wasted (CHAOS Report Standish Group 2002). An enourmous amount of money. We should develop software only after making sure that will be used.

It is very common in software projects not to know who the end users are. Is the Product Owner of your team a real user? Or are they only intermediaries? Only the end users can somehow clarify to the development team what they want to use and how they want to use it. Only in a very close relationship with the end users the right features can be revealed.

The "Build-Measure-Learn" cycle, defined for Lean Startups, should also be applied for the software development process since the beginning. In practice this means:

Always having the minimum amount of tasks in the Task Board, just enough to support the next conversation with the end users. (Build) 

Measure closely the production environment results. How the end users are actually using the features that have been developed. (Measure)

Stay completely open to the new directions that the end users will reveal while using the software. Avoid having a Product Backlog already predetermined, preventing the natural flow of the software needs. (Learn)

Figure 1: The Build-Measure-Learn loop from the Lean Startups.

Even for very big and complex applications, it is when is more important to avoid waste. The first thing to be done is divide the big and complex application in a lot of small independent projects, which can be focused and managed in a more accurately and realistic way. After that, clearly define who the end users are and bring them as close as possible to the development team. When the software projects are simple and small, it's much easier for the users to absorb the business concepts, understand the technical needs and provide accurate feedback. As well as much faster and cheaper for the development team to produce the right results. (Further reading: Mini & Lean Applications)

"(...) And some mistakes we made by the way. Some mistakes will be made along the way. That’s good because at least some decisions are being made along the way. And we’ll find the mistakes and we’ll fix them."
 (Steve Jobs, WWDC 1997)  R.I.P.    :_-(   

A Method to Develop Uncertain Software

Figure 2: The Agile Development poster adapted for the Uncertain Software

Agile Development  is undoubtedly a major step forward for humanity. But even with the Agile methodologies and tools, there is still too much waste, too much backlogging, too much repeated documentation and too much planning in software development.

The Agile Development process starts with building the Product Backlog. However, the Uncertain Method starts the development process defining the Minimum Viable Products for the application.

To identify an MVP it is necessary a lot of knowledge about the users (and customers) of the application, otherwise the software will never be viable (Read also: Defining your MVP). It is very common Product Owners having a hard time to minimize and prioritize requirements. They usually want everything to be done, and urgently. Not rarely a Product Backlog has several items with the highest priority. Even if they still think that everything can be done, the development process can be facilitated by identifying which  feature they want to be the first immediately delivered, that means, just put the highest priorities in an order and select only the top one. The goal is to give a starting point to the development team. From there, the next priorities should be defined from the results of the interviews with the end users.

I totally understand that almost every feature has external dependencies. It is difficult to isolate and develop them independently. But if the development team can simulate (mock-up) the external dependencies and focus on each MVP separately, the prospects become much clearer and new possibilities of implementation easily opens up. The advantages are enormous. In fact, what usually happens is that several of this dependencies will not need to be implemented anymore because the plan normally changes when you start to dialogue with the end users.

"It is necessary to deeply understand the essence of a product in order to strip away the non-essential parts." (Jonathan Ive, Apple's chief designer)

Each development team should focus on its own MVP and start working with the first prioritized feature. A Task Board can be used, Stand up meetings, retrospectives, etc, but the most important thing is to deliver something as quickly as possible in the production environment, so the end users can personally manipulate the software and the Build, Measure, Learn loop can run the most efficient possible.

Non-systemic approaches are very helpful, like low fidelity prototypes or any other User eXperience practice. But keep in mind that an end user interview in front of the working software is priceless to a developer. The psychological atmosphere that is formed in a moment like this provides unique insights to the developer with so much valuable information that no documentation and no intermediary can possibly describe it.

Figure 3: The Agile Manifesto revised for the Uncertain Software

Once users are already satisfied with the current MVP, it is time to start the next one. The relationship with the users at this time will probably be much more fluent. It will be easier to identify what they want next. And often they don't care so much if the software is super flexible and adaptive, sometimes even if it has some minor errors. What they normally prefer is a software that has personality, something that makes them say "That's cool!".

No Rights Reserved. Please copy us!

The concept of Mini (& Lean) Apps

After I installed the app from my bank on my phone, I never went back to the website to access my bank account. Even if the computer is in front of me, I still prefer to pick up the phone. The cell phone app from my bank is much more practical, concise and objective.

Why don't we follow the same principles of a mobile app for web sites? This is the idea of ​​Web Apps (see also http://en.wikipedia.org/wiki/Web_app).

My bank's website today is a white elephant. It has a lot of information and functionalities, but it gets all mixed in navigation. I can do almost everything on the website that I could do in the bank agency. In terms of availability, this is a great advantage. But by the side of objectivity, excessive opportunities are harmful.

Note: I'm a client of several different banks and their websites all have these same characteristics.

I'm advocating here the transformation of enterprise applications into several Mini Apps, with very practical goals, performing very specific tasks with simplicity. The users set up and work in their browser or their desktop the most common tasks, when needed, if needed. All set in accordance with their interests, as they do in their smart phones.

Lets see other examples:

How about Microsoft Word as a "marketplace" containing a lot of mini apps, instead of one big and complex desktop application? When you only want to create, open, edit, save or print a text document, you use the main app (simple and practical as a notepad). But if you want to insert Cliparts, Wordarts, Charts, Cross References, Symbols, etc., then these functions would be in a separated mini app, with a more specific and targeted navigation, much easier to use and the most important, visible only in case you need it.

And how about your company's intranet looking like the screen of your cell phone? The HR App separated from the app for corporate events, which are separated from the contact page of the staff's team. Each one with their own navigation, their simplified interfaces and peculiarities. You no longer need to navigate through a bunch of links to view your paycheck.

The idea is that each Mini App is a whole product and a peace of a large application. Independent and autonomous. You type your bank's URL in your browser and see in the home page only the apps you chose to use. If you have a credit card but have no investments with this bank, then you see the app to access your card in a practical and simplified way. The investments links would not be visible at all times, confusing you.


Developing Mini Apps

Developing complex applications as a set of Mini Apps is a great facility for users. But the biggest advantage is the development cost.

With Mini Apps, the development team can focus more precisely on the several Minimum Viable Products that the application has, and if they are developed independently of each other, with plenty of autonomy and following the Lean Code concepts, the cost of maintaining this software may drop considerably.


The LiveSource Mini Apps

When I started developing LiveSource I was often adding new functionalities to the source code without worrying about the amount of classes and source files that were being created. In a matter of few months, the code for LiveSource has become highly complex and very expensive to maintain. Not to mention the user interface, that every new feature makes the navigation more confused and harmed.

That's when the idea to separate LiveSource into several mini apps came. The original big application was divided into several Minimum Viable Products, such as a Product Backlog app (called EasyBacklog), separated from another mini app to generate and display a status task board (called Live Task Board), another to deal with the automatic generation of documentation from the source code, and another one for dealing with software metrics.

Figure1: The LiveSource Mini Apps

Notice in the lower left corner of the picture above, links to access the various mini apps provided by the LiveSource's website. Each one has its own "world", they are different products with independent user interfaces and independent source files.

.  .  .

The independence of the Mini Apps of a big application must be total. The user interface, configuration, source code, all autonomous, separated from one another.

The autonomy of the Mini Apps automatically brings tremendous visibility to the specific characteristics of the final product, characteristics that are often overlooked when the application is only viewed as a whole, as a big soup of features.

The Lean Code

Following the wave of Lean ideas, I would like to create a new one here in this blog:
The Lean Code.

In a nutshell, Lean Code is a software project that is short, independent and extremely organized. The Lean Code can be easily maintained and its intention promptly understood by any participant in the software development process, including non-programmers.

The idea is that even a large and complex application can be composed of several independent, small, organized and easy to maintain software projects. Starting with the SOA concepts, the Lean Code goes much further adding the ability of a viable and an easy-to-read source code and the focus on the end user language inside the source code.

Maintenance is one of the highest costs of software development. Two thirds of the lifetime cost of a software involves maintenance. (See Software maintenance). It is much faster (and cheaper) to identify a problem or a feature that needs to be fixed in a Lean Code, considerably reducing the cost of software maintenance.

How many features is your source code implementing at the moment? The answer to this question is a good indication if your software project is Lean or not.

A Lean Code implements a minimal amount of features at a time. If your source has become a spaghetti, that means, it is too long and so complex that you are not able to identify the features it implements, then the case really needs a Lean refactoring.

It is also important that a Lean Code is viable. A Viable and Lean code is the one that has proven itself that has users and customers satisfied. (See the definition of Product-Market Fit).

Good follow-up to this reading would be: The Clean Code (or Uncle Bob's blog) and The Lean Startup from Eric Ries.


The Lean Code in Practice

"To trim the size of a code base and keep it small, we have to eliminate unnecessary code, employ good coding practices, and justify any new code." (The Art of Lean Software Development) 

After much research on code visibility, I realized that to develop a Lean Code you need the following topics below:

• Ubiquitous Language,
• Isolated Minimum Viable Products (or Mini Apps),
• A tool to visualize the intent of your source code.

The advantages of using the ubiquitous language in the source code are numerous. This topic alone is extremely important, and that is why a whole post was previously written for this subject:

Ubiquitous Language inside the Source Code

This post will describe in detail the important aspects of the Ubiquitous Language when developing a Lean Code.

The next item is about the MVPs. If your application has a countless amount of functionality, simply implement them all in one given mass of source code will not help in understanding and maintaining this code. Therefore the following definition:

A Lean Code should contain only one Minimum Viable Product.

When the requirements of your software begin to multiply, turn yourself to the intent of the application. Focus on your MVP. After interviewing your clients and consulting your market, if new features prove themselves as actually useful to the users (see Defining Your Mininum Viable Product), then split these new features in different MVPs and create independent software projects for them, with isolated source code. If necessary, use APIs and communications interfaces between the MVPs, but not simply develop them into a single mass of the same source code.


LiveSource and The Lean Code

Development tools are very important to assist the process of building a software. No wonder a development team always uses a number of them. However, most current development tools used by programmers, called IDEs (eg Eclipse, VisualStudio, IntelliJ, etc.), unfortunately are very technical and aren't ideal to view the intent of the source code or to be used by the non-programmers who are also part of the development team (such as stakeholders, product owners, business specialists, project managers, testers and even customers and end users).

That is why LiveSource was developed: for the intention of the source code can be filtered, viewed and understood, and so that non-programmers can participate and contribute more actively in the software development process. Learn more about the advantages of LiveSource here.

Live Source is a Web Toolkit that ensures the source code will no longer be hidden behind a complex technological lawyer, but instead, will be online translated and understood by the programmers and non-programmers of your development team. If the intent of the business is not clearly reflected in the source code, that is the way LiveSource will collaborate with the development team: openly exposing the problem.

"I see value in keeping my source code comments a bit more organized and easier to see than browsing through code.", comment from a LiveSource early adopter.

When a person (programmer or not) views the source code through the LiveSource tool, it is easily detectable if the source is sufficiently organized or not. You can see if the documentation of this code, if any, is relevant to the business domain or if it is only adding technical details (often useless) for the programmers by themselves.

Having the intentions of the business domain completely linked to the source code is a key feature of the Lean Code. The name of each file, each directory, each class, each package, each function and each variable must directly reflect the intention of its existence to the business domain. A non-programmer who reads the name of a file or a function for example, should easily understand its meaning. And then, the documentation of this code should add the business information that justifies and explains its need.

I'd like to repeat here the importance of reading the post about Ubiquitous Language inside the Source Code.

When all participants of the development process, including product owners, project managers, customers, users, etc. can actively participate in building the most important artifacts of a software, that is its source code, the dynamism of communication and accuracy of the results directly reflects on the quality of the final product generated and dramatically reduces the cost of its maintenance.

After the Definition of your Minimum Viable Product

After defining your Minimum Viable Product (see the previous post of this blog) the next steps are actually develop and validate it.

What features need to be provided for the Early Adopters start using your product?

As an example, here are the User Stories for LiveSource's Minimum Viable Product:


MVP 1:  LiveSource is a web Toolkit that loads the source code of your software and generates an easy to read version of it, understandable for the whole development team including by non-programmers.


Stories: 

• "As a User, I want to view a list of all my projects."
• "As a User, I want to view a list of all the source code files of each one of my projects."
• "As a User, I want to view an easy-to-read version of each source code file."

LiveSource is a very big and complex project, but as you can see, there is only three User Stories in the first MVP  This is exactly how a Lean development is supposed to be: start small, eliminate waste, deliver fast, etc.

Also with the User Stories list, it is important to have a draft of the user interface. Could be something very simple, in a piece of paper, or a picture of a drawing. We call that a Low Fidelity Prototype.

Figure 1: Low Fidelity Prototype for the LiveSource MVP

At this point, I am already developing using some Agile techniques. We can start planning a Sprint here, defining a Product Backlog, estimating, prioritizing, etc.

To be simple, for the first release of the MVP we don't need a login page and we don't even need a database. We will extract all the file contents from a remote repository, like Git or Subversion for example.

For now, lets include the three stories in a first Sprint and lets describe all the necessary tasks to implement these stories.

User Interface tasks:

• List all the projects available in a web page.
• When the user clicks on a project, the system shows all the files stored in the remote repository for this project.
• When the user clicks on a file, the system shows the easy-to-ready version of the source code of this file.

Server side tasks:

• Connect with the remote file repository of a particular project.
• Load a list of the files available at the remote repository of a particular project.
• Load the source content of a particular file of a particular project in the remote repository.
• Extract from the source code all the code documentation available.

I can add some Spikes to this list, for example a task to study some API's to connect with remote file repositories, or another task to study how to extract documentation from a source code. Any of these tasks could take a lot of work hours. But I will not add them to my task list right now because I already explored all these topics before when I was researching the viability of my project and they are working very well on my prototype already.

Next step is distribute the tasks over your development team. Let the programmers choose what they can implement and when they can commit themselves for a delivery.

While you are implementing your MVP, try to make it as independent as possible. When new features start to come, try to not just add them up to your MVP, instead, try to create a new MVP that are as much  independent as possible from each other.

Also, while implementing your MVP you can keep asking your early adopters for feedback, input some real data and do Usability Tests. As soon you start having feedback as better.

At the end of the implementation, you should have your early adopters already using your MVP or ready to start using it.

The main point of this post is: Don't start a new MVP while your early adopters are not already using the MVP's you have developed. There is a lot to adjust as soon as you start receiving your customers feedback, this adjustments are most of time much more important than new features.

The good time to start developing new features is when you already have 40% of your users saying that they will be "Very Disappointed" if they no longer can use your product. We call that a Product/Market Fit.

If you are not reaching your Product/Market Fit, you should start the whole customer development process again. Go back to the prototype stage and listen more to your early adopters. Find out what are the reasons they have to use or not your product, and adjust your MVP until you get Product/Market Fit.

It is really not easy to get to this point. You need to be very determined and normally takes a lot of iterations to be ready to scale. The path described here is a good starting point for you to succeed.