Guild Blogs

The guys from Stelligent have another great post. This time on Continuous Production, the next step after Continuous Integration.

We've committed to iteration-less pull based software development starting on Monday for one of my teams. A number of factors led up to this decision, not to mention the vast amount of discussion I had with my project managers.

The factors:

• Story size was difficult to estimate and kept crossing iteration boundaries.
• The programmers really didn't see the value of estimating stuff they weren't familiar with and in our planning poker session gave out lots of ? and 100 cards.
• I am looking for a good departmental metric for the rest of the company to see how development is doing and Velocity is always too abstract.
• We were spending to much time researching the time it would take to fix a bug that we weren't going to work on for several weeks.
• There was invisible work being performed.
• We had a tool (Rally) that wasn't really being used as intended.
• The scheduling process seemed overly complicated.
• We didn't have a great way to express the result of adding "one more thing" to the release.
• We are just about to get a true single backlog per product line.

What we are ending up with:

• A kanban board currently in the PM office, to be moved to the team space as soon as physical re-org is complete (~2 weeks). The kanban will have 4 columns: pending, blocked, in process and complete.
• A single department metric: throughput expressed as average days to complete a story.
• Limited work in process (WIP). We are starting with a maximum of 5 stories WIP and will experiment from there.
• Differentiating stories from support requests.

Our current kanban board.

What we're not sure of yet (that we know of):

• How many support requests in process (RIP) makes sense? 1? 5? 10?
• How the blocked state will get (mis)used.
• If we need to track the amount of time a story spends in the blocked state.

The kind of output I'd like to track.

Casie is one of my project managers who has a blog but doesn't post much. I'm hoping this change will cause her to comment more often about what she is thinking and experiencing as we move through the process.

References:

Lean Software

• Amit Rathore: Estimation considered harmful
• Amit Rathore: If estimation is harmful… then, what’s not?
• Peter Seibel: Software estimation considered harmful?
• The Poppendiecks: Managing the Pipeline
• David Anderson: Stop Estimating
• David Anderson: Agile Estimating
• Corey Ladas: Time-boxed iteration: an idea whose time has come and gone
• Alistair Cockburn: Are iterations hazardous to your project?

Estimation

• Mike Griffiths: Agile Estimation – Upfront Estimates

A good reminder

As my team becomes more responsive to the business needs placed upon it I realize that I haven't clearly communicated the guidelines I'd like to see in place and why I believe the guidelines are helpful. Here is a recent clarification I sent out (modified for a more general audience).

The Question: How do we know what to work on and what not to work on?

This question has come up a number of times in every project team I've ever worked on or with. It is a good question and one that deserves an answer.

Short answer:
Only items on the backlog should be worked on.

Follow-up question
#1: Who gets to add things to the backlog?

Answer: The
Product Owners have the right (and responsibility) to add or remove things from the backlog. They take input from many people outside the company, inside the company and inside the department.

Please, please, please do not interpret this as reason to not tell the Product Owner your great ideas or lobby them to raise or lower the priorities of certain backlog items. You have a unique insight to the products we create and we need your input.

The primary reason behind this approach is that we want to make it crystal clear what we are working on. There is a concept in astrophysics called "Dark Matter" which essentially is stuff we can't see but affects what is going on. Dark Matter in software development is all the little things that we do, but don't track that end up making the project late. The dark matter isn't necessarily "bad", we just don't see it until the project is late and someone asks why. The backlog and support queue are ways to "see" more of the dark matter.

Follow-up question #2:
What about issues that come from support?

Answer: Support
issues are just another form of work that may have a higher priority than what you are currently working on.

Note that all support issues are not created equal. If it is not obvious check with the Product Owner and the support manager to understand the urgency of the situation and the requested turn around time. If it is possible try to finish the task you are working on so you don't have to try and pick it up again in the middle later.

Currently we track these issues in the support queue and that is fine. Just be sure to assign the issue to yourself if you are working it. Your project manager may choose to replicate this information in the project tracking tool so that we have a consolidated place to review this data.

Follow-up question #3:
What happens if <insert executive here> asks me to work on something else?

Answer: It depends :-) You will get requests from people from time to time that aren't on the backlog. If you know the answer off the top of your head feel free to answer. Generally though please redirect them to the Product Owner (politely of course). Once again, the idea here is to make the work visible and the Product Owner needs to be able to help balance the workload against other existing priorities.

Follow-up question #4:
How do we schedule things like unit tests, JVM upgrades, product evaluations, build servers, and meetings?

Answer: These types of things are definitely required to build our software, but they are not typically backlog items into themselves.

These things tend to group in 3 categories: big technical changes, non-story related work and tasks.

Big Technical Changes tend to be things that affect the system horizontally, i.e. you have to touch almost the whole system in some way. Examples of this are significant runtime or database upgrades, new persistence mechanisms, new security models, etc.

Big Technical Changes in our future are things like migrating to Subversion, upgrading Sybase ASA to version 10, upgrading PowerBuilder to version 11.2, and migrating to Eclipse 3.3.

These happened infrequently (2-3 times/year), but have a potentially significant impact on the project schedule. Because of the possible impact Big Technical Changes need to be coordinated with the Product Owner in the form of a Technical Backlog which gets scheduled in the same way as any other backlog item.

Non-story Related Work tends to be things that help us get work done better/faster but is smaller in scope than big technical changes. Often these kinds of changes don't directly affect the code we ship to our customers.

Examples of this are improving the build server, upgrading Bugzilla and testing framework improvements.

These happen about once per month and can be a separate backlog if big enough or can be attached to a story as a task.

Tasks are the technical things we need to do in order to complete the backlog. The Product Owner owns the backlog, but the task list is owned by programmers, testers and writers. The Product Owner doesn't muck with the tasks and nobody else mucks with the backlog.

Tasks may directly or indirectly affect the code we ship. For the most part I expect everyone has a basic handle on what tasks are.

Example Backlog:

As a Manager I want to Print the Category Setups so I can refer to them when I am not at the computer.

Tasks I'd envision:

1. Research reporting tools to replace existing one
2. Create sample report in BIRT
3. Create sample report in JasperReports
4. Add button to print report on Category screen
5. Create final report in selected tool
6. Create test cases
7. Test case #1
8. Test case #2
9. Test case #3
10. Update documentation & help files

Researching the tools are tasks in the first report that is worked on. Also note that tasks 2 & 3 probably didn't exist until #1 was mostly complete, similarly tasks 7-9 and #6.

You can also see some of the elements of "Done" that we defined in the past.

There aren't any meetings, unit testing, refactoring, compiling, designing or breathing in the task list because those are just part of the everyday life of creating software.

Summary

Only work on tasks related to backlog items in the current iteration and urgent support issues. The Product Owner manages the backlog, everyone else manages the task list.

Thoughts?

Are you or someone you know an expert in Sybase MobiLink? I am looking for someone to help us out by doing some knowledge transfer, performing a readiness assessment and assisting us in the deployment of MobiLink that underlies a new solution we are offering.

This will be a contract engagement that I expect this will start as a week of on-site time followed by additional occasional consulting.

Contact me if you are interested or have questions.

I gave my Intro to Scrum talk for the SAO Dev SIG today. There was a great turnout with good questions and a range of experiences. An added bonus is that they recorded it for what will most likely be my first podcast. More info when it becomes available.

I also promised I would make the presentation available here.

The reading list is itemized in this previous post.

I had a great time at the PADNUG meeting last night. A fairly large group (40-ish) showed up even though DevConnections and P&P are going on this week.

As promised I have uploaded my slides for those who wanted to review them closer.

In addition here are the Scrum links:

• www.mountaingoatsoftware.com/scrum
• www.scrumalliance.org
• www.controlchaos.com
• http://groups.yahoo.com/group/scrumdevelopment/

The Scrum reading list:

• Agile and Iterative Development: A Manager's Guide
• Agile Estimating and Planning (Robert C. Martin Series)
• Agile Project Management with Scrum (Microsoft Professional)
• Agile Retrospectives: Making Good Teams Great
• Agile Software Development Ecosystems
• Agile Software Development with SCRUM
• The Enterprise and Scrum
• User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series)
• Lots of weekly articles at www.scrumalliance.org

The tools:

• Unit Testing: NUnit
• Unit Testing: MbUnit
• Productivity: Resharper
• Builds: NAnt
• CI: CruiseControl.Net
• CI: Draco.Net
• CI: Hudson
• CI: FinalBuilder
• Test Coverage: NCover
• Dependencies: NDepend
• Duplicate Code Detector: Simian
• Mocking framework: TypeMock
• Mocking framework: Rhino Mocks
• Mocking framework: NMock
• Test Automation: Selenium
• Test Automation: WatiN
• Test Automation: Watir

It was one of those wonderful home IT support issues that show up from time to time.

My Mac suddenly stopped sending mail. It could receive mail, but not send. The message was: "This message could not be delivered and will remain in your Outbox until it can be delivered. Sending the message content to the server failed."

Odd things have happened with my hosting provider in the past so I just decided to wait for a day to see if things would clear up.

The next day nothing had been resolved and my wife had resorted to using webmail to make sure the mail was getting out. Webmail was working so it seemed unlikely that the mail server was down, just my communication over port 25.

I look around in my mail settings and tweak a few things with no change in behavior.

I little googling later and it turns out that some ISPs have been blocking port 25 to try and help with the spam problem. At this point we are way beyond what mere mortals should be worried about. I can't imagine working through this with my mom over the phone.

I started poking around on Qwest for information regarding blocked ports, but didn't get far.

Back to Google and I come up with this post on Mac-Forums: OS X Mail will not send replies

The thread meanders a bit, but the meat is in post #7 by DarthMoops:

Hey, I was poking around on the Internet some more. It looks like many have had Mac Mail troubles with Verizon. The following seems to have fixed the issue (so far).

http://expertmacintoshconsulting.com...;id=34;lang=en

Go to: Apple Menu > System Preferences > Network > Built-In Ethernet > Ethernet TAB > Configure/Manually > Max Packet Size(MTU)/Custon > set to '1492' > Apply

The referenced site seems to have disappeared but to my amazement changing the MTU from 1500 to 1492 solved the problem!

This is so obscure I can barely believe it. There were other site that referenced this change, but most had to do with wireless connections, whereas I am hardwired.

If being a geek wasn't your thing and you don't have a handy geek laying around (like my wife does) - what do you do? Drag your computer back to the store? Call the Geek Squad? Pave your system? Get a new computer?

What is a normal person to do?

https://db.sao.org/calendar2/event_description.htm?eventID=11/28/07

iCal

A very nice woman (whose name I can't remember - sorry!) drew this for me during my SAO QA SIG talk.

Notice the signs the testers are carrying, these were points from my talk, so I know she was paying attention!