Jekyll is still one hell (good) of a blogging and web site system. If you are hosting your own WordPress blog and you are technical capable: Look into Jekyll. It’s a complete static website generator using markdown as a file format. I love it and I am still a bit on the learning curve.

There is a yeoman generator for Jekyll and Bootstrap that makes some things easy. You might be better off with starting a plain Jekyll project and wiring everything up yourself. However it is a good if you want to see how things can be wried up and have a basic idea how bootstrap works.

I found out what copywriting is. It’s essentially writing for marketing reasons. Aha. Thank you wikipedia. One of these words that I listened to multiple times but never really questioned what they imply.

I decided on the kinds of trainings I want to provide as a “standard” to my customers. These will be: “Extreme Programming”, “Pair Programming” and “Userstories with Gherkin and BDD”. Watch out there: News will be out soon. if you want early information: Shot me a mail.

I a talk about clojure script (Clojure Script: Lisps revenge) kept me up at night and I blame David Soria Para now for me having thoughts of trying it. It looks like the hell of a beast of a programing languages but looks like it fixed a lot of the functional fuckups that are in JS. And ITCOMPILESTOJAVASCRIPT!!!EINSELF!!!

“Sitting together fuels team communication. This has impressive results, cutting time-to-market by two thirds in one field study*. It enables simultaneous phases, eliminates waste, and allows team members to contribute insights to others’ conversations.

To sit together, create an open workspace. This takes longer than you expect. Organize your workspace around pairing stations, locating people according to conversations they should overhear. Provide plenty of whiteboard space. Make sure there’s room for personal effects and a place for private conversations.

Open workspaces are hard for some to accept. Get team members’ permission before switching, or they may rebel.”

1. Sit all the disciplines together.
I often see designers skipping this one and staying with their designer teams. Not so good. Everyone should be on the product they are working on.

2. Agree to common rules explicitly
Different people have different needs and desires. Talk about them and write them down. After a few weeks: rinse and repeat. make this explicit

3. Must not be in a room, but can be close
A glass wall often does as well. If I can see my Product owner (a role that requests own rooms very often in my experience), I can approach him.

4. Adapt your visual management
If you are doing hardcore Scrum you might dive into Kanban now. There are different disciplines and roles in the room, working on on one thing. So the normal Scrum Board most likely will not cut it. A good place to start is Kanaban.

5. Rituals! Rituals! Rituals!
I have heard of a “Disco Friday” where teams would play nice music all day long aloud on friday or seen hourly Nerf gun matches. These rituals help to firm groups and keep them in high cohesion.

6. Style it
Invest some work in styling the place. Some lights, LED ambient illumination, posters on the wall etc. will really help teams to form and stick. Make sure to provide a budget.

7. Clean it
Once a week/sprint: Clean the workplace and bring everything in order. Its a very short procedure for most places and it helps providing general order and cleanliness.

8. Have the Meetings together
Do not let the “Backend Guy” bail the Grooming when you are working on Frontend Stories. Do not let the designer bail as well. Everyone has to learn what the other disciplines do. When someone sits there and does not get it: Help him understand. Re-Arrange Groomings so that there are Stories of any Kind. You know the vertical slicing thingie? You should do it. And no .. neither the designer nor the tester will bail the Retrospective. It takes disciplined and willing teams to practice it this way. But in my experience: The seasoned crafts(wo)men will happily participate.

9. Have a extra room for “Discussions”
When different trades of craft work together, there is a lot of need to discuss things and talk about it. You will need a room for this since every discussion will be a interruption for everyone else in the room. Buy a set of high quality noise dampening head phones. I am working at a client here in Hamburg where you have small chambers for working 1on1 as well as meeting rooms that are general available for phone conferences etc.

10. Have more than enough Space
Even People with Computers need Space to work and think. Provide this. Don’t make cross-functional teams and cram them in a small room and be surprised you get a lot of complaints from the inhabitants of that room . If you cant afford space, maybe do not hire developers at all. There are regulations for how many office workers can be in a certain set of size here in Germany and I have seen several occasions where these laws where used as a common denominator of how many people fit in a room. This is not the way it works.

Coding conventions sound so easy, but get hard over the course of a longer project and with bigger team size. With a little feedback and forth with Johann Peter Hartmann, the following principles for a coding standard were up for discussion.

understandability – The conventions should help the programmer to understand the code and should be easy to understand themselves

learnability – It should be easy to adopt and learn a coding convention and the convention should help the developer to easily find a way into a codebase

attractiveness – It should be attractive to adhere to a certain standard

analyzability – The standard set itself should be machine analyzable. It’s either THIS or THAT, not MAYBE, SOMETIMES or OFTEN. 😉

changeability – The standard should be easy to change and changes to the code, by a new standard, should be easy to do as well.

My list of tipps should help you find a standard and keep it up.

1. They apply for everyone in the team.

No developer, in no situation should be exempt of the conventions. It might sound dogmatic, but this is a rule that applies for everyone. Even for $pointyhairyboss, if he is still pushing to the codebase.

2. There is no perfect convention for every given project.

I see this discussion revolve again and again: Developers looking for “the standard”. Where do I set my braces, which kind of whitespace do I use? Please tell me. I am to smart to look for THE standard, give me any standard and I will adhere to it.

3. Automate checking

No one wants to check, what could be millions line of code, by hand ot just looking at the code. Tools can help you with that. What ever you decide, try to create an automated check for violations and make this one available to all the developers working on the software.

4. Have examples and explanations

Coding conventions may seem to be a very subjective thing. But when explained properly, in a markdown, text file or wiki page it gets easier to accept to code by standards that are not your own (yet).

5. Your codebase must have 0 violations at all time

With command line tools and checking before you push stuff to a repository, this should be easy. There might me exceptions, but make sure you group them into modules exempt from the checking process or make other wise sure the initial thought of a same structured codebase does not get undermined. See 6.

6. Change if required

If the rules don’t fit, change them to better ones. Migrate the module to the new rules. Do not only change the rules. Change the code as well.

7. Everyone is responsible not only for his own conventions

Where ever you are in a pice of code, you are encouraged to fix any violations or add a example here and there. Didn’t you find enough comments? Cool, add some. Something is formatted wonky? Fix it! Somebody used spaces? Change it to tabs if the spec says so. Where ever you are in the code, a OneButtonTest will be a good practice to look at.

8. Make conventions per module, not per team.

Different modules might be written in different times and adhere to different standards. So splitting up parts of your software that follows a very different style might be reasonable. In Javascript and a browser environment you would use tools like component and bower to get things back together. Small modules help you maintain different styles. Think about it: If you have a long running project, it’s very likely you will have more than one standard. And small modules allow for different ones in different occasions and situations. One argumentative nail in the coffin of Big ball of mud designs G*

TRAINING: Another research task was on the basics of lean. I am hammering together a workshop on the Lean Basics and Kanban, so I needed all in one Place on this Cheatsheet. I need to recreate this with CC.

NEWS: Mytaxi was sold to Daimler. I am applauding the team + Nic Mewes and Sven Külper. A german startup dream come true I guess. That is something that other big german funders never did: Building something original, as one of the first movers, not cloning anything. You better worship that ;))))

I am a big fan of Grunt.js but I must admit: Gulp is awesome. I got really tired of big configuration files that seemed to be a mistery after a while. You might wanna read the
“quick intro to gulp.js” and give it a chance. You will not regret it. Lean and Mean I say.

I think I will try this. Using this one would end up with a recreatable environment, that 5 years later, everyone who wants to use the software, can recreate. It’s not ma a magic bullet, but I think it could speed up a lot of things heavily.

A day setup can save you a lot of worries. The less you depend on things made “by hand” and if you put something aside for a while, you will be able to return easily.

Reading the C2 wiki, in the context of extreme programming, a bridge thread is

The first iteration of an XP project should aim to be a BridgeThread : an end-to-end application, which does not have to contain much significant functionality, but from which the rest of the system can be hung. The BridgeThread determines the system architecture. In this XP works much like a weaving spider

Bridge Thread

The bridge thread tries to answer a question that is posed very often and I do hesitate to give an more specific answer than: “Just pick ANY, it will be a long effort to build this product and in X months, what does it matter with what we started”.

The idea of the bridge thread tries to answer the same question. Some ideas (far from complete) regarding the Bridge Thread

Make sure it is as independent as you can from other stories. It is the beginning, so one of the primary concerns, even more than in later sprints is: Deliver something.

Make it a core functionality for your product. If you write a app that helps you getting a cab in a city: Do not make it the login. Try to be as close to the part that delivers the value to the customer as possible. Most likely login is not your main business case. (I have advised otherwise in the past … I changed my mind)

Don’t take any shortcuts. Use a small story, but implement it completely

Don’t sweat it . It is sprint 1. Getting shit done is more important than getting a lot of shit one. Not producing any bullshit is even more important

You will have to set up a lot of stuff: CI, automated tests etc. Did I vote for a small Story already?

All layers included. use a story that needs all layers of your architecture.

Your estimates are most likely not really good in the beginning. You could pull a story, implement it and pull the next one. Story by story. This is how a Kanban team could approach such a problem.

Don’t commit to a sprint goal .. just try. There is no real way to commit to something you don’t know.

Have everything extra-ready. All assets. Maybe a DB design. Architecture? You should have a good Idea of this. As much as I love emergent Architecture and Design, just don’t try always when the last responsible moment for that is. One or two extra hours invested wont hurt. Beforehand the sprint. Not 20 minutes before you start the story.

Try to hammer a estimate in SP on the Bridge Thread anyways. And Re-Estimate in later sprints. This way you can make sure, that the learning, that took place in the first sprint lands in later sprints.

Do you have more hints what to choose for starters in bigger “Projects” or at the beginning of a new Product or Codebase? Please share them below.

This was written a while ago. It proved valid as a guiding document in how to organize self-employed work by providing a manifesto instead of “hard rules”. So if you want to know, why I changed my Bio status to “Funder/Trainer” instead of “Looking for a Job” (No that I don’t, but I am not the kind of guy to sit tight and wait – So why not create a well crafted business here):

This might be the first post of a few that try to explain this move, it’s implications and the funny stories alongside.

Every project worth doing has a vision, and someone who’s championed that vision and fought for the budget. That person is the primary stakeholder. (This person is the real product owner; anyone else is just a proxy with a title.)

In order to achieve the vision, a bunch of other stakeholders have goals which have to be met. For instance:

The moderator of the site wants to stop bots spamming the site.

The architect wants the system to be maintainable and extensible.

The users want to know how to use the system.

These goals are tied in with the stakeholder’s roles. They don’t change from project to project, though they might change from job to job, or when the stakeholder changes roles internally.

Within a project, we deliver the stakeholder’s goals by providing people and the system with different capabilities. The capabilities show us how we will achieve the goals within the…