Oren Ellenbogen's Blog

Team up: my presentation is available

Oren Ellenbogen — Tue, 01 Mar 2011 12:06:18 GMT

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"

Team up

View more presentations from Oren Ellenbogen.

Subscribe to the new lnbogen feed (via feedburner)

Oren Ellenbogen — Tue, 18 Jan 2011 11:17:31 GMT

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.

Pizzability at Delver (Pizza + Usability testing)

Oren Ellenbogen — Tue, 11 Jan 2011 13:12:54 GMT

We just had our 1st Pizzability at Delver. There were 25 of us, from development, QA, HR, Project and even Marketing. We basically ate pizza and saw a few usability videos made by real users at Delver. The goal was to have fun and allow people to sit back and relax (between each bite) while watching how people are using our product. This, I hope, will help connect even further “the makers of Delver” to our users. Bon appetit!

I forgot to write down what I’m trying to learn

Oren Ellenbogen — Sat, 08 Jan 2011 23:31:17 GMT

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!

Why using roles and permissions internally? Trust died?

Oren Ellenbogen — Sat, 31 Jul 2010 09:48:22 GMT

In almost every management tool out there, there is a sophisticated roles and permissions system that allows you to pick what your developers / product manager / project manager can or cannot do with the system. “You can move a Feature to In Progress only if your Team Leader authorize it”, “Only product manager can create new Feature”, “Only Project Manager can start a new Sprint”. I see it happen sometimes also in source control tools “You can commit only after your Team Leader checked the ‘code review done’ checkbox” or “Only Team Leader can commit code”.

Again, this is an internal system being used inside the organization!

I think it’s a destructive and counterproductive approach. People will stop using tools that are making them less efficient. If I know that only my Team Leader can commit my code, I’ll probably commit once a week or once a month as I cannot sit and wait for him every 10-60 minutes that I normally commit. Same goes for management tools. People will not use the tool to its full potential, if they’ll need to send emails such “can you please create this feature for me?” or “can you please approve this feature so I could start working on it?” What’s the point? I can create tasks in my OneNote or excel file and keep moving from there.

This way, data becomes less relevant, less honest, less up to date. You should trust your people to act smart and train them to utilize tools better.

How do I recover from disasters?

two words - backup system. Usually it’s really simply to backup your data every X hours (or minutes) and rollback if disaster occurred. Your people will get better as they’ll practice more often, get feedback from you and adjust. This will prevent disasters from happening to begin with. Backup system should allow your teammates to practice often, this is their safety net. Don’t use roles and permissions to create virtual trust or avoid personal headaches. At the end of the day, it will cost you more.

Sprint Planning versus Version Planning

Oren Ellenbogen — Sat, 31 Jul 2010 09:08:30 GMT

Should you start with planning your sprints and then see how it fits your versions? Maybe start with versions and understand how your sprints look like? Maybe planning versions by themselves is enough? How do you start?

Decouple external planning from internal planning

External value (features your customers will enjoy) moves the organization. It is why you get paid. No one will pay for “let these kids develop for fun only”, this is why open source projects were born, for developers to write some code that may or may not be used by others. Versions are communicated out to your customers, named in a language your customers can understand “in version 1.0 we will allow our customers to upload their profile image” rather “we will integrate jQuery and develop highly scalable upload mechanism over Amazon Cloud”.

Internal value (features your organization will enjoy) keeps the organization fully operational, doing its best over time. It is usually not communicated out (your customers don’t really care if you’re using C# 4.0 or C# 3.0) and not named in customer’s lingo.

Versions are more tangible

Most of us stick to planning versions and our sprints actually look the same as our versions. We’re results oriented and we want to please our customers. Moreover, no external power is actively pushing us toward internal value.

Sometimes internal value > external value

If you’re strictly results oriented, you might produce great results but only for short, unpredictable periods. Sometimes you’ll need to delay customer’s value to handle broken “machine” in your factory. Your customers won’t like this delay, but they will understand it if you’ll offer tradeoffs and communicate “we are fixing internal machine to keep our high level of production steady”. They will prefer stable producing rather than insane, poor quality or unpredictable results.

Use Sprints to prioritize internal value with external value

Maybe you can devote 5% of the sprint to maintain your ability to produce fast? Maybe 10%? Maybe 1%? It’s really up to you to figure out what you want to push every sprint. Be careful of dismissing internal value, it’s your role to actively push for it.

How do I start?

I prefer to set some goals for my sprint first: (a) is there an internal value I want to push? (b) Are there people in my team that I want to push by leading features? (c) What is my team availability for this sprint?

With this in mind, I’m starting to plan my versions for the sprint and next one, making sure I understand perfectly what should enter the sprint and when. This is the first time I validate my plans. If the planned versions fully occupying my sprint (or even more than that), I raise a flag and trying to figure out if something can be shifted without causing damage. If not, and I have some “buffer”, it leaves me with understanding how much of my internal value I can push inside the sprint, alongside external value. This is the second time I validate my plans. Did I manage to push my goals to the sprint while producing external value? If I notice there is a big need for internal value that cannot wait, I will try to understand alternatives with our product team and supply tradeoffs.

Then, all is left is to organize when should each feature start/end and making sure external value (versions) are released on time while internal value is keep moving. Keep your head above the water, plan to last.

Should you allow changes during Sprint?

Oren Ellenbogen — Fri, 23 Jul 2010 22:26:50 GMT

Sprint is a planning unit, keeping it stable during that time allows a pretended piece of mind for the developers from marketing/product ever-changing demands. So it feels anyway. We developers signed up a virtual contract with our product teams saying “we will be Agile enough to allow you to change your mind every 1-3 weeks, but don’t disturb us during that time! We want to work, not wasting our time on talks!”.

Does it make sense to you? Is this the true notion behind Agile? Would it be acceptable for a great business?

Well, it makes sense only if you think that waste is more valuable than your attention. Delaying smart decisions or cutting off bad ones after 2 weeks, 2 days or even 2 minutes is simply counterproductive. If you know that a feature selected for the sprint became a waste due to priority change, why should you move forward with it? why throwing the problem to the other side of the fence: “well, my product team should have been wiser with their priorities. We’ll do it anyway just to teach them a lesson so they won’t do it for next sprint!”

Priorities tend to change. It happens constantly. Don’t panic, be open-minded and make sure your team leaders can handle priority shift. It’s perfectly okay to say no, but make sure it’s a “reasonable no”. If you see it does make sense to move out some features and move in some others, do it with care, offer tradeoffs (“this change might mean we won’t be able to release the version on time, let’s delay it in 2 days”) and make sure motivation passes to your team. Your teammates need to realize that providing organized waste is plain dumb; they also need to trust you doing these changes with full attention, clarifying tradeoffs and setting expectations. Practice your agility!

Why tracking Actual Hours is so imperative?

Oren Ellenbogen — Fri, 23 Jul 2010 21:55:49 GMT

After bashing prediction systems, claiming that measuring performance of your teammates to predict release dates or personal behavior is inherently wrong, you might deduce that I meant “measuring Actual Hours is pointless”.

On the contrary my friend, I believe that tracking Actual Hours is imperative for better planning and cutting off waste.

Translate internal units (Story Points / Ideal Days) to external units (Calendar)

How can you translate a 3 Story Points or a 3 Ideal Days to “it will be ready next Tuesday?”
Using Actual Hours, you could actually see a correlation between Story Points size (internal to the organization) to total amount of Actual Hours Range (external as you can put it on calendar). For example, you might notice after a few sprints that 3 Story Points (based on latest 5 features), are usually taking 23-28 Actual Hours to complete. Assuming you pick a number, say 6, as the amount of Actual Hours in 1 day a developer can do, such features will translate to around 4-5 working days. Story Points can be translated quickly, based on empirical knowledge, to a range of working days. This will make release dates predication much easier, assisting your Project Manager and your Marketing team to communicate it in their roadmap or create plans accordingly.

Actual Hours help to quickly balance effort in a Sprint

You’re on the first day of the Sprint and you’ve got seven Features (/ User Stories) in “Not Started”. You also made sure that people availability (Joe got 50 hours this sprint) is updated as some have vacations and some got exams during the sprint. Even more, you already decided who is the owner of each Feature. How can you balance the tasks effort, in hours, between your teammates? how can you decide if some features will be developed by multiple developers and still see that your plan is feasible?
With Actual Hours history, from the example above, you can see that 3 Story Points translate to 23-28 hours. You can immediately add to all features worth 3 Story Points one task called TBD with 25 hours (~avg) and assign it to the owner. You move to each one of your features, checking their Story Points -> Actual Hours range, adding the task. Next, you slowly break this big TBD task, in each feature, into multiple TBD tasks, each with different owner and estimation, until you see that the effort is balanced between all of your teammates.

2 flows for example:

a. 3 Story Points (range: 23-28 hours) -> 1 task worth 25h for Joe -> 1 task worth 10 for Joe, 1 task worth 5 for Jim and 1 task worth 10 for Annie.

b. 2 Story Points (range: 10-18 hours) -> 1 task worth 14h for Jim -> 1 task worth 10 for Jim and 1 task worth 4 for Annie.

c. [ … until all work effort are balanced by availability and optimal ownership … ]
d. Make sure that your breakdown makes sense in terms of people availability. Make changes if needed.

Summary

Actual Hours are imperative as they (1) provide a way to translate internal work units to external work units and (2) allowing fast effort breakdown. The key is to set expectations right with your teammates, explaining why their performance measurements are so crucial and how they will be used. They need to understand so they will be able to honest, to have an incentive to help you. Don’t break their trust.

Story Points over Ideal Days?

Oren Ellenbogen — Thu, 22 Jul 2010 12:10:48 GMT

Many teams going into Scrum, have internal debates around whether or not moving to Story Points or sticking with Ideal Days. It seems that there is a lot of personal feelings involved.

Ideal Days – what is it all about?

Just imagine a work day without any meetings, phone calls or people bothering you. It’s a full day of making things done, full day working solely on your tasks, whatever that means.

Story Points – what is it all about?

Story Points are a bit more abstract notion. It includes 3 parts: Work Effort (how much effort the work will take), Complexity (implementing known yet complex code) and Risk (3^rd party integration, POC required etc). It inherently abstracts away the “who” to allow you to consider the “what”.

Estimation is expensive

I’ve said it before - estimation is expensive. You should find ways to make your estimation faster, unless you were specifically required to execute the Feature or bringing a super detailed estimation. If it’s not the case, and you were asked for numbers to determine Product Roadmap or feasibility of features, stick to fast gut feelings, may it be private hunch or collaborative hunch.

Fibonacci size – what is it all about?

To make estimation faster, it’s easier to have smaller list of options to pick from. For example, instead of picking a size from 1-100, you should pick from a smaller numbers range, like Fibonacci: 1,2,3,5,8,13 and then go to 20, 40, 70, 100. Why the jumps? Because the bigger the estimation, the bigger likelihood of being wrong or wasting too much time discussing how wrong. So instead of arguing on whether it’s 6 working days or 7, you just pick 8 or 5, depending on the specifics (effort, complexity, risk). The purpose is to estimate fast, not to be 100% precise.

Using Anchors

Usually, the idea is to price Features (or User Stories) against other Features *like* them. “This feature is around the same effort as that feature so it will be 3 Story Points as well”. After picking a few Features as “baseline”, it’s easier to estimate faster others features against them.

Ideal Days baggage

I personally believe that Ideal Days brings too much baggage into the discussion (making estimation slower):

1. Who’s Ideal Day? How long is one Ideal Day? Each member will consider her/his Ideal Day. Instead of focusing on fast estimation, everyone passing in their head “well, Joe is new in the team, it will take it twice as much! Let’s price it as twice as much then”. Story Points “don’t care” who is implementing the Feature. This is exactly how it should be done as you never really know who will actually be the implementor until you start working on it.

2. Ideal Days are not strongly correlated with estimating Complexity and Risks: People have in mind, when using Ideal Days, mostly effort involved. Story Points, due to its abstraction level, allows better focus on Complexity and Risk.

Matter of flavor, I guess

Anyway, I feel that it’s not really important whether you’re using Story Points on Ideal Days, as long as you (1) remember to price Complexity and Risk as well; as long as (2) you understand that estimation is expensive. I feel that Story Points offer better abstraction which allows faster estimation, but it’s really matter of “whatever works”.

Write down Estimation Reasoning!

Make sure you keep your estimation reason. “We said its 5 Story Points because it’s ~3 Story Points for effort and ~1-2 for Complexity and Risk. We felt good enough with 5 Story Points.” Why? If you would like to use this estimation as an anchor in the future, while trying to estimate a new feature, you should remember what the original 5 Story Points meant for you: “Was it 5 Story Points only because of effort?”

Experimenter's bias kills software predication

Oren Ellenbogen — Wed, 21 Jul 2010 21:58:13 GMT

“In experimental science, experimenter's bias is bias towards a result expected by the human experimenter.” – Experimenter's bias, Wikipedia.

Almost every management tool out there attempts to provide estimation regarding when the feature / user story / version / release will be ready. Fogbugz took it to extreme with their Evidencing Based Scheduling, others such VersionOne and Mingle use pretty graphs or other visuals to achieve the same.

“Computer, when it will be done?!”

I think there is an inherent paradox with such prediction - it depends on developer’s honesty. You must ask yourself what is the developer’s incentive to fill the information as it is? why should she or he be honest? The way I see it, developers are staying in their safe zone, pricing things in high enough granularity (around 8h or more per task) and fill the actual or remained hours so they won’t look bad or good. They just want to be right. Why? So they won’t appear as too optimistic or too pessimistic to the prediction system their boss is using to plan the next few releases. It actually makes sense; the predication system caused the results to behave as expected by driving developers to “safely” play with the numbers. The actual, somehow, always equals to the estimation! How nice!

The second you’re telling your developers that their estimated and actual hours are being used directly to predict the future, don’t be surprised that it will be the future they want you to see. This is why I’m not convinced about using Actual Hours for readiness prediction or judging if a teammate is over optimistic/pessimistic.

As a team leader, you should care that your teammates will learn to estimate better, to allow themselves to be wrong, without everyone to see it on their prediction tools. They need to make mistakes and get personal feedback. People over Tools !

Why should you still use Actual Hours then?
More on it to follow…

Why should you strive for moving Features to done?

Oren Ellenbogen — Tue, 20 Jul 2010 09:36:20 GMT

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!

Estimating Features: options, context and God

Oren Ellenbogen — Mon, 19 Jul 2010 22:09:30 GMT

“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 3^rd 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…

Planning your Sprint

Oren Ellenbogen — Mon, 19 Jul 2010 14:17:56 GMT

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.

צשןך

Oren Ellenbogen — Mon, 19 Jul 2010 12:49:09 GMT

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

Visibility over Progress

Oren Ellenbogen — Mon, 19 Jul 2010 12:34:17 GMT

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:

Do you fully understand the Feature business value?
Do you have Risks mapping (what can go wrong and what to do on such case)?
Do you have the right people in-sync? (QA, Operations or other relevant team members)
Do you break the Features by layers or by verticals? Are you OK with that?
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?
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.

Lnbogen meets Facebook Like

Oren Ellenbogen — Thu, 15 Jul 2010 12:58:52 GMT

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

Adjusting big Features to Sprints

Oren Ellenbogen — Tue, 13 Jul 2010 12:46:33 GMT

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.

Beautiful Code?

Oren Ellenbogen — Tue, 13 Jul 2010 09:44:27 GMT

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:

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.

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.

How to break Feature into Tasks: no leftovers!

Oren Ellenbogen — Tue, 13 Jul 2010 08:44:19 GMT

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.

Technical Features (in your) backlog

Oren Ellenbogen — Mon, 12 Jul 2010 11:20:28 GMT

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.

How to break Feature into Tasks

Oren Ellenbogen — Mon, 12 Jul 2010 09:41:50 GMT

There are many ways to take a Feature and break it into workable unit of Tasks. Measuring “breakdown quality” is being ignored most of the time, as it’s very elusive to define “good breakdown”. The ability to break something into smaller pieces is one of the biggest signs of an experienced craftsman, so you should definitely challenge yourself by asking: am I known for predicting work effort well? detecting edge-cases early? Communicate progress to my boss clearly? being able to work with others on the same thing smoothly?

Introducing a Feature

Before we can play with breaking Feature into tasks, we need to have an example of a Feature in front of us. Let’s pretend that our desired Feature is “Signup and Sign-in” where to goal is to allow users to register and sign-in to the system. Next, here are the flows:
1. User can enter the signup page, if she’s not currently signed-in (else - redirect to homepage).
2. User can enter his details and signup.
3. User details will be validated, by [rules]. If failed - user will be asked to fix and re-send.
4. User will need to confirm her signup via email, before signing-in.
5. User can sign-in only after confirming her signup, if pending – show message.
6. User can sign-in in case she’s not signed-in already, using her credentials.
7. User can sign-out, only if she’s currently signed-in.
8. Page header needs to show relevant links, according to whether or not the user is currently signed-in.
9. If user fails to login multiple times (configurable), deny login for X minutes
…
[a few mockups here, a few technical/business notes there regarding URL structure, SEO to have in mind, analytics requirements, etc]

Breaking by Layers, the common way

A very common way is to break Feature by “application layers”:
1. Adjust database schema.
2. Create Data Access code to allow persistence of user (details, credentials encrypted etc) and retrieval of information.
3. Create Business Layer logic to validate credentials, confirm signup, perform sign-in.
4. Add signup and sign-in pages, alter header according to user state.
5. Add relevant validation on client side via javascript.

You can imagine that each task here will be a priced as 10-15 hours or even more, according to the implementer and the exact details. If the implementer founds an edge-case, it might mean that the every one of the layers here will be affected by it, making the estimation even less reliable.

Breaking by Verticals

A different approach will be using the flows above to form the tasks:
* create readConfiguration helper method
* create validateUserDetails method for server side
* create generateConfirmationNumber(userDetails) method
* create(/use) email sender provider
* create validateUserDetails for client-side
* create signup(userDetails) - schema to store user details, Data Access and Business to validate information and activate generateConfirmationNumber for sending confirmation email.
* create signup page (using validateUserDetails, signup method)
* create signin(credentials) method – schema to store number of login attempts, Data Access and Business to validate information, blocking user due to multiple attempts.
* create confirmUser method - Data Access and Bussiness to validate confirmation
* create signup confirmation page.
* create signin page
* create isLoggedIn method
* change header links according to status (via isLoggedIn)
* redirect user on entering signup page when currently signed-in (via isLoggedIn)

It’s not a 1:1 match between Task and flow, sometimes one flow will require multiple Tasks, but the flows drive the breakdown. No doubt, all of the tasks here are much smaller, each will take around 1-4 hours and very self-explanatory.

Why should you prefer Verticals breaking?

Confidence in achieving progress: if you strive for small tasks (up to 3-4 hours), it means that you’ll need to understand exactly what is needed to be done before committing to it. Every time you’ll finish a task, you’ll feel better that you’re moving on the right path. Because tasks are small, you will enjoy this feeling a few times during a day, which is important. You need to run away from “I wrote some code today, but I’m not sure if I’m on track”, poor planning will make you feel unproductive for long time.

Provide complete context to allow sharing workload: what happens if you need someone else to assist you? If you work by layers, it’s hard to understand “what is done”. The context is the entire Feature, which is too big to share easily. By working on vertical tasks, the context is much smaller as flows are smaller unit of execution. If you’re stuck, you can raise the flag and ask someone to assist you by taking a few vertical tasks and make them happen. They’ll have no trouble understanding what needs to be done.

Confidence building: make it part of your Sprint

Oren Ellenbogen — Sat, 10 Jul 2010 22:55:55 GMT

One of the responsibilities of a great execution team is to make sure they will deliver in great speed and great quality, over time. “It’s a marathon, not a sprint” might be a confusing statement if you’re actually using Sprints in your development process ;)

What do I mean by “confidence building” and how does it affect you? Well, I believe that you need to earn others confidence over time, making sure your customers, internal and external, are happy with your results. For that you’ll need to make sure you understand what’s expected from you, to reach deadlines on time, to raise the Red Flag early and offer alternatives, to deliver product with great quality and to produce estimation that prove themselves as meaningful. Your job is to keep the execution machine at full speed and building the confidence as you go.

My recommendation is to make sure your Sprints will contain some internal maintainability time so you could stay on track rather than “have a good Sprint once in a while”. Here are a few thoughts:

Bugs elimination – making sure the backlog is not overwhelming. Pick wisely, based on ROI given by product and technical teams.
Provide rough estimation on the Features in the roadmap, review previous estimations and see if you were close.
Push small POC for risky features to come.
Create technical design for big/risky features you plan to address next sprint.
Eliminating technical waste – small refactoring to enhance team productivity.

You can either treat them as features, or simply buffer some availability of the team to handle this.

No matter what, do not burnout the trust people have in you; your boss hired you because s/he trusted you to do well, it doesn’t mean you don’t have to work hard and continue to earn her/his confidence in you. It is a marathon, after all.

User Stories do not replace Features

Oren Ellenbogen — Sat, 10 Jul 2010 21:18:54 GMT

User Stories became very trendy when Scrum became popular due to its smaller abstraction level; this made it possible to break big Feature and adjust its pieces into a single Sprint. I think this was taken too far, where User Stories sometimes completely replace Features. Not only I believe that Sprint should not be a release unit, I also believe that User Stories are not the correct work unit in a release or a Sprint:

1. Losing the why –User Stories by themselves are incomplete: they are missing the *why* - why do we think it is wise to develop this all experience? User Story describes only a small portion of a full experience. If we want to have real discussion on the value of a new capability, we must understand the full picture. The value always lies in the forest, not in the trees.

2. User Stories are usually not valuable to the customers by themselves - If you break a Feature into 20 User Stories, how many completed User Stories are enough to release the Feature? You cannot give your customer the Story of “A user can enter his password, the system will validate it by [rules]” without actually letting him register to the system. Your customer might enjoy tracking the Feature as you develop it this way, but you probably cannot release a version with 2 User Stories out of the 20 needed.

3. Maintaining another abstraction is expensive – what happens if a Feature changes? If you’re holding your User Stories separately, you’ll need to update them. Sometimes, as mistakes being made and it’s hard to sync papers, you’ll update one and not the other. So your business team, as an example, will work with the Feature paper but your QA team with the User Stories. Abstraction is smart only if it is beneficial over time.

I believe that User Stories are too pricey to be used as planning and execution units; they abstract a lot of the significant value Feature has to offer and introduce fragility in the process.

What User Stories are good for?

I would use User Stories only as a lingo between developers and business/marketing teams. They are small enough to be discussed without thorough background and big enough to explain behavior and expected outcome. I would not use User Stories to plan my sprints or my releases; I would aim to work in units I can deliver to my customers and discuss value of complete experiences.

How to adjust a big Feature into a Sprint?

Why Feature should detail full experience

Oren Ellenbogen — Sat, 10 Jul 2010 17:00:49 GMT

Sometimes, multiple Features offer multiple experiences to the same motivation/goal/pain.

This is why it’s so crucial to document the why, the motivation, the pains, the reasoning behind a Feature. Although “The why” is crucial, it is not enough by itself. A great Feature must also detail the experience our users will enjoy, may it be capabilities, flows and look & feel. Only then, we can understand the purposed reality, before it is a reality - before we develop it and spend money to bring users to play with it.

With that, a real discussion on whether this Feature will be the best way to achieve this goal can take place. If you let your team be part of your vision building, by sharing the pains and goals, you can get invaluable internal feedback during “thinking time”. Fixing the Feature flows, improving usability or look & feel, before it’s developed, is always cheaper than doing it after it after the fact.

How User Stories were born

Oren Ellenbogen — Sat, 10 Jul 2010 16:30:28 GMT

“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...

Feature, User Story and Task

Oren Ellenbogen — Sat, 10 Jul 2010 12:45:57 GMT

Many confuse the terms Feature, User Story and Task. I believe it’s important to grasp the difference between them as each one serves different purpose and sometimes even different audience.

Feature

Feature is a detailed experience of how your users will do something with your application. In order to make “something” meaningful, a Feature must include (1) the reasoning behind it, the motivation, “the goal”, “the pain to solve” – without it, it’s simply impossible to judge Feature’s ROI in terms of value versus effort and money. Once this is in place, Feature should include (2) user flows. A user flow might be “User can click on the delete button to delete his record, this will popup [a message] for him to verify first”. Usually, a Feature will be built from multiple flows, edge-cases and wording to make sure the grand experience is fully complete. To help relating flow with look & feel, a Feature should (3) include mockups and other accessories. Lastly, (4) business (and even technical) notes should be added to wrap up the experience: URL structure, SEO considerations, user messages user, analytics requirements etc.

Language: customer’s lingo.
Estimation Size: Ideal Days / Story Points / T-Shirt sizes
Clients: Internal and external: development/marketing/business/analytics teams and also your customers (to share with them on feedback forums, blogs).
To Include: (1) reasoning (2) flows (3) mockups and (4) business/technical notes.

User Story

User Story is a single “user flow” from a Feature I described above. “User can enter his password and re-enter it for password verification. If the passwords are not matched, the system will show a message”. Another example: “User can enter his password; the system will check the password’s strength by [rules] and notify the user if the password is not strong enough”. By itself, from User Story is hard to understand the entire picture, but it’s a smaller unit of work to plan and execute by.

Language: customer’s lingo.
Estimation Size: Ideal Days / Story Points
Clients: mostly internal, sometimes external - some User Stories just don’t make sense on their own, without the Feature as complete background.
To Include: (1) flow (2) mockup and (3) business/technical notes.

Task

A task is a specific “todo” with a given work estimation. A Feature can be broken into multiple tasks and so does a User Story. A task will be something like “Add new column to database called Rate and model it in the application – 1 hour of effort”, or “create javascript function to validate input on price field – 1.5 hours of effort” or “create landing page for our campaign with Nike and connect it to our analytics system – 3 hours”. Task resolution will always be much smaller and much more technical than Feature or User Story. It will explain what to do rather than why.

Language: development/marketing/business lingo.
Estimation Size: Hours
Clients: internal only!
To Include: technical information needed.

Great Sprint Demo: the recipe

Oren Ellenbogen — Thu, 08 Jul 2010 21:12:44 GMT

As I mentioned, you should not tie sprints and releases together. I thought to add a few notes about what will make a Sprint Demo really great. Luckily Moran Haviv, our legendary Project Manager at Delver, wrote a great recap I thought to share with you:

Why Sprint Demo?

· The primary purpose of the Demo is to communicate, share and celebrate what everyone managed to do in the last sprint and what is the value of it for the user/Organization; In other words: what are we doing here and Why are we doing it?.

· Collect valuable feedback to make sure our users will love our product as much as we do!

· Teams gets to show off with their output/artifact to everyone; (even if the software has no UI it might yet deserve to be presented by a good story).

A few guidelines for preparing great demo

Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
What is a good Story? Or How can you tell it :
- Use a meaningful relevant theme;
- Demonstrate sequence of events as the user would experience them (tell the story);
- Use realistic data and characters—use examples and names from your user community or members of the development team;
- Make it Exciting and Entertaining
Keep it short. focus on what’s interesting and what’s valuable about your feature (you don’t need to exhaustively cover all your acceptance criteria).
Prepare. Create any necessary test data.

Version: extract releases from sprints

Oren Ellenbogen — Thu, 08 Jul 2010 21:03:19 GMT

Separation of Concerns

Working by the “scrum book”, sprint is also a release unit, in which you want to complete all the effort you committed to your clients and demonstrate it at the end of the sprint. Well, not in my book. Sprint should be remained an internal unit of time. Sprint is used for planning, for doing and for reflection, to make the team work better over time. It doesn’t mean that your customers will enjoy adjusting to your schedule.

I prefer to leave release cycles outside, as they are external unit of time. You need to adjust them to your customers, not the other way around.

Let’s say that you picked 3 weeks as a sprint size after considering “big enough, small enough” values. If you tie sprint and release together, that means that your clients will see things every 3 weeks. That might be fine, but it won’t allow you to challenge yourself to reduce release cycles. Even worst, the customers might demand a shorter release cycle to earn confidence in your delivery. A dangerous move, in my opinion, is to reduce the sprint size to match desired release cycle. This move might violate the “sprint should be big enough to avoid unacceptable overhead of planning/reflection” principle. Yes, your customers will be happy but your developers won’t. It won’t last. You want both internal team and external customers to be happy and enjoy a process that pushes them forward rather than pushes them around.

What is a Version?

Version is just a bunch of capabilities with a specific target date attached to it. Version is easy to communicate out: “we plan to allow a user to upload image, crop it and update his profile image in version 1.1, which is targeted to July 20th”. Basically, for each targeted date you specify a list of features, enhancements, reports etc. The customers gets to say when the versions should be aimed for, according to their needs.

What does it mean about Sprint Demo then?

Well, if the release cycles are shorter than sprint cycles then the Sprint Demo will become a show off by the team to each other rather to your customers. Obviously, you may want to add another “Release Demo” meeting for your customers (and maybe include the team in it). By doing Sprint Demo internally, the teams will get the chance to see what’s going on “on the other side of the corridor”. Oh, did I mention that this is also fun? It allows the organization to collect valuable internal feedback to make sure our users will love our product as much people who wrote it!

Sprint: plan just enough, do it, reflect

Oren Ellenbogen — Thu, 08 Jul 2010 19:36:38 GMT

“Sprint” – what does it mean?

Note: my definition of sprint is not by the book. It’s perfectly fine by me as I love adjusting theory to practice; I hope it is okay with you as well. Basically, a sprint is just a time window that you plan to achieve something at. Just imagine a box with your interesting “todo” notes. For example, in the next 2 weeks you may want to plan to perform some proof of concept for your initiative; plan to create 3 landing pages to check which one covert users better to registered users; plan to write a tutorial or even plan to upgrade your team’s computers.

Why do I need to define a specific time window then?

The idea of a sprint, in essence, is simply to (1) ease psychological acceptance of changes and (2) allow shorter, just-in-time planning.

Specific time window, made constant (sprint after sprint), allows you to understand that things might change and you now made mental and physical “room” to adjust when needed. It’s a bit of sugarcoating, of course, but it’s making the transition smoother.

The just-in-time planning part is more “acceptable” when you’re embracing the fact that it’s too damn expensive trying to break all effort into small pieces. You’re customers are “allowed” to change their mind, so – what’s the point of understanding that something being requested for next year, will take 121 hours to develop? In 2 weeks, hell, in 2 days, this effort might cancelled. Breaking future effort to small pieces is great, but only if it’s extremely cheap to achieve or extremely relevant now. Until then, you might be okay with high level estimation.

The perfect size: big enough, small enough

Sprint should be big enough to (1) achieve meaningful progress and (2) avoid unacceptable overhead of planning + reflection. That means that if your smallest effort is always at least 1.5 weeks, don’t use 1 week sprint. If you need a full day to plan a sprint and another to reflect on how it went, don’t use 1 week sprint. Otherwise, your people might feel “we’re doing nothing but planning and reflecting”.

Sprint should also be small enough to allow to reflect and adjust often. Just like “release often” attitude, adjust often will make the organization work better, faster. Don’t dismiss it lightly.

How many sprints should I plan in details?

Good question if I may compliment myself for asking so. I would aim for detailed plan at least 1-1.5 months in advanced, unless you’re in a really volatile market and 1 month is “too far”. If your sprint size is 2 weeks, then I would say around 2-3 sprints. By saying “in details” I mean very detailed understanding of effort, real breakdown or very solid understanding, based on similar effort in the past or one-of-a-kind magic ball. The idea is to have good image of near future; this will obviously be expensive to create, but will give you confidence on how to achieve the most important goals on your table.

I would try to understand what’s coming later on (3-6 months), but invest much less time and stay with high level estimation. I don’t want to waste time on planning potentially irrelevant effort.

Natural dependencies planning

When sprint size picked wisely, there is much “smoother” feeling of dependencies planning. There is no real need for Gantt or something of that sort, thank God. Everyone will be aware of the effort being made in the sprint and will align dependencies accordingly. The feeling will be more natural, more just-in-time rather the stating “we need infrastructure team to finish in 6 months something so we could use it 9 months from now!”. It doesn’t mean that dependencies planning is gone out the window, you’ll still need to do so for big infrastructure effort, but you’ll see that it happens less than you were used to. This is a good thing.

Reflect and adjust

At the end of the sprint, it’s a great time to sit down and consider what went well, what wasn’t (take Action Items) and what can be done to have better sprint next time. You’ll adjust to external changes better when you’ll adjust to internal pains better.

I thought that Agile == no planning

Now, that is just sick. Seriously, no one is expecting you to work badly. Great planning is the only way to produce great products to your customers, deliver it on time and with high quality.

Not all planning are born equal

Accept it, plan accordingly :)

Delver beta is alive!

Oren Ellenbogen — Thu, 13 May 2010 10:53:37 GMT

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