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.
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.
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.
* 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…
* 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…
* 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.
* 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.
* The time in the team room has a value in gold.
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.
When we talk about professions, we like to know if someone is good at the profession or if he’s bad. A good professional should probably be successful more than the bad one, or? So what about project managers? What is the definition of a good project manager. He should be successful at managing project, then. But what is successfully managing projects? Does this mean that the management should be successful or that the project should be success? But what does it mean to successfully manage a project and what is a successful project? This post focuses on the latter statement: the successful project. In many definitions, you take requirements, budget and time (and sometimes quality) and look before and after. If you can check as many of these groups as “as planned” then the project is a success. But then there is the sense of success. This should not be understated.
We in Sweden can be proud to be on the top three list of building projects. The problem is that it’s not the best but the worst building projects in the world. Just after the opera house in Sidney, we find the soon to be completed building of the tunnel of Hallandsåsen. So, why has this tunnel made it into a list just two places below the Panama canal?
For you who are not up to date with Swedish politics, it all started with the railroad and the heavy industry in Western Sweden. In order to ship all the heavy goods, they wanted the railroad to go through the hill created in the last ice age, instead of over it. This would not only cut time but also enable heavier train loads. It was a sure thing but also a political necessity. It was important to show that we spend money on trains and not just cars.
The problem is that the hill was not helping out here. When they started to drill, it also started to rain in ground water into the tunnel. Not little, but a lot. And the wells in the surroundings were drenched and the tunnel needed to become more water proofed. Then the cattle on the hills started to become sick and die. The water became contaminated by the material they used to seal the tunnels. Also, it was not as easy to drill as they had expected. It was slower and harder. I don’t think anyone disagrees with me when I say that during this time, everyone saw the project as a failure. So there were haltings of the project, companies were sued and there was also legal proceedings regarding the spoiled water.
The projected was halted and then restarted. In 2015, the tunnel is predicted to be opened, 23 years after they started on the tunnel. I mean, Apple started selling the IPod one year after he launched is idea to his team and here it takes 23 years to dig a tunnel which is 8,6 km long. The tunnel was originally thought to cost 1 BSEK but will probably cost at least 12 BSEK in the end. Cattle died, people had to get new water supplies and of course we had all the scared people when we had the poisoning scandal.
A couple of weeks ago, I saw a TV documentary about this project and it was interesting to listen to how people involved saw the project. The engineer who saw this as the most interesting thing he’d ever done. He loved the technical challenges and probably saw the project as a success since they’d been able to overcome all these technical problems. We had the farmer who’d found his dead cattle one morning, who definitely saw the project as a failure: all that wasted money and of course the sadness over his lost animals. Then there was the project manager, focusing on the target: getting the tunnel DONE. He was a bit disturbed about the failed time plans, missed budgets etc but his work (even if there were probably many project managers along the way) was to be completed. They had not given in. The politician then. He was the most interesting person to listen to, from my perspective anyway. He also saw they project as successful, since it would be completed. But here comes the interesting part; he felt that it had been mandatory to complete the tunnel, even if it meant spending all that money since otherwise the spent money would have been waste. Come again? If you’ve wasted 2 BSEK, this money will still be waste even if you spend 10 BSEK more. But if they would have cut the project, then they would have spent the money but would not have a tunnel. Now we spend 12 BSEK and we get a tunnel. That is of course true, but think of all things you can do for 10 BSEK…
Finally, the reported turned to the potential customers. The heavy industry guy. As we all know, they don’t sit down for 23 years and just wait. They’ve found other ways and he didn’t see any big use of the tunnel.
The funny thing is that different stakeholders in a project can have such different opinions on the successfulness of a project. But who’s opinion matter?