Comments for Stephan Schwab

Comment on A Real Pickup Truck by Joel Helbling

Joel Helbling — Fri, 27 Jan 2012 19:23:50 +0000

Nice truck!

Comment on Max the Haflinger by The young not always do as told « Stephan Schwab

The young not always do as told « Stephan Schwab — Thu, 05 Jan 2012 01:22:33 +0000

[...] things they are being told. Usually they try to ignore instructions and get away with it. So did Max, the Haflinger, this afternoon. I took him out of his stable and started to walk him towards the [...]

Comment on Cucumber: When Programmers Have a Dream by Randy A MacDonald

Randy A MacDonald — Wed, 07 Dec 2011 19:12:28 +0000

Check out thre June 27 entry here: http://aplxp.blogspot.com/ talking about how APL seems to have covered the customer interaction problem.

Comment on Leaving Panama by CaDs

CaDs — Mon, 05 Dec 2011 10:08:21 +0000

I’m sorry to hear that the rainforest farming didn’t really take out.
Can’t really say than I’m surprised, some how I saw that coming.
I guess that there is a lesson to be learned there, and I can say I also learned mine.
I’m sure you’ll do great things wherever you decide to move.

I wish you luck Stephan, and thanks for everything you teach to me :)

Comment on Focus on making the commitment leads to low quality code by Bob Allen (@CuriousAgilist)

Bob Allen (@CuriousAgilist) — Thu, 13 Oct 2011 20:40:53 +0000

The first paragraph seems like such a hopeful beginning (pairing, small stories, cross-functional: goodness all around), and then … red-flags-a-plenty start showing up:
1. “They expect the project team to provide a fully estimated and fine grained backlog for the scope of the whole project before actual development work begins” is a obvios problem. T-Shirt sizing comparative estimates should be sufficient for anything beyond the next two sprints. Doing sprint planning estimates in hours (or even in NUTS) should bring the needed level of detail to the surface at the appropriate time. If NUTS is used, then observed actual hours (after the sprint) compared to NUTs will determine the ratio of one to the other, thereby providing a “velocity” as the basis of future projections.

2. Performance reviews based on making commitments and “There is fear”. Yeah, duh. A minor adjustment to the planning session: re-estimate and ask team for a thumb vote on one-story-at-a-time. As soon as the team is unsure if they can commit, then cut it off, the team is done. Use yesterdays weather id put a cap on what they are allowed to commit to (i.e. what the team actually delivered in the prior sprint). There must always be headroom for what is learned during the iteration. The team can always agree to accept an additional story during the iteration AFTER they have established that they have excess headroom.

3. “The capacity is determined by how many team members are available during the iteration.” Hmmm. No dedicated team(?), -or- is this just taking into account things like time away from the office? If it’s the latter then OK. If it’s the former, then I would guess that team “norming”/cohesion is lacking or non-existent.

4. “..discuss the story briefly and then the programmers go off to implement it while the tester prepares or refines Cucumber scenarios..”. Ping-pong pairing between developers and/or dev+QA for ATDD would create much greater cohesion on the team. Which leads me to the last point…

5. The word “refactoring” never came up. Perhaps it was to be assumed based on the mention of Cucumber, but it’s apparent absence is seriously diluting the value of pairing (real-time code review).

6. I lied, one more thing: retrospective was never mentioned. This is where the quality issue and the accumulating technical debt should be surfaced.

The company -is- accumulating technical debt. That much is clear. Since this doesn’t sound like it’s a lean startup where some technical debt makes sense (because a lot of what gets produced is throw away to test the market), then I’d say this one needs to be reined in. Focusing here will expose the rest.

The smell is that of veneer: an Agile veneer (“aren’t we cool, we do agile”) over a waterfall mentality. I suspect the adhesive may no longer be holding.

Comment on Cheap programmers on a ship anchoring off the coast of California by Burchard

Burchard — Fri, 30 Sep 2011 07:49:43 +0000

I ltirelaly jumped out of my chair and danced after reading this!

Comment on Focus on making the commitment leads to low quality code by Raj

Raj — Sun, 07 Aug 2011 21:52:45 +0000

Agreed that this is a potential pitfall where any organization that thinks it has a concrete schedule based on product back-log story point estimates or even estimates of hours for tasks could face. If developers are told that they will be held to “estimates” then there is little incentive to spend time in “mutual problem solving” or fixing design smells once the iteration has started. It is so important to realize that the essence of agile is to constantly adapt. Teams sometimes have to adapt to improve design or code quality as issues can pop-up mid-sprint. This could mean that the original estimate is no longer valid and delivery of the story is going to get delayed.

Comment on Estimation creates silos and prevents teams from developing solutions by Raj

Raj — Sat, 06 Aug 2011 20:47:42 +0000

An excellent post. A very accurate description of the pitfalls that “scrum” teams sometimes face in the face of project management requiring detailed estimates for the project.

Comment on Focus on making the commitment leads to low quality code by Stephan Schwab

Stephan Schwab — Tue, 19 Jul 2011 04:04:24 +0000

Actually the team has been asked to re-estimate the backlog already, because the estimates were seen as to high.

Comment on Focus on making the commitment leads to low quality code by Stephan Schwab

Stephan Schwab — Tue, 19 Jul 2011 03:17:23 +0000

Case study format of sort – yes, that’s what I had in mind. It’s pretty rough and my very first try at this. Do you think that might be useful?

I am putting emphasis on professional behavior. Not writing clean code will create problems for the organization later and as a professional I have to stick to proven practices regardless what outsiders (outside of the profession) tell me.