What's hot ? (and I mean really ...) - scroll down for more
1).  Code Templating - advanced usage of delegates & generics: my slides & demos are available for download! CodeProject article is also available.

2).  My series "TDD in the eyes of a simpleminded" is in progress(including code!): preface, part1, part2, Q&A 1, Manual Stub .vs. Mock Stub

3).  TDD Workshop: SeeCompass v0.1 and v0.2 are out.
# Monday, April 09, 2007
# Vision from an ex-software prisoner, Part 1

Too many times in our lives as developers, we feel that in spite of our talent, skills and knowledge we just can't seem to bootstrap ourselves from the mess we're in. It reminds me many movies (and the great Prison Break television series) where you see a nice, innocent guy put into jail with a bunch of murderers and rapists. After stabbing a guy in order to prevent from being stabbed, our hero gets into more trouble than he started with. This vicious circle goes on and on so by the end of the movie, you are not sure what he could have done different. His skills, talents and knowledge were thrown away, replaced by the need to survive. In many scenarios in life, I feel like that guy.

Avoiding the (really)poor analogy of un-unit-tested\unmanageable\coupled\you-name-it software to jail, I decided to stand up to the challenge(talk about "What not to do") raised by my friend, Uri Kalish, and share with you my vision regarding top mistakes I have experienced in the last few years. If it will able 1-N (see, I just had to be all geeky about it, even after talking for a full paragraph on jail and murderers) of you guys & gals to change 1-Z things in your world, this post will worth any future creepy comments I'll get from real ex-prisoners (what?! there must be some ex-prisoners .Net, Java frustrated coders out there, right?).

  • "Promoting" best coders into solely management positions
    It is the fear of losing someone and the way our community treat one's status causing this behavior. To make things worse, in most of these scenarios, the company (somehow)feels obliged to let him\her* manage 4-5 people so there is no fat chance he'll write code in the coming 2-3 years. I believe that this is the top-1 fatal mistake companies do. They are losing their most talented, most efficient programmers without the right adjustment and natural growth by the rest of the team. The way I see it, this is what a Team Leader should be responsible for:
    • Code for at least 60% of his time. Not 20%, not 30% and most definitely not 50%(this will cause him to fall back into 60%-40% manager). Great war leaders were great warriors, always on the front of their men. If you prefer to be left behind(technology speaking), managing from above, you should not be a Team Lead.
    • Get to know your people - what do they like to do after work hours, what are their hobbies, write down their birth-dates so you could buy them something symbolic. Make them feel like home. Spending 10+ hours in the office is more than most of us spend in our home. Notice how a very cheap gesture may change your team's world - some people like fancy keyboards, some(I'm included) prefer a big LCD screen and others prefer an extra bonus. Let's say that you invest up to 500$ per person, the ROI is still tremendous(try to think your hourly cost and how fast you'll return it). People will have everything they need(=want) in their office. Google is famous of hiring the best just because of taking care of the small details.
    • Manage your team's time - help to set the deadlines per sprint\iteration, but more important - analyze the team's productivity by picking up time estimations and actual time spent, and perform some calculation via various tools to understand the bottlenecks your team experience. Make them see, make them witness of how they can become more productive with the right set of exercises.
    • Be a mentor by leading the team with daily improvements. Change the way they think, blow their mind with new stuff. Direct them to "home reading" that you know they'll enjoy. Make them excited! Be a great developer for them.
    • Shield your team members from political business. Make sure no one is interrupting them meeting the deadline.
    • Meet the deadlines. Don't afraid to speak your mind when things are out of track. Make them see you've got what it takes to lead them back to the right path. Tough love may create great developers with the right amount of genuine caring.

         This will allow the Team Leader to remain an efficient programmer and the team grow into the new situation.         
 

  • Big teams
    Team size should never be more than 4, where preferable(IMHO) is 3. We want our Team leaders to write code, remember? Managing more than 2 people other than yourself will make your TL too busy to code. Even worse, big teams will cause team illness:
    • No matter of how much good-will exists in the team, keeping many people in the loop is simply too much overhead. It will wear off your teammates.
    • This will divide the team into smaller "virtual" teams, each one is built around a user story or a complete feature.
    • Now it's getting hard to know when you're breaking things for others as no one is really into your teammates code or requirements.
    • This leads us to the most unwanted behavior - no one in these virtual teams is an expert on their domain as the team switch context all the time to meet the big team deadlines. Context switch and lack of domain experts will kill you team. From inside out.

         Keep your teams small. Managers should sync the small teams and keep the eye on the ball for them. This is their skill, their talent.

  • Waste valuable time on the wrong tasks - skills .vs. tasks impediment
    This one really gets me. How many times you've been asked to do something you know you shouldn't have assigned for? Giving a c++ hardcore hacker to write HTML is silly(at best). Now, I can relate to the feeling managers have assigning these tasks  just to keep the deadlines but this shows of lack of creativity rather than good leadership. For example, the c++ hacker will cost around ~X5 then a young talented designer (by young I mean 16 years old cool dude that's doing it from age 11). Hire someone, even for a few hours a month and let the them do their magic. From some reason, managers never thought about hiring a graphic designer to write hardcore c++ code, right? It will be amazing to measure the ROI you can show your bosses even after 2-3 iterations just by putting the right players in the right positions. The same goes about database, system administrator, (customer)documentations etc. Stop treating someone's time as equal to someones else time. hardcore multi-threading guru will not enjoy a full day or two of playing with HTML to fit different resolutions. Be creative and make the adjustments! 


I have a lot more rants and tips but I'll leave it for further posts so be good and stay out of software jail.


[*] - I'm sorry but writing him\her all over the place is plain crazy. You know I'm no sexist ;-)

Agile | Management
Posted by Oren Ellenbogen 
09/04/2007 01:19, Israel time UTC+03:00,     Comments [4]  |  Related posts:
Best teams work for each other
Left Brain Storming
Can you build software like House ?
No, THAT is not Agile
Continuous Integration as Quality Reflection
Semicrum - Implementing Scrum at Semingo
Monday, April 09, 2007 1:50:44 PM (Jerusalem Standard Time, UTC+02:00)
Yo,
Strange, Where is this prison? Are there big black prisoners with ....

To the point,
I would like to ask few questions about the "Promoting issue":
1) lets say you have many small teams of three (for example: 3 teams), which are working on the same big product,
1.1) who will synchronize them?
1.2) how many times (a week) the team-leaders should meet and talk?
1.3) 40% manager says that the manager only met with customer for 50% and manage his programmers for the other 50% (20%-20%),
(I am thinking of short sprints with sprint-review at the end and planning task at the beggining of the iteration)
not even talking about the management above him and his other team-leaders (the sync issue)...
// 20% - mean 2 hours a day, or lets call it a name: one (10 hours) day. => which means 2 days a week.
2) I couldn't understand whether you best programmer - as a leader is good or bad,
I know some places (without mention names) that the took:
2.1) someone, with charisma but with no .net background, learn him the surface and let him manage that team.
2.2) I also know teams which take the best programmer (which means the best, truely geeky, no charisma) and let him manage the team.
I can tell you for sure, both teams sucks. for the first was 80%-20% the second was 20%-80% and both of the team-programmers told me this sucks.

I still think that you need a good programmer as a team leader, but you have many good programmers, you should choose the right one with the skills of managing, charsima, I somwhere read about it: evangelistic-leadership.

Shani.
Shani Raba
Monday, April 09, 2007 5:50:38 PM (Jerusalem Standard Time, UTC+02:00)
1.1). In addition to programmer and Team Leader, you should have a Product Manager(I'll describe his set of responsibilties in later posts) that should sync the teams. He should be also the vision creator and customer proxy(meaning plays the customer's role when the original one is unavailable or too busy).
1.2). It depends. First, the team leaders should get together with the Product Manager(&customer, if needed) and decide what they want to accomplish for the next iteration and how to integrate it in the process itself (AS PART of the iteration). After the list(including priorities) is formed, it's time to have a meeting with all the teams(including team members & QA) and see if the context inside the list is feasible. After spliting the tasks and assigning it to the teams (by domains), it's time to gather team meeting. There, each person should select from the pool of tasks the things he\she would prefer to do(I know, it's risky, but we're not playing with kids here. Everyone knows that the team must do it, no one will make it for them) and off you go.
During the week, I would say that a 2 hours meeting between the Team Leaders, should do - this meeting should include only how the integration is going and detect bottlenecks so things can be refactored in the same iteration(and maybe raising a flat to the customer, allowing him to switch priorities).
So assuming the iteration is 2-3 weeks long, I would say about 1 meeting at the end of the current iteration (planning the next one), 2 at the beginning of the new interation and another 1 every week - this is about 1.5 meetings a week in avarege.
1.3). I don't think Team Leader should talk with the customer for more than 10% of their time(and this 10% is part of the 40% management time, leaving him 60% to code). Working close with the customer is the role of your Product Manager. The Team Leader should get the list of features per iteration by his Product Manager(customer proxy) or cusomter, including the priorites, and see how many items can be done in this iteration.

2). I totally agree with you about the traits required from the Team Leader. I merly said that in a lot of companies, they're afraid of losing this talented guy\girl because "he's just a programmer, he want to progress". Assuming that you're taking a superstar programmer which is ALSO a leader, you still have to make sure he can be productive in his new position. Managing 5 people other than himself will hurt the group drasticly and will wear off the Team Leader (geeks like to code), making them unproductive at best (they feel gratitude to the company for promoting them, but they hate to run THAT MUCH around everyone). This post does not talk about which traits your Programmer has to have in order become a Team Leader.

To recap, promote your best programmers&leaders to become Team Leaders, but make sure they could still express themselves
in coding.
Oren Ellenbogen
Tuesday, April 10, 2007 5:07:53 PM (Jerusalem Standard Time, UTC+02:00)
in my opionion there's no one formula or a structure if you will that is best for all.
the team leader and team definition my vary from team to team.
it depend on your team itself , the project even the company's vision.

I do agree that the team leader should be the mentor but he doesn't have to be the best programmer in the group (but it helps).
The size of the team should be decided by the team's destiny to profill...
You might have a big team , even 20 programmers but i good team leader powers other in his team to have to power to make a relevant decisions...
Gadi Berqowitz
Friday, April 13, 2007 6:57:56 PM (Jerusalem Standard Time, UTC+02:00)
@Gadi - I say statistics show us otherwise. I believe that it's not in the company's vision or the project planning to decide if the team size should be 3,4 or 12. It's about analyzing what works in the world, where thousands of projects fail every week, and what does not and using math to move the odds to your side.

About Team lead, I did not say you need ot put your best there, just like I wrote to Shani:
"I merly said that in a lot of companies, they're afraid of losing this talented guy\girl because "he's just a programmer, he want to progress"."

In software, in my opinion anyway, no matter how genius or how charismatic the Team leader is, no one can control more than 3 people ON DAILY BASIS. I never witness(nor hear about) a successful project managed like that. So if a project requires 20 people to be completed, there is no reason to create one big team with one Team Leader that needs to watch 20 people every single day. Why not breaking this team into groups (~6 teams of 3-4 people, including fully-responsible Team Leader) and bring a great product manager that will be responsible for about 6 team leaders on more 2-3 days basis. These teams should be experts on different domains in this huge project.

It is much simpler to tell how much time it will take you to complete a task if you are an expert in that domain right? Now we have 6 groups of experts instead of 20 people where each knows just a little about everything. Keep in mind that having 20 people with poor overall knowledege will lead to poor quality with integration(no one knows enough about the system) and many context-switch. Small teams will allow your people to choose their tasks for the current iteration (as they own the domain, they are experts in it) so I really see a WIN-WIN forming small teams.
Oren Ellenbogen
Comments are closed.