A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Screwing Up Software Development – a sarcastic look at how projects fail

We all complain about potholes on the city roads, but when it comes to software development, the process sometimes becomes so monotonous that you long to have potholes and speed breakers in the process. So, what do you do when you want a bumpy ride? You introduce the bumps yourself! So if you mangers are reading it and you find out that one of the developers is introducing potholes go easy on him, he is just making is work challenging. Statutory warning for developers using Scrum: Implementing the below mentioned techniques might lead to you being sacked from your job, but for the carefree go on and implement it.
Starting off with the ScrumMaster who is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influencing. What is to be kept in mind is that he is neither a tech guru nor does he know Scrum. He has no contact with the customer and lacks test environment so he won’t present too many hurdles in your way. Starting off with your mission, don’t have a default Definition of Done (DOD) and even if you have one don’t bother to obey it. Start to assume that if the code is acceptance tested, has release notes written and there is no increased technical debt then you haven’t messed up with the code base. Don’t have Sprint Retrospective, even if you have one don’t list improvements, even if the improvements are listed don’t execute them and even if the improvements are executed don’t follow them up. Have unwanted people at the meeting. Don’t have a set pace of work keep changing your pace from time to time.
Another aspect of the team which can be attacked is team commitment. Put pressure on the team. Don’t track and learn, try over committing or under committing every time. Let the technical debt pile up and continue ignoring it. Stick to your own role and don’t help others in the team. Take care of only your personal backlogs and implement all stories in parallel. Another critical feature of Scrum is Product backlog. It is a high level document for the entire project and contains backlog items such as: broad description of all the features required, wish-list items, etc. prioritized by business value. It is open and editable by anyone and contains rough estimates of both business value and development effort.
It is owned by the product owner. For defeating its purpose fill the product backlog with never ending stories. Product owner can help by not prioritizing and not maintaining it properly. Shy away from merging, seldom integrate and try to evade responsibility. Finally make Sprint backlog too complicated. It is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks with the level of detail that the whole team understands what to do. For our mission don’t use it during daily Scrum, don’t update it regularly and last but not the least don’t prepare a burndown. Hope the above techniques add some spice to your work life. All the best!

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>