Team up!
        Leadership, process, survival and pride @ the Agile era




   Team Lead Role


Oren Ellenbogen (@orenellenbogen)
Who am I ?
                              Oren       Ellenbogen


* Blogger: www.Lnbogen.com
* Engineer @ Commerce Sciences

* ex. Delver (Sears) – Director of Engineering
The Agile/Lean Crusade 2.0
Food for thought
When
Pressure
Beats
The crap
Out of
Leadership
Meet the tech leader


He’s smart, ridiculously smart




Bob (the CEO):
“What about Chris? He’s amazingly talented!
 I guess he can handle it…”
The company adjusts…

New team = our smart dude +2 teammates




magic!
A leader in trouble
                                            ?
                                             ?
                                             ?
“I match my shoes to my pen”
“I love reading hex”
“I shave per new version of Ubuntu”


“I guess I can tell others what to do”


Maybe we need more than technical skills?
Meet the “passionate” leader


“Let’s use Scrum!”
[process kicks in, time passes]


 Ozzi (a developer):

        “why do we need a daily report?
         Shouldn’t a weekly status suffice?”
A leader in trouble

“Let’s do it!” is a great attitude!   ??
But people forget reasoning fast
                                       ?

Why should we do it? why now? why ever?



Maybe we need more than passion?
Meet the “experienced” leader

• Working for 6 years as senior dev
• Knows all the secret God classes
• All the magical javascript quirks




   “I am technical enough and experienced
      enough to lead a team. I’m doing it for
         a long time now, I deserve it!”
A leader in trouble                          ??
                                               ?

• Does he know what leading means?
• Does he care enough to make others shine?




 Maybe we need more than experience ?
Are you feeling ready to lead?

        Can you define
          what a “great team lead” means?


        Do you currently have
          enough management tools?



        Are you suffering from a
          process without leadership?
Why?
(Some background)
Organization IQ: f(pressure)
Our reality:
• Organizations constantly need to change
• Pressure constantly adds up
• Lean/agile processes makes things even faster!

Pressure has its impact:
• We adapt poorly
• Picking (sometimes) the wrong people
• Neglecting proper guidance, forgetting the why
There is 1 reason to become TL
Lack of putting thoughts on paper

Thoughts are volatile, you’re missing:
• Self retrospective
• Passing it on
• Ideas writing (instead of “good memory”)
•   …
                                             1
Team lead role –
WTF is it then?
Define: team leader



If you had to pick 3 qualities of a great
   team leader, what will they be?

          (hint: “a leader” is not a quality)
Attempt: team leader
 Visionary
   Product vision (can you explain the why?)
   Architecture vision (incorporated with product
    requirements)
   Team vision (incorporated with architecture)

 Cares about people
   People will follow your heart (honesty)

 ROI driven
   Pick your battles, explain the why, offer tradeoffs
Caring?

It’s the small stuff
   That counts most




                         * Welcome gift to a developer, after writing FB message saying it’s SWEET!
Your attempt: team leader

 My definition is only my point of view




   The real question is do you
have your own definition written?
It’s about confidence
 Your boss:      you’re on top of things, actively report.

 Your people: things will be handled (technical
  backlog), you have their back

 Your peers: You’re able to deliver & communicate (team
  player)

 Your company: You help the company to deliver faster
  with higher quality

 Yourself: You’re able to make other shine.
Ideas         / tools / thoughts




How to make others shine
Different unit of productivity
   Time to change your state of mind




 Then                       Now
Key decisions list
                     Document it!

Guidance:




Why: to be able to reflect later, with yourself & others
Visibility > progress
 No glory in running
 forward in the dark



Guidance :
1. Ask for ETA (when?) and their COMMITMENT!
2. Thinking end->backwards (how?)
3. Early *complete* breakdown (what?)



Why: ETA > Progress    (create visible organization)
Gut feeling estimation
Does it get any better?




                     Range is good!



Why: allow quick re-prioritization (product/business)
Must, Delegate and External
Is it really my
responsibility?

Guidance :
1. Team leaders should specify:
   1. MUST
   2. DELEGATE (HOW?!)
   3. DEAR BOSS, PLEASE DO X, Y, Z

2. Challenge and consider how to do less MUST and more Delegate

Why: reduce personal pressure to take care of the MUST
Ownership as a driver
Increase your execution unit


Guidance:
1. Give ownership to drive commitment.
2. Set your expectations!
3. Ask them to stand behind their commitment (not nice to have)
4. Help them be effective (close feedback loop)
5. Don’t stand in their way


Why: get to know your bottlenecks
Estimate together
Teach the dark magic of estimation


Guidance:
1. Consider practices to estimate faster (Poker Planning)
2. Try to reach some consensus and endorse
   open conversation about the estimation
3. Track estimations (estimated vs. actual) over time and analyze
   your team’s gaps


Why: avoid “you said 2 but I’m doing it, It’s a 10”
Test to last
Avoid the (default) graph:


Guidance:
1. Create an environment striving for production-quality
   code in your tests
   a) Tests instead of overkill documentation
   b) Reduce maintenance time when changing behavior
2. Consult and learn how to build maintainable tests
   a) IoC, tests structure, open-source projects, language tricks


Why: tests == confidence == easier release cycle
“Beautiful Document”

       Document’s worth = f(“initial value”, time)

• Like a car, it’s around 40% less valuable 15 minutes
  after you finish writing it.
• Unlike car, people won’t use it every day.

My attempt: a beautiful document is when…
    Requirements, pains, motivation and
     known constraints are well specified.
    Why: less time to write and most chances, it won’t change
Bullets knowledge base
 Keep your
 Documents relevant

Guidance:
1. Phrase (Owner)
2. Small explanation about each phrase
3. Talk with (Owner) for further details
4. Practice to learn the details
   (pair-programming, leading a feature)


Why: relevant know-how is key to fast release cycle
“Beautiful Code”

Unique != beautiful:
   Unicorn style of code is not really beautiful




My attempt: beautiful code is when…
   It should be easy to add new features.
   It should be easy to change existing features.
   It should be easy for new teammate to become
    productive almost immediately.
Final note
Pay it forward
Think forward, teach today


Guidance:
1. Teaching helps us think of what’s important to know
2. Delegate so you could move forward (future growth)
3. Prepare to grow from day 1
4. Teach so you could grow internally (opportunity > need)
5. Teach to be taught (you’re strong at A, she’s at B)


Why: Job Safety is so 90’s
Thank you!


Oren.Ellenbogen@gmail.com
www.Lnbogen.com
@orenellenbogen

Team up

  • 1.
    Team up! Leadership, process, survival and pride @ the Agile era Team Lead Role Oren Ellenbogen (@orenellenbogen)
  • 2.
    Who am I? Oren Ellenbogen * Blogger: www.Lnbogen.com * Engineer @ Commerce Sciences * ex. Delver (Sears) – Director of Engineering
  • 3.
  • 4.
  • 5.
    Meet the techleader He’s smart, ridiculously smart Bob (the CEO): “What about Chris? He’s amazingly talented! I guess he can handle it…”
  • 6.
    The company adjusts… Newteam = our smart dude +2 teammates magic!
  • 7.
    A leader introuble ? ? ? “I match my shoes to my pen” “I love reading hex” “I shave per new version of Ubuntu” “I guess I can tell others what to do” Maybe we need more than technical skills?
  • 8.
    Meet the “passionate”leader “Let’s use Scrum!” [process kicks in, time passes] Ozzi (a developer): “why do we need a daily report? Shouldn’t a weekly status suffice?”
  • 9.
    A leader introuble “Let’s do it!” is a great attitude! ?? But people forget reasoning fast ? Why should we do it? why now? why ever? Maybe we need more than passion?
  • 10.
    Meet the “experienced”leader • Working for 6 years as senior dev • Knows all the secret God classes • All the magical javascript quirks “I am technical enough and experienced enough to lead a team. I’m doing it for a long time now, I deserve it!”
  • 11.
    A leader introuble ?? ? • Does he know what leading means? • Does he care enough to make others shine? Maybe we need more than experience ?
  • 12.
    Are you feelingready to lead? Can you define what a “great team lead” means? Do you currently have enough management tools? Are you suffering from a process without leadership?
  • 13.
  • 14.
    Organization IQ: f(pressure) Ourreality: • Organizations constantly need to change • Pressure constantly adds up • Lean/agile processes makes things even faster! Pressure has its impact: • We adapt poorly • Picking (sometimes) the wrong people • Neglecting proper guidance, forgetting the why
  • 15.
    There is 1reason to become TL
  • 16.
    Lack of puttingthoughts on paper Thoughts are volatile, you’re missing: • Self retrospective • Passing it on • Ideas writing (instead of “good memory”) • … 1
  • 17.
    Team lead role– WTF is it then?
  • 18.
    Define: team leader Ifyou had to pick 3 qualities of a great team leader, what will they be? (hint: “a leader” is not a quality)
  • 19.
    Attempt: team leader Visionary  Product vision (can you explain the why?)  Architecture vision (incorporated with product requirements)  Team vision (incorporated with architecture)  Cares about people  People will follow your heart (honesty)  ROI driven  Pick your battles, explain the why, offer tradeoffs
  • 20.
    Caring? It’s the smallstuff That counts most * Welcome gift to a developer, after writing FB message saying it’s SWEET!
  • 21.
    Your attempt: teamleader My definition is only my point of view The real question is do you have your own definition written?
  • 22.
    It’s about confidence Your boss: you’re on top of things, actively report.  Your people: things will be handled (technical backlog), you have their back  Your peers: You’re able to deliver & communicate (team player)  Your company: You help the company to deliver faster with higher quality  Yourself: You’re able to make other shine.
  • 23.
    Ideas / tools / thoughts How to make others shine
  • 24.
    Different unit ofproductivity Time to change your state of mind Then Now
  • 25.
    Key decisions list Document it! Guidance: Why: to be able to reflect later, with yourself & others
  • 26.
    Visibility > progress No glory in running forward in the dark Guidance : 1. Ask for ETA (when?) and their COMMITMENT! 2. Thinking end->backwards (how?) 3. Early *complete* breakdown (what?) Why: ETA > Progress (create visible organization)
  • 27.
    Gut feeling estimation Doesit get any better? Range is good! Why: allow quick re-prioritization (product/business)
  • 28.
    Must, Delegate andExternal Is it really my responsibility? Guidance : 1. Team leaders should specify: 1. MUST 2. DELEGATE (HOW?!) 3. DEAR BOSS, PLEASE DO X, Y, Z 2. Challenge and consider how to do less MUST and more Delegate Why: reduce personal pressure to take care of the MUST
  • 29.
    Ownership as adriver Increase your execution unit Guidance: 1. Give ownership to drive commitment. 2. Set your expectations! 3. Ask them to stand behind their commitment (not nice to have) 4. Help them be effective (close feedback loop) 5. Don’t stand in their way Why: get to know your bottlenecks
  • 30.
    Estimate together Teach thedark magic of estimation Guidance: 1. Consider practices to estimate faster (Poker Planning) 2. Try to reach some consensus and endorse open conversation about the estimation 3. Track estimations (estimated vs. actual) over time and analyze your team’s gaps Why: avoid “you said 2 but I’m doing it, It’s a 10”
  • 31.
    Test to last Avoidthe (default) graph: Guidance: 1. Create an environment striving for production-quality code in your tests a) Tests instead of overkill documentation b) Reduce maintenance time when changing behavior 2. Consult and learn how to build maintainable tests a) IoC, tests structure, open-source projects, language tricks Why: tests == confidence == easier release cycle
  • 32.
    “Beautiful Document” Document’s worth = f(“initial value”, time) • Like a car, it’s around 40% less valuable 15 minutes after you finish writing it. • Unlike car, people won’t use it every day. My attempt: a beautiful document is when…  Requirements, pains, motivation and known constraints are well specified.  Why: less time to write and most chances, it won’t change
  • 33.
    Bullets knowledge base Keep your Documents relevant Guidance: 1. Phrase (Owner) 2. Small explanation about each phrase 3. Talk with (Owner) for further details 4. Practice to learn the details (pair-programming, leading a feature) Why: relevant know-how is key to fast release cycle
  • 34.
    “Beautiful Code” Unique !=beautiful:  Unicorn style of code is not really beautiful My attempt: beautiful code is when…  It should be easy to add new features.  It should be easy to change existing features.  It should be easy for new teammate to become productive almost immediately.
  • 35.
  • 36.
    Pay it forward Thinkforward, teach today Guidance: 1. Teaching helps us think of what’s important to know 2. Delegate so you could move forward (future growth) 3. Prepare to grow from day 1 4. Teach so you could grow internally (opportunity > need) 5. Teach to be taught (you’re strong at A, she’s at B) Why: Job Safety is so 90’s
  • 37.

Editor's Notes

  • #2 Points to deliver:We’re in the Agile/Lean “era” – companies expect their execution to adjust quicker and deliver faster.These processes puts a lot of pressure on the execution part, raising the amount of pressure on the management level.Most managers are lacking tools to adapt and excel in their role within the new reality.
  • #4 הקונספט של ר"צ הוא אחד המושגים הכי מופשטים, הכי לא ברורים ועם זאת בין הכי חשובים בארגון בריא.רוב האנשים מקודמים לתפקיד זה מבלי חפיפה מסודרת, הגדרת ציפיות ברורות או תוכנית חניכה. אחד מהדברים שקרו בשנים האחרונות הוא ניסיון לפתור תהליכי עבודה שלמים (scrum,lean,XP), לפעמים, תוך כדי התעלמות מבעיות צוותיות לפני הכלת התהליך החדש.בתחום שלנו, הנחת העבודה או ברירת המחדל שלנו היום לא מספיק טובה – "ר"צ הוא מנהל עבודה בעל סמכות" ו"כשנצטרך אז ניתן למישהו את התפקיד, נפתור את זה איכשהו"מטרתי היום לנסות לשים את תפקיד הר"צ במרכז העניינים, להסביר מדוע הדברים מתגלגלים כפי שהם ולהציע כמה דרכים לשבור את מעגל הלחץ שעליו נדבר עוד מעט.
  • #5 סיפור – יש שינוי בחברה, צריך לזוז יותר מהר או אולי לפתח מוצר חדש או אולי לפתח תשתית חדשה. צריך מישהו שינהל את זה...בד"כ, מסלול ר"צ מתחלק ל3 סוגים: 1. "מגה מוח" - אנשים סופר טכניים ש"נופלים קורבן" לצרכי האירגון, בד"כ מבלי שהם רוצים, אך מסכימים (בגלל מוניטין, שכר חדש או בונוס נחמד)2. "רד בולים" – כאלה שדוחפים את האירגון קדימה כאנשי פיתוח.3. "שמעון פרס" – כאלה שהיו מספיק זמן ומרגישים שעכשיו הזמן לעשות את הצעד הבא.
  • #10 אם אתם מוצאים את עצמכם אומרים "כי ככה עובדים כאן" או "כי ככה זה היה, אז המשכנו" תרימו גבה. האם זה מה שאתם באמת רוצים שיקרה?גם אם אתם דוחפים את כולם קדימה, האם יש לכם תשובות טובות לגבי המוטיבציה מאחורי זה? האם אתם דוחפים אותם מעבר לצוק?
  • #13 אני חושב שיש היום שיחה מועטה על הנושא.אני חושב שאם אני אקח 10 ר"צ או 10 מפתחים מוכשרים עם פוטניצאל ואשאל אותם את השאלה הזאת, 9 יגידו שהם מרגישים שחסר להם כלים, ציפיות, אפשרות למדוד דברים.1 כמובן ישקר.
  • #15 הרבה פעמים זה לא באשמתנו הישירה, הארגון כורע תחת העומס ומקבל החלטות של אופטימיזציה לוקאלית
  • #22 למה כתוב? כי קל להגיד דברים וקל יותר אפילו לשכוח מה אמרנו. ברגע שיש לנו משהו בכתב, נוכל להסתכל על זה פעם בתקופה ולחשוב האם משהו השתנה?האם למדנו משהו?האם אנחנו חושבים אחרת?