Author: Oren Ellenbogen

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

Estimating Features: options, context and God

“We need to support registration in the application. Here are some details, how many days to develop?” — Where should you start from? Should you simply throw a number? Maybe read it first and use your gut feeling, your experience? Is there a trap here? Although there are no recipes for estimating successfully™, I want to elaborate on the options in front of us, before we dig into the details.

Guesstimate everything months in advance by 20 seconds of thought

If you are able to read a Feature specification and give estimation based on “whatever works for you”, you win! For small features this should probably be as simple as pie, but what about the big ones? Still easy?

“We have someone who can do it with some sort of dark magic ball !”

I call him (or her) God. If you have God in your company, you win!

(1) Estimate by detailed breakdown

Giving proper estimation without feeling bad about it 10 seconds later is not cheap. I don’t care how much experience you have. So, are you ready to invest? You should not only consider coding effort, but also organization time – testing, deployment, monitoring, bug fixing etc. After you have this in mind, did you consider risks? What about 3rd party integration? What about inexperienced developer who might work on this feature?

One way to provide detailed estimation is by actually doing the Design (of the solution) and bring one to the table; This means doing a Design Review with your peers, break the feature into tasks, estimate hours needed per task and give very solid numbers. You can do it by yourself, you can do it with others; the price is not 20 seconds, but this is highly useful for solid estimation.

Wait, Context is king!

Before you start throwing numbers into the air or diving into an expensive design to come up with estimation, what is expected of you?

1. Purpose – how your estimation is going to be used? To determine roadmap? To understand feasibility? For prioritization between 2 Features? Each might require different “estimation plan”

2. Size – is it good enough to say “it’s a big feature” or maybe “it’s around 20-40 days” or maybe “it’s 24 hours”?

Back to your options list

Well, you could estimate by detailed breakdown, if you really need low granularity. Sometimes, rough estimations might be enough. What now?

(2) Estimate by personal hunch

You can obviously estimate based on your personal hunch, taking into consideration organization time, risks and what not. In many cases, assuming you’ve got enough “gut feeling” built by your sheer experience, this should suffice to build roadmap or understand feasibility. If this is the expectation, it’s probably the cheapest way to provide numbers.

(3) Estimate by collective hunch

You can improve (or at least feel more confident) granularity by adding one or more experienced teammates into the mix, double-checking your hunches and forming a collective hunch.

(4) Estimate by team hunch

Again, more people involved might mean better estimation, due to larger feedback. There is the obvious risk of “2 people, 3 opinions”, but at least you’ll have some other, non imaginary, voices of sense.

What does it all mean?

Each method offers some advantages and suffers from some inner faults. Understand the context and pick wisely. Accept the fact that things change and features might be thrown away – do not waste time on estimation more than is really required. More about features estimation to follow…

 
by Oren Ellenbogen on Agile, Management, Scrum

Planning your Sprint

With a given time window and people, how much can you pull off?

Many managers are requested to offer a plan. Knowing how much you can actually deliver is one of the toughest question managers need to face with. It’s too elusive to measure it correctly, and there are many moving parts. You need to please your customers and your teammates, creating a plan to deliver external and internal value, picking wisely what is really feasible.

I tried to come up with a few tips to make this process a bit more structured, making it less elusive, less daunting and less “we’ll see as we go”:

1. Pick by External Priority – what will make your customers happy? Make sure you have the right priority from product / business teams and give it high consideration in your planning. At the end of the day, you are here to provide value to your customers.

2. Pick by Internal Priority – making sure you are building confidence as part of your Sprint. You want to excel over time, you must devote the time to allow it.

3. Pick by Features Size – try to see how many features of each size you can deliver in a Sprint. For example, after 2-3 Sprints, you might notice that you’re usually able to do X big features, Y medium features and Z small features. Usually there is a connection between feature size and QA effort or deployment effort, thus making this size estimation very useful.

4. Pick by Velocity – if you know you’re able to complete X Story Points (or Ideal Days) every sprint, based on your last 2-3 Sprints, use this information to pick Features to fit this number give or take. I always believe that you should aim for ~120%, to allow positive pressure which encourages self-improvement ideas, but don’t aim for failure or naïve success. There is nothing to gain there.

5. Pick by Personal Growth – you might pick some features to allow inner growth in your team. For example, you might notice a need to strengthen one of your teammate’s leadership skills by allowing her/him to lead bigger features. It doesn’t mean you should act naively; organization needs is more important than personal whims, but the organization will never actively push toward personal growth as a goal. It’s up to you to make time for it.

 
by Oren Ellenbogen on Uncategorized

צשןך

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 ;))

 
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 Uncategorized

Lnbogen meets Facebook Like

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 :)

 
by Oren Ellenbogen on Agile, Management, Scrum

Adjusting big Features to Sprints

Many times when picking Features as execution unit, it’s hard to fit a big Feature into Sprint. This always cause the feeling of Features is too big as an execution units, leading some organization to prefer User Stories over Features, wrongfully neglecting Features over time. User Stories as execution unit are not the optimal way to go as they don’t provide enough value by themselves – you need to have “enough” Story Points to release a valuable version to your customers. They are also too abstract to understand the big picture, missing the overall why behind them. I believe that Feature broken into Tasks is a better approach and better execution unit. Obviously, there are multiple approaches to deal with big Features. You should pick the right tool according to requirements and people involved.

Breaking Big Feature, some options:

1. Extract design from execution: You can complete the design of a big Feature in Sprint 1 and implement it on Sprint 2. This way, instead of having a very big design effort and implementation effort on the same Sprint, you can use the first Sprint to understand effort and risks and use the second sprint to implement and deliver the goods, after understanding ROI better.

2. Extract framework from client: User Stories, just like Scrum in a way, introduce too many “Do’s and Don’ts”. For example, it’s considered a “bad practice” to have Technical User Stories. I believe that if the framework has specific needs (raised by the Feature) and it’s easy to break it out from the Feature itself (user behavior), it’s perfectly okay. It’s actually another step in the right way to build confidence as part of your Sprint!

3. Break big value to multiple smaller values (*caution*): Features, by nature, bring a value to your customers. It is possible though, to break the value into multiple Features, each carries only part of the value, without damaging the overall behavior. Instead of creating a “Search Engine” feature, it’s perfectly fine to define “People Search” and “Articles Search” as different features, each bringing different value. It’s even better to define sub Features inside “People Search” to enrich user experience over time, according to feedback by your customers. Caution: you need to do it carefully, sometimes breaking a Feature into multiple Features is silly as each doesn’t bring enough value by itself, until all of the pieces come together. Still, this is a powerful question to use: “Can we deliver real value to our customers by breaking this into multiple parts?”.

Most of the time, your Features should be small enough to fit a Sprint. It’s that simple – if the features are usually estimated in 2 weeks, don’t have a 1 week sprint. That being said, you should have the right (or at least some) tools to handle big Features. If it wasn’t obvious so far, don’t be afraid to “twist and mix Agile”. You owe it to yourself to understand why you’re doing things and adjust it if needed, even if it’s written in some book that it’s a “bad practice”. It might be bad for them, but it might be perfectly fine for you.

 
by Oren Ellenbogen on Agile, Management

Beautiful Code?

I remember enjoying Jeff Atwood’s (aka Coding Horror) post about “code isn’t beautiful”. It took me a while explaining to myself why people are chasing after “beautiful code” so much. Why people are so passionate finding or forming beautiful code? Should great painters talk about beautiful colors or beautiful paintbrushes? I always thought they appreciate the entire painting, created and driven from emotions, dreams, ideas, styles and yes – colors & paintbrushes. They appreciate “the all” more then the exact technicalities. Why are we trying to figure out the best paintbrush to use or the best color? Why not trying to figure out the “best all”, the best experience, the best value, the best process?

I would define Beautiful Software as a surface to allow three magic abilities to emerge:

  1. It should be easy to add new Features.
  2. It should be easy to change existing Features.
  3. It should be easy for new teammate to become productive almost immediately.

If you’re able to have these abilities in your painting, your software, then you’re probably doing something beautiful; you probably figured out the correct paintbrushes, the right colors and most important – how to use them wisely to introduce true beauty.

I am not mentioning pseudo-code, language specific or whether or not testing is worthy. There are many ways to paint beautifully, it is up to you to figure out what makes software beautiful to you and figure out the right tools and process to achieve it. Don’t hang to tight to the “perfect algorithm” or “perfect Design Pattern”. There is nothing neither perfect nor beautiful about color or paintbrush by itself.

 
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 Agile, Management, Scrum

Technical Features (in your) backlog

One of your responsibilities as a developer or team leader is to make sure you’ll be able to shine over time by constantly building confidence. This is why I strongly believe in maintaining a list of technical Features as part of your backlog. These are Features you believe will make the application more robust, provide better monitoring or make the team more productive (& happier) on their day-to-day work.

Have it to pass the message “we leave nothing as technical debt”

When someone in your team says “we really need to refactor this! it way too buggy and we cannot write tests for it”, don’t make it a technical debt that is written as a comment in the code or as a note on someone’s inbox. Make it a Feature, make it part of your backlog, pass the message that even though we cannot fix everything now, we will give it the right attention.

Have it to build confidence

Pick a few technical Features at each Sprint and make them a reality. This will make sure your team will be able to continue to produce fast and with great quality. Plan how much effort, from the entire Sprint, you would like to use to reduce waste – 1%? 5%? 10%? More? It’s really up to you. You need to balance it with thoughts of producing value to your customers while producing value to your team.

Have it for rough times

Having technical backlog is very useful when you need to re-plan the next few versions due to priority shift by the product teams, while your teammates are waiting for work. You can reduce pressure by letting them kill waste while you make certainty in the plans.