User Driven Development is the Agile Development practices revised to incorporate these best Lean Startups principles, like the Build-Measure-Learn loop and the concept of Minimum Viable Product.
Agile software development is a software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.
Even in strictly Agile projects, the end user is not very well considered. In fact, the Agile practices don't mention explicitly interaction with end users.
As soon as the application is defined and a team is assigned the User Driven Development can start. Users can participate in the development process since primitive states. Follow what is being developed creates confidence and straights the collaborative relationship. More the users feel their inputs are being considered, more likely they are to continue providing it.
BY ALLINE WATKINS
User language inside the source code
"Programmers should speak the language of domain experts to avoid miscommunication, delays, and errors. To avoid mental translation between domain language and code, design your software to use the language of the domain. Reflect in code how users of the softwarethink and speak about their work. One powerful approach is to create a domain model.
End Users are Ubiquitous
Not every software project has a dedicated business analyst or a domain expert. But every software must have users. Also, every software should be written for the users.
The reason why many users are not using all the resources that are being developed, usually is not because they are bad, usually it is because they are excessive. Users simply don't need so many functions.
LiveSource - The eXtreme Lean Toolkit
LiveSource is a web toolkit created to help the Lean development process. LiveSource guides the team inputing the end user language inside the source code and also generates the usage metrics for your software.
Plan for the current iteration
Product Backlog, No More
Agile Development is undoubtedly a major step forward for humanity. But even with the Agile methodologies and tools, there is still too much waste in software development.
The Agile Development process starts building the Product Backlog for the application. It is not rare projects achieving hundreds of items in their backlogs. Even these items being just a brief description for the features (not a whole requirement analysis like the waterfall method), it is still considered Upfront Planning and upfront planning doesn't give much room for user inputs. If it does, a lot of replanning effort is required.
Minimum Viable Product for Enterprises
In a software, there are always several solutions that can be offered to the users. It is common that the development team, the business analyst or the product owners, just assume wich one is the best solution and wich one the end users are most interested in. But, in fact, 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.
In product development, the Minimum Viable Product or MVP is a strategy used for fast and quantitative market testing of a product or product feature, popularized by Eric Ries for web applications. (From Wikipedia)
The Lean Enterprise
If you have small development teams inside your enterprise and if you combine them straight with the end users practicing the User Driven Development techniques, you can call it a Lean Startup inside your enterprise company.
The developers will have to have the authority to build what they think is the best fit for the software, with no defined hierarchy inside the team, they will need to be as close as possible to the production environment, users will have to like and use the software while is being produced and the product owner is the one that will keep the vision and make sure the team is on track.
Small Improvements Meeting
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.
"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.