Dissdent Trainings – Preamble

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.

Btw: The thing has a name: Dissident Trainings and a github account

Goals vs. Capabilities

Liz Keogh, lunivore

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…

View original post 327 more words

So that the crazy ones don’t forget

Here’s to the crazy ones.
The misfits.
The rebels.
The troublemakers.

The round pegs in the square holes.
The ones who see things differently.
They’re not fond of rules.
And they have no respect for the status quo.
You can quote them, disagree with them, glorify or vilify them.
About the only thing you can’t do is ignore them.
Because they change things.
They push the human race forward.
And while some may see them as the crazy ones,
We see genius.
Because the people who are crazy enough to think
they can change the world,
Are the ones who do.

Effective Meetings

A lot of people find meetings ineffective and boring. They feel forced into something and feel they are wasting their time. On the other hand we are working in teams. So getting together and doing something is just one part of the “Team Game” you are taking part in. It is not avoidable and certain stuff is just more effective in a group or must to be done with a group.

1. Invitation

Every meeting must have an invitation. This invitation consists of a Title and a Description of the meetings goal(s) and contents. All the materials that are contents of the meetings should be added to the invitation in order to keep informal parts brief.

Optional: Add a time Schedule. Everyone will be able to know for themselves if the meeting is going into the right direction.

Example:

Decision on Meeting Rules

Dear team, I have worked on some meeting rules, that I want to install company wide. As you all know, I have interviewed people through out the org what they find acceptable and important in meetings as well as what they dislike. Out of this I distilled a set of X Meeting rules that I want to install as a general rule for everyone in order to make sure we dont waste time in meetings. 

Schedule 

• Welcome (5 min)
• Presenting the rules and the reasoning behind them (10 minutes)
• Feedback on the  rules (10 minutes)
• Break (5 min)
• Open Discussion – Mini Fishbowl (15 minutes)
• Voting (5 minutes)
• Closing (5 minutes)

You find all the informations that I gathered in the attachment feedback.pdf and the propose rules in rules.pdf.

2. Law of two feet

I got this from Open-Space.

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.

There are those meetings where you don’t know if they are effective or you can be effective in them. Just show up and leave if you don’t want to participate anymore. It is a powerful instrument to know that you can leave anytime. That is a bit like having a Safeword.

3. Time box

A meeting has a definitive time box. Make this timebox not exactly 60 minutes. Make it 25 minutes, 55 minutes (with a 5 minutes break after 25 minutes), or 85 Minutes (incl. 2 breaks). There are people, whose job it is to attend a lot of those meetings (Project Managers for example). Having and using up 60 minutes time boxes will make it virtually impossible to have one meeting after another. As soon as they leave your room at 13:00 and have more than 0 meters to move, they will be late. Same goes for resources like meeting rooms: They are used constantly, so the moment you are using you rtimebox of 60 minutes to a full extend, someone else will be late.

If the meeting can be finished early, fine. If it will take longer: Schedule a new one or do whatever it takes. But don’t break the time box

4. Protocol decisions. 

Decisions and important points must be documented. You are already sitting in a meeting with some people, using up a lot of working hours. If the content of the meeting allows: Use a public Wiki or folder in Google Docs (or whatever means you have in your company). The decisions made and feedback gathered is the value that was created with massive cost (8 persons *1 hr = person day)  so please be disciplined and write a protocol. Just one person in the room document stuff. If you are sitting in a room and don’t have stuff to document, you are probably wasting time anyways.
These protocols make a great and probably searchable “brain” and “memory” of your company.
There might be stuff that needs to be accessible for a smaller round of people. But be aware: ANY effort to  keeps stuff “private” or “secret” is a cost to the company.

Mail the link to the protocol to everyone who was invited (!). Especially the “dropouts”, who used the “law of 2 feet” or didn’t accept the invitation at all will need the information.

5. No devices

Apart from a laptop for the protocol and stuff that needs a projector I don’t want to see any mobile phone, google glass or whatever in your hands. Stop checking company Mail, Tinder dates, Facebook status or what ever you are doing. If you can’t give the meeting you undivided attention: Goto 2. You are disturbing the meeting. This accounts especially for bigger get togethers. How often did I observe 50 people in a room and minimum 10 are checking on their phones. Just for an experiment question these people privately about the contents of the meeting. You will find out that it is hard to memorize stuff when you are looking at the latest set of cat pictures.
Best thing is to get people used to the practice of making a staple of devices or put them all in a box.

 

I think this set of rules makes sense and I would love to get some more opinion on what other people use as ruleset for meetings.

The hen and egg problem

Imagine, you do a project with a UX guy. He is building the UI and expects an api while doing so.

The Problem

The API will change and new methods will be required as well as changes to “old” parts of the API. You are creative, right? Not everything is laid out in a User-Story, right? New features lead to new Ideas, right?

This leads to a slow down in the cycle. A Server is a different thing. If you want to release, you need a working server component and the client. In order to build a stable one, a defined interface in terms of a restful API would be a good start.

However, this Ping-Pong has a price: time.

Fake it, until you make it

A good Idea would be a API prototype, kinda easy to create and change. In a very short amount of time. Save the time for the concrete implementation of the API by using a mock System.

Interfake is a tool which allows developers of client-side applications of any platform to easily create dummy HTTP APIs to develop against. Let’s get started with a simple example.

Interfake on Github

Playing Ping-Pong with the UX guy just got faster.

Finding out (learning) the requirements of an API is part of the building process (Hello no estimates folks). The cycle time here, goes down (Hello Kanban Community).

Optional: You could create a bunch of tests for the mock API to code the real API against. This is not implemented (yet?). This would be a nice Artifact for a TDD process, right? Estimating a User-Story in a agile context that already has a bunch of ready made Unit-Tests is easy? I would think so.

 

 

 

 

 

How to reduce scope

So, you have the problem that you can’t meet the deadline? You added people and circulate ideas about cutting on quality in order to meet the deadline? What to do as a product owner in this situation? Your Backlog is big and  full of shiny stories, but you can’t build them all? It’s sounds a little receipish, but bare with me for a moment. Here is a genuine idea: Use a relative weight backlog! What you need:

• A set of user-stories organized as a relative weight backlog
• Stakeholders and Management
• A room and time (up to 3 hrs)
• Explanation of Value+Benefit, Storypoints and Risk
• Some techies around to answer stakeholder question
• A general estimation by the stakeholders, how much value in % they want to give up, in order to meet the deadline. It’s a estimate 😉
• A empty list of stuff to remove

What are you looking for?

1. Stories that have Zero Benefit and Zero Penalty. 

These should not be in the backlog anyways. If there are no dependencies to other stories, there should be questions about how the feature landed in the backlog in the first place. If you find dependencies, see if you can resolve them. Put all the items on a list.

2. Stories with low penalty or low benefit. 

These can  be discussed. piece by piece. Document every decision when you start closing the stories. You got the stakeholders in a room. They can make it happen. They can remove stuff from the backlog. Add stuff to “the list” while you have the discussion. Check on the dependencies.

3. Stories with high risk. 

Depending on how risk was defined  by the team, choose items with a lot of risk involved. Remove carefully. Risk often is related to security/scalability etc.: discuss carefully, be nice to developers.  On the other hand: There can be gems. Maybe a little value created is covered by a big technical risk.

4. Others

You got your own ideas about what should be in or not? Good: After a team already created a relative weight backlog in the first place every stakeholder and developer should have the right infos already. Add stuff to “the list” The work begins!

1. Check if all Stories are rightly in the list. If there is to much objection: remove it from the list, back into the backlog.
2. Sum Up the Value removed. Try to stay below the value that was initially agreed on.
3. Make a decision about “the list”: “If technically possible remove this stories.

Meeting ends here Now the Product Owner works through the list and makes all this sad calls to People who will not receive their feature. Sad Panda day. The team works through “the list” gives it a shot to kill the stories. There were those dependencies: you might have to write new stories. Be nice and give it an estimate. If you are not estimating … ok … you just have to be sure you are removing more than you add. The “agreement” Meeting  Back to the meeting room with team, management and maybe some stakeholders. The rest of the list is presented. This is what will be removed. The Team and PO present the changes that have to be made and the consequences that arise out of this. This is what will be added to the backlog. Let people ask questions. End the meeting (everybody agreed already to what will be removed) Remarks

• Don’t mix this up with a discussion about deadlines. It’s about removing scope. Have this discussion with a smaller group. You removed stuff, come up with an idea how much time that saved. So easy then.
• Yes, you have to have a relative weight backlog. The process of estimating it in the first place speeds up the sessions about removing scope.
• Doing this is a serious effort. Prepare the sessions, make everyone aware that removing stuff from a already filled backlog requires effort in the first place.
• I would estimate 3hrs for a 60 item backlog in the first meeting, the effort for the re-planning
• If you have your qualitiy requirements in the DOD or DOR, there is a lower chance for cutting of quality (win).
• Everyone took part on the decision, lower chance for bad feedback on the big project retro.

Social Human Architecture for Beginners – The Booklist

While giving the Talk about “all those soft skills”, I referred to a lot of Books and Papers that someone could read. I will list all of them now

Introversion / Extraversion

• WP

Maslow

• WP
• Motivation and Personality by Maslow

Non-Violent-Communication

• WP
• Rosenberg’s Book

Weinberg

• Egoless Programming
• Psychology of Programming

Conway’s Law

• WP
• How do Committees invent
• Mythical Man Month 

Tuckman

• WP

Daniel Pink

• AMP
• Drive

Flow

• WP
• Book

McGregor

• Theory X / Y
• The human side of Enterprise

I hope those are of value for everyone who participated in the talk.

The most import…

The most important thing I’ve accomplished, other than building the compiler, is training young people. They come to me, you know, and say, “Do you think we can do this?” I say, “Try it.” And I back ’em up. They need that. I keep track of them as they get older and I stir ’em up at intervals so they don’t forget to take chances.”[25]

Grace Murray Hopper (December 9, 1906 – January 1, 1992) was an American computer scientist and United States Navy Rear Admiral. A pioneer in the field, she was one of the first programmers of the Harvard Mark Icomputer, and developed the firstcompiler for a computer programming language.^{[1][2][3][4][5]} She conceptualized the idea of machine-independent programming languages, which led to the development of COBOL, one of the first modern programming languages. She is credited with popularizing the term “debugging” for fixing computer glitches (inspired by an actual mothremoved from the computer). Owing to the breadth of her accomplishments and her naval rank, she is sometimes referred to as “Amazing Grace”.^[6][7] The U.S. Navy destroyer USS Hopper (DDG-70) is named for her, as was the Cray XE6 “Hopper” supercomputer atNERSC.

 

Miško Hevery about Pair-Programming

Miško Hevery about Pair-Programming

Over my dead body!

Ever since I started with XP and especially Testing, there is a pattern evolving that works like this

“The Agency”

When I worked in a “Agency” and wanted to do Unittesting, TDD, Application Testing in order to achieve what you can achieve with it, my Bosses and Senior-Colleagues told me:

• Too much Time to invest
• Will slow down development cycles
• Not working in our specific environment
• But over there, in “The Big Enterprise”, they do it, the have the Use-Case for High Quality

I kept on babbling my TDD, Refactoring, fowlerish crazytalk and finally applied for a position with “The Big Enterprise”

The Big Enterprise

When I worked in “The Big Enterprise” and wanted to do Unittesting, TDD, Application Testing in order to achieve what you can achieve with it, my Bosses told me

• Too much Time to invest
• Will slow down development cycles
• Not working in our specific environment
• But over there, in “The Startup”, they do it, the have the Use-Case for High Quality

I kept on babbling my TDD, Refactoring, fowlerish crazytalk and our Team applied it (Kudos to my Boss who simply let us do it – Tank you Stefan!) and finally went to work in a startup

The Startup

When I worked in “The Startup” and wanted the Teams to do Unittesting, TDD, Application Testing  in order to achieve what you can achieve with it, my Bosses and Colleagues told me:

• Too much Time to invest
• Will slow down development cycles
• Not working in our specific environment
• But over there, in “The Agency”, they do it, they have the Use-Case for High Quality

I kept on babbling my TDD, Refactoring, fowlerish crazytalk and wrote this Blogpost 😉

There is NO alternative to high Quality

Over the last 13 years, the time I create Sourcecode in a professional environment, I have heard the same argument all over again and again. And I saw all of them failing with quality: Big Enterprise, The Agency, The Startup. They all told me the same Story. They ALL were WRONG. I realized one thing: High quality is nothing you ask your boss for, you do it, you don’t even get into the discussion if it pays off or not. Either the company is committed to high quality code, that steadily improves or it is doomed. Either the company knows science or it doesn’t . If it does, it will go for quality. If it does not, it is doomed. Like a cancer patient using Globuli and Crystals for healing.
Crappy code will fail your customers, your Business, your Shareholders, your Investors and it will fail YOU. Miserably, every day. And dear Developers and people around them: This is all your Responsibility. Every day and you can change it. Every day you can decide for Quality or somethings else. I realized this:

As a person, taking pride in my craft, using the tools that the modern development lifecycle provides, I have the sole Responsibility to work with these tools or walk away. This way or: Over my dead body.