Tag: agile

Looking for a job!

Hello everyone – it’s finally that time. After finishing my Master’s and a bit of a break I’m finally looking for a job.

For the impatient, my CV/resume: online PDF

Who are you?

I’m Tobi, online I’m better known as PragTob. I’m a Berlin based full-stack engineer (with a bit of a tendency towards the backend) and deeply interested in agile methodologies, web technologies, software craftsmanship and teaching. I contribute to a variety of open source projects (e.g. Shoes, Hackety Hack and after_do), engage in a multitude of community events (e.g. Ruby User Group Berlin), enjoy attending and speaking at conferences.

My favorite programming language at the moment is Ruby and it’s the one I’m most experienced with, along with my favorite implementation JRuby. Naturally I’m also interested in other programming languages, these days mostly Clojure. As for frameworks, I’ve done quite some work with Ruby on Rails, writing applications and teaching it at workshops and courses.

You can check me out more online, including profiles etc., at my website. Of course, looking around this blog can also give you a pretty good idea of what I’m like.

What are you looking for?

A great job of course! Working on interesting problems with nice colleagues in an interesting area, where I can learn new things. I’m mostly interested in web development and related technologies. If the company supports the community and contributes back to open source (or even has an open source product!) – all the better!

I prefer working in an office with my co-workers, working together, pair programming and discussing options in front of the white board. That said, other options are possible. I love open source and am used to distributed working on open source projects, for instance.

At this point in my life I want to refrain from working for advertising companies, banks and the likes. Moreover, I really want to stay in Berlin for now, it’s a great city with many great companies. Something super awesome would have to come up, to make me move. Also, a job where I’m away from Berlin most of the time is probably not ideal for me.

What now?

Well if I sound like someone you want to work with or if you want to figure out if you want to work with me, please go ahead and get in touch 🙂 You can shoot me an email at pragtob@gmail.com

As a reminder, since you made it this far, you can find my CV here

3D Planning Poker

This post introduces a technique, which we have labeled “3D Planning Poker”. It is aimed at helping agile teams with their user story estimations. It was invented by Jannik Streek, who is coauthoring this post together with me. At first we have a look at estimations, mentioning our perceived short comings of Planning Poker and then we introduce our suggested technique.

Estimations and (normal) Planning Poker

Estimation of user stories is an important task when developing software. It is especially well known and practiced in agile software development processes. Teams rely heavily on estimations during their iteration or sprint planning meeting in order to commit to a reasonable amount of work during the next sprint/iteration. Obviously false estimations can be a huge problem. Therefore good estimations are desirable.

Due to this reason a couple of methods were invented, most prominently Planning Poker. Planning Poker provides an easy estimation method which gets everyone involved. Moreover you get the unbiased estimation of every team member since no one knows what the others will estimate when they show their own estimations. However in our minds it suffers from a couple of problems:

  • Quietness: if you have people in your team who are not that extrovert, you will probably have the problem that they will not be that active in your discussions.
  • Late feedback cycles: You will only get adjusted estimations after a re-estimations round which also takes time. Often it would be beneficial to get more direct feedback.
  • Tiredness: Usually estimation is kind of a boring process: Sitting around and estimating can be time-consuming and dull. Thereby tiring the whole team. Moving around the room can be done during breaks, but maybe it would be even better to include that in the estimation process?
  • Slow to get the big picture: At first you have to look at every card of your team members in order to recognize what the team estimated overall. Cards have to be shown around because not everybody can see them (the card of your neighbor is hard to see, for instance). It takes some time before you know what everyone estimated.

Introducing 3D Planning Poker

We want to introduce 3D Planning Poker in order to address these short comings. It’s a technique / process which was actually developed during a course in Software Engineering at the Hasso Plattner Institute. The basic idea is to have an estimation method with “live” feedback and movement to don’t get tired during the estimation. At the same time we experienced that even rather introverted people get more motivated and active.

The technique works like this: In your room you put your usual estimation numbers (for instance: 1, 2, 3, 4, 5) up as big numbers on the walls. Make sure that the numbers are in order. At first a user story is discussed, as usual. But then when you are actually estimating everyone should just move to the number on the wall matching his/her personal estimation. Everyone should move at once so people don’t get biased when they see where everyone else already stands or in which direction co-workers are heading. When everybody arrives at “their” estimation number you can easily see where most people stand and how far apart people stand. That gives you a nice visualization of the estimates and thereby an immediate impression of the current “estimation situation”. The people with the biggest difference in their estimation also have the biggest (room) distance between them. Just like with normal Planning Poker the people with the most diverging estimations should explain to each other why they estimated the way they did.
A really cool thing about this technique is the live feedback. People are allowed to move to new estimation numbers during a discussion, which gives you immediate feedback. Plus: there is no need for a re-estimation as the team estimation changes dynamically. In our meetings it was the norm that during the discussion people got convinced by an argument or simply noticed that they misunderstood the story, so they moved into one direction or the other. Sometimes even one of the people discussing would get totally convinced and moved to the spot of the other disputant.

3D Planning Poker in action
That’s what 3D Planning Poker looks like.

The only concern regarding this method is that people might be influenced by others, because they see them walking to an estimation. So Charlie could always try to follow Steve to his estimation. But this bias is observable, as the team can notice when someone always follows other people or always stands next to specific persons. You lose the total unbiasedness of Planning Poker but you get some more movement, live feedback and possibly more engagement.

In order to achieve the best results you should have a team in which everybody trusts each other and actually has the courage to choose a number by him- or herself. That’s why we believe that this technique might be unsuitable for freshly formed teams. However we encourage you to try it with more mature teams especially if you notice that planning meetings are becoming a “boring routine”, which they should not be.

What do you think about 3D Planning Poker?

We shared this idea with some people at the XP 2012 conference and got very positive feedback, which actually motivated this blog post.
What are you thinking? Please share your opinions, ideas and/or concerns with us! Do you have other kinds of techniques or processes in your team for estimation that you would like to share? Did you try 3D Planning Poker and would like to share your experiences? Please comment!

Cheers,

Jannik & Tobias

Teaching Agile

graduation hat

I’ve been at the XP 2012 conference and I had a great time and a lot of interesting conversations. One topic that particularly intrigued me is how we can teach agile software development at universities. There are, to my knowledge, quite some universities that don’t teach agile software development at all or do it very badly.

I attended a good talk by Mark Lainez. He, and some of his colleagues, use their spare time in order to give presentations and hold workshops about agile at Belgian universities. This is super awesome. They do this because they saw a lack of “Agile” education at universities in Belgium. However this is not only a problem in Belgium. It is much more widespread than that.

This post is mainly aimed at people like Mark and lecturers at universities, who want to introduce “Agile” to universities. I’m lucky to be at a, in my eyes, particularly good university. As I’m a student myself I’d like to share my thoughts on what worked for me, what didn’t work and what might work when learning about agile software development.

Theory is good – but people need practice

Let me tell you something about my studies at the Hasso Plattner Institute: We learn about design patterns in our third bachelor semester! Awesome right? The bad part: Few students care at first. You need a big project in order to understand the benefit of design patterns.

It’s the same thing with teaching agile, people need to work on something real in order to realize the benefits. People need to practice pair programming in order to see how much it improves their code, their skills and their productivity. I was very skeptical about pair programming at first. However I had a key moment with pair programming. I noticed that I hardly got stuck anymore on hard problems whilst pair programming. When I run out of ideas to solve a difficult problem my partner usually has a good idea to solve the problem. If that does not work then we can discuss and come up with a new approach. You have to experience this in order to really appreciate its value.

However it’s really hard for external speakers to arrange a course with the development of a whole project at a university. Therefore I recommend, inspired by what Mark did, little workshops where you introduce people to pair programming or other techniques.

Furthermore put an extra effort in a really good presentation. Students usually have higher expectations for external speakers than for “normal” lecturers. Try to get them engaged, for example with games. There are lots of little games you may play. These games usually don’t take too long, you get people engaged and most importantly you make your lecture memorable. You can find a list of suitable games at tastycupcakes.org.

At my university we had the Lego Scrum exercise. I liked the Lego Scrum exercise very much and I remember that my fellow students mostly felt the same. At the very least it is something that everyone remembers. Here is a little video of us doing the exercise (sorry for no subtitles!):

I highly encourage you to embed those games into teaching agile software development. I believe that they can truly make a difference. But once you got the students engaged and they know about the theory, then it’s time for practice! Time for a project! Or more?

Don’t conduct one agile project, conduct 2!

Let me tell you something more about my bachelor studies: We are supposed to develop our first project with agile software development methodologies in our fourth semester. And you know what? It was a disaster. But a disaster that was needed.

We were using eXtreme Programming (XP) for the first time. We had enormous problems with estimations, user story slicing, iterations, test driven development (TDD) and probably everything else you can imagine. We did a whole bunch of mistakes. It was not just my group. Nearly every group I remember faced similar problems. For instance nearly everybody wanted to do TDD but ended up with a code (line) coverage between 20% and 50%. When we didn’t get our user stories done during our first iteration we simply prolonged the iteration by one week. Yes we really did that.

Of course, there were bright spots. We used pair programming and loved it. Our planning went pretty smooth towards the end. However I honestly don’t know how I’d feel about agile software development if this would have been our last agile project.

Luckily we conducted a second project in another course, which has already been praised. There we were using Scrum in a team of 50 people (with sub teams of course). We developed a customer relationship management system in Ruby on Rails. Our planning and retrospective meetings were facilitated by students who took the course in previous years. It was interesting to see how much we all improved as we grasped the concepts better. Moreover it was a good experience in inter team dynamics.

It was good but we still had a long way to go. Unfortunately not everyone seemed to like the concepts as much as we did. We were one of few teams to choose an agile development process for our bachelor project, were we were (mostly) free to choose how we want to work.

Adaptive vs. Innovative

Clarke Ching opened my mind to another important aspect: Adaptive small changes when rolling out agile or the “all at once” package. I believe that some of the problems we had were related to this. If you try to implement so many new and different concepts all at once, you will most likely end up implementing every change just a little. There are just too many new things which you can’t possibly really implement the first time around.

Therefore I believe that it could be beneficial to run workshops specialized workshops or exercises prior to the project. These exercises could focus on estimation, pair programming, TDD or… you get the idea. This way students get the opportunity to familiarize themselves with a method prior to using it in a project. Or you could tell students to simply focus on a set of changes and not try to implement all of XP all of a sudden. I just had the feeling that it was a bit too much, so maybe these techniques could be used to mitigate the problem.

The Takeaway

Theory is good and necessary, but practice shall never be underrated. If you give a lecture as an external speaker make sure to make it memorable. Engage them. Share your enthusiasm with them. You won’t convince them all. That’s alright. But if you give it all, you will successfully plant the idea of “Agile” in their heads. And I’m very thankful for everyone, who does this.

Become a student volunteer for the XP 2012 conference in Malmö (May 21-25)

Hello everyone,

I’m responsible for the student volunteers of the XP 2012 conference in Malmö, Sweden. The XP 2012 is a big international conference about agile software development. If you are a student and want to join the conference, this might be an opportunity for you. The following is simply a repost of the content that I put up at the XP 2012 home page in the volunteer section. So if you are interested in joining a big international conference about agile software development in order to meet with representatives from research and industry read the following text (or check out the link) and contact me! Oh and yes, of course I’ll attend as well 🙂

Volunteer

Do you want to go to the XP 2012 conference? Does the conference fee seem to be over your budget? Are you a student? Then you can be a student volunteer for the XP 2012 conference!

What requirements do I have to fulfil in order to become a student volunteer?

In order to become a student volunteer you need to:

  • be a student
  • speak English fluently, Swedish (Pratar du svenska?) would also be good, but not necessary
  • be interested in agile methodologies and development practices
  • be able to pay for your travel expenses and accommodation yourself, as unfortunately we can not pay for this. If you don’t know how to get to Malmö or where to sleep please feel free to contact us.

What do I get as a student volunteer?

As a student volunteer you get:

  • free admission to the conference – the full conference normally costs 10995 Swedish crowns (~1240€), even as an early bird
  • the opportunity to listen to a wide variety of talks about software development from leaders of the field from both research and industry
  • contact to people from research and industry – including possible future employers
  • insight into the organization of a large scale event
  • free food at the conference
  • a T-Shirt
  • the printed proceedings of the conference

What do I have to do as a student volunteer?

As a student volunteer it is your task to:

  • help preparing the venue for the conference
  • help with organizational tasks before and during the conference
  • help guide visitors of the conference to the right places
  • be present in the conference rooms and help with technical problems

It is our goal to have enough student volunteers so that not everybody has to be on duty all the time, so you can take a break and visit the talks and presentations you are interested in.

Interested?

If you are interested or have any questions please feel free to contact me at topf11@student.bth.se or tobias.pfeiffer@student.hpi.uni-potsdam.de

If you are worried about travelling to Malmö or finding accommodation also feel free to contact me, maybe I can help you or we can get a group discount at a Hostel.

Frequently Asked Questions (FAQ)

What is the registration process for a student volunteer?

Simply send me an email, that is enough to get registered as a student volunteer if we still need student volunteers. If you get an email from me confirming that you are accepted as a student volunteer, then this is enough.

How many student volunteers do you need?

The number of student volunteers we need is highly dependent on the number of attendants of the conference. Once we have enough student volunteers, applicants will be put on a waiting list in case we decided that we need more student volunteers or in case somebody got sick.

Why Waterfall was a big misunderstanding from the beginning – reading the original paper

You probably know that there is the Waterfall process – by now feared by most as “the father of the plan driven approach”. Some may even know that Waterfall was supposedly “invented” by the paper “Managing the Development of Large Software Systems” by Dr. Winston W. Royce in 1970. But have you ever read it? Why should you? It’s probably just an endless explanation of how great Waterfall is… or is it?

What if I told you that it is the exact opposite? If I told you that it is a paper identifying this pattern (without naming it Waterfall) and describing its deficiencies and proposing enhancements? Don’t believe me? Well let’s see what Mister Royce writes right after introducing the pattern on page 2:

I believe in this concept, but the implementation described above is risky and invites failure.

Doesn’t sound so positive, does it? Oh and that’s not even the best part! The best part is that the paper actually includes some thoughts that I would classify as agile.

Wait what?

Yes back in 1970 the paper, that supposedly invented Waterfall was describing its deficiencies and actually contained some agile thoughts. I really recommend you to go ahead and read this paper. Or stay with me and let me explain it to you – or do both.

The reason why I’m bringing all of this up is that it seems that all of this is a little known fact. I mentioned it to two of my lecturers (both PhDs) during discussions about agile vs. plan driven. The fact that they didn’t know this kind of shocked me, so I decided that this probably needs some more exposure – and this is all the exposure I can give.

But all is not lost, I actually learned this fact from a lecturer, Dr. Joachim Schnitter, at my home institute – so thanks to him!

The misunderstanding

Royce doesn’t define the Waterfall model and recommend it, he identifies the pattern and shows one of the major problems of the Waterfall model as the testing phase occurs at the end of the development process:

The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed.

He further on states that faults found there will most likely result in a major redesign of the software, he describes the devastating effects of this as:

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

To me this analysis is pretty much right on target in describing Waterfalls biggest problem, highlighting that he doesn’t recommend this approach at all. He is suggesting improvements.

So how is this paper agile?

It is certainly not totally agile, but it contains thoughts that go in the right direction and really resemble some current agile practices. Winston Royce proposes 5 enhancements to the “Waterfall” model, they are as follows:

  1. Program design comes first
  2. Document the design
  3. Do it twice
  4. Plan, control and monitor testing
  5. Involve the customer

Let’s focus on the latter 3 as the first 2 aren’t pretty agile to my mind (especially not number 2 as it highly emphasizes documentation):

Do it twice

Royce basically advocates that if your software product is original, the version delivered to your customer should actually be the second version of the product, at least for critical areas. He goes on to explain:

Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort.

He explains that this is done to identify problems early on, so they can be tackled appropriately later on. All of this sounds like a “spike” to me. You go on to build a part of your system, which you have little knowledge about, in order to increase your knowledge about this part of the system . You do so in isolation and throw the code away afterwards. He says that you should do this, but for the whole system.

Plan, control and monitor testing

In this section he once again argues that it is bad, that the testing comes last. However he does not jump to the conclusion that testing should come first, but he greatly emphasizes the importance of testing for the success of a software project. He also says that code should be checked by a second party, as many errors are easy to spot. I know it’s a very far stretch but that reminds me a bit of one of the motivations for Pair Programming, although he doesn’t suggest anything like it.

Involve the customer

This basically stands for itself as it is also one of the four core values of the Manifesto for Agile Software Development. He more explicitly says:

Involve the customer – the involvement should be formal, in-depth, and continuing.

He also states what it is like when the customer is not involved and the development team is basically left alone:

To give the contractor free rein between requirement definition and operation is inviting trouble.

He suggests 3 points after the initial requirements generation, where “the insight, judgment, and commitment of the customer can bolster the development effort.” These are: Preliminary Software Review (after Prelimnary Software Design), Critical Software Review (after Program Design) and Final Software Acceptance Review (after Testing). Although this is not an on site customer yet, it is much better than “make a contract and then let the contractor work alone in the dark on the system according to the contract” – don’t you think?

So was Winston Royce agile?

Certainly not, but he had some really good ideas on how to improve software development, some of which may be classified as “agile”. But why have most of us never heard of this before?

So how did Waterfall become so popular if the deficiencies were so well-known?

What I write now is just a rumor, nothing more. I’ve no way of telling whether it is true or not and clearly no reference.

So from what I’ve heard sometime some guy of the Department of Defense was given the task to look for a software development process to develop a new system. He found the paper of Royce, read the first page (which is quite positive) and saw the figure at the top of page 2 depicting what we now know as the “Waterfall” model. As it was simple and seemed good he went on to propose the depicted process, without ever reading about the deficiencies and proposed enhancements. Maybe it’s just an urban legend, maybe it’s true – I don’t know. Either way I’m sad that Winston Royce has been so misunderstood.

Lesson learned

It can be very beneficial to go back to the roots and read the original sources, even over 40 years after their initial publication. If some more people would have done this, maybe we would have (mostly) gotten rid of Waterfall as a Software Process by now. However it is still there and going strong. To each his own, but I prefer agile methodologies, practices and associated software development processes. To me they are way more productive, effective and fun. And it is always good to know that a CMMI level 5 company can highly benefit from a switch to Scrum – doubling the productivity and reducing defects by 38% (and many more benefits). I encourage you to go ahead and read about it in the Scrum Papers, the section (paper) is titled “Scrum and CMMI Level 5: A Magic Potion for Code Warriors”. Have fun reading it and I hope you enjoyed this read as well!

Can a distributed project be agile?

Resources page online

Hey folks,

just a quick post: I just created a page containing many of the resources I stumbled upon while learning about programming, software engineering, web development, that I found extremely useful. Most of them are free so go and check the resources section out!
This list is also a good indicator of what I might write reviews about in the future.

I hereby want to thank each and every author of the referenced material for their contributions. This is my way of saying thank you, I hope that through my blog some more people find those great resources. I also hope that I can help all the people who are looking for resources in order to learn about Ruby, Rails, web development or any other stuff.

Also if you feel like there are any good resources in the form of guides or tutorials missing please let me know (via comments or ways described in the About section) . I would enjoy this and feel free to share this if you think someone might have use for it.

So once again: Go and check out the Resources section (or simply click on the link on the top right!).

I hope that this may be of use to you.

Tobi

The Agile Samurai by Jonathan Rasmusson

“The Agile Samurai” is an awesome book about agile software development by Jonathan Rasmusson. I read it this march so my memory isn’t the freshest but I wanted to get this up either way since I want as many people to read this book as possible.

It is a really good introduction into agile Software Development, starting with the very basics. However I believe that people more experienced with agile development should also read it since it includes many good to brilliant ideas which I have failed to find elsewhere. Personally I attended two good lecture series before reading this book and I still learned a lot.

The book is also a really good read as it is spiced up with humour, stories from the work of the author and awesome illustrations.

Content

The book starts with a simple introduction to agile, featuring the core concepts and how an agile team should generally be composed. It continues with Agile Project Inception which is mainly about how to get everyone in on an agile project and my favorite part of the book: The agile inception deck! The book then continues with Agile Project Planning covering the topics of how to gather user stories, how to give good estimations and finally how agile planning works and why the plan will always change. Then the book turns toe Agile Project Execution where it is examined what exactly happens during an iteration, how to communicate and, what I found especially interesting, how to set up a comfortable and functional workspace. The last chapter briefly introduces agile methodologies such as Test Driven Development and continuous integration.

What makes this book special?

To me this book is special thanks to its unique style. Everything is written pretty clear and in a familiar language. Not only does it feature some good humor but also some special sections which I really liked:

  • Master Sensei and the aspiring warrior: Here you find a conversation between the aspiring warrior (you) and the Sensei. Usually the aspiring warrior asks questions, which you might have flying around in your head as well, and gets bits of wisdom as answers from the sensei. I really enjoy this kind of conversations in books as it is a welcome change from just text.
  • War stories: Here you can find stories Jonathan has experienced himself or he knows about. Those are usually more than worth the read, as they are examples straight from the real industry. To me they were the proof that what this book tries to teach me really is important and it helped me to see these problems, which really motivated me. I can very well remember a story where they were having a meeting about a software system that is meant to replace the old mainframe system. Then the guy financially in charge of the project asks how the new system would integrate into the old mainframe system. Ouch!
  • Illustrations: Last but surely not least the book features many awesome illustrations. They are often used to explain or emphasis a point. But, at least for me, sometimes they were just there to be pure funny and I am totally ok with that as I love this (for instance the chapter “Meet your agile team” starts with a picture of some ninjas – priceless.). For me the illustrations really helped me to remember the things better, as I am a visual learner.
Illustration from the agile Samurai by Jonathan Rasmusson (taken from his blog)

Choice bits

Here I want to briefly introduce what bits of wisdom impressed me the most with this book. Those are the first things that come to my mind when I think about this book.

The Agile Inception Deck

The inception deck is a real awesome technique to make sure that everyone is on board and everybody has the same vision of the product that is going to be built. It is lightweight, meaning that is not a heavy analysis that drags on forever but rather some exercises that can be finished very quickly while yielding a good knowledge of the product to be built. It’s not an original idea of Jonathan Rasmusson as the book states that it is rather an idea of his former coworker at Thoughtworks Robin Gibbons.

These exercises include creating an elevator pitch (“What would you say about your product, if you had just 30 seconds?”) and creating a NOT-List, so a list of what you are clearly not going to do during the project (so everybody is on the same page).

I don’t want to summarize the whole inception deck, since Jonathan has an excellent blog post up that does just this. Thanks Jonathan!

Personally I know how important this is and I wished that I had read this book 6 months earlier. I worked on my bachelor project which was about building a process engine (or workflow engine, if you will) which would run in the cloud – or so we thought. We contacted external partners, attended a Cloud Computing seminar, set up an Ubuntu cloud on iMacs (:P) and did a ton of research on Cloud Computing and how process execution might work there. Roughly two months later during a presentation the one ultimately in charge of the project stated that he doesn’t want such heavy focus on Cloud Computing, multicore support would be enough and we should focus more on human tasks (which we didn’t give much attention before)! You might suspect how we felt after this experience…

An agile warrior asks the tough questions first!

He really does. In my memory this is kind of a recurring theme of the book, to ask the tough questions first. Because from waiting situations rarely get better. If you point a problem out right when you notice it you might be able to fix it. Changing something later on is always more expensive and sometimes outright impossible. So this is a really good habit to adopt, although it takes a lot of guts from time to time.

The visual workplace

It’s about a workplace where everyone immediately sees the current status of the project and the core values of the projects. So you not only have your big storyboard with your user stories that are available, currently work in progress or done but also burn down charts and the agile inception deck you created right on the wall where everyone can see them. It is suggested that you might also put up a set of working agreements (for instance the time everybody should be in the office and the time the daily standup meeting takes place) and a list of shared values (for instance “asking the tough questions first”). This chapter made me especially recognize that I want to work in an environment like this.

Personal Impact

In this section I like to write about the impact this book had on me personally. Because I think if you read a good about your profession it should impact the way you think about your profession and/or the way you work.

The impact for myself has been pretty huge. Before reading this book I was interested in agile methodologies but my main focus of interest has been IT-Security in every way. While I still maintain this interest it has diminished a bit in the favor of agile methodologies and Software Engineering as a whole. This book not only made me realize that this is a very exciting and challenging topic but also that this highly collaborative environment, where you work together to achieve a common goal and always close to the customer, is an environment I’d enjoy to work in.

The cherry on the cake was just that I wrote Jonathan an email and he was quick to reply, genuinely offered me help and pointed me to some good knowledge resources during the course of our conversation. He even wrote an article about it and my software engineering course in his blog. It is a very different mentality than the pure “try harder!”-mentality often found when it comes to IT-Security. I prefer nice and helpful.

Conclusion

If you don’t already own this book and are interested in agile methodologies you should absolutely read this book. No matter if you are a beginner or somebody who has been doing agile development for quite some time now. You know if you really want to be agile, you are always looking for ways to improve and I am sure this book surely can accomplish this. I would even recommend reading this book to executives who wants to get to know this “agile”-thing, what it is about and whether or not the company should adopt it. But then again I don’t know too much about executives.

I would only not recommend this book to people who don’t enjoy a good amount of fun, illustrations in books or slight references to Samurais and Senseis.

If you want to get this book you can easily get it from Amazon or straight from the pragmatic bookshelf. What I recommend anyway is checking out Jonathan’s blog every once in a while, since he shares much great information (including parts of the book) there.

Feedback

As this is my first book review I would gladly enjoy some feedback on what was good about this review, what was bad, what you felt was missing and what you felt should have been left out. Comments on what would make you come back to this blog are also appreciated. You can do so via the comments section or check out the About section for other ways to contact me.