4

I am kind of new in agile environment since I always participated in projects before which was only said to be agile while it wasn't.

Now I am really in an agile project and I see a setback - if it is setback - of agile methodology, the lack of pre-planning. I see that our BA talks to key users, collects data, which are pretty much just a sketch what they really want. Then we first need to refactor many of things because the real needs are a little bit different. Then there is a second phase when we realize they need a bigger system we expected, following that we need to make bigger refactor and generalize everything afterwards.

My questions are: Is this the way it should be? Given by the information are we doing it in the good way? And if the answer yes, then does the low planning costs match with the higher refactoring and rewriting costs? So to say: profitable?

CsBalazsHungary
  • 1,389
  • 3
  • 13
  • 15
  • 1
    The point of agile is to provide you a lightweight framework for you to *start* from. Unlike many other development models, you are allowed, and even encouraged to **modify it to suit your needs**. If you feel that you need more up-front planning, **do more upfront planning** – Ampt Jul 15 '14 at 16:14
  • 3
    There's a difference between being agile and being a cowboy. Those who think that Agile means "abandon all planning methodologies" are doing it wrong. – Robert Harvey Jul 15 '14 at 16:15
  • @RobertHarvey I understand what you say, I don't think it is the case here. I suspect there is a huge amount of difference between the information available in the beginning and at the end. I mean if we would solve everything in generalized form, then we would never finish the first sprint. – CsBalazsHungary Jul 15 '14 at 16:19
  • Well, your question is a bit vague. Agile favors iterative prototypes over lengthy planning because the customer doesn't know what he wants. But you still need planning. – Robert Harvey Jul 15 '14 at 16:21
  • Agile to me means not doing all the planning up front or even doing the minimum planning just to get something to barely work. In fact, it is even about planning that there will be things that are out of plan – InformedA Jul 15 '14 at 16:28
  • 1
    Perhaps see this answer: http://programmers.stackexchange.com/questions/78263/how-do-you-explain-to-an-agile-team-that-they-still-need-to-plan-the-software/78351#78351 – quickly_now Jul 16 '14 at 02:42
  • Waterfall means planning for three months, working for eight months, then realizing your plans were crap, planning the refactor for two months, working for five months, realizing your plans were crap, etc. Agile means planing for two days, working for eight, repeat until done, which happens soon because you throw out your plans far less often. You plan less because you catch boneheaded plans faster. – Gort the Robot Jul 16 '14 at 03:58

6 Answers6

12

Then we first need to refactor many of things because the real needs are a little bit different

You are creating a false dilemma.

Real needs are almost always different than what users think/can tell you. Agile attempts to find these differences closer to when the code is written instead of at the end of a full project.

Agile is NOT "we will just start coding and see what happens." If you don't even know what features you are going to be working on for a sprint or they consistently change, have additions, or significant modifications all during the sprint, you are not really doing Agile development.

You need enough planning to be able to do a sprint without revisiting the requirements/user stories constantly. If this isn't happening, you aren't really using Agile appropriately.

This related question describes approximate planning times. You might find this useful. Additionally, this answer directly discusses planning for Agile.

Agile != no planning (contrary to many perspectives...).

Community
  • 1
enderland
  • 12,091
  • 4
  • 51
  • 63
  • 1
    Re:"You need enough planning to be able to do a sprint without revisiting the requirements/user stories constantly. If this isn't happening, you aren't really using Agile appropriately." Even in Waterfall-like you are revisiting user stories and requirements constantly. To say that if you are revisiting then you aren't doing agile doesn't make sense. As you start designing/implementing user stories/requirements it always uncovers new questions. Nobody is omniscient enough to cover everything that could pop up ahead of time. – Dunk Jul 15 '14 at 17:45
  • @Dunk I would only add that some people in some profession can actually cover almost everything ahead of time. This often applies in hardware construction area, and they themselves have decades/centuries of doing trials and errors in the lab and/or with disastrous failures. At the end of the day, it's about how to 'cache' and 'compress' those failures into a knowledge base that can be organized, stored and retrieved easily (either in human brain or set of books, database, library etc..) – InformedA Jul 16 '14 at 01:52
  • I can accept the answer, I feel like having less planning, but it is hard to summarize the planning time since it is very divided by time and it might add up to waterfall planning in sum if the project is big enough. – CsBalazsHungary Jul 16 '14 at 06:26
  • @random:Maybe there is some profession that covers almost everything. However, I can't think of one. Even construction projects which have been done hundreds of thousands of times usually end up having quite a few hiccups. About the only time things go smoothly is when building an identical thing that already went through the hiccups many times over before the system for developing that specific product had been developed. The problem with your "cache" those failures idea is that it only works if you are doing the same thing. Anything new will have its own unique issues that are overlooked. – Dunk Jul 17 '14 at 20:20
  • @Dunk what you said is true, but the point I want to say is that the 'cache' still helps because for things that are not the exact absolute same but very similar, you can still make your subjective decision to apply the 'cache' or not. In many cases, it helps doing it that way. – InformedA Jul 18 '14 at 05:32
3

Define "planning"

By "planning" I think you mean understanding the needs and figuring out how to do it, generally with a group of stakeholders (esp. users) and developers (et al). This involves a lot of conversations, thought, learning-time, etc.

Traditional methods try to plan too much to start, almost always with incomplete/unstable information.

Agile recognizes that information is incomplete (at any point in the project, but especially in the beginning), and so favors frequent, incremental conversations (and design/plan adaptations).

Assume that a certain volume V of communication is necessary to gain the mutual understanding necessary to properly plan and execute a project. How much V should be consumed up-front as opposed to in-process is subjective.

Personally, I like to consume just enough V up-front to get started; once everyone gets the basic idea/metaphor/goal and is excited about the project, jump into something with tangible value and show benefits - but with as many additional (but more focused) conversations as necessary.

Community
  • 1
Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
2

Agile doesn't mean no planning, or even less planning; but it can mean no planning phase in the project.

In a true Agile project, the team is always planning, but in smaller chunks. Every new piece of knowledge gained nudges 'the plan' in one way or another. The plan itself is fluid and accepting of change.

The problem is that there is a tendency to want to sit down and document the plan. The moment you do that, the plan becomes a little bit out of touch with reality, which is constantly changing. The more time you spend documenting the plan, the more out of touch it can become.

Agile recognizes this counter-intuitive fact, and tries to minimize planning when you least know what your users ultimately need (i.e. at the beginning of the project) and maximize the planning closer to when you know more (i.e. later in the project, as you're developing and getting feedback). Agile also recognizes that in many cases, documentation of the plan is less useful/important than execution of the plan.

As such, Agile asks that you only spend just enough time and effort planning (and documenting the plan) to allow the project to move forward responsibly. Any more than that, and it's a waste.

Eric King
  • 10,876
  • 3
  • 41
  • 55
1

I would argue Agile (in my case agile scrum) is actually deferred planning compared to waterfall. The difference is agile planning I personally feel is your large scale plan is fuzzy / not detailed yet, but your short term plan is planned to extreme detail. As apposed to Waterfall where traditionally you planned the entire project up front (to the extent you could realistically do so)

Agile planning

Agile itself can be broken up into tons of sub methodologies, but at the highest level it's having detailed plans for short time spans 1 week to 1 month, past that is really pushing it. Your longer term plans more than 1 month down the road typically are not planned into much detail (yet) and live as list of features, bugs, etc to be done some day in your backlog.

The planning of your short term "sprint" is very detailed. You plan out the entire sprint, who will do what, technical details, etc. The precision of these plans vary team to team, but generally speaking successful shops tend to air on the side of more planning than less. The end of your sprint is your deadline, all work listed should be done by then (exceptions apply)

Typically you list all your want / need to haves in a backlog, each sprint you start at the most important items divvy them out you your team until you've assigned to the point they'll be kept busy, while still realistically finishing on time.

You repeat this process every sprint. This makes planning progressive so as the situation of the project changes the project can adapt.

Traditionally waterfall you planned everything up front and spent 3,6, or 12 months pounding it all out, Then going back and adjusting things at the end.

one way to think of agile is it's still waterfall, only your releases are weekly not annually. (someone will not be happy I said that, my point is you still plan things through just the scale of the plan is WAY smaller, but more often.)

Eric J Fisher
  • 648
  • 5
  • 11
0

BA talks to key users, collects data, which are pretty much just a sketch what they really want.

Do you feel the BA should spend more time, ask better questions, collect more data so you can plan out the entire strategy with little to no refactoring? Why don't the developers ask for more details before starting to code? Seems like there is a history here.

we realize they need a bigger system we expected, following that we need to make bigger refactor and generalize everything afterwards.

Do some sort of retrospective and determine if these things could have been identified sooner rather than later. You may find out that no one expected this at all.

Is this the way it should be?

I don't know about "should be" but this is usually the way it is and agile is a way to handle it better. How would you feel if you spent more time gathering incomplete specs, spent months writing code, and then having to rewrite all of that? This sounds even worse.

Given by the information are we doing it in the good way? And if the answer yes, then does the low planning costs match with the higher refactoring and rewriting costs? So to say: profitable?

You need to understand why "real" requirements aren't getting recognized until after some development has taken place (It's not that uncommon.). Maybe the BA can gather more or maybe you need to ask more questions and have him go back to the clients for details.

Sometimes you have to build something and get it in front of the clients so they can then determine what they really want. Few can do it in the abstract. Don't expect to double your upfront planning and cut your development in half. You'll probably find yourself making more detailed plans that just get thrown away because many places don't take the time to rewrite them due to falling behind.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • I sort of understand BA, I don't want to blame him without reason, he is on 2 other projects, I can imagine it is a tough job to be ultimately precise in this position especially in agile structure where it is sort of baseline that we don't want to discuss everything in the beginning like in the waterfall model. – CsBalazsHungary Jul 15 '14 at 19:42
-1

I've been doing agile for years now - the one any only answer to your question is : "yes".

Agile development results in somethinh between little and next to no planning at all - it has its focus on flexible, customer-bound solutions - actually planning the solution strips the flexibility / agility away nigh-completely because the customer is bound to his own specifications and stories.

It is a somewhat "chaotic" process - although not really; solutions are implemented in a strictly pre-set environment which bends according to rules of flexibility / agility, scrum (for example) has no planning at all (if you dont count sprint planning), but the process of change can only happen via teamwork, strategic and tactial planning and large amounts of user-feedback. In the result, the team will have implemented a highly functional, highly user-compliant solution in even less time than other processes / frameworks facilitate... if carried out correctly (you will need a highly competent team) the lack of planning does next to no harm, only minor drawbacks are to be expected which are very manageable and can be eliminated over time with little effort.

specializt
  • 107
  • Forced to downvote this one. Even if what you said can be true. This kind of thinking and talking gives agile a bad name. Agile still requires good planning ability, especially high-level strategic planning at the architectural level. – InformedA Jul 16 '14 at 01:05
  • you have obviously not understood the core concepts of agile. – specializt Jul 16 '14 at 08:52
  • First sorry for the down vote, secondly I understand that in Agile, few people said that it is about micro-planning for short-term, but vague in the long term. So they say planning in details for each sprint. This is another reason why Agile will be associated with a scrum, messy, unorganized, non-existing-process way of doing things. I disagree with those ideas because the way I see it, the planning in each cycle is about choosing a subset of TODOs and unfinished tickets created after high level planning is already done. The choosing criteria are quite subjective. Correct me if I am wrong. – InformedA Jul 16 '14 at 09:06
  • Neither is there any "high level planning" nor can ticket-assignment be called "planning" at all - user stories are converted into sprints and sprints have an adequate number of tasks and subtasks, these are assigned to people and thats it. No planning involved. Scrum is about your ACTUAL work, your way of DOING things, the effort you put into it and how well your result will be, its more of a philosophy than an actual process. If you start planning things you're either doing it wrong or you've encountered major problems - which CAN result in a sprint-cancellation. – specializt Jul 16 '14 at 09:28
  • Uhh ohh, then I need to find another name for my methodology then. It is definitely not Agile. The only thing I see in common at the moment is that I would perhaps consider user stories as unimplemented features, tickets, TODOs. – InformedA Jul 16 '14 at 09:34