Posts Tagged ‘Agile’

I have worked in many big companies as a freelancer and as a Scrum Master and one take-away from me has been how often there is mistrust between “the business side” and the “development team”. As a Scrum Master it has been my job to bring the sides together and remind them that we are nothing without each other and hopefully also bring a bit of understanding of all aspects of developing software and doing business with it to all involved.

As a Scrum Master, I have coached or taught many Product Owners and the main lessons have been; Trust the team. Tell them (somewhat clearly) what you need and why and then work with them to get to a good solution. Listen to their concerns – it will help you long term.

I have also had to work with many teams to (re)build trust in the Product Owner – to help them communicate their concerns clearly and help them understand the role and understand why we are not always aligned in our wishes for the product. And hopefully highlight, when the Product Owner listens to the team and help show why the Product Owner makes those product decisions.

What has been true for all the journeys my teams have been through, is that the work has flowed much better with trust and understanding between the people involved.

A trick I use often, is to nudge on the language used. Nudge the Product Owner to always say “we” and the team to include the Product Owner into the “we” that they already have in their head. It is a dirty trick, because it seems like such a small thing, but it has a big effect on the teams self image. Seen over a long period of time, you can really appreciate the difference. No more “us and them”-language. “We” are taking on responsibility for mistakes made and “we” are the actors in the successes achieved.

Talking to all team members, about how we can play different roles with different viewpoints and that these viewpoints needs to be balanced and respected, is key. Maybe a few team members are especially good at remembering the architecture view, the security view, the code quality view, the business view or the user feedback view and all these are important. Probably not equally important, but weighed in a certain way, that is dependent on our situation and that can change over time. We can disagree on the trade-offs we make, but we have to respect that there are trade-offs that have to be made and trust that when we make those decisions, we do it with good intentions and to the best of our knowledge at the time.

There is an excellent way of expressing this trust; The prime directive:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

–Norm Kerth, Project Retrospectives: A Handbook for Team Review

The prime directive is usually mentioned in the context of the retrospective, but they are really words to live by. I say: Hang a poster with it in your workspace and remind everyone about it often. To build software well as a team, we need trust.

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.

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).

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:

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.

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:

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.

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?