Friday, February 15, 2008
But on what? On wine, on poetry or on virtue, as it suits you. But get drunk.
And if sometimes, on the steps of a palace, on the green grass of a ditch, in the lonely gloom of your room, you wake up, the drunkenness already abated or completely gone, ask the wind, the wave, the star, the bird, the clock, everything that flies or groans or rolls or sings or speaks, ask everything what time it is; and the wind, the wave, the star, the bird, the clock will answer: 'Time to get drunk. In order not to be the martyred slaves of Time, get drunk. Get drunk ceaselessly. On wine, on poetry, or on virtue, as it suits you.'
Friday, February 01, 2008
The Project Manager refused to commit anything to writing. No documents and no emails. If you emailed him a question the response was “coming right down”, if you cornered him in a meeting he wanted to talk 1:1 afterwards.
The problems started out small, the PM would start sitting next to a dev and having them make UI changes. He then moved to demanding larger and larger feature changes and getting upset at the large estimates.
Eventually the situation devolved into pure madness, with the PM blaming the developers for the fact the product didn’t match what he had been promising management. We finally reached our limit started brainstorming with ways to put an end to the PM’s refusal to commit to requirements.
I proposed solution that I later named Viral Requirements. The idea is actually quite simple, but the effect it had was amazing.
The first step was to setup a MoinMoin wiki and created a new WikiPage for each section of our application. Each WikiPage contained a table with the following columns:
This was a single, testable requirement. The rule was that each requirement was specific enough that it could be tested and could only have one possible valid result.
This was the current state the requirement was in. There were only three real states: Approved, Needs Approval and DEV. The DEV state was used when the Product Manager was too busy to look at the requirements and approve them. The idea was the Dev would give the PM 2 days to approve a requirement before he went ahead and implemented it.
The PM was required to put his initials and a date into this field when he approved the requirement.
So the workflow looked like this:
- Dev writes requirements in Wiki
- Dev emails PM with link to pages that need approval
- Dev waits for PM to approve (or after 2 days marks the State as DEV)
- Dev checks in code and submits to QA
- QA tests against requirements
- QA refuses to signoff on the change until all requirements are approved.
That last line is very important, because of the 'State: DEV' the development and testing could continue, but I could refuse to release the product until the PM signed off on all the requirements. This prevented the PM from blaming the team for any delays and forced him to digitally sign his name next to each requirement.
Within a month, all blame games had stopped and things were moving much smoother. Eventually the PM just rubber stamped everything anyway or had the Business Analyst review the items for him.
A nice side effect of this is the once word got out what we had to do to handle requirements, it brought a lot of scrutiny to the PM and how he was running things. When that company was bought out, he was let go.
He was a really nice guy, but he had obviously checked out a long time ago.
Wednesday, January 09, 2008
I had an interesting experience back in December. One of the Product Managers was responsible for taking an out of date spec and updating it to reflect the current product. She sent out a SharePoint link to the Functional Spec she wanted reviewed.
There were tons of errors and it looked like she had only made some cursory changes. I decided to give up reviewing the spec and I sent her a quick email that said her spec was still very out of date and that I only got halfway through the document.
Here is the email thread after my first email:
I’m not sure you read the right spec. I’ve now spent all day correcting issues in yours only to realize that the version TFS that I put up on Friday afternoon had more stuff in it than the one you commented on.
I double checked that I am using the correct spec. SharePoint has a history option for documents and you can see what changes were made, by who and when they were saved.
The link you sent ( also in this thread ) is the one I commented on. It was added to Sharepoint by you Friday 12/14/2007 at 3:26 PM.
I downloaded the file again (this time to a new location) and manually walked through every single comment I made to make sure the text I commented on was the same in the linked document you provided. Everything is the same.
I am not sure what document you are working on, but it is not in Sharepoint at the link you sent out. Maybe it is a local copy?
Please come see me if you have any other questions or need me to walk through what I did.
So this looks cut and dry right? I clearly documented the version of the document I was looking at and all my ducks were in an order.
The conversation continued, in email and then in person. She was positive I was looking at the wrong version and I was positive that I wasn’t. When I went up to her desk to walk her through what I did, I ran into a problem.
The SharePoint history for that document no longer matched what I had seen only 10 mins before. The 12/14 version I had referenced now said 12/13. This confusion only reinforced the PM’s belief that I somehow downloaded the wrong version of the spec.
I was baffled. I knew what I had seen, I had double checked. What could have happened? I went back to my machine and luckily I still had the SharePoint window open and I could clearly see that I was not crazy. In the following screenshot you can the same document (notice the GUID in the URL) had mysteriously changed dates and timestamp.
It took me about 30 mins to Google and troubleshoot the issue, but the conclusion we came up with was that she had checked out the document, made changes and never checked it back in. So when she sent out the link it still pointed at the old version.
This turned out to be a known issue/feature with SharePoint that has tripped a few people up.
This was a good reminder to me to always approach any contentious issue with an open mind. If you respect the person you are talking to, there is likely a good reason they have formed a differing opinion and you should always be aware that things my have changed, even in the time it takes to walk over to demo something.
Wednesday, January 02, 2008
My new company implemented TFS about 6 months before I took over the QA Department. Unfortunately I had no say in the setup and subsequent customizations that occured. While I am sure everyone had the best of intentions the end result was a nightmare.
The original plan was to take full advantage of TFS; Sharepoint, VSS, Iterations, Tasks, Requirements and Bugs. They were even going to migrate all existing requirements from Word documents into TFS and link everything up to Tasks and Bugs.
Sounds like a solid plan, with a little hard work and planning, what could go wrong?
Unfortunately this major shift in process was treated like a skunk works project. One QA guy put together a sample installation, got approval and then worked with the Dev team to set something up.
My opinion of the whole adoption phase was that everyone was focused on hammering out (on paper) a series of workflows that felt familiar to what they were used to using. And then when time was running out they tried to hammer custom workflows into TFS.
Here are some of the decisions that were made:
- Heavily customized the CMMI process template.
- All workflows modified
- Added new fields and changed the meaning of existing fields
- Created custom triggers to enforce a very complex 'Assigned To' scheme (Dev, QA , Business)
- Created a single TFS project, using the company name, then created sub projects (using Areas) under that one project.
- Placed all code under a single VSS branch, created one giant build for all code.
- Ignored the recommended SharePoint setup and created a custom hierarchy of projects to store documents in.
- After about 3 months of use they switched the layout around, so now there are ‘historical’ documents in an old area and newer documents in the new area.
Here is the current state:
- Product Managers pulled requirements back out of TFS into new word documents because TFS was too difficult to use.
- Bugs are tracked and assigned to developers using a spreadsheet with TFS IDs.
- There are functional bugs inside TFS with the custom 'Assigned To' workflow logic that was added.
- All of the default Reports were broken, new reports have not been able to be created due to the complexity of the changes.
- TFS is used only to store code/documents and file bugs. Requirements and Tasks are no longer tracked in TFS.
- Everyone thinks TFS sucks are are 100% resistant to making changes or trying to fix the issues.
So this is the problem that I have to fight the unpopular fight to fix. When I get some time I will blog about my proposed solution (I do have one that I am working on) as well as track my progress.