Get Real

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.

Let's get rid of >>>>

Timelines that take months or even years

Pie-in-the-sky functional specs

Scalability debates

Interminable staff meetings

Useless paperwork E.g. charts, graphs, boxes, arrows, schematics etc.

The “need” to hire dozens of employees

Meaningless version numbers

Pristine roadmaps that predict the perfect future

Endless preference options

Outsourced support

Unrealistic user testing

Top-down hierarchy

Let me know if above these helped you anyway ever to 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! 

"Agile"

I know you may have read many articles and probably tried picturing the definition of "Agile". But if you are confused by complicated terms then this post may help you. I have tried to put it in simpler terms.

Let's go over what is Agile ?

Agile is a philosophy that uses organizational models based on people, collaboration and shared values. Agile promotes three core values : trust, transparency and collaboration.

How it works!

Agile uses rolling wave planning; iterative and incremental delivery; rapid and flexible response to change; and open communication between teams, stakeholders and customers. There are many agile methodologies that adhere to these tenets, such as Scrum, XP, Lean and Test-driven Development (TDD), etc.

How it helps!

Agile principles and practices are topics of growing importance in project management and used by most successful companies. Project management practitioners, software development teams can use agile principles and practices to successfully manage change,improve communication, reduce cost, increase efficiency and demonstrate value to customers and stakeholders.

Let's go over few core agile principles and practices (tried putting together in simpler terms)

• Early, measurable return on investment through defined, iterative delivery of product increments.
• High visibility of project progress allows early identification and resolution or monitoring of problems.
• Continuous involvement of the customer throughout the product development cycle.
• Empowerment of the business owner to make decisions needed to meet goals.
• Adaptation to changing business needs, giving more influence over requirement changes.
• Reduce product and process waste.

Hopefully this helps you understanding the principles and practices agile proposes. I will post about Agile Manifesto on my next post.

How to write User Story ?

Over the years I have worked with quite a few Product Owners and also I have played that role myself but often I have seen people having very minimal knowledge about writing good user story and that does impact development. So this post is all about it how to write good user story!

Before I get into it I prefer to put an example of how an user story should be written:

If you notice this example meets the following high level definition of what a Product Owner should write:

• Provides a simple medium for
• Gathering basic information about stories
• Recording high-level requirements
• Developing work estimates
• Defining acceptance tests [Normally been written in the back of 4"X6" card, however if you are using any online tool most of them provide acceptance criteria block.

• Acts as agreements between customers and team members to discuss detail requirements during an iteration

However, here I have put together the detail definition we should capture in user story and here the participants are Team and Product Owner who needs to write this together:

• Story identifier and name
• Story description: A sentence or two that describes the feature in customer terms
• Story type (C = customer domain, T = technology domain) [E.g. customer domain would be something which comes from customer thus this is nothing but features whereas something would be called as technology domain which comes from the team say refactor certain area of the code or support they need to get something done etc.]
• Estimated work effort: The estimated work effort needed to deliver the story, including time for requirements gathering, design, coding, testing and documentation.
• Estimated Value Points
• Requirements uncertainty (erratic, fluctuating, routine, stable): An "exploration factor" for a specific story
• Story dependencies: Dependencies that could influence implementation sequencing
• Acceptance tests: Criteria the customer team will use to accept or reject the story.

XP vs Lean vs FDD

Over the years I have noticed people getting confused about XP vs Lean vs FDD so thought to put together this article view

PRINCE2

Wrote about PRINCE2 and it's adoption Slideshare of PRINCE2