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.
What we are ending up with:
Our current kanban board.
What we're not sure of yet (that we know of):
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.
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.
Only items on the backlog should be worked on.
#1: Who gets to add things to the backlog?
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?
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.
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:
- Research reporting tools to replace existing one
- Create sample report in BIRT
- Create sample report in JasperReports
- Add button to print report on Category screen
- Create final report in selected tool
- Create test cases
- Test case #1
- Test case #2
- Test case #3
- 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.
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.
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.
As promised I have uploaded my slides for those who wanted to review them closer.
In addition here are the Scrum links:
The Scrum reading list:
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).
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?
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!
|<< <||> >>|