Former diary of a former believer

Community?

2011-09-18T18:04:00.002+03:00

I haven't been blogging in a long time and I guess this might be my last post. The reason is that I'm a lot fed up with the "agile community". There are many good people there, but they are overwhelmed by these kind of people:
1. Consultants who are trying to get better business for themselves. They push for the things they can sell in conferences and seminars instead of focusing on how to improve things for all.
2. Developers who care only about software development itself and ignore everything else.

Put together those two kind of people and you achieve one community that mostly care about things like TDD and its flavours (which are good, but Shu level things) and such things and ignore everything else. If we assume for a moment that the software industry itself is a system it appears pretty clearly that thinking only to its pure development part and optimizing just that leads only to suboptimization. Unfortunately the other parts (leadership, management, business development and so on) are considered uninteresting by many of the people in the "community", and so ignored.

Given that, the only thing I can say now is: So long agile community. I might still show around to some events sometimes, but I don't see myself having any kind of active role there anymore.

TDD, development or design technique?

2010-05-04T14:24:00.001+03:00

TDD is definitely one of the most controversial techniques that the IT industry has. Someone thinks it's really good, someone thinks it's really bad. Someone thinks it's a development technique, someone thinks it's a design one. So, I want now to share my view on the matter: TDD is for me a development technique, not a design one (unless you can accept bad design).

The best team I've worked in decided, in the beginning of the project, to use a full TDD approach. Tests were written before coding (both unit and acceptance tests), things were considered done when all tests passed and so on. But every time, for every single feature we had, we ended up reverse engineering a class diagram out of the code, and every time we realized that the design was simply bad. Responsibilities were in wrong places and the contracts were, at least, fuzzy. So what we did was planning big refactorings on those class diagrams and then execute them (of course, also the test cases had to be refactored). If my memory is good, we had 5 major architectural changes during the project, as you can see, a lot of rework.

Could that rework be eliminated? Well, most likely eliminated no, but drastically reduced yes. I believe that with a 1 hour architectural planning session right after sprint planning (we were working in scrum with 2 weeks sprints) we could have produced software with the same amount of quality but with much less rework (which is a thing that customers are never happy to pay).

Will something like that always happen when doing TDD? My answer is yes. TDD has a big flaw: it forces all the focus to the single unit under work (in most of the cases, one class), but it leaves the iteractions with other units in the system out (and eventually, all the "big picture"). The main benefits that planning sessions would bring in are that the entire team would be forced to look at the big picture and that the contracts between different units would be defined before starting coding them.

Last but not least, how can someone who calls him/herself a developer accept that the design of his/her software is done by some tests (which are just other pieces of software)?!?

Scrummaster's pitfalls

2009-11-11T10:36:00.002+02:00

During these years I've noticed that many scrummasters are falling in the same pitfalls (and well, I've fallen in some of those too). In my opinion those are the potentially most dangerous for the team:

Scrummaster committing to the sprint backlog
When a scrummaster commits to the sprint backlog he/she starts having a dual role: scrummaster and team member. The team then might get confused and start misunderstanding things said as scrummaster as things said by the team member and viceversa. Two things then might happen:
1. Team starts doing blindly whatever the scrummaster says, even in matters that the team should decide by itself. In that scenario the scrummaster becomes the biggest team's bottleneck, as all the decisions will pass through him/her.
2. Team stops listening to the scrummaster, making almost impossible to him/her coaching the team.
There's one easy trick that might help in this situation: having the scrummaster wearing 2 different hats: one when he/she's acting scrummaster and one when he/she's team member. This would make visible which role he/she's playing, but on the other end I think it's better not to have the scrummaster as team member at all.

Scrummaster telling the team what to do instead of coaching
This happens many times when the scrummaster is a former project manager, but not only in that situation. Also in this case the effect is that the team might become completely dependent on its scrummaster (who will then be the team's bottleneck).
I've fallen in this pitfall too. At that time I was scrummastering a quite joung team who had just put their first made product to production. A bug has been found in that product affecting their customers so the team started investigating it. As many young teams would do they started trying out things without any structure, running many different (manual) tests in production and not getting any result. After half an hour of that I stood up, blocked all the work they were doing and started telling them how to proceed (I had the most test-oriented person testing in production, the most senior developer checking the code and the rest of the team trying to reproduce it in a staging environment). The problem has been found and fixed, but the team didn't learn how to investigate things and had the feeling that whenever there's an emergency situation I tell them what to do. What I should have done in that case was to start challenging them by asking questions that could have made them realizing they were proceeding in the wrong way (usually asking "why?" is a good starting point for that). On a side note, this is still an argument of discussion between me and the team's product owner, who thinks I made the right thing (but then again, in his point of view fixing the product was the top priority while in mine making the team growing should have been the right one).

Scrummaster acting as proxy between the team and the product owner
This is a sneaky pitfall, luckily not that common (or at least I haven't seen it only once) but really distructive for the team. What I've seen started with a team having a product owner knowing exactly what he wants but not having so much time to spend with the team, as in that organization the person acting product owner has a lot of other things to do. Because of that lack of time he started delegating to the scrummaster things like "this is not what I want, tell the team that what I want is that" and such. Eventually the team, who already was in a conflicting situation with their product owner (as their product vision is different than the product owner's one) is now seeing the scrummaster as "the other side" in that conflict. That situation is still ongoing so I can't tell how it ended, but if I would be that team's scrummaster what I would do is offer the team to step down and have one of them replacing me in that role.

I'll go on talking about this topic in the future, stay posted ;)

Agile moving

2009-10-23T12:49:00.004+03:00

I'll soon be moving to a new flat and I decided to use an "agile" approach: a lot of planning but no plan and a way for visualizing the work in progress:

So far it has worked pretty well, dependency between various task is handled in the "ready" column (tasks can't be ready to start if they depend on other ones that are not done) and the work in progress limitation brings focus (instead of scattering between too many things at a time).

UI design and scrum

2009-10-19T10:01:00.001+03:00

I've been during last week to the Scandinavian Agile conference in Helsinki and there I was really interested in a session called "Combining UI design and scrum", as the topic is quite hot and I still haven't see a good way for doing that.

First of all, I should mention that I've been really disappointed by that session. Overall, it had the feeling of a pure marketing session as it didn't explain at all the GUIDe methodologies used there (just a slide with a link and comment like "go read it yourself") but the focus was mostly on "see? we can do this, we have already done this, if you need this call us".

The second biggest disappointment came from the fact that the session was more about "separating UI design from scrum" than combining them, stating things like "only a UI design expert should to the UI design without involving the development team" and "in the product backlog you should put feature, not user stories as user stories are a problem and in the backlog you want to have solutions". What I got from the session is that the speaker's idea is that customer and UI designer should talk in order to have the UI designer fully finalize the UI and then hand it over to the development team, that should start implementing feature-by-feature starting from a mock-up.

While I think having a full UI mock-up ready before starting developing a product is a good thing (even PatientKeeper does that) I don't like the hand over part that what has been described in the session involves. In my opinion the development team (or at least part of it) should work together with the UI design expert and in that way get the knowledge on the product that the mock-up itself doesn't bring. I've never done that myself to that extent but I'm really interested if someone has at least tried and what were the outcome. So, if you've done that and want to share your experience please contact me, or, if you're in the Helsinki area, join one of the agile dinners!

Agile++ or just plain Agile?

2009-04-17T12:52:00.002+03:00

Some days ago a colleague linked me a news on InfoQ about Ivar Jacobson, the father of use cases, saying that "Being Smart is an evolution of being Agile". After reading it I had the strong feeling that Ivar missed the point, calling "Agile++" what's simply Agile and calling "Agile" what's just a bad implementation of it.

For example, he says that being unsmart with people is "viewing processes and tools as more important than people", while being smart is "recognizing and understanding that software is built by people, not with processes and tools!". How can be that "viewing processes and tools as more important than people" be considered "Agile" in any way, when one of the 4 points of the agile manifesto is that "we have come to value individuals and iteractions over processes and tools".

All the other points he quoted as "being smart" are just plain Agile:

Delay all the decisions until the latest possible moment, in order to take advantages of the experiences done until that moment;
Don't build architecture up front, think about it for a while and then implement what you need (but keep some doors open for future implementations);
Have a cross-functional small team that can carry on all the work required for carry on the project (yes, also testing!);
Don't get stuck in copying a process that worked somewhere else, but use it as a first step and then continously adapt it by trying out new things.

And, if you really want to be smart, keep in mind that Agile is not a silver bullet. Agile is a tool that might or might not bring to success, depending on a lot of factors. Don't try being Agile if you don't need to!

Lean software development & Software craftmanship

2009-03-10T13:16:00.002+02:00

I was randomly browsing the net and I've stepped into an interesting article written by Mary Poppendieck about lean software development, I think it says everything that has to be said on that topic, and I recommend reading it to everyone: http://www.poppendieck.com/lean.htm.

On another topic, yesterday Marko sent me an interesting link for a Manifesto for Software Craftmanship: http://manifesto.softwarecraftsmanship.org/main. I definitely agree with those things, and hope more people will start following those ideas!

Assumptions are evil

2009-02-27T08:32:00.003+02:00

One thing that always makes me thinking that there's something wrong in our industry is that when building software people always makes assumptions instead of asking clarifications.
For example, if I would go to a construction company asking them to build a building somewhere they will ask me for sure if I'd like to have a new Empire State Building or just a wooden summer cottage, but if I would ask for some software in an unclear way to an average software team they would start building it making their own assumptions, and most likely what they'll produce is something that doesn't fulfill at all my needs.

Quite surprisingly things like that happen also with scrum teams, which is quite unbelievable considering that the product owner should know what he (as team's customer) wants or, if he doesn't know, he should figure those things out. There are companies where if the team doesn't have anything to do (because the PO is not doing his job properly) they would just go surfing (ok, maybe not the wisest thing to do in Finland, but works brilliantly in California where they are) instead of assuming, and I can tell you that the cost of having a team surfing for one day is less than having a team building a wrong software and then fixing (if not rewriting it).

In summary: assumption is the mother of all fuck-ups, don't assume, just ask. It's a simple rule, easy to follow, but its impact is quite big.

What is agile?

2008-12-02T23:09:00.002+02:00

I was later on on the usual Agile Finland dinner and one of the question that was asked to everybody there was: "what's agile for you?". This is the answer I gave:

Agile is not a silver bullet, it's not a bunch of practicalities, it's the biggest cultural change in the software industry in the last 25 years, fixing the wrong idea that software development is an industrial thing and bringing it back to its original craftmanship dimension.

Anyone who wants to challenge that?

The key to success?

2008-11-30T16:41:00.003+02:00

I've been during last week in Tampere for the Nääsvillen Oliopäivät, or OO Days. The conference has been good, excellent talks during mornings (Alistair Cockburn, Pekka Abrahamsson and Jim Coplien) but way too many sales speeches in the afternoons, and no OO at all!

Alistair's keynote was about the few foundations that he founds crucial for software development and about properties of a successful teams. The first foundation he highlighted is that software development is a craft (quite surprisingly I had a conversation on the same topic with my friends Ari Tanninen and Marko Taipale while driving to Tampere the morning before the presentation). As a craft it has to be learnt, and about learning Alistair used a Japanese concept called Shu Ha Ri. It says that there are three stages in learning:

- Shu (traditional wisdom): you learn the basics of a technique, applying its rules blindly
- Ha (breaking with tradition): you reflect on the technique, finding exceptions to its rules and reflecting on them
- Ri (transcendence): everything is now natural, there's no need to think about the rules

I see that as really actual, and especially I see two big pitfalls coming out from that: people in Shu never leaving that stage and people in Shu trying acting as they would be in Ri without having the right knowledge and understanding.

For example, it's a very well known fact that the majority of projects using scrum fail. There's a good literature about that, and usually the causes are: teams sticking to what the book says, without adapting the scrum framework to their own needs (Shu people sticking there) or teams trying adapting the framework to their needs to early, when they don't yet understand it (Shu people acting as Ri).

After that and all the other talks my personal conclusion is that the key to success is not in tools, frameworks, processes and such. It's in people. And it can be summarized in one simple rule:

THINK!

Discipline and agile

2008-11-03T19:22:00.000+02:00

Discipline

Most of the people while reading this word would think about the military discipline and never associate that with agile. It's quite funny that for many people being agile is mostly lacking discipline, while in my opinion it's impossible being successful in the agile world without discipline.

In the old days life in a software project was ruled by The Gantt, a simple diagram illustrating the start and end date of every activity in a project. Those dates were thought in the design phase of the project and defined by different people (usually the analysts) than the ones that were implementing the actual software. Developers were receiving a long and detailed frozen specification document from analysts and were then supposed to handover to a testing department the software they've realized.

Now let's think about the agile world as seen by someone used to work in the waterfall way: there are no separate phases (analysis, development, testing...) but just a small requirement gathering at the beginning of the project, maybe there aren't even strongly defined release dates, there's not even a project manager telling people what to do next: it sounds really awful! "How can those people work in that way? That's anarchy! They can just do whatever they want. How can they even know if they're on track?!?".

And now is when the discipline part plays an essential role!

The Manifesto for Agile Software Development says that working software is more valuable than comprehensive documentation, so an agile project doesn't have any big specification document or such, instead there's a list of feature the project should provide. A team without discipline could then think that instead of realizing those features one at a time they could go on in the old way and start doing horizontal development: "let's now start building the persistence layer, then let's add a business layer on top of it" and so on, maybe even parallelizing those developments without any kind of integration until everything is almost done. This would make impossible showing anything to the customer until the end, because everything would be 90% done. How can that team be sure that they're developing what the customer really wants?

A disciplined team would do something different: estimating the complexity of all the features and then start working on one of those at a time, maybe the project's most important, and implement it completely (from GUI to persistence for example). The team would then show the implemented features to the customer as soon as possible, in order to get feedbacks that would allow them to know if they're moving in the right direction or not. Knowing how complex a feature is and how much time did it take to realize if the project is on track, is falling behind or even if it's going better than expected. Making the daily work visible, maybe using a burndown chart, will immediately show how the things are going, allowing the team to take actions if things are not proceeding so well, but it requires a strong discipline (keeping always up to date the scrum board or kanban board for example), even if it would be easy sometimes to cheat and say that something not done is done "because there's time tomorrow to finish it".