Stand-Up or Scrum Etiquette

My new role is on a team that has a scrum with almost 20 participants. At this point, it is important to obey the ethos of a scrum (or stand-up) or there is a potential to waste the time of many people.

Here is my basic Scrum Etiquette. It is good to remind people of it at the beginning of a scrum at the beginning of a new sprint or when things are out of control.

Scrum Etiquette:

• Turn up on time. The scrum will start without you;
• If you can not attend the scrum then give someone your update and they will go through it on your behalf;
• Your update should consist of… 1) What I've done since the last scrum. 2) What I'll do between now and the next scrum. 3) Any blockers;
• Your update should take about 30 seconds;
• All other conversations should take place after the scrum in a Dev Huddle (for tech talk) or BA Huddle or Tester Huddle or specific delivery teams; and
• Speak to the team and not just the scrum master. It's about sharing with your whole team and not just reporting your status to the boss.

Scrum Anti-Patterns (for the Scrum Master to look for when running the scrum):

• More than one person acting as the scrum master;
• Everyone speaking to the scrum master;
• Long updates with too much detail;
• Technical discussions that other team members aren't interested in;
• People not mentioning blockers. People should explicitly state if they have no blockers; and
• People looking uninterested.

I did google this and there weren't enough clear definitions. Every team is different and you will adjust to yours. This is a good starting point.

Go forth and scrum.

Your compiler is your friend

Today, I spent a small amount of time helping a developer solve a problem.

That may be how I start a lot of my posts for a while since I am working with some smart chaps who are learning to be better devs. The thing about learning to be a better developer is that you learn it from writing a helluva lot of code and from working with old grey haired devs like me.

Ok, I don't have grey hair but I do this wise Gandalf voice that really deserves some grey hair.

When I started developing, a compiler wasn't much without a linker. We spoke of lint and didn't mean the stuff left in driers. We had pet dinosaurs.

One thing that understanding the parts that come together to be the Build that we all speak of now is that we learnt to listen to what each part was telling us. No, no, I don't want you to go out and conduct some native American dreaming ceremony but I do want you to listen to your compiler warnings.

In today's adventure, I paired with a developer who was having issues adding a set of XSD schemas to a .NET schema collection. The thing is that this class was deprecated after .NET 2.0 and the reader feeding it was also of the past.

The compiler told us so.

The thing is that although many developers are warned over and over again that they are using an old API function and to use X instead, they persist. They ignore that and many other warnings. This however is the most common one I see outside of warnings about variables being initialised but not used.

Your compiler is telling you this for a reason. It isn't because it has had a slow day or it is having a grumpy moment. No, it consistently warns you that there is a better way to do things now and even suggests how you should attempt this.

So, we solved our issue today by listening to the warnings and using the latest and greatest (be it 3 years old) and all was well.

Yes, we have evolved as a profession to obey our build errors and not check in a broken build to avoid the hisses and boos of our colleagues. Now we must grow to listen to the warnings. They are not wasted cigarette lighters at a Pink Floyd concert. They are not a gasp of exclamation in a sea of squealing teenage girls at a boy band concert. They are not platform high heels at a Kylie Minogue concert. No.

To be a better developer, you will listen to the advice you get from your build, your static code analysis and your IDE refactoring suggestions. You will do it because it will make your code better and more up to date. You will do it because it will stop the bad things happening that happened to those before you. You will do it because it will stop my soul from hurting.

Be it Visual Studio or IntelliSilly, your IDE is your friend. Your compiler warns that there be dragons and you must listen.

We Are So Progressive

While waiting for my clearance to clear (that's all for another blog post), I've been talking to different people about short term gigs. I am not in any major hurry to find anything so the conversations are not stressful job interview types but more a chat about whether we can work together.

One interview was such an entertaining conversation that I was impressed at my ability to keep a straight face the entire time. Instead of giving you a blow-by-blow of the whole session, I'll just share the top three highlights that made me smile afterwards.

"I don't believe in unit testing. It gives people a false sense of security. I believe testing gets in the way, which is why we fired the dedicated testing team."

This came out of me asking what the automation in their dev and deploy processes is like and what kinds of testing (automated and manual) were in place. The development manager and architect (who is the same person) went on to lecture me on the false security blanket that unit testing is and that it is an overhead that in no way helps assure a quality code base. He used words like coverage and feedback loop and other buzzwords but not in any way that seemed to fit in with any kind of practices or processes I'd ever heard. It's very possible I was hearing of very new ideas. Yeah, possible.

In the end, he had reduced his delivery team to a business analyst and a bunch of developers who pushed code through to Production in 20 minutes with his surety and trust that they simply didn't write buggy code.


"We have Continuous Integration right there. *points at monitor hanging on wall* That screen shows our 16 production apps. It pings them every few minutes to see if they are still working. If they are, it's green. If they aren't then they appear red."

Now, that is a dashboard but it in itself is not CI. I've been seeing the term Continuous Integration used a lot of by people who think it is based on red and green lights. I'm guessing the amber light of traffic lights must make them really confused.

In this case, I asked if they had any automation around their build or deploy process. Again, I was dismissed as some kind of charlatan with ideas from yesteryear. This was the point where I became most distressed, in that burning-building-and-the-lifts-are-out-and-I'm-on-the-75th-floor kind of way.

The dev manager said that "yes, our profession is going towards automated testing but that's a phase." He said he was going away from it having proved it wrong. He said "I am progressive." After later whinging to some ThoughtWorkers, we decided he was progressing backwards and so was technically correct. *sigh*

"Data modelling is over-kill."

Now, I'm the kind of girl who watches Fast and Furious 6 and thinks there weren't enough car scenes. I even read reddit and wonder why the comments ended. Over-kill is not something I claim or proclaim much at all.

In this case, he (dev manager guy) wanted to know what I liked about ASP.NET MVC. He wanted to make sure I hadn't just read the FAQ. I just spent the last 18 months as the Microsoft PFE ASP.NET MVC Lead in Asia so when I say I know MVC, I wrote the FAQ. Either way, test away.

I gave my reasons and went on to talk about DDD and the merits of building a domain true to your users. He sniggered. That's ok. People snigger.

In this case, he challenged every idea of modelling to the point that he said he'd discarded Entity and any persistence layer at all and thought a Dataset passed straight to the templating engine wasn't awful.

I sighed again.


So those were my favourites. I commend myself on my ability to listen and consider all that was said. Even his impressive 20 000 requests on his 16 web applications per day had me keeping a straight face. Ask any of my colleagues who've worked on farms that do that in a second. Oh well.

One thing I took from this whole experience is that everyone has a world that seems huge to them. What we must learn is how to judge up and out. There are people out there who don't want a pissing contest. They just want to help you build software that scales, is robust and can be extended.

In my world, I always want to strive to work in better places that teach me bigger and more amazing concepts. Everything I know is tiny and insignificant compared to what I have to learn.

At least, I know that.