Category Archives: XP

My view on the current state of Agile

Stick along long enough in software development, and you may have come along the ride for Agile software development practices, methodologies, and/or frameworks. Stick along long enough in that community – ok, that might be a reach too far, given that community only exists about 30 years or so. All of the above said, I notice some developments lately around the term Agile, and need to get my thoughts down. Not that I think I have a particular relevant perspective to start with. But maybe I can offer some perspective to one or another reader.

If you know me, you probably know that I have a tendency to look back on where did we come from to better understand things happening in the present. If you are not that kind of understander, maybe this blog entry might not be for you. So, be warned before moving on.

Continue reading My view on the current state of Agile

“Our release process pains us”

This week I had a conversation with several coaches at a client on something I consider pretty basic Agile knowledge, actually. To collect my thoughts together, I think it would be good practice to write all of them down for the time being. The topic at hand deals with test automation and enabling release-at-will through a zero-bug policy and how to get there. I think it’s going to be a brief blog entry, but fear my thoughts might run away there. So, stay with me.

Continue reading “Our release process pains us”

7 Zero-order measurements for agile projects

About two years ago I read Quality Software Management Volume 2 – First-order measurement from Jerry Weinberg. In it, he explains the differences between first-order and second-order measurements. The latter is a replacement measurement. Instead of measuring the thing, we measure something that we substitute for the thing that we are measuring. For example, measuring code coverage usually is a second-order measurement for test quality. It does not really measure the quality of the underlying tests, since you don’t know how many assertions lie behind the covered lines of code. In the same book, Weinberg also provides the concept of zero-order measurements for projects. A few months ago I was surprised that these seem to be focused on traditional projects, rather than agile ones. Since then I decided to come up with zero-order measurements for agile projects. So, here are some of the things I look for when entering a new client or company.

Continue reading 7 Zero-order measurements for agile projects

Tell a story at the daily standup

Yesterday during my keynote at the Agile Testing Days 2012 I said I see a lot of standups, where testers report on their yesterday’s work in the following way:

Yesterday I tested the thing with the stuff. I found some bugs, and filed them. Today I will test the foo with the bar.

I think this is horrible test reporting. While concluding the fifth beta of Elisabeth Hendrickson‘s upcoming book Explore it! I found a few more hints in the same direction. On the same line I will relate good test reporting during the standup to what for example Michael Bolton talks about when it comes to test reporting – we should tell three stories during test reporting:

  • a story about the product
  • a story about testing
  • a story about the process
Continue reading Tell a story at the daily standup

Some surveys on the state of our craft

One of my colleagues made a claim yesterday which I would like 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.

A week with Kent Beck

In November I had the opportunity to stay a whole week with Kent Beck. it-agile GmbH invited him for two courses – Responsive Design and Advanced TDD – and one workshop to Hamburg, Germany, and I took both courses and the workshop. Today I was contacted by Johannes Link who was surprised not to find a write-up of this week on my blog. It turns out somewhere during the past year I have turned into a reporter. So, here is my summary from what I could get from my notes. Initially I planned to write it via email to Johannes, but then I though why not share those comments on my blog. Maybe others are looking forward to it.

Continue reading A week with Kent Beck

Software G Forces – The Effects of Acceleration

At a local talk in Hamburg, Kent Beck talked about G Forces in software, and what effects acceleration of the software process has. With regards to Continuous Deployment he talked about scaling up the deployment cycle from annually to a deployment cycle within minutes.

Continue reading Software G Forces – The Effects of Acceleration

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?