Finding better ways of developing software
Last week I was giving a presentation on Agile in my Alma Mater in Ukraine. That was a very interesting event and I was positively surprised to see many 3rd year students interested much in the ways for effective software development. Here are the presentation slides published via slideshare (I changed two photos just in case they were a bit too sensitive for the corporate security):
Bookmark/Search this post with:
I’ve promised
myself I would actually take some vacation this week, and fortunately
with small children in the house, it’s actually possible to do
so! So, before the kids wake up, a blitz retrospective: High Points,
Low Points and Potential for Improvement in 2009.
Bookmark/Search this post with:
Year 2007 was a year of explosive growth on our site. In 2007 it was a purely private blog, in 2008 the site became a collective work of several highly creative contributors: Jurgen, Przemyslaw, Peter, Mike, Matt, Janusz and yours truly (you can become a contributor too). January to December we rocked from 12000 to well over 70000 pageviews a month.
Top stuff
According to Google Analytics ten most popular writings of the years are:
Bookmark/Search this post with:
In the spirit of the season (Year-End Recap and Top 10 List season I mean), in this episode of My First Agile Project I'll be going over the previous posts in the series and giving some behind-the-scenes comments. If you've read some of the series, keep reading for more you might like. And if you haven't read any of my posts before, I've read some very kind things about the series on readers' blogs so you don't have to take my word for it when I say you will like it. If you don't like it, I'll give you your money back guaranteed.
Bookmark/Search this post with:
Christmas and New Year is coming so it's time for some summary. I've never done this before but this year was quite awesome and I have something to be proud and loud.
Let's start from January when I moved from my hometown to the glamorous French Riviera i.e Cote d'azur (yes, the sea here is pretty much azure).
I accomplished some cool stuff at work and one that I can share with you is the new generation hotel search engine - Wallaby (which is working but still in beta phase).
Bookmark/Search this post with:
Due to its exterior simplicity lately Scrum has become the most popular Agile method. What can be simpler, than few artifacts roles and procedure? The unfortunate consequence of this exterior simplicity is that often people try adopting the method without a deep thought and proper guidance. Some coaches consider it so big problem, that declare the fall of agile (I don’t think so).
One of the particularly interesting aspects that is missing from the simple method description is that Scrum is a powerful experimentation framework. The cadence of short iterations and mandatory reflection moments allows a team to try significant amount of improvements in a rather short period of time. You think making acceptance tests a mandatory part of all the requirements is useful? – Try it for a sprint or two and see if it works for you. Arguments about the effectiveness and social aspects of pair programming and colocation seem to be going forever? – Move the tables together and try pairing for a sprint. Some practices such as Test Driven Development might need some more time for a real try, but even in these cases them it is usually possible to figure out the required experiment length in advance. Scrum applied with a decent amount of rigor forces participants to focus on the goals and evaluation criteria of the potential improvements and arms the team with the regularly applied improvement cycle.
Bookmark/Search this post with:
Last week, I wrote down a new idea about how to determine business value using a variation of planning poker. At the same time, I tried out the method in a real project. How did Business Value Poker survive its first encounter with the real world?
Previously, the two product managers had come up with a list of functions. The dilemma was that Product Manager #1, the manufacturer of the complete system, valued new hardware sales generated by the software. P-M #2, a user of the system, valued operational savings. At the first attempt to prioritize, each manager was given 1000 points to distribute among the functions. The business value was the sum of each party’s vote. This produced a value but no consensus.
Bookmark/Search this post with:
This is my last post on AgileSoftwareDevelopment.com. I let Artem know that I need to concentrate on my own blog for a while. The success of my site is a welcome surprise for me, but it also means that it's demanding all of my attention.
On AgileSoftwareDevelopment.com I published 46 articles this year, including some timeless classics such as 10 Principles of Agile Project Time Management, The 12 Best Questions for Team Members, and Oh My God, They Fixed the Bug!. I also published my share of useless and controversial drivel, such as Professionalism = Knowledge First, Experience Last, and Specialization is Good. But I had fun writing it, and I'm glad that most of the people throwing bricks at me missed me.
Bookmark/Search this post with:
Hamid Shojaee from Axosoft published an excellent and funny video on the basics of Scrum. In under 8 minutes of animation Hamid describes most of the basic concepts. I don’t agree with everything (in particular I I would like to see the release burndown chart described), but you can only explain so much in under 10 minutes and every Scrum installation is different anyway. Have a look and enjoy! High definition version is available here.
Bookmark/Search this post with:
Photo (c) Janusz Gorycki
The Bet
Let's bet: I will buy you one pint of beer for every minute it takes me to find an embarrassing bug in your code.
Admit it, you have no chance of winning this bet. Ever. Finding bugs in somebody else's code is dead easy. Preventing them is next to impossible. Well, on second thought, scratch the "next to" part.
There is this user story acceptance criteria of "No known bugs should exist" - yeah, right. If you are a Project Manager (agile or otherwise) and your developers tell you they produce bug-less code, and that they do enough testing to be sure their code is healthy, they are either delusional, or are liars - I don't know which is worse. If you have a consultant who claims that they have a cure for bugs and will make your projects clean and shapey, do yourself a favor and fire him. Or better yet, do everybody else a favor and shoot him on the spot. The world will be a better place.
The Rant
Which brings me to the subject of this post - bugs. The most fundamental, yet easily forgotten fact of life is that all software sucks. All software has bugs. If yours does not, then it means only one thing - nobody uses it. Some of the best software I have ever seen has so many bugs that they overflow their bug trackers' bug counters. And you know what? It is actually a good thing! The existence of bug reports means somebody is using the software and actually cares to report back to you that he is having a problem with it, instead of just deleting it from their hard disk.
Bookmark/Search this post with: