About

Nodeta is a software development company that focuses on web software. We employ a highly agile and effective process. We have worked both on light independent projects and in the environment of large global enterprises.

Our Products

Flowdock

Streamline your team's tasks, feeds and communication. Organize with tags. Sign up for beta!


APIdock

APIdock provides a rich and usable interface for searching, perusing and improving the documentation of projects that are included in the app.

Categories
Archives
-->

Coping with the law

Mikael Roos June 5th, 2008

I think everyone who participates in Scrum ought to know the essential laws that Scrum was created to deal with. But much more important, I think that the client must acknowledge them, since I do not believe it is possible to be successful at buying software without being fully aware of these fundamental laws, coping with which is of utmost importance when it comes to developing software. It never hurts to remind oneself of the laws, that Scrum was created to deal with:

Specifications and requirements will never be fully understood (Ziv’s law)

Where your mind sees a square, the next guy’s sees a circle. Specifications should be documented but the maker of the specifications has to be fully available for the development team to ask questions and to communicate eye-to-eye. The maker of the specifications, who should be or at least strive to be the best expert of the actual requirements, absolutely cannot be a stranger to the development team.

The users will never know what they want until the system is in production and maybe not even then (Humphrey’s law)

The users may also believe they need something they in actuality have no use for. Users customarily claim they need a feature for a business requirement that can often be covered much better by a very different feature. Users cannot make specifications. Users’ feature requests obviously still need to be heard so the developers can come up with the right feature to cover the business requirement and empower the user to reach his goal. Users’ goals and the software’s business requirements should be crystal clear to the developers and the developers need to show interest towards them.

An interactive system can never be fully specified nor can it ever be fully tested (Wegner’s lemma)

Important to acknowledge, and just as important it is to understand that regardless of the impossibility, full test coverage, automated and manual, should be attempted to achieve. The specification of a software is always a work-in-progress, even after the software itself is ‘completed’. This needs to be accepted and specification documents need to be constantly edited during the process of developing the software.

Leave a Reply