It is for a good reason that the agile movement should be based on the agile manifesto – I think it’s a sign of strength to be able to state what basic principles you base your work on. But why do I find this so important?

Independent of if your process is packed with rules, artifacts or roles or if these things are kept to a minimum and independent if you use agile or waterfall, situation arise when the process and the rules make more harm than good. If you then have shared values, these can guide you so that the rules don’t become more important than the outcome. “This is by the book” is in my world a sorry excuse for not having good arguments for why you act as you do. Even if something is in a book, you should not hide behind that. Of course there are corporate rules which you must decide to follow as being part of an organization, but values can be helpful in stopping people using these rules for their own purposes, that being laziness, fright, power lust, uninterested, uncertainty or what ever is behind hiding behind books and regulations.

It is my opinion that processes and rules should help us reached the highest sustainable productivity in order to reach corporate objectives. In order to do so we need to take good care of our business and very good care of the people which are a part of this business: customers, partners, employees, etc. Not that we should be afraid of hurting their feelings and therefore tiptoeing around problems (this is in my opinion quite the opposite of what you should do) but every time you hit someone with “this is by the book” they will not reach the highest sustainable pace. They still don’t understand. There is also a good chance you kill their spark. Therefore People over Processes. In the agile movement we care about the people. That is why I agree that we should stop using the word resources and this is why we have loads of habits in the agile processes. But they are not there because they are in a book, they are there for a reason.

This is perhaps also why I now here so many complaints about methods like scrum. I hear more and more getting the feeling that many scrum implementations have lost touch with People over Processes and are holding on to habits which are not the best for the long term or the short term productivity and seem to be there just because they are in a book.

But I’m not working for checking off that we’ve followed all the rules in a book. I work for making holiday dreams coming true. What do you do?

As of a couple of days ago, I’m splitting my time between two projects. As it happens it’s also on two different locations here in Stockholm so I’m happy that we have a warm autumn here in Stockholm so I can ride my bike between the projects, but what is really fun is that we’re using Specification By Example in both projects.

One major difference between my work will though be that I’m a core team member in my “old” project, while I will be an outsider/stakeholder in the new project. I’m supporting our product owner and writing examples but not be an active team member. This will very interesting to experience in combination with Specification By Examples – does example writing business people have to be part of the team?

This means that I’m that fortunate that while learning this I get lessons in two rather different projects and from two rather different styles of implementation of the examples.

Today, I had the first specification session with the new project and we started of discussing what we want to catch in the examples in the project. We then started writing examples, both some that are included in the scope of the original user stories but also the framework for examples to be implemented in later stories. Tomorrow we will test the examples on the team. This will be really interesting to see and hear.

Another difference between the projects is that we will be using a more conservative form of scrum in this project which is also very interesting when comparing with the other project where we have used something more of an almost post agile process with few fixed artifacts and more a continious adaptation of our process in order to improve productivity.

If you search for “objectives” and “projects” or some related terms, it is easy to get the opinion that everyone and everything is showing that clear objectives are essential to the success of any projects. If I’m to be a bit mean here, I would say that some seem to think that as long as you have clear objectives , success is a given.

But then again, if you really think about it: clear objectives are not the same as success. I could have the clear objective of running a marathon in a year but without a million different things such as actually preparing, getting enrolled (or measuring the distance oneself), you will not stand on a marathon finish line within that time limit.

And now Philip Runsten, a Swedish scientist actually states in his newest research report that clear objectives can (and probably will) create more misunderstanding than more fuzzy objectives. Being a skeptic, I cannot but salute Runsten for challenging this deep faith in clear objectives which we can find in our modern society.

Runsten has in his research looked at what makes competence intensive work groups successful. I haven’t read his report yet, so this is just what he writes…

He states that in his research he finds that teams that are forming clear and common objectives for the group are less successful than those which lets individuals in the group form their own opinions about the objectives. They all look from their perspectives and try to get their objectives prioritized, making this process alive during the completion of the task. If you instead start with defining clear objectives, these tend not to be questioned, which is negative for the team’s productivity. If you have clear objectives, it is often assumed that these are owned by a leader and not by the group collective.

True or false? Well, I’m going to at least do some reading. The paper (in Swedish) can be downloaded from http://hhs.diva-portal.org/smash/record.jsf?pid=diva2:420968.

Yesterday, one of the team members introduced me to the site http://shitthatsirisays.tumblr.com/. I’ve never been a big fan of these intelligent guides, probably because it does not suite me as a user so even if I do find myself with an IPhone using Siri, I will probably not use that service.

But what is interesting with Siri, from what I can see from the examples, is that Apple must have used personas which made fun of the functionality and actually built it with these guys in mind. Not only do they try out the edge cases, but while doing so they are active online and this has a viral effect. My friend told me and now I’m spreading the link on my blog.

And the examples shows that Apple does not only realize how their users are, but they also show that they are not so super serious, allowing us to make fun of them and ourselves. Again, Apple is to be saluted. Darn, they are so good.

Today, while starting up our fourth iteration, we again work with our examples. Our coach, Jocke Holm, is now stepping back more an more, enabling us to take more and more control. The situation is similar to being the kid learning how to walk. It is so nice to be carried around all the time but you at the same time crave the freedom of making it on your own. I salute Jocke for making it a smooth ride for us: it is not easy seeing your kids fall and hurt themselves but the hurt they feel if you haven’t allowed them to doing so under controlled situations is so much harder.

This time I had prepared myself and actually written something of a skeleton for an example. Jocke told me not to show it straight away and this was a good thing: I new some of the tweaks I wanted to catch but I still wanted to see if the guys came to the same conclusions as I did.

I then presented the guys to two of our new personas which we have developed at TUI Nordic. We have more personas but these two have very different objectives and behaviors when consuming the services we are developing for them. Together we just made some quick notations of their different needs and then we headed for the examples.

One of the guys started writing about the happy scenario and when we felt comfortable about this, I started adding some of the complexities which are necessary to exemplify the features. The guys ended up with a semi-similar example compared to my first draft. The differences were important and good.

It’s a good thing for me to do some initial drafting before discussing with the team since I then have thought of some of the most important details but it was also good to start from scratch while working together. I actually found that the scenario was not focusing on the thing I had expected and this is not the first time I find myself in this situation while working with examples. The methodology  really turns my head sometimes, making me see what the real issue is instead of assuming that the problem is how the wanted feature is as it’s explained by the customer.

What’s your occupation?

If you are like me you don’t give the same answer to children and adults. To other adults I say stuff like “web development”, “User experience”  and the name of my organization. To kids it’s a whole other thing. I work with airplanes and Bamse. And to tell you the truth, the answer to the kids is in my opinion actually a better answer.

I don’t know if it’s true, but I’ve heard that the founder of Swedish H&M said that he wanted every employee to say that they were selling clothes when asked about their occupation. He wanted everyone to feel that they were also part of that big process, independent of if they were coding business logic or cleaning toilets. If you don’t know that your work should lead to more sold outfits, then you have a problem.

But then again; how silly isn’t that? I don’t work with the actual planes in any practical sense and even if I’ve walked the Gemba in one of the Little Hop (Lille Skutt) costumes (don’t share this info with your kids), I don’t daily with Bamse. I’m working on improving our webs. Or am I?

You could, as we see it, realize that if the purpose is to bring these kids and their parents on planes to Bamse and get there with a smile on their faces, there is so many things that must work. They must buy the trip, get the transportation, etc, etc. And what happens if we sell them the wrong trip so the parents are upset while arriving? And how joyful will the greeting from Bamse be if he has the wrong info about when the kids are arriving?

At TUI Nordic we talk about giving service to each other in order to maximize the service to the customers. In other words: in order to secure that the greeting from Bamse is the best, the Bamse guy should have been given the best service from us, his colleagues. This is called a Service Profit Chain.

This also calls for another type of leadership. Instead of staff servicing their bosses with completed work, a manager should see himself as providing a service for his staff. Leadership as a service, in other words. Interesting and difficult but also rewarding.

Or perhaps it’s just me wanting to say to kids that I work with airplanes and Bamse without lying to them…

I think I’ve always worked with agile values and even after this becomes so outdated that it’s embarrassing for me and everyone around me, I guess I will stick to those values since they are near and dear to me. Getting stuff to work for real, working as a part of a group, collaborating and acting on change is both my strengths and my weaknesses.

But when does an organization become agile? “Are we there yet?” as so many kids have asked their annoyed parents in cars and planes and trains all over the world. I guess that large organizations are always and never there since there where always be areas where the agile values are melted into the foundation and areas where this is not an option. Yes, that goes for Google and its likes as well.

But what I find interesting at work right now is that we’ve somehow reached a tipping point where agile is no longer the odd case but something you can actually expect people to know and embrace. Not everyone is agile, interested in agile or wants to be agile but that is, as I mentioned, expected in any organization or group.

I guess there are many reasons for this and I cannot at this moment say what actually made us reach a tipping point. I don’t think anyone standing at any tipping point really knows that if the tipping point is not super obvious.

So what is next? Adapt to change, collaborate, working for working software, be part of a team and having loads of fun while doing so.

Some say that objectives should be SMART, Specific, Measurable, Attainable, Realistic and Timely. But goals should also be (to be really useful) something you could say a NOT in front of and it still makes sense. This is the reason I like the agile manifesto: it says for example Working software OVER documentation. Since someone could argue that a lot of documentation is more important than working software, this statement becomes so important.

When creating personas, I would argument that the same rules apply: in order for personas to be useful they must be so formed that you cannot please them all with your features. This is one of the reasons I like our personas: they are based on our segmentation model which stresses motives and personality. It is so easy to fall back to different types of users, defining them as people. But a person is more than his user behavior. He has values and motives.

A couple of days ago, we were working on a number of functions and how our personas interact with these functions. I was taking the role of one of the personas and I often ended up with not seeing the value with that function in this role. Suddenly one of the participants just stated:

- I don’t like that X. He’s arrogant and grumpy.

And there you go. Some people are like that when they are interacting with your brand, your product and your functions. If all your personas are likable in all situations and they always love all your features, I think you’re missing out on some of the real values of personas.

The best teacher I’ve ever met had of course many talents which all together made him a brilliant tutor and one of them was teaching us to be aware of the distraction of details while solving a problem. While writing examples today, I again was struck by the importance of this.

This teacher, who gave math classes in High School made his own math tests and the last task was always something special. In order to solve that you need not only have grasped the lessons but you also had to be really clever. I must say that I, as a mediocre  math student, seldom cracked his last question, but I always looked at that first when taking a test and it was always a pleasure seeing him after the test explaining how to solve it.

One of his first tests included this question: given that you have a red, one meter stick. What would be the smallest dimension for a box to hold that stick?

This still requires some thinking for me to solve but the most interesting part is that he wrote that the stick was red and many students focused some of their problem solving on this fact. Why does he write that the stick is red? How does this affect the dimensions? But the answer was that he intentionally included facts which were distractions. He said that one key area of problem solving is understanding which facts are relevant and which facts to ignore. I guess some of the students hated that… But it is an important lesson in real life, as all software developers (should) know.

While writing examples, I struggle with this all the time. I try to think out all details and often get stuck writing examples which covers all these facts. And then it hits me: that fact is just the redness of the stick. It makes the problem solving hard but it is just a distractions. When I can ignore that fact, the examples becomes so much simpler to both write and understand.

My old teacher died many years ago, but his teaching stays with me in my daily work. What a sign of great leadership.

We’ve now moved into iteration three or something like that. Some of the practices have changed, some stay, but it’s still both so rewarding and hard. Writing good examples are really so much harder than one could have expected.

What works for me is that we start with a group. The group can be between two and five people. We discuss first with eyes on each other and on the whiteboard. No writing should be allowed just to keep us concentrated on the dialogue.

We then take a coffee break, go back and try to structure the conclusions in a semi example way. The guys most often talk about how to make it a good example given the Gherkin language but otherwise the focus is on the business rules.

We then part ways. It never takes more than 2 hours, most because you need to change focus and not become too stuck. We are never done after two hours but continuing is only semi constructive.

I finish up my notes and send them to the developer responsible for typing in the example. He takes notes too and can therefore compare the two versions in order to see how clear we are.

After a first rough version we sit down together and discuss how well the example(s) match our discussions. This takes no longer than 30 minutes and after this the developer updates the example. This is often an iterative process where we can have many very short discussions but after a few rounds, we feel that we are done.

There after I sit down with another developer, letting him read and explain the example to me. This is to ensure that the example is interpreted as expected but also that it can be understood by someone else. This always result in some minor changes.

Done!

We’ve now gone into our third iteration using Specification By Example and after a really good iteration we had a more struggled iteration the last two weeks. But this is a good thing: we’re learning so much from the previous iteration and I’m happy about the learning’s we’ve done. Better now than later; we will have ample time to handle new challenges later.

But as we’re moving along, we can also see a need for solid personas. I’ve worked some with personas previously but have never really fallen for it. Guided by our coach, Jocke Holm, we hoped to find the real practical usage. Yes, I’ve seen that it’s probably useful but when it’s come to the real thing, I’ve not used it to any greater extent. But now we need to form good examples with clear business value for our different users.

We looked at the personas we have on TUI Nordic. They are based on our segmentation model and I’ve previously found them somewhat useful but Jocke thought something was missing.

What we did was started writing and thinking about our personas and the result was a longer story and this made the personas come to life for me. Suddenly, with all these details and small moments I actually saw the grace of personas. I could see how these very detailed personas helped me in prioritization and forming examples.

But I also realized that I couldn’t present a number of novels to the team. Hence, I searched for a good model to present personas and totally fell for Per Axbom’s template for personas. With our novel form personas, I could present the key differences in one easy format. The templates are in Swedish but I think you can probably get the picture anyway.

From Per Axbom

And I must say that some of the other templates will probably find their way into my other processes too.

Time flies and on Tuesday, we complete the first iteration, using agile practices and more importantly: Specification By Example.

We started off with a number of short planning sessions, setting the stage and discussing the scope. We were here coached by Joakim Holm from Adaptiv and Herbjörn Wilhelmsson and together we actually set a little bit different scope than we had set before and now the scope feels manageable. Herbjörn and Joakim forces us to really look at the scope, which up until then had been in practice a big delivery: all or nothing and we hadn’t been able to force ourselves to see it differently.

Findings:
* Even if you’ve been working with agile practices before, an outside coach can help you renew your practices and consider new ideas.
* With an external party, the scope can be discussed more freely and sometimes, as in this case, the scope can actually be divided into manageable deliverables.

Parallel with the actual planning and completing of the project, we’re also coached in Specification By Example. We’ve done some short training sessions and as we’ve gone along, we’ve just started writing feature files with scenarios. We’ve also initated (but not yet started) a book club based on Specification By Example. This book club is targeted internally and to everyone interested in the methods. More on this in a later post…

Findings:
* It is one thing to read a book on a method, and another to really test and get feedback from someone who’s been doing this before. We would have gone in a completely wrong direction hadn’t we had the feedback from Joakim and we would either had ended up just trying to get the example tests working or simply giving up.
* The combination with small training sessions and directly testing something really works for me and things got really concrete right away. This probably works better for me than a couple of intense training and then being left on my own.
* The whole team participate in the training som SBE becomes a common thing for the whole team. Everyone can edit the files and anyone can discuss them. This means that I can test my scenarios with anyone in the team – perfect for a coffee break.
* As I’ve worked so much with user stories before, I initially had a hard time understanding the differences and had I just started working on this on my own, I would probably had missed the point.

During the iteration planning, we discussed the highest prioritised user stories and I was actually challenged in my priorities: why is this important? Does this really give business value? So, I changed my mind. I also stressed the importance of success in the first iteration. New teams are often underestimating the challenges in the first iteration…

Findings:
* Challenge your onsite customer if you don’t understand the priorities: very often there might just be assumptions behind the original prioritisation.
* Don’t take on too much during the first iteration: it is better to build a habit of succeeding.
* Don’t spend too much time on estimation in the first iteration – you know next to nothing so it’s better to afterwards evaluate how long things actually took.

After the iteration planning, we got going in an ordinary agile manor. I will not in this post go into details concerning the agile practices but what was interesting was that even if we’ve not been talking TDD, the testing and the pair programming came naturally to the crew and I just had to hand out some extra keyboards and mouses. This also lead to developers working on areas which they’d not worked with previously. Developers who normally only works with user interface now have a basic understanding on what’s underneath. Nice…

I for myself, started to write on the scenarios. Joakim started with an example based on our user stories. He told me to start editing and I had to fetch my old and hidden knowledge on how to edit test cases in Visual Studio from the long term memory. I started writing some and then asked Joakim what he thought. His quick reply was that I needed more training on Gherkin well, actually this is the good point: he was (and is) absolutely right but now I got the feedback directly and could slowly improve my skills.

Findings:
* It would have been very hard to start working without the first examples from our User Stories. Now I could see based on my problem domain how this would work with the scenarios, etc. It became much easy to just get going. Had I started from skratch, I would have had a hard time knowing where to start.
* It was good to get direct feedback on my scenarios. By pointing at errors or areas of improvements in my real cases, I learnt so much more than I would have from made up examples.
* I always discuss quickly with someone before checking in changes. Would I be working on my own, this would make no sense. Now I get to test the scenarios on someone else and at the same time build their business knowledge. I also get so many good hints about good scenarios from these discussions.

So how is it going? Well, the progress board looks really good and we feel confident now when the iteration is nearing an end. If I would change anything, it would be my own priorities. I chose to do some other things which kept me away for sometime days. I tried to slip by when the meetings were inhouse but I can definitely say that I should not have prioritised all these outside tasks. Not that I don’t do other stuff otherwise, but I try to do so many of these tasks while in the team room because otherwise I miss out.

Findings:
* The time in the team room has a value in gold.