Posts Tagged ‘Agile’

14th July
written by Therese

Our industry is plagued by an epidemic of very bad code

– Robert C. Martin (known as Uncle Bob), founder of ObjectMentor and author of several books including Clean Code: A Handbook of Agile Software Craftsmanship.

Of course Uncle Bob would say that because it serves his purpose of selling the Clean Code-book, but I would still agree with him on this one. I often hear a lot of programmers complaining that in a world of perpetual recurring short deadlines there will be a lot of technical debt and code debt in our line of work. Unfortunately.

But what can we do about it? There is never time for a spring cleaning and the business usually can’t see the point of such an activity, but hey, they are not the ones having to live in that messed up codebase.

Sometimes I even hear the technical debt argument as a anti-agile argument – because an organic not-designed-up-front architecture is inevitably going to end up with a lot of technical debt IF NOT REFACTORED on a regular basis. My answer to that, is that refactoring is a part of any agile programmers job – your story is not finished before you have refactored the code and considering architectural refactoring should be part of sprint planning.

A similar point is made by Uncle Bob in this video from the IT-conference JAOO (about 7 minutes in);
When Uncle Bob asks Pete McBreen how a programmer can get the time to write good code and his answer is: “you should cheat the boss – just write good code without permission to use the time”, Uncle Bob comments, that he doesn’t consider that cheating – he considers that professionalism!

I still believe that an organic REFACTORED architecture is better than an up-front-planned architecture, that is outdated and worked around when adding new features.

Is your work also impeded by bad code? Do you consider it professionalism to cheat your way to a liveable codebase?

P.S. Michael Feathers (also in the video) just wrote a blog post about learning from bad code. Please consider helping him with this project.

9th July
written by Therese

I no longer believe in doing Scrum by the book!

This will be considered a provocative statement for some but let me just explain myself: I’m not suggesting that we shouldn’t follow a well-defined, tried and tested process, but I AM suggesting that we adapt the process to our current needs and maybe as far as you couldn’t call it Scrum anymore.

Now some seasoned agile people will say “DUH, of course you have to inspect and adapt. That is what agile is all about”, but I have also heard a lot of people saying, that “of course that project failed – they didn’t do Scrum properly” (whatever that means).

The Organizational Patterns book

In my opinion what matters is that you reflect on you proces and continuously improve (Kaizen) – if you do that you can start out with Scrum and adapt into something that is a better fit for your organization. It is much easier to fit the process to the organization than to fit the organization to the process.

At JAOO last year I attended a tutorial called “Scrum tuning using Organizational Patterns” (by Jim Coplien and Gertrud Bjørnvig) based on the book Organizational Patterns of Agile Software Development by Jim Coplien and Neil Harrison. It transitioned me into what I jokingly call my post-Scrum phase – a phase where I can see agile as a collection of good ideas to choose from; a toolbox. The organizational patterns book adds to that toolbox and provide ways to guide the adapt part of inspect and adapt.

Now I have the feeling that I know more about why Scrum is precisely that collection of good ideas (organizational patterns) and what kind of problems Scrum is aiming to handle and that feeling gives me the confidence to reflect on the Scrum method and adapt to the concrete needs of the projects I’m involved in.

As Jeff Sutherland writes about Jim Coplien and the Organizational Patterns-book:

Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes. It takes over 60 pages of rather dense text to describe these patterns.

The connection between Scrum and Organizational Patterns can be seen in this overview that I stole from the slides by Jim and Gertrud:

Click for larger image

I recently found a link about the Top 10 Organizational patterns – As far as I can tell they are presented as in the book, but the links to other patterns are dead links (and remember; content is more important than form in this case).

Organizational patterns have really helped me move beyond Scrum and to value some of the more social aspects of software development higher. If you are having problems with your process consider looking into this concept. I know that patterns are sooo 90’ties, but they are still a reasonably way to transfer knowledge.

And I should probably revise my first statement – I no longer believe in doing Scrum by the book, but I do believe that a book can inspire me to fine-tune Scrum maybe transforming our process into something completely different – if that is what we need.

16th June
written by Therese

Just as I am a Scrum fan I am also a fan of the Pomodoro technique. The Pomodoro technique is a personal time management method inspired by agile practices such as the backlog, the sprints and making the work priorities visible and explicit. Pomodoro means tomato in Italian and the Pomodoro technique was developed by Francesco Cirillo.

A short explanation of how you use the Pomodoro technique to manage your day:

In the morning you make a backlog, prioritize it and estimate it in number of Pomodoros. A Pomodoro is an uninterrupted time span of 25 minutes.
Then you start work: work for 25 minutes then take break – if you are interrupted handle the interruption in a number of specific ways depending on the type of interruption.
Write down how many pomodoros you use on every task and make notes about interruptions.
At the end of the day take some time to reflect on what you have done, how long it took you to do it and what you could do better, document and put in an archive.

This is a great technique to use if you are coming home from work not sure what you have accomplished and how your time was spent. This way you make sure to document your day, think about your priorities and compare them to your actual work done. The data collection side of this technique can also be used to assess the consequences of a change you have made to your habits or working environment.

You can read more about the Pomodoro technique in this free e-book written by the originator himself. He has also made a cheat sheet useful for talking to colleagues or friends about the technique:

Pomodoro cheat sheet

Click image for PDF version

As this technique is quite popular with software developers there is a lot of software implementations to assist you in using this technique: several iPhone apps and versions of the timer used to measure the 25 minutes.

I have used this technique when I had to write my thesis at the university and it worked well for me. The e-book is easily read and even though the technique is difficult in practice, the learning curve is not steep. The first pomodoro was the hardest one but the technique was easily picked up. Maybe you should just try it – I would love to hear your experiences.

10th June
written by Therese
Scrum Cheat Sheet

Scrum Cheat Sheet - click for larger image

Often tasked with explaining Scrum to people new to it, we have debated thoroughly about the essentials of Scrum. What should you focus on? In a short presentation you do not get the luxury of being exhaustive and tailoring the explanation to the person you talk to is a great strategy but when speaking to a larger audience not always an option.

Well, a quick Internet search answers the question with a Scrum Cheat Sheet. It sums up the key elements in Scrum without getting you bogged down in details. Of course this is not enough to teach someone Scrum but it can serve as a great conversation starter.

There are several of the short points on the cheat sheet that deserves highlighting even to functioning Scrum teams and that is a testimony to the quality of the points.

The two points that are actually highlighted with a different color are some of the vaguer points about Scrum: “DONE” = potentially shippable and Visibility+flexibility = Scrum. Not neccesarily the MOST important points about Scrum but maybe the author of the cheat sheet has some experiences that makes these points especially important to her.

Personal experience makes me focus on the following:

  • the responsibility of the Product Owner,
  • that items on the product backlog can be added by ANYONE,
  • that functionality not done is not shown at the sprint review

I would probably have added to the part about retrospectives that they are not about assigning blame (a simple but in practice difficult rule). The explanation about story points is also a bit off compared to my experience and I would have mentioned planning poker, but I can live with the current form of the cheat sheet and applaud the author for making it. Nicely done!

What would you have highlighted? Does the Scrum cheat sheet match your take on Scrum?