I am trying the all-in-one integration at Google+.   You can find my new posts at Geoff Corey's Blogger site and if you would like to circle me on Google+ and keep up with my latest posts.

It happens.  For whatever reason a release is blown.  Maybe it was an estimate too low, hardware failure interrupts productivity, team member sick it doesn't matter.   The release is not going to happen in the manner as it was planned.

Hopefully you are using an agile process such as Paceline, Kanban/Lean, SCRUM and detected the release is not going to happen early.   Unfortunately if you are using a waterfall development process it is likely too late and you will begin to see turnover as your team also knows it isn't going to happen and do not want to stick around for the death march.

So what is management to do?  You got your release manager or project manager showing the current projection of the release and there just isn't enough days?   Well the worse thing management can do is announce the  death march.   Visions of Bill Lumbergh peering over your cube wall with coffee mug in hand telling you that you need to work on Saturday and Sunday too will likely bring out the unmotivated Peter Gibbons in all of us.   It actually is dentrimental to the organization.  Not only will it result in demoralizing the team and likely increase turnover, it will also teach the remaining team members to sandbag the estimates.

The best thing management can do is hopefully be capturing week by week, retrospectives on how to improve the process, eliminate roadblocks.  Maybe you should do a software development eco-system assessment as an unbiased way of discovering opportunities to make a more effecient environment.  

So now your saying, "yeah, yeah, we did that and we still are not going to make the date!"  Fair.  Did you meet with the team to get their perspective on how to make the date?   Maybe eliminating or scaling down the solution to a tactical approach and do the strategic solution later?   Maybe adding another resource from an under utilized team can bring it in the date.   Did you look at your cumulative flow chart from you kanban tool and eliminate bottlenecks?   Maybe the team is unbalanced number of analysts, developers and quality engineers to have a good flow.

Lastly, did you go back to your customer and tell them to make the date you would have to cut scope?   Maybe the customer is willing to push the date out or cut scope to make a date.   If you are not communicating with the customer on a week by week basis this becomes a painful topic.    However even in fixed-bid projects I have negotiated the reduction in scope to make a critical date for the customer.

In short, the command and control days are over.  Simply saying we will make the date at all costs is part of dinosaur managerial thinking (or lack of thinking).   That is not managing, that is dictation.   Work together as a team with regular dialog with the customer and deliver business value frequently and you will be part of the success of the business instead of an impediment.

 

So, for the second time in my life it happened again.   Wife told son to change the oil and he went to one of those "oil change specialist" down the street.   So what happened?  They overfilled the oil and when we drove the car it blew the seals on the engine.   No point arguing with this particular quicky oil place, they will deny that it is their fault.

So the convienence of going to a shop that their only job is to change the oil is going to cost me $500 - $1000 in repairs because they cannot do the one thing they are suppose to do.

So folks, just go down to the local auto parts store and buy oil, oil filter, oil pan and a gas jug to put the used oil in to take back to said auto parts store and recycle.   Not only is it cheaper on the oil change, it is cheaper because you care about your car and won't screw it up.

So I was looking at the long list of agile tools and found TweetScrum specifically to manage the daily standup.   For distributed teams this is a nice way to get off the phone and document online the meeting in real time.    Funny that on my last project there was a team member that had this idea as well.   Proves my point that if you have an idea, likely there are 10 others with the same idea and if you have a short window of time to act on it or someone will beat you to the punch.   Which is a good case to do agile development.

Tweeting your daily standup in my mind has a few challenges:

• Statusing 140 characters at a time.
• Conversation / clarification is a bit disjointed
• Still need to get folks together to resolve blockers

So here is what I would use, Skype.   Skype is free and the Scrum Master or Cycle Advocate can define private chat rooms (invite,kick control) for team members.   I would define chat rooms as the following:

• <project name> - Standup
• <project name> - Deployment
• <project name> - Watercooler

The standup would be just that, standup status:

• What did I complete
• What am I working on today
• Do I have any blockers?

Deployment chat room would note the weekly deployments to a new environment and the watercooler can be for general discussion, cool links, general questions.

The beauty of Skype chat rooms is they will hold the messages for you until you login so you never miss a conversation.   You can setup seperate chats to work on particular blockers that come from the standup meeting or other collaboration.    You can do Skype to Skype voice calling and share your desktop screen to pair up on a particular problem.

While TweetScurm is a nice idea there are better tools for distributed collaboration out there in the wild.    What tools have you found that help with distributed teams?   I'd love to hear some other success stories!

We moved into this house 5 years ago.  It is now a 20 year old house and while we liked the location we were not hot on the kitchen.  

There were a couple of issues:

• Cabinets were painted with white latex and the previous owners cooked with grease.  The result was the top of the cabinet doors were impossible to clean.
• The layout was an L-shape and put the refridgerator in the corner.  This made it hard to get in and out of the refridgerator since we could not open the side door all the way.
• No undercabinet microwave. So we just put a microwave on a table in front of the side window we never used.   Literally we put up blinds, closed them and never opened them again.  That side of the house has light all day long and made the kitchen hot as a result late in the day.
• The pantry had those cheesy folding doors that always seem to break.
• The corner cabinets were wasted space as it was hard to get kitchen items in and out.

Here you can see the original cabinets, the refridgerator location and the wall where a window and the pantry were located.

So we contacted our good buddy Richard Ransom who redid our deck and windows (see Buiding a new deck) and asked for help.    Richard builds houses for a living and with the housing market being stagnet has been doing home improvement jobs.  Richard listened to what we did not like and he made several suggestions.

• Remove the side window and wall it up.   Use that space for the refridgerator.
• Tear out the old pantry and replace that with two floor to ceiling cabinets with pull out drawers.   Each floor to ceiling cabinet end caps the the floor and ceiling cabinets.   
• Do cabinets all the way around and lazy-suzens in the 3 corners.

Richard researched using stock cabinets to keep the remodeling costs down.  With custom cabinets you can spend as much as you want too.  Stock cabinets made this project very affordable.

Here you can see the same corner remodeled, the new sink and where the refridgerator was relocated.

Here you can see the endcap floor to ceiling cabinets.  With all the cabinet space we have more room then we can use.   A nice result is not having the upper cabinets so big and low that it makes it harder to cook and make use of the counters.   The cabinets are high enough to allow some serious cooking to get done and allows plent of light. For countertops we did not want to do formica again as kids juice seems to stain it.   Corian counters can get scratched up and can burn.  Granite did not cost much more.   One concern that Richard pointed out is the weight of the granite on the floor joyce could cause sagging in this old house.   Checking the joists most of the weight was going to be close to foundation and spread across multiple joists so no issues there.

We then redid the first floor in laminete by our friend Jerry Shirey (Floors2You .   The master bedroom on the first floor and living room had the original carpet for the house and it was impossible to clean.   The dust generated from the carpets required changing the air filter monthly. Jerry and crew did a fantastic job redoing the entire downstairs in two 1/2 day sessions.    

Finally we had Finishin' Touch repaint the walls and ceiling.   Replaceing the cabinets exposed the original ceiling and you could see how dingy it had become over the years.   The original kitchen was some sort of lilac purple which was hideous.   The other rooms were a cream color that was pretty dingy as well.

Doug of Finishin' Touch did a fantastic job on repainting the ceiling and walls in a marthon session that can only be described has heroic.

So if you need work done, give these folks a call!  They do great work.

Remodeling & Renovations - Richard\\ Ransom - 919-369-6370

Floors (wood or carpet) - Floors2You (Jerry Shirey) -  919-280-3377

Painting - Finishin' Touch (Doug) - 919-272-8875

 

We all have difficulty getting stuff done. There are always challenges that derail us or distract us from getting the things we need to get done, done! Whether that be Facebook, text messages, instant messages, email, cell phone, or the household dog that wants to tell you that the cat wants out. Let’s face it, we at a time of instant communication and information overload. Enter time boxing. Time boxing is a technique where you stay on task for a block of time and then break to do what ever you want to do. It is effective and has proven to work. There are many articles on time boxing you can find on the internet and a good intro is 5 reasons to practice timeboxing. One technique that I think is very well written is Pomodoro Technique. Being a fan of E-Myth by Gerber I like to document routines and provide feedback into the routine to improve the process. Pomodoro Technique has this nailed. All you need is a paper and a timer to get off your procrastinating butt and get stuff done! I use a dashboard timer for my Apple Mac from http://www.freelanceadvisor.co.uk/lifestyle-and-timeout/tools-time-boxing/ allows you to setup multiple dashboard timers of differing times to execute during the day.

Just got off a project where everything was specified by the customer as one liner requirements. System shall do this. System shall do that. Such old school gathering of requirements shows the lack of understanding what a customer really needs and what adds business value. Here how software development falls apart right from the beginning. First, there is no realistic way to track metrics. Second, the business analyst have to string together what “they” think are the processes. Many requirements are likely never defined but should be or implied. No way to track that either. Here is an example building a house to illustrate a point: House shall have 3 bedrooms House shall have 2 bathrooms House shall have a kitchen House shall have 4 electrical outlets in each room House shall have a family room Ok, the the analyst spends time putting together the specs and then reviews it with the customer. Customer response: Why am I walking through a bedroom to go from the kitchen to the family room? Where is the shower? I said we need 2 bathrooms! (yeah but you said bathrooms, I didn’t know if you meant half-baths or full-baths) Why are all the electrical plugs on the same wall? This goes back and forth and then you get to the front of the house and all the subjective stuff comes into play such as what kind of door, windows, colors and it goes on and on. So what is wrong with that? It is terribly inefficient. Once more it is a guessing game for the analysts to interpret what the customer wanted and sometimes the customer needs to be saved from themselves. Customers tend to ask for the moon when a 1 acre plot will do. Also on the metric front, it adds no value and has no meaning. I have 200 one-liner requirements and they get broken down into 40 use cases. Some of those requirements are shared across multiple use cases. So what is the point is tracking how many requirements are complete? You could to have the PM map it all out and spend the better half of the week trying to build a burn down chart for the last week? Who cares about last week! What about this week? If I have one use case that has a single requirement that takes 30 hours to implement and another use case with 10 requirements that takes 30 hours to complete are you going to build a project plan based on the velocity of 11 requirements a week? What happens if I schedule 11 of the 1 requirement use case’s that take 30 hours to complete each? Worthless metric. So what is the solution? Well I believe small incremental builds that continually add business value is the way to go. Agile development has been working well in that regard for years but it is not is not without issues. Stories written by product owners are either well done or not much better then the one-liner system shall requirements. I will be discussing the requirements gathering topic in follow up articles. So what works in your shop?

Don’t you hate gathering metrics that don’t mean anything? In the 80’s it was KLOC (thousand of lines of code) in the 90’s projects got so big we had to do big bang waterfall estimates where nobody had a handle on how long it would REALLY take to complete a project. Now in the agile age we have story points but management still wants hour estimates so they can answer, “when is this done?” All of these methods have issues with dealing with the unknown, risk, interruptions, attrition on and on and on. I do like story point estimates. SCRUM and Paceline as well as other agile methodologies do estimate based on story pointing. A customer or product owner would describe an end user feature. The team would then apply a story point to the feature. One common method is use a fibonacci sequence of 1, 2, 3, 5, 8, 13. This was really effective and development teams would quickly have the same feel as to a story point based on amount of work, complexity and risk. Stories that were larger then 13 probably were too complex or too broad and would have to be either broken down or the product owner would rewrite the story. It is amazing how quickly the team sizes the story pretty much the same way. Story point estimates are great because:

• They incorporate complexity and risk
• They are decided by the team
• Easy to size up an iteration once you have team velocity (number of story points complete in a cycle)

Where story points fall down:

• Management erroneously attaches hours to story points

Great article on story points vs hour estimates I recommend reading blog post from Jeff Sutherland Story Points: Why are they better then hours? To address the deficiencies, the backlog is complete can be calculated by velocity of the team. Velocity of the team is known after several cycles have been completed. But then all the management what-if scenarios start being asked:

• What if I add this team member?
• What happens it this team member leaves or get reallocated?
• How many folks do I need if I want the backlog complete by 2nd quarter?

SCRUM tools out there do not do a good job providing this information so management and product owners can make decisions. There are other variables such as heads down time of the developers versus meetings they are attending but not coding. Development metrics are not enough, I believe team management metrics are also in order and should be captured. Beyond story metrics, velocity should also be combined with: Code blocks per week Hours of coding per week Average hours per code block Why I think this is important is we all know interrupt driven development is unproductive. A developer working one block of 4 continuous hours will be more productive then a developer that works 4 blocks 1 hour each with meetings in between each block. Now here is a metric that management should focus on! An optimized work day for developers will have a higher velocity then an one that interrupt driven. I would put forth that this should be measured by role: Team Lead, Developer, Test Plan Writer, Test Executor, etc. Now if we had those metrics combined with velocity we can see how long it will take to finish this backlog of 50 stories and we now have metrics to make management decisions to try and make the team a productive as possible. What metrics have you found to be useful?

We bought a home in Fuquay Varina that is 20 years old and we knew it was going to take some work to get it where we want it to be. One of the items on the list was the deck that was build to wrap around the above ground pool. My estimation was the addition to the deck was a do-it-yourself job by the previous owner. The wood was splintering, the rails were rickety and very much out of code. The rail posts were only 4x4’s and not very steady. The kids were constantly getting splinters in the feet and because it got so much sun during the day, nobody would go out there until late afternoon or evening. The deck also got very hot as it was in constant sun. We would not go out there until early evening.

We had Rick Ransom, that built and remodeled homes around Raleigh, Garner, Apex, Cary, Holly Springs and Clayton area, put together together a plan to take care of our problem areas. We didn’t like the fact that there was not an edge piece around the pool which made quite uncomfortable to sit on the edge and dip your toes in the water. We also wanted to cut down the amount of sunlight on the back deck. We also would like storage so pool cleaning equipment was not laying all over the place. Rick did an incredible job. We have bench seats around the pool that doubles as storage for the pool equipment. Rick designed a shadow box over the main part of the deck with an outdoor ceiling fan to keep the air moving. Lattice work on the side also help cut down the sunlight but still lets the air move around. The edge board bent around the pool looks great and keeps the board edges from poking and scraping as you sit on the edge of the pool. The posts are strong with chippendale rails that look great!

Rick did an incredible job and I highly recommend him! If you have a remodeling or new addition you will not go wrong with Rick Ransom. He use to build houses until the bubble popped. So no project too big or small. Give him a call at 919-369-6370 to get quotes on your project if you are in Raleigh area.

Before

After

The Sony Vaio VPCCW17FX uses the Realteck ALC262 codec and out of the box Ubuntu 9.10 the internal microphone does not work.  However the mic input jack does work.