Self Management

by Oren Ellenbogen on Agile, Management, Self Management

Why should you strive for moving Features to done?

If Sprints are not execution unit, what is the rush of moving Features to done as soon as possible during a sprint? Why should you care about it if you’re not limited by end of sprint deadline?

Other than the fact that done is fun ™ (obvious sense of accomplishment), striving for done features will push the entire team to excel. I’ll try to cover it from two angles, manager and developer.

Nothing new, you commit to version instead of Sprint

The only difference of introducing versions to decouple execution from sprints, is that you commit to version rather than sprint. So far, no big change, you need to release on time to allow fast feedback by your customers. It’s the same “Agile attitude”, the same fuzzy feeling in your tummy.

From Developer’s point of view

1. Prefer small amount of WIP (Work In Progress) – we are poor with multi-tasking and we hate to get back to things we thought we already finished. If you aim to move Features to done, you can be more confident moving forward without leaving some concerns behind you.

2. Practice Growth – the more features you’re estimating, breaking (into tasks) and leading, the more you’ll improve your communication and leadership skills. Because all of the above is so hard to get right, you need to practice as much as you can to feel comfortable leading bigger features over time and later on, if desired, leading your own team. Great leaders not only know how to push features but they also can explain to others how to get better at it, to share feedback. For that, you’ll need to practice enough, to reflect enough, until you really grasp the complexity behind it.

From Team Leader’s point of view

1. Prefer small amount of WIP – you should prefer 7 features done from 9 planned rather than 15 features in progress from 20 planned. You cannot deploy half-baked features thus 15 features in progress means zero value to your customers.

2. Create predictability by making Velocity graph stable – If you want to plan your sprint faster and with more confidence, you’ll need to understand how many Story Points / Ideal Days you’re able to do each sprint. For that, you’ll want your Velocity graph to avoid spikes every sprint (example: 30 SP, 2 SP, 87 SP, 40 SP) but rather have a “stable” Velocity graph (example: 30 SP, 27 SP, 34SP, 29SP). Constant spikes mean that you won’t be able to say how many Features (by Story Points) you’re able to perform. Less confidence => more time spent on planning.

3. Create predictability by making Features Size Completion stable – again, if you want to plan your sprint faster, you’ll need to know how many big / medium / small features you’re able to pull off every sprint or every version. Try to strive for known throughput per feature size to increase confidence.

Planning Sprint, just like estimating features, might be very expensive and hard to nail down. The trick is to create solid picture that strengthen your gut feeling about what you can actually do. With this in hands, you’ll spend less time breaking everything to little pieces or worry about the quality of your plan; instead, you’ll have solid empirical history behind you to back you up. More time for you to get some tan!

 
by Oren Ellenbogen on Agile, Management, Self Management

Visibility over Progress

After talking quite a bit about how to break a Feature into tasks and avoiding leftovers, I would like to address the natural habit of what I call “blindly moving forward”. How often do you find yourself after 3 days of coding, still unclear of how many days are left or whether or not you’re closer to the end? How often you tend to forget what exactly you originally meant by “the end”? How often you find yourself feeling too invested to stop and figure out what the hack is going on?

We are, naturally, very outcome oriented. “I need this Feature done until tomorrow” or “I need to see your plans for next Sprint until end of day” keep pushing us during our daily effort. We are driven to supply outcomes, losing the ability to track the big picture because of vast, ever growing demand for results. Just like multi-threading coding, it’s not enough to throw some languages, tools or IDE with cool debugging options to the mix; we need to change the way we think and act, to supply visibility rather than mere progress.

When breaking a Feature, ask yourself these questions:

  1. Do you fully understand the Feature business value?
  2. Do you have Risks mapping (what can go wrong and what to do on such case)?
  3. Do you have the right people in-sync? (QA, Operations or other relevant team members)
  4. Do you break the Features by layers or by verticals? Are you OK with that?
  5. Do you have low granularity of tasks (up to 3-4 hours)? Enough to make you feel good about “no surprises”? Enough to allow others to join you?
  6. Do you know when you’ll be code-ready? Can you commit to a date?

As a Team leader, you should ask for visibility from your teammates. They should earn your confidence by offering a complete plan, knowing what the expected outcome is and communicate their status during the development time. If you ask me, I will always prefer better understanding of current status over naïve “I managed to progress today”.

As a developer, you should aspire for complete visibility to make sure you’re moving in the right path. This will allow others to give you honest feedback, join you if you’re a bit behind schedule and practice leadership in a way that is building confidence in your organization: people will feel that you know what you’re doing and will trust your good judgment and commitments. They will feel more confident when you’re behind the wheel.

If you feel that this is an overhead, you probably in a misconception of the time it will take you versus the time it will save you. Answering the above shouldn’t take 5 days; it should take couple of hours. This will ease your mind regarding “did I miss something?”, saving you hours of juggling between building confidence with your manager(“Can you update your progress?”, “Where are you standing?”) and actually building the software.

 
by Oren Ellenbogen on Agile, Management, Scrum, Self Management

How to break Feature into Tasks: no leftovers!

Once you decide how to break a feature into tasks, it’s crucial to make sure you don’t leave any leftovers as part of the breakdown. Feature breakdown must include each and every task to make it a complete unit you can deploy as part of a version. Completeness means that not only a Feature is deployable and it can be monitored, it’s also with great external quality (no major bugs left behind) and great internal quality (design-review, QA test-cases review, code-review, UI review).

You want to price a Feature by the gross organization time; this is the only way to understand how much a Feature really costs. Knowing that, you can correctly price future roadmap without needing “Bugs Elimination Sprint” or “Big Refactoring Sprint” to introduce quality after things were delivered to your customers.

No leftovers:

1. Design review – may it be over emails or formal meeting, the design should be solid and well thought

2. QA test-cases review – making sure QA will test the right things or add more test cases for relevant edge-cases.

3. Testing time – writing tests (unit + integration) should be priced as part of the Feature, not after, not next sprint.

4. Code review – for knowledge sharing and internal quality validation.

5. UI review – making sure the UI look & feel just like Product team wanted it to be.

6. Bug fixing + validation buffer – fixing major bugs should be priced as well! if you’re not sure how much time to spend, start with 5-10% of the total estimated effort, and learn from your experience (by Feature size, complexity etc)

You can add more to this list, if the team/organization needs it. The idea is to make sure that once a Feature is complete, you’re feeling great about it and got confidence it won’t be fired back to the kitchen, to cook from scratch. You should have the same confidence about changing an existing feature; it should be easy, voodoo-less and highly testable to do so, with low chances of breaking other flows in the system.

 
by Oren Ellenbogen on Self Management

My reading stack content fillers

After writing about “Build your weekly reading stack and frame it“, I thought to share some of the blogs\articles I read lately about Personal Development. I call them my “content fillers”.



  • Paul’s Tips – You can find here real pearls among the huge content Paul has to offer. He talks about life, creativity, productivity, time management, leadership. I love reading his stuff because it’s an easy read and you can pick up a lot of great life practices(for example: Just being smart isn’t enough if you want to get ahead and A neat trick for dealing with anxiety).

  • ProductivityGoal – Great stuff about Work and Time management (I recommend the category “one question interview“).

  • Steve Pavlina – One of the greatest in the “Personal Development” area. I really recommand reading his old posts. Notice: Almost each and every one of his articles and even most of his blog posts are a great potential for your weekly reading stack (more than 4000 words per article).

  • Scott H Young – I just started to read his stuff about a month ago. So far I’m very impressed by his level of knowledge and his original ideas for life.

  • The practice of leadership – One of my favorites. You will have to look around this site, but investing 1 hour of wandering around in this site can fill your stack for a good couple of years.

  • I will teach you to be rich – Great stuff about money. Facts, numbers, ideas, links.

  • Get Money Online – if you have a site(or even better – a blog) and you want to make money out of it – read it!

These sites can easily provide enough content for a 5-10 years of weekly reading. I’ll publish more during the next couple of weeks.
If you’ve got interesting sites to share – please drop a comment.

 
by on Self Management

Build your weekly reading stack and frame it

For those of you who know me, I can spend about 15-20 hours a week reading blogs\articles about various of topics (which means 1-2 days of work a week!). Sometimes, I prefer sinking into a set of articles instead of doing my chores. Though “free” reading is very important and educational, some tasks must get done. I tend to forget it and then feel uncomfortable about it. I feel like I have an elegant excuse to avoid critical tasks. “Hey”, I say to myself, “It’s important to read about managing my time better or the new features in .Net 3.0, so I’ll read a few more articles and then I’ll complete my Math homework”. The reality is that I finish my Math homework the night before class which is bad for several of reasons: (1) I don’t sleep well the night before, (2) I feel uneasy – “maybe I should have invest more time in it” and (3) It’s “life smell” (the older brother of “code smell”) meaning I know it’s wrong and yet I carry on with this paradigm.


Reading blog posts or articles in “free style” may cause a huge wast of time. It happens to me all the time. I jump from post to post, from article to article and start reading until I’m tired.  About 30% of the information I read I don’t remember an hour later as it wasn’t all that interesting to begin with (but hey, “I can’t stop in the middle right?” says the stupid voice in my head). I enjoy reading technical stuff, but I also learned to appreciate my time. It was time to come up with a system to control my reading and make the most out of my time.


Stack your reading on weekly basics


I managed to lower my wander around posts and articles. For big posts\articles, I read 1-2 paragraphs at the beginning and the last one and decide if it’s important enough to get inside my weekly reading stack. If it’s a small interesting post, I read it all the way (avoiding reading the first & last paragraph again later from my stack) and throw it away(of my mind). How can you save your post\article into your stack? My system is very easy. I’ve created a directory named “Reading Stack” on my desktop, there I use the browser’s “Save As…” menu item in order to save an offline copy of the post\article.


This directory must fill just enough data to read for one week. No more and no less. I don’t want to carry my reading material from one week to the next one as it will decrease my motivation in time (“damn, I can’t seem to overcome the amount of data I want to read” syndrom). I read about 7 big(~3000-5000 words) articles a week and about 50-80 small ones(from my SharpReader). I pick my articles very carefully and thus using my time wisely as opposed to before where I’ve read a lot of useless data and wandering around blogs.


Frame it (with time)


As I’ve mention, packing the data is hard but not as hard as finding the time reading it. You must find some time in your schedule to invest for reading (it takes about 5 years of 1 hour reading a day to become an expert in a given field). Try to find some “delta” time that you’re currently not using. For me, it was the time before my university classes and during some of the breaks. I usually arrive to my class(with my laptop) about 20 minutes before the lesson starts. This is ideal for reading almost 1 big post\article. I sometimes read during the lesson itself (watch out for this one, I won’t recommend it for anyone, but it works for me) and read a few paragraphs during the breaks(while talking to folks at my class). I usually manage to finish about 2 big posts\articles during one class. Luckily I have 2 of them during my week so that 4 big posts\articles. The remaining reading I do in the weekend, but I have only 3 left so it would be much easier to finish (Weeoow! one more tasks is done!). Try to figure out your “dead” time (waiting for a doctor, watching a game(read along if it’s not that important game), if you use the train – it’s a perfect dead time) and add to it the amount of time you need in order to be happy with your weekly reading.



That’s it. I’m now reading about 25-30 big articles a month which means around 200-250 articles a year! This is a number I can easily live with while still have time for my chores. I feel easy to start reading something and then save it to my articles stack. I _know_ I’ll read it later this week so I’m not afraid of losing this information. I’m still investing a large amount of hours (~10-15) for my weekly reading, but most of these hours are taken from “dead” time I’ve got anyway.