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.
To show you a bit about our processes, we have been recording our daily scrum stand-ups and now compiled it all to a single time-lapsed video.
As you can see in the video, in start of each sprint we have our stories, represented as white A5s and tasks as Post-its on the left side of the whiteboard. Stories are prioritized from top to down, top being the most important.
When a task—for example, “make a time-lapse video”—is put on the board, it’s moved from left to right according to the approximate amount of work done, measured in Zörgöns™. On the most right is the “done” column, where tasks regarded as complete are moved.
Video holds about 4,5 sprints (10 weeks) of daily Scrums in 30 seconds. Check it out below.
Here is some proof to back up our overly lengthy tagline, Rails-doc is the first Rails documentation app that wasn’t developed by one guy in his underpants. Rails-doc.org has an actual team behind it – a team that employs an agile development process.
There’s hardly a better visualization of Scrum than a timelapse video! It shows the progress of our second sprint.
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.
