A while ago, I called for some participation on the state of our craft. I promised back then to present some intermediate answers in late January. Here they are.
Responses from the programmer and tester surveys
4
Category Archives: Scrum
Some surveys on the state of our craft
One of my colleagues made a claim yesterday which I would viagra to put some numbers on. I raised the question on twitter, and received suspicious answers about the numbers of my colleague. Please forward this survey to anyone you know who is programming: http://www.shino.de/programmer-survey/ It consist of just four question, so you should be able to answer them in a few minutes.
Over twitter I also received the feedback that things are worse for testers. I would like to put numbers on that as well. Therefore I also put up an equally small survey for tester: http://www.shino.de/tester-survey/ Please forward this survey to anyone in the software business that you know of.
From time to time to I will publish some of the results. I aim for end of January for the first set of data.
Lessons from complexity thinking
While Diana Larsen was in Germany in July she spoke about a course she was currently taking called Human Systems Dynamics. Since then some of my colleagues started to dive into it. So did I. I didn’t take the course, but decided to go for some of the books on it. The first one I came across is called Facilitating Organization Change – Lessons from complexity science, and deals with a lot of stuff on complexity science, self-organization, and how to introduce changes in a complex adaptive system (CAS). These are some of my first thoughts after finishing the book.
The case for slack
Some while ago, J.B. Rainsberger posted a case for slack, and that you might be sabotaging your peoples training. I think it was Kent Beck who pointed me to the self-similarity of nature in eXtreme programming explained. In this post I’m going to take a closer look on how we learn, and how nature is self-similar in this regard, and what we may derive from this.
Continue reading
Scrum Norris
Yesterday evening there was a thread of scrumnorris going over twitter. Since these messages were in German, let me translate them.
- Chuck Norris is ScrumMaster and ProductOwner – simultaneously.
- Chuck Norris can do 6-month sprints.
- Chuck Norris wears Timeboxershorts.
- Chuck Norris does not move story cards, he moves the taskboard.
- Chuck Norris does not estimate, he knows.
- Chuck Norris pairs alone.
- Chuck Norris starts project with a Roundhouse-Kickoff.
- Chuck Norris is allowed to appear late at the stand-up.
- Chuck Norris sits on the stand-up meeting.
- Chuck Norris has implemented everything at the planning meeting.
- Chuck Norris does not estimate user stories, user stories estimate him. (This doesn’t translate well.)
- Chuck Norris writes the code first, then the test.
- Chuck Norris is not afraid of bugs, bugs are afraid of him.
- Chuck Norris does not do Kanban. He does not know limits.
- Chuck Norris does not pull, he pushes.
- When Chuck Norris says “done”, then it’s “done”.
- Chuck Norris does not deploy, he develops on the production environment.
- Just Chuck Norris knows, that a real burn-down requires napalm.
- Chuck Norris has no burn-down chart. Around him everything is already burnt down.
- Chuck Norris answers just two questions on the stand-up meeting. Chuck Norris does not know obstacles.
- Chuck Norris does not prioritize the backlog.
- Chuck Norris takes two baby-steps at once.
- Chuck Norris does not use test-driven development. Chuck Norris always drives.
- Chuck Norris is the prioritized backlog.
Any additions?
Not a process
Alistair Cockburn told us about a research in the UK on Scrum. He pointed out to the student, that Scrum is not a process, but something different. This made me thoughtful and I decided to elaborate some more on the terms and reflect on the other Agile methodologies about it.