The tipping point of agile in an organization

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.

Categories: Agile

The annoying personas

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.

Categories: Agile

Ignoring the redness of a stick

2011/10/21 1 comment

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.

Settling down with specification by example

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!

Categories: Agile

Personas to the rescue

2011/09/29 1 comment

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.

Categories: Agile

Completing a first iteration using agile and Specification By Example

2011/09/10 2 comments

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.

Categories: Agile, sbe

Draftning a first example

2011/08/30 2 comments

Yesterday, we worked on values, objectives and user stories in one of our projects. We were also given a short introduction to SBE by our coach Joakim Holm. SBE, for you who like me are new to to the concept stands for Specification By Example. I will not with my so not even basic whisp of knowledge about what this really means at this point even try to explain it, but we will formulate solid, important requirements and test cases in the form of specifications which can be executable. I will probably go into more details in later posts but if you want to readup on the subject, just google Specification By Example and you’ll find someone who can explain this much better than me.

So, back to my first encounter with these specifications. When I saw the way they were written, I first didn’t really understand how they relate to user stories – why do both? What is the difference between the notes on the flip side of a story card and a specification?

A bit skeptical, I during the first session started writing user stories. This is familiar grounds for me and we found a bunch of good stories. So I left the user story writing workshop with the intention to write a number of related specifications, exemplifying the user stories. No probs, hey. I know how to write this stuff, don’t I? I’ve written tons of user stories and as many test cases.

But this was no cup of tea. Writing these examples was so much harder than expected and I went home with a draft for one specification and more questions for our next session. Some of the questions are of course questions about formulating examples but most of them are domain questions and a large portion are directed to the developers and the architects. Which I guess is the purpose of this work. Keep you posted.

Categories: Agile, sbe