Management and leadership is a topic near and dear to my heart. As such, I decided to invest some time and construct a lecture to help out current team leads and upper management to gain some outside view. This will hopefully gear up your thinking on the subject, opening your mind into new practices and new questions you should consider pondering.
Obviously, potential leaders will enjoy this presentation as well :)

If you want me to come and give this presentation at your place, please ping me. My email is on the right or reach me at @orenellenbogen (twitter)

Team Up:

Lately, it seems that process became trendier than core leadership skills. Agile, Scrum, Kanban stole the focus. 
BUT – it is leadership that fuels process adoption rather than process auto-magically fixing disfunction teams.

In this talk we’ll explore what went wrong in this process adoption race: from hiring or promoting the wrong people, avoid setting clear expectations from our leaders, to dropping lean practices due to lack of deep understanding (forgetting why we started to begin with).

The dark side is interesting to explore, but we are here for the bright light – we will bring the FOCUS back to how we want our leadership to look like. 
We’ll try to figure out how we want our leaders to look like in the "Agile era"

2 months ago I switch to FeedBurner to track amount of readers of my blog. This helps me to understand if I’m living in a void  

I recommend switching your current subscription to the new one by simply tracking the feed here: http://feeds.feedburner.com/lnbogen
I apologies for the inconvenience and appreciate your time reading my stream of thoughts.

I’m writing for about 5 years now. I’ve spent numerous hours writing about coding, architecture and management. Some people liked it although my blog is yet another stream of words in a big pile of information called “the internet”.

The amazing fact is that my top post (by far, I’m talking about ~90% of my traffic) is about Visual Studio .Net 2005 Colors!
Yes, a single post, out of hundreds, about a niche topic, got all the spotlight. Frickin’ Lovely.

So like most startups, I’ve build->didn’t measure->didn’t learn->WTF? FAILED!

This year I’m trying to drive my effort by aiming for learning first (learn –> measure –> build): starting from what I want to test (my hypothesis) then to see if/how I can actually measure it and then to build it, or write about it. I’ll share my journey as I go, hoping you’ll find it interesting.

Happy 2011 everyone!

You probably meant to write mail but the keyboard fooled you; but hey! you can read about leadership, development and coding instead of reading your emails! What a win!

(I’m curious to see if you reached my blog because of this post, if you did – please “Like” this post. Viva la Google ;))

Leaving a comment is considered a bigger commitment than just voting “Like” or “Recommend” on a post you feel is useful. I believe that such information, which posts you find interesting, is also useful to other readers. With this information, others can find more recommended posts, even though they don’t necessarily contain 50 comments.

This is why I added “Facebook Like Button” to my blog.
If you Like it, let me know :)

“Agile/Lean movement” and Scrum in particular, made short cycles a key factor in the process. May it be cycles of planning, cycles of development or cycles of releases, there was a big arrow pointing at *short cycles* to figure out how to get more accurate, more responsive, more productive faster.

Due to the short cycles, the Features or “Product Backlog Item”, sometimes, just didn’t fit in. “My 2 months Feature won’t enter our 2 weeks Sprint!”. Because Sprint is, wrongfully in my opinion, being highly tied to releases, it raised a need to allow breaking Feature to multiple Sprints. The question is “how to break it right?”.

User Stories came to offer a methodology to assist in this need. The idea is to detail the Feature in multiple end-to-end flows (which good Feature already detail) and implement them one by one instead of trying to implement the entire Feature at once. Because User Stories are subset of a Feature, in the same language as a Feature, it felt that these stories can replace Features and Sprint will contain them as smaller execution parts. This will obviously “solve” the mismatch of Feature size to Sprint size.

I claim that it didn’t solve anything at the core level. Even worse, my feeling is that User Stories introduced a dangerous abstraction, one that should be used carefully. More on it in my next post…

Delver is all about letting you to explore, research and (eventually) purchase products in a different way. Pushed and driven by what your network has to say, it will be easy for you to see what books your friends recommending, what kind of movies are hot or which camera you should buy next. You could publish polls, to get help from your friends on what to purchase, you can rate products and write reviews, you can create a catalog of items (“My ski trip to Italy”), create a gift catalog and share it with your other friends, recommend products to your friends and plenty more!

You’re more than welcome to check it out at http://delver.com/

We are still in “closed beta”, which means you need an *invite* to get in. Once you’re in, you can send invites to your friends and enjoy their feedback on items you’re interested at. If you want an invite, drop me a line with your email (or email me directly).

I’ve spent around 2 hours to figure it out, so at least I’ll write it down.
I’m using dotTrace 3.1 to do some analysis for .net web application running on Windows Server 2008 R2 (IIS 7.5).

I got strange numbers and was missing some data (methods calls) running “profile web application” until I set the affinity of the w3wp.exe process to single Node (single core). This can be done easily by opening the Tasks Manager, right click on w3wp process –> Set Affinity –> pick just one core.

Only then you should record the required page(s) and take the snapshot.

During team’s growth, the practice of keeping the knowledge base sound, looks like mission impossible. There are simply too many concerns to write down and maintain: picking a proper (=”searchable”) title to the knowledge base item, keeping the history of changes in the design and why they were made, adding some drawing etc. Text notes (and pretty pictures), what can we do, are getting obsolete extremely fast.

“How can we keep the team’s knowledge base without running after our tail?”

My team came up with this suggestion:

“Let’s keep the titles and put owners next to it, the rest can be solved with good communication and tests!”

Examples for such “knowledge base items” are, from our real list:

• Supporting Contextual Sign-In scenarios (Avish)
• Common CSS Classes for our beautiful look-and-feel (Moran)
• Creating and using pretty-URL routes (Ken)
• …

We broke it into domains like “basic architecture”, “common features”, “cross-cutting concerns”. Now the list is easy to search at (wiki) and fun to maintain.

This work extremely well if:

• Code-reviews are done on a regular basis. This means that at least 2 developers can talk about each knowledge base item.
• Tests are written to built great confidence (to refactor easily) in the code. I talk about unit-testing, integration testing, UI testing etc.
  • Great tests explain how to use the API and what should be expected from it.
  • Tests (mostly integration tests) explain the latest architecture.
• Comments in code should include the “why” behind the logic. Team members can add to it even more if needed, by talking with each other.
• New developers are exposed to the knowledge base, talking with the relevant owners. This is a great reference to look at.

Simple, short, effective!

Great dishes. Great timing. Every single day. This is one amazing place to eat at!

In many ways, running a great team of developers is just like running top-quality kitchen.
You’re measured by your ability to serve great quality(CI? well tested?), super tasty(nice UI?) dishes (features?), to hungry people (clients?) in reasonable time (before they’ll leave to another site).

Without solid understanding of ETA, there is no way to predict quality and release in time.

Most of us are driven by what life has to throw on us, may it be some personal event, a new book you read that makes you want to refactor everything or simply a lot of context-switches between projects and bugs.
Add this to our constant urge to excel at what we do, and you get a “miraculous” skill of losing control over our time. We’re built this way. Life is pushing us around!

How does this effect us or the “wheel” I’m talking about? I want to introduce you to Joe. 
Joe is a nice guy in my imaginary world, working as a superstar developer for “TheBestOutThere” company. Joe was assigned to complete a feature and asked to estimate when it will be done. “This feature is quite simple”, he shoots fast, “a few changes here, a few there and then the UI to nail the all thing. Hmmm… I guess that no more than 2 days of work”. So our story begins…

The first day goes pretty well as Joe adding the needed fields to the database and even manage to complete some tasks regarding the logic needed. On the second day (reminder: the last day according to the ETA) things starting to bite Joe’s ass. The feature turns to be a bit more difficult than he anticipated, and he feels that it will take 2 extra hours to complete the work. Keeping it in mind, he already notifies the wife he’s going to be late today. “Damn, late again?”, he ponders, “oh well, at least I know what is left to do now”. Knowing that he needs to leave late today, he continues to work and suddenly he detects a really ugly piece of code in his path. “Refactoring time baby!”, he smiles to himself. “Well, I already have a few spare hours, why not?”, he convince himself once more. It works. The refactoring takes additional 4 hours. Joe, in a panic attack understands that it took more than he planned, hurries up missing a few critical tests and canceling the “code review” meeting claiming “this feature is simple enough!”. The code-review still takes place as this is simply a must for top-quality kitchens. Fixing the code review comments, including adding the missing tests (as needed to begin with) cost a few more hours and so days starting to fly by. After 5 days, Joe moving the feature to “code-ready”, now waiting for QA to test the feature. QA opens about 7 bugs, which take 6 more hours to fix (with solid unit tests to reproduce these bugs). On top of it, some more fixes were needed for easy deployment later on in production. The feature took total of about 7 days. Where is the missing 5 days went to? is Joe simply a poor estimator? Not quite, he just suffer from bad “context” we all do. He suffers from the constant battle between deliver fast and deliver with high quality. The problem is that it’s really hard to understand how estimation and quality work together.

If ETA is Jesus, Quality is God. Which is more tangible?

People are wasting time trying to convince themselves they can outperform on a daily basis. We can’t. Our best is probably not as great as we imagine. Instead, let’s not try to improve our ability to code faster, think faster or drink more coffee. Even if you manage to get better at it (or consume more coffee and urinate to a cup), it won’t last for long (urine tends to stink in the room).

Instead, think carefully about “where the hack my 5 more days went to? Could I see it coming?”
Here is the “context” Joe needed to have in order to produce a complete feature, with great quality, in time:

1. Did I spare enough time reading the spec and talking with the Product Manager about it? (yes, this is part of the feature!)
2. Did I make sure there are no open issues left?
3. Did I spare time thinking about how this feature will be tested? how we can automate these tests easily?
4. Did I spare time to design the solution and do the required review with other people? what about the hours needed to fix your solution based on the reviews?
5. Did I spare time to read QA test cases and give feedback on it?
6. Do I have everything you need to make the feature a huge success?
1. What about people helping you out where needed?
7. Did I spare enough time to write the code itself? are you sure?
8. Did I spare time for testing? I talk about really great testing (unit tests, integration tests, automated UI tests, manual UI tests)
1. Again, the goal here is great confidence in quality, not 100% test coverage.
9. Did I spare time for code reviews? for code reviews fixes?
10. Did I spare time thinking about how this feature will be deployed?
11. Did I spare time sitting with the Product Manager again on your final result before merging your work back to “trunk”? (do it now as it’s “hot”)
12. Did I spare time for “bug fixing buffer” (saving ~10% of the feature time for bug fixing is a good start, try to reduce later)?

Estimating each one of these steps (use “buffers” if certainty is low) and you’re a bit closer to understand where the missing 5 days vanished. 
Joe was thinking only about the coding effort, not the entire picture! This, by nature, means inability to consistently predict when something will end. He was pricing the wrong thing!

What does it take to make your team great unit of brilliant minds producing great dishes, every time:

1. Hire the best. They simply worth it. (oh well, that was easy, right? :))
2. Trust them doing the best work one can do! Help them get them but don’t think they can’t get there by themselves with the right set of tools and context.
3. Start with explaining the meaning of great ETA – without it, prediction is impossible. Consistency is a lost cause. This is one bad kitchen.
4. Ask people to stand behind there ETA. They are responsible for it!
5. In the same breath, remind them that quality work is the right path to get a correct ETA. Quality work will lead to shorter cycle eventually!
6. But (here comes to tricky part!), they should also remember that over-refactoring leads to high quality of nothing important (as nothing really reach production).
7. So, define together what is “quality work”. Set it as “team context”.
8. Constantly hear what your guys has to say about “I wish we could fix it!”. Eliminate the big things (lack of tools, too many context-switches, not enough testing etc).
9. Try to inject a lot of honesty, communication and great motivation to the team. This is the basic engine oil no one can live without.
10. Measure delivery cycle length: spec –> design –> getting ETA –> feature is code-ready –> solving all bugs –> deployed in production.
11. Talk with your guys to understand waste again. Eliminate the big things now! seriously!
12. Keep hiring more people, only the best, you’ll need them soon enough.

Over time, the cycle of delivery should get much better while the quality will get even higher. The trick here is that people will feel more confident in the flow, “saving’” time to write quality piece of code, making features amazingly stable in the 1st attempt. This is the consistent rhythm you should dream of. The wheel spins…