in love with waterfall

Even if your company has forced you into SCRUM, if you are an influential team member or the mighty scrum master itself, you can find ways to keep your love close. Directly speaking, you can change SCRUM to still irradiate the warmth of the lost loved one. And it is even legal.

So I am suggesting you a new scrum but. Written by the book, it could say:

(We use SCRUM, but) (because we are in love with waterfall,) (developers speak first and only then testers in our daily stand-ups)

but it can be masked as:

(We use SCRUM, but) (because testers can not test unless developers develop,) (developers speak first and only then testers in our daily stand-ups)

I've seen this applied, so it's proven to work!

marketing

These two guys definitely think that marketing should be in the toolbox of every developer.

So you follow the above links recursively until you know everything about the two and marketing in general, evaluate how credible the two are, and then start to think if what they say makes sense.

And it does seem to make sense: market yourself, market your stuff! And then you think: Hold you horses, I work in this cube of this big corporation, there are others in other roles that will do the marketing, I can just code.

It happens that recently in one All-hands we've had, I've heard one of our PMs say something along these lines: We need to sell our new features to the Sales guys first, and then they can sell them further. And some time before this, I had heard our Director saying something along these other lines: We need to sell our product better to the Software org, so that it will count in the next product stack.

It all adds up, don't you think? But will a time come when you'll have to sell your stuff to the product director? Or to your manager?

... I don't think so, you're just a poor soul in a cubicle, right?!

let go (II)

To the one thinking about a software architect career, the bad news is that the LET GO advice applies to you as well! The good news is that it does not apply as drastically as for managers, so you might get your share of coding.

But what are the shares that you're "winning"? Creating a vision of the product, technical communication with the stakeholders, sharing the project risks with the project manager (agilists do not have a project manager role in their team and they are perfectly fine with that, no extra comments allowed :/).

I heard this guy saying yesterday that one characteristic you should look for in your next architect is that of being able and willing to step back. He was referring probably to stepping back in order to get the big picture. One other thing that he said was that he had seen cases when the software architecture was not properly looked after because the architect was too busy writing code and/or keeping up with new technologies.

This is what I'm saying! We should look for people who are also able and willing to let go!

let go

I can't help but giving out pieces of advice, probably a reminiscence from the times when I used to perform as a manager - yeah, I know what you think, hell of a coach, just an old fashion know-it-all manager. (Phew ... it's just struck me this bug of mine is what drove me to subconsciously start this blog!)

Anyway, today's advice goes to former software developers who embraced a management career and can't help but performing half of their time (they wish) as a developer and the other quarter (25% of time is wasted) as a manager.

LET GO! Just be a manager, your team needs you to take care of them, this is your most important task now! Why let go? Cause you can't afford it: besides the limitations that nature put on your intelligence, you are even more limiting yourself by focusing in two different directions.

easy svn merges?!?

Here is what you need to do to merge the changes from your long-living personal branch into trunk:

1. Back merge from trunk to your branch working copy

>>svn merge <svn_root_url>/trunk/<component>

2. Commit the branch working copy

>>svn commit -m "backmerge from trunk"

3. Reintegrate merge from branch to trunk working copy

>>svn merge --reintegrate <svn_root_url>/branches/<branch_name>/<component_name>

4. Commit the trunk working copy

>>svn commit -m "<meaningful message> ... <codereview url> ..."

5. Record-only merge to your branch so that you can continue using it

>>svn merge -c<revision_number_from_step_4> --record-only <svn_root_url>/trunk/<component_name>

6. Commit the merge from trunk
>>svn commit -m "record-only <rev_number> from trunk"