Like all good agile practitioners, we set out some guidelines at the start of the meeting. We would time box each story discussion at 8 minutes and then move on. As well, we decided that each team member would take turns reading one of the stories so that everyone was involved and engaged. We started out well and made some progress but it was obvious that things were coming off the rails, and fast. Team members were getting frustrated, a couple of members were just pointing stories really high because they weren’t understanding the business value that each story conveyed (the product owner was present, and the team had met previously and discussed the stories in a brain storming capacity), the product owner was getting more and more frustrated, the team members quickly lost interest and everyone left the room feeling a bit worse for the participating.

I thought I would highlight some of the issues and try to address them:

History repeating
Some of the team members had worked on implementing the feature that we were pointing in the meeting in a past iteration of the project. The attempt failed costing the team of 3 people a months worth of time. It was obvious that this weighed heavily on those specific members and it was influencing there estimates. Understandably one can be sympathetic of this attitude, failing at the same thing over and over again is demoralizing and soul crushing. The thing is that scrum accounts for failure as long as you learn from it, I think though that this issue is a very difficult one to get past and I can’t really criticize too harshly on the topic.

Breaking the law
After the first story was done and pointed in the time allotted, we quickly ran overtime on the second and it just got worse for each subsequent story. We had completely ignored what we all agreed on at the start of the meeting and it turned a 30 minute exercise into a 90 minute marathon. I think in this case sticking to what we agreed to at the start would have made for a much more satisfying meeting, I think the desire to please the product owner and get the stories point outweighed the obvious fact that we weren’t doing a good job pointing them. I think in retrospect we should have just stopped the meeting and moved onto other work and reconvened another day, it probably would have saved a lot of people a lot of time and energy. This is something to try next time for sure.

A couple of interesting things happened later in the day that this meeting took place, my co-worker Jason Little wrote a blog post talking about this exact topic (I think the meeting had a pretty deep impact on all involved), go check his post out .

The other interesting thing is that I caught a tweet on twitter that stated “storming is the most interesting part of team formation”. This kinda made me think for a second, so I Googled the term and came to this interesting wikipedia page. The really interesting bit for me is the entry on storming:

The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Tolerance of each team member and their differences needs to be emphasized. Without tolerance and patience the team will fail. This phase can become destructive to the team and will lower motivation if allowed to get out of control.

This so quantified the exact feelings I was having about the meeting, it really reassured me that this is a normal process and it eventually leads to bigger and better things. It certainly made me feel much better about the situation and that we can and will progress past that stage onto more productive and fulfilling team situations.

Rockefeller Habits meet SCRUM

So as part of our company alignment and implementing the Rockefeller Habits at Q4 our quarterly theme was moving rocks together. We set aside a room with a video camera and plates with peoples names on them, if you felt the urge to recognize someone you could go into the room and record a short video message and give the person a rock. The end result would be that someone would *win* and get a prize.

Well we watched all the video’s today, which was hilarious and very very inspiring at the same time. It’s amazing that you can work with a group of people every day for months and years on end and sometimes never know what they are doing, seeing those people recognizing and rewarding there peers is a great way to better understand what the people you work with do on a daily basis.

Anyways as part of the moving rocks theme, the person with the most rocks at the end of the month would win a prize, and much to my surprise I was the winner this month (the first month). I’ve got to say it’s a great feeling being recognized and rewarded by your peers (this months prize was 100 at Canyon Creek). Even though it was me that won this month I think this is an amazing step for a small company to take and really makes me feel appreciated and valued.

One thing I personally have to do for the next month is give out more rocks, I want to make sure someone else wins next month and this has just inspired me to give those rocks out. If anyone at work is reading this, you guys are all an integral part of an amazing team, YOU ROCK!

To cut to the point, I was promoting some changes for a client last night. It was an update to part of our product that allows our customers to send automated and one off emails to lists of subscribers. I had done promotions similar to this in the past (in fact i’ve probably done the same thing maybe 100 times). But somehow, someway I managed to screw up. Not a small screw up either, I accidentally sent a test email message to the subscribers of one of the clients email lists.

That doesn’t sound so bad?
Sure it might not seem like a big deal, in fact I wasn’t even aware of it until the client pointed it out to me (there is nothing worse then this, NOTHING). You see our customers are publicly traded companies, and the software we develop helps them streamline and manage disclosure around their websites. I with an accidental mouse click had caused some level of damage in there shareholders eyes. I don’t even have to tell you the anxiety and frustration I felt when I was alerted to what I had done.

Ok, that’s bad
Yes it was bad, it was too late to undo anything so it was time to put into play this great saying one of my co-workers has:

First, get the cow out of the ditch, then figure out how the cow got in the ditch, and then make sure that cow never goes back in the ditch.

It has nothing and everything to do with software development all at the same time.

Obviously getting the cow out of the ditch was out of reach, but there were some measures that could be taken to ease the impact on our customer. I recommended that they send a one off email to the list that I had accidentally sent to, simply explaining that a test message was sent in error, they thought this was a great idea and did it.

Next, I had to examine all the various steps I had taken trying to reproduce what I had done. I had opened the wrong test email and sent it, an honest mistake but one that can’t ever be repeated again.

With that information in hand I put together some process recommendations for our company internally to implement when promoting these kinds of changes, as well as some product changes that could make this same scenario much more difficult to repeat in the future.

So in the end it worked out ok?
I guess if you look at it optimistically, yes everything turned out ok. For me, this was a situation that I was not comfortable with happening ever again. Fortunately the people I work with let me handle the problem start to finish, they didn’t breath down my neck and demand answers right then and there, they trusted that I would do the right thing, plus the client who was initially annoyed and frustrated appreciated the constant communication and recommendations that were made.

So what do you do when the shit hits the fan?
I’m sure this has happened to many a software developer. What do you do when this happens to you? I would be very interested in hearing about it, I think these hard learning lessons are ones that should be shared, never swept under the rug. If we can’t reflect and learn from these mistakes we as individuals and groups will continue to make them over and over again.

Q4 Web Systems is looking for a kick-ass senior .NET developer.  If you are a technology junkie and your idea of fun is spending a Saturday night reading about Team Foundation Server 2008 or playing with Silverlight 2.0 just because it’s cool, we want you!

You will become assimilated into our product development team where you will be responsible for the product advancement of our 2 application suites.   You will participate in design and architecture reviews, code reviews and write code with automated testing in mind.

Q4 offers a great environment as well as competitive salary and benefits.

Job Requirements:

• 7+ years enterprise application development experience with 2+ years in architecting software platforms
• 4+ years experienced with .NET/C#, ASP .NET, distributed services
• Strong interest in Design Patterns, Refactoring, TDD
• Solid understanding of object oriented vs. component design
• .NET Application deployment methodologies with N-Tiered systems, redundant/failover Windows technologies
• Excellent Understanding of FSDL including best development practices, documentation, QA processes and deployment strategies
• Windows 2003, SQL server 2005 and IIS 6.0 as it relates to application development and scalability
• A willingness to promote and ensure a common understanding of user stories
• Prominent participation in the planning, design, and implementation phases of high level concepts as well as user stories
• Ability to work well within a team of developers
• BS in Computer Science
• Secure application development
• Application stress testing

How to apply:  Send your resume to careers@q4websystems.com Only suitable candidates will be contacted for an interview.

What followed was literally a couple of hours of back and forth with the CEO of the company and we had the site done and ready to go.

For such a quick turnaround I’m really happy with the results.  Clean, simple and to the point.

www.q4press.com

On to other things, we are having our first shareholder meeting this week. It’s going to be really interesting meeting some of the people that have made it possible for us to get to the point we are at without having to struggle financially. I do know a few of them personally already but this will definately add a different dimension to it. Feeling a bit nervous but excited at the same time.