An introduction to Smaller, faster, better way to build software. Well then, it's time to skip all the unnecessary stuff and focus on build the real thing. Some of it I have listed here which you can stop doing and build the real thing.
***Then how to build the real thing!
Do you remember Agile Manifesto(s) ? Read more
- Individuals and interactions over
processes and tools
- Working software over
comprehensive documentation
- Customer Collaboration over
contract negotiation
- Responding to change over
following a plan
Interestingly if you follow what I have listed above and get rid of the ones I mentioned, you will see how quickly you be adapting to these new changes and start building the real thing early before your competitor builds it :-) Sounds easy ! Well then it's time to Be Agile and follow Scrum !
With the advent of Object Oriented Software development methods it became easy to break large software projects into very small components and therefore able to take advantage of the building incrementally during Sprint, build the MOST important feature first. Since each sprint outcome is working element of the product this ensures rapid feedback and adjustment to the changing needs to the marketplaces.
Let me provide you an quick introduction to Scrum Vocabulary (Note: this is probably the smallest introduction I have ever written :-) So feel free to read other relevant ones you will find in my blog)
What is it ?
Scrum provides a language for this common sense way of organizing, performing, and managing work.
Product Backlog:
All work to be performed in the foreseeable future, both well-defined and requiring further definition.
Sprint:
A period of 30 days or less where a set of work will be performed to create a deliverable.
Sprint Backlog:
That work that is well enough defined that it can be worked on with relatively little change over a period of 30 days or less and will result in a tangible, incremental deliverable.
Scrum:
A daily meeting at which progress and impediments to progress is reviewed.
Do you agree with me with the benefits of Getting Real ?
Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.
Getting Real foregoes functional specs and other transitory documentation in favor of building real screens. A functional spec is make-believe, an illusion of agreement, while an actual web page is reality. That’s what your customers (whether internal or external) are going to see and use. That’s what matters. Getting Real gets you there faster. That means you’re making software decisions based on the real thing instead of abstract notions.
Finally, Getting Real is an approach ideally suited to web or mobile-based software. The old school model of shipping software in a box and then waiting a year or two to deliver an update is fading away. Unlike installed software, web apps can constantly evolve on a day-to-day basis. So far it I have taken advantage of this approach of Getting Real. Are you thinking ? I think it's worth a try!
