Sebs on Conferences

Flames small, fast

Posted on January 5 2012

Black butterfly

Posted on January 5 2012

@321Heinz presented me with a challenge:

For the last days you are remaining in this company you are required to approach one colleague only in a non violent way.

I extend this challenge to all colleagues and I am very keen to see the result, since the first attempts have been very successful.

So lets show some empathy and give it a try ;)

Posted on July 28 2011

Mauritius writes in his blog about the Reasons why Scrum will never work. He tries to take the devils advocate position.

http://maurits.wordpress.com/2011/07/13/why-scrum-will-never-work/

I think the complete post lacks the learnings of the last 10 years so I want to respond humbly to his inquiries ;) (and have some fun in the process)

 

Reason 1: the cornerstone of Scrum is about trusting people. Creating a safe environment so that we can be open to each other, learn from our mistakes. And all that other touchy-feely hippy back to the 60′s stuff. That is not going to work! Did you notice my disclaimer when I started this blog? I had to put it there because quite a few people read my blog, including customers and my boss. There are a lot of pointy haired bosses out there (oh no, another disclaimer: by boss isn’t one, he is a nice friendly guy, bla bla bla). This world is full of alpha males (and females?) who are not at the least interested in you, your process, the outcome, etc. Being open is only going to hurt your career. Room for mistakes, taking risks? Don’t be naive!

The Book “Five Dysfunctions of a Team” highlights “Lack of trust” as the basis of a big number of other problems stemming from it.The Author says:

Dysfunction #1: Absence of Trust
This occurs when team members are reluctant to be vulnerable with one another and are unwilling to admit their mistakes, weaknesses or needs for help. Without a certain comfort level among team members, a foundation of trust is impossible.

This is pretty easy stuff and my comment on this is:

If you are working in an environment where someone pays you and stil is not giving trust you might wanna look for another job. Remember: the Jobmarket is a sellers market. ;)

Reason 2: according to Scrum ‘people do the best they can’ if you give them enough freedom. What the hell is this based upon? They don’t. They will probably do the least they can because in general most software developers are underpaid, especially compared to their managers. That’s why they want to become managers or software architects as soon as possible, since they can then still be lazy without anyone noticing and the added bonus that they are getting better paid.

It is not only giving freedom. According to a smart guy, named Dan Pink it is: Equal payment +(Autonomy, Mastery, Prupose)

• Autonomy - Freedom to work on what, how, where, when and with whom. You might wanna give as much freedom as reality allows.
  

When it comes to payment: If you have the feeling you are not equally paid in comparsion to your colleagues and the “market”: Ask for a raise so that you feel to be paid according to your expectations or change the  employer. But please: stop complaining, it wont help anyone. You might wanna think about your own laziness and if it attributes to the expressed wish to get better or equal payment.

You might wanna read the book http://astore.amazon.de/agiletools-21/detail/1594488843 from Dan Pink and enlighten yourself.

Reason 3: because of the previous reason we still have to put project management on top of Scrum teams, so at least it has some output. So this is probably going to be business as usual. Assigning tasks to team members, micromanaging developers, demanding progress reports, etc. All the usual actions to slow your team down as much as possible.

 

If the reason for project management ever was to use the stick on the developers, it was wrong in the first place. If someone is too lazy to do what he signed a contract for and needs so constant attention that a complete line of work is generated around him … there is a more substantial problem.

Reason 4: Scrum is just a process. I have seen many processes (like CMM which is nowadays called CMMI) and I have seen them all fail and leave a lot of frustrated people behind. So if you are stuck (like most companies) with a bunch of average people then nothing is going to change. Scrum doesn’t improve your software, good people do! And by definition, you don’t have those good people since you just have Joe Average (or worse) as a programmer because your company doesn’t want to pay a decent salary.

This constant believe in Joe Average is as wrong as all thinking that is in prejudices may they be around race, gender or your favourite MMO. Noone is average just because he is not paid enough, every human beeing is a special kind of mamal, individual, great and of endless beauty. nah .. ok not all but most of the are. And you know, you can select those when you hire people.

Reason 5: Scrum delivers ‘business value’. Well no, actually it doesn’t. For many reasons. The guys or girls that know about business are not going to be involved in your project. They like to lunch with customers, not work on this weird thing called backlog to explain a bunch of introvert nerdy software developers what to do. So your team ends up with a junior help desk employee as a product owner. And besides, your whole ICT department is a cost center anyhow. So don’t start about business value.

If you are working for a customer who is not willing to contrinbute more than just money: Get a new customer. You know, the project market is a sellers market: You are the seller. The customer is the buyer. 

Reason 6: an Agile team is supposed to continuously improve. That is why Scrum has retrospectives to see what went well, what can be improved and to define actions. Now do you really think people want to improve? First they have to think of possible improvement actions. Next they may even have to execute them, which might well take them way out of their comfort zone. People resist change, and therefor improvements. Your old working habits may suck, but at least they kinda work and it gets you through the day.

Improvement means getting things done easier. And in addition to it you might wanna read again

• http://astore.amazon.de/agiletools-21/detail/1594488843 (Dan Pink - Drive)
• http://astore.amazon.de/agiletools-21/detail/0749953357 (Seth Godin Linchpin)

And out of my own experience I have to add that it is the responsibility of teh person hiring to hire people who are able to inspect and adapt. The right persons improve and that is a majority of people, not a minority as so many management books tell us these days. Humans are delivered with apositive featureset and made bad by people not expecting any good from them.

Reason 7: the Product Owner focusses on the ‘what’ and ‘why’ questions, the development team decides ‘how’. Nicely separated so the team can go for quality and thus high velocity on the long term. However, this is not going to work. Your product owner wants this functionality right now and doesn’t care the least about software quality. Just deliver those features as fast as possible because there always is a deadline, promises made to this important customer, etc. And don’t think you can blow away this junior product owner, because behind him is this business manager ranked high in the companies hierarchy. You as a developer are just part of a cost center and probably going to be outsourced soon anyhow. Now how is that for motivation and trust?

A Product Owner that does not care about quality has no idea that in software the longterm cost in 99% of the cases are much higher than the initial development cost. If someone spending a lot of money in development is in charge and has no idea about this face, you better leave the project/company. Why? Your boss has NO idea aka is not well educated enough to call the shots in a software project.

Reason 8: my previous point was about quality. There is some evidence that pushing productivity lowers the quality of software. On the other hand, when you focus on quality, you will get higher productivity. However Joe Average programmer doesn’t care about software quality. If the quality is poor, developing some piece of software takes more time, but why care? He is getting paid between 9 and 5. The project manager (or Scrummaster!) will take the blame for missed schedules. Even worse, if this developer is hired from another company it is in his (and his company’s) interest to stay as long as possible. So this all means that your productivity in Scrum isn’t going to be the least bit higher than with any other method.

No comment on this amount of generalizations and wrong things, go buy a better book with jokes please.

Reason 9: “yes, but if we only build the necessary features, then at least we will have a lower total cost, right?” It never stops to amaze me how naive people are when they say something like that. You don’t build necessary features. Most of the time you are on a fixed-price contract for a major banking or insurance company. Or even worse: a government contract. They have selected you because you offered the cheapest bid (which is pretty naive in itself) but they are going to make sure that you will deliver all the requirements they have stated up-front. Of course at least 50 % of these requirements have no business value at all, but hey, you aren’t going to fool the project manager that handles the project from the customer side. He is an alpha male and you are going to deliver that last bloody feature as well!

Do not do fixed price/time/featureset contracts, this is what I learned when I grew up. Leave this to others who have lifetime to waste.

Dear Mauritius: Your black hat is very old. There is no doubt that the Internet is full of FUD, but just repeating old prejudices is not going to make anything better.

Posted on July 28 2011

Peter roessler strikes again ;)

321heinz:

6-3-5 Brainwriting is a Brainstorming method that generates 108 different ideas or views for any topic within 30 minutes.

This is how 6-3-5 works:

1) Choose your brainstorming topic/question

2) Prepare the sheets with the topic/question and a table of 6 rows and 3 columns (see image below)

Posted on July 15 2011 with 7 notes

I proposed talks for the Ale2011 Unconference in Berlin, September 2011 and there where some questions raised. I will post my proposals here and try to answer the questions upfront. Maybe this will create a little new momentum to get people to rate them, improve the proposal and answer open questions. 

The Agile Meme, far beyond survival of the fittest

Agile Software development has changed the way we work and is still doing so.

The ever changing and evolving forms of “New ways we work” could be seen as memes or “an idea, behavior or style that spreads from person to person within a culture”.

Looking into the theory behind memes can help us understand how to develop and spread versions of agile methodology at workplaces and ease the adoption of Scrum/XP in our environments.

Topics:

What is a meme and why is Agile one.

The 7 forms of meme replication and how they appear in agile development environments

• Quantity of parenthood
• Efficiency of parenthood
• Proselytic
• Preservational
• Cognitive
• Motivational

We will have a look into the appearance of these meme replication forms in your organization and how you can use this angle to review your own actions as a person changing an organization.

Questions

Q: Memes are a really important topic. I love the work of Julian Everett in this space. Would be useful if you could list the seven forms of meme replication.

A: This was my main point from the beginning on. I now state the forms of replication in the Abstract.

Q: I am not sure whether this will give me new insights that can be really useful for me.

A: As soon as you know how exactly the spreading of such a cultural message or idea affects the persons/teams who are confronted with it you could use the contents of this talk to “debug” your interactions with them to be more effective.

History of Agile

The methodologists seem to rise and I suppose they are somewhat right. From the early days when we used things like the V-Model or the Waterfall a lot of things happened in Development Space that tried to:

• grow the rate of success in projects
• use wisdom of the crowds
• simply result in more enjoyable jobs
• get stuff delivered bug free

But all that started way before we even thought about software development as it is concluded today. We will have a look into the timeline from 1950 to now and checkout who and what influenced the ideas and beliefs of people that tried to do things better, built and changed the software development space.

Questions

Q: I don’t see how this can be viewed as a practical experience. Maybe if you could provide more information on how this talk can provide practical insights that can be used on our current situations I’d be more interested. 

A: For years I had the wrong impression that Agile/Iterative Development was kind of a modern response to heavily engineering influenced methods (aka waterfall) that where not applicable to software development. Oh boy, was I wrong. So I started to do some research and a totally different image unfolded in front of me. This contents really helped me to explain to people why iterations, pull and small dedicated teams work without always starting by citing the agile manifesto. The basics are going far beyond the manifesto and the early approaches to XP at Chrysler. If agile-critical people do not trust the content and creators of the agile manifesto, they might trust the guys who flew to the moon. Right?

I will now send a mail to all the persons who asked questions, maybe I can add some of the question/answer stuff to the conf. tool which seem not to be made for such conversations.

If you want to support my proposals: Everyone can register at https://www.conftool.pro/ale2011 and help me to get a speaker spot at this conference. Either by giving me an Idea how the proposals can be improved or just by liking it. I would really love to be there and exchange thoughts with the European lean/agile community.

Posted on July 5 2011

The coach camp, what to say about it? A little more happened than I had expected and in general I must say I am grateful I was accepted as an attendee to participate i this event. It was on the ending of the “Play for Agile” conference that it came to my mind that this would be the next chance in a realistic timeframe to meet all the nice people again and have a Openspace to communicate with them. After Play4Agile it turned out that my role is more and more turning to a coaching one or I could use the methods of coaches in my (work)life. According to the fast brainstoring I did in my hotel room I had the following topics I wanted to gather more Information on. 

• Insights on “Training from Back of the Room” technique, which is very natural for me now and where I wanted to deepen the experience and gather new Idea
• Get a Coach or Coach myself to follow the path I am on?
• How do FedEx or HackDays work
• Management and facilitation of innovative processes
• What to do with the new freedom in my worklife
• Non-Violent communication and as it turned out Group Dynamics
• More ways of using Post-Its and presenting the Post It Planning
• Techniques to relax my overly excited/energized mind at night

It’s so easy to write that very transactional list of thoughts down after the event, not all of this was exactly in that terms on my mind. All went well, the coach camp had a more exactly stated meta topic (fire, keeping the inner fire burning) which resulted in some comments about tree hugging. I don’t know what to say, beeing one of the critics on that overall and overamplified theme, now sitting in the train to my home I can say it worked and maybe I was wrong.

Beeing at the second Openspace in format conference I had a easier approach to all of it. For example I knew when it was time to take a break and take the chance to walk in woods or simply powernap. It can’t be overstated that the “energized work” over a day contains some challenges for the mind and body that only can be adressed by using the law of 2 feet and some rest. Since the list contained some topics that required me to work with some challenges my personality obstructs on me and my environment, all this turned out to be very emotionally touching. I really must say that my peergoup absolutely helped me through one or the other problematic processes and (again after p4a11) gently helped me to emotionally survive the moment where I for example realized my fallacies in communication (or started to). There is no way to make up an amount of money that could pay for that experience and was way out of bounds with all the other conferences I attended this year. As good as all of them might have been, this was outstanding and is only comparable to Play4Agile, but still a class of it’s own.

So I feel oblidged to share the insights I gathered.

Back of the Room Technique

I think I started out good and now it’s time to walk that path. It’s one of the best training techniques I have encountered and I should focus to make sure everything is applied correctly. I need to acknowledge I am at the beginning of that journey and a special shout goes out to sergey for challenging my stance of beeing receiver of information partly and not only the facilitator. Maybe I broke some rules of facilitation with that behaviour, but I feel like I need to observe this and further experiment.

Get a coach or Coach myself?

Last week someone told me I should consider personal coaching to be more effective with what I do. It turned out that I will not do it for several reasons and futher go with networking. Some of the reasons: Who the fuck do I think I am I need something like a personal missbehaviour corrector? I would feel like a spoiled kid, and considering the amount of coaching I can receive from the people around me and at events like #accde11/#p4a11 I should be fine. Since my listening mode is broken sometimes, this is the main reason I do not get good advice in my brain. Another one is that people at such conferences strat seeking my advice (WTF?) and I am better off with giving and taking than with paying and taking. So dear environment, please bear with me. I decided to network further, and explore that path maybe occasionally visiting a specific trainig (group dynamics and non-violkent communication)

FedEx-Hack Days
Yeah, the dutch saved my life again. A very humble and nice fellow development guy explained FedEx Days in his company and the group came up with a lot of good ideas of fedex days. I was suspecting that there was a chance i’d spoil the session with too much activity and input from my side, so I decided standing on the side and clustering the information that was flowing though the room and simply enjoyed listening to the concrete and very competent advice. Funny thing is that some people thoght I facillitated the session which I didn’t, at least from my perspective, I just stood there and wrote post-its, added some content if I liked to and oserved the scenery. I got enough information on planning a FedExDay and providing it to @Bibliothomas so he can make it happen at our company.
Management and Facilitation of Innovative Processes
This is more complicated, but I got more practice in Systemic Design, Infos on the roles (which I had pretty much ignored to that point) and a little new Activity called 6-5-3. Lots of Infos gathered, we will see how far I will get this time on work with this. This is where I am a aboslute newbie. Sven Tiffe and LeiderLeider turned out to be absolute funny partners to work with.
Non-Violent Communication  and Group Dynamics
Great Sessions with exactly the input I needed. Both absolute weaknesses of me and so these where the sessions where I was emotionally and mentally 155% involved and the very polite way both presenters held their sessions contributed to the fact that I didn’t block mentally and got a deeper understanding why one or the other person that I would have deemed “overfriendly” are just approaching me the right way to keep me in “Social Connection Mode” in  conversation.The main Learning: Non-Violent Communication is about listening and Solutionbs in a Group are only 20% on a Content Level (Rest is Process and lots of Social). if I had read the book that @321heinz Gave me on non-violent communication I would have known a model for listening for months. This 2 Sessions triggered and are still triggering stuff in me, maybe a little more than I could take.
Post-It Planning
In the Post-It Planning Session I tried to show off the style of planning for the workshop in Amsterdam when I was late with planning and had to align the “Back of the Room” Activities to a whole dayy workshop and there was even a very small timebox at hand (I wanted to go to a bar and not waste a moment in the hotel). So far, the Session, from my Posint of view was to frontal and I still lack basic Skills with such 1 hr presentations to let people interact and still have a specific outcome (very stipud fears btw considering the room is full of people who knowhow to make outcomes sure). I likes it, the people liked it and what needs to be left to say: Those colorful stickies are warmers for most of the people. I learned over the day that I need to go with the bigger ones. ;)
Relaxation techniques
Over the last months, with travelling, ongoing change management stuff and still work at hand, serious sleeping issues arised. I simplky couldnt sleep and on #p4a11 it turned out that this was not only a sign of stress, second to that I adopted behaviours that simply made it more problematic to fall asleep. I got a lot of advice on techniques that help fast passing away to sleep and I will try them. But go out for a walk is a good thing however.
This was it …. but not … a multitude of things that happened outside what my little mind could come up with before the conference began. A thousand thank yous go to the organizers and the participants. This weekend was worth a thousand smiles and we all know that they are a currency of infinite value ;)
p.s. maybe more to follow

Posted on June 19 2011

Heimspiel at Homebase

Finally a Scrum workshop at the homebase. Colorful technique works here as well.

Posted on June 15 2011

So you are thinking of starting a new Thing and need to set up a infrastructure for a new XP Team that is distributed? Lots of Tools can help you.

Github

The Code needs to be somewhere, right? A small amount of money is required for your private repo. Giuthub offers a lot of tools to help you in deployment or patching.

• SCM
• Wiki
• Bugtracker
• Stats

Google Docs Pro

A way to set up a organization with docs, email and so on.

• mail
• docs
• groups
• simple management

Mindmeister

Cheap online Mindmapping tool that provides functions not avail. in google docs

Cloud9

Online IDE with Teamcoding features that will help overcome distribution problems.

Posted on June 5 2011

nevver:

Dead at 62, Gil Scott-Heron

Very sad: Role Model, Voice of Truth, Inventor of Rap, Compass of Morale for the 21st century. Gill left us with important Heritage, now we are obliged to accept it and continue where he left us.

Posted on May 28 2011 with 850 notes