• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Agile methodology - not relevant to all projects

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
one of the key approaches in agile is defining a sprint.
A sprint is basically a block of work which gets executed during a brief period of time and will represent a subset of the entire application intended to be developed.
The block of work will pretty much capture an end to end functionality, executed as subsets of requirement gathering, design, development, testing, deploying.

Let say the initial sprint which I had defined works fine, but once I move on to the next sprint i.e sprint 2, I realize there will be major changes in the design and development of existing modules that have been developed in sprint 1.

If I look back I see that It would have been better and more productive if I had taken both the sprints in one go which would have saved me design and development efforts.

So division of sprint is a challenge in itself.

I think agile is very hot now but I really doubt whether its methodology to go about(based on my limited knowledge of agile), a combination of waterfall and agile is something that makes more sense. Also then someone has to write a book on when to use agile and when to use waterfall :-)
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

rajen kumar wrote:one of the key approaches in agile is defining a sprint.



Actually not, no. A sprint is a concept from Scrum, which is just one of the Agile approaches. Agile just asks you to "deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." Many use short iterations to do that, but some also use iteration-less approaches like Kanban.

Let say the initial sprint which I had defined works fine, but once I move on to the next sprint i.e sprint 2, I realize there will be major changes in the design and development of existing modules that have been developed in sprint 1.



Well, as the first sprint wasn't very long, there isn't that much code to change yet. And as the next sprint isn't very long either, there also isn't likely to be that much change needed. And as Agile asks you to develop code that is highly changeable, for example by using a well decoupled design supported by tests; and as there are techniques like refactoring to be mastered that allow you to make those changes safely and effectively, this actually doesn't turn out to be a big problem, once you learn how to work in this way.


If I look back I see that It would have been better and more productive if I had taken both the sprints in one go which would have saved me design and development efforts.

So division of sprint is a challenge in itself.

I think agile is very hot now but I really doubt whether its methodology to go about(based on my limited knowledge of agile), a combination of waterfall and agile is something that makes more sense. Also then someone has to write a book on when to use agile and when to use waterfall :-)



Well, I'm now using Agile techniques for more than a decode, for the last nine years on a one-million-lines-of-code project. And I have no doubt whatsoever that short iterations are the way to go. So, if I had to write that book, it would be a very short one. In fact, I will write it for you, right here, and free of charge:

*When to use waterfall*

Use waterfall when you don't expect to learn anything along the project. That probably means that you have done exactly the same project before and would do it exactly the same way again. In which case simply use the code from the last project.


*When to use Agile*

Otherwise.


*When to mix*

When you are just learning Agile. You can't learn it all at once. Start with your biggest problem. Get training. Get a coach. Have fun!
 
rajen kumar
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well, thanks for the useful comments.
The refactoring part is something thats need to be understood and getting used to working in this mode.
Refactoring code is ok , but design is something I always hate to do.
And while using agile methodologies , waterfall approach is used in each iteration on a smaller scale.

I guess I need to dive deeper in various ways and use of agile.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

rajen kumar wrote:
The refactoring part is something thats need to be understood and getting used to working in this mode.
Refactoring code is ok , but design is something I always hate to do.



Refactoring *is* design.

What do you hate about doing design?


And while using agile methodologies , waterfall approach is used in each iteration on a smaller scale.



Uh, no, not really. Most specifically, testing comes *first*.
 
Ranch Hand
Posts: 686
Netbeans IDE Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First let me clarify - I work in a manufacturing environment where the only thing that is constant is change. Agile here - does not work for me. I have to change my design in between each sprint. Projects are so short (sometimes not scoped) that I can't even define a sprint. If I try to imagine a sprint I would end up with useless code. I wonder if Agile is useful for such a project.

I work in Mfg so I know Kanban but in terms of software??

Would agile work for shirt projects weeks - 1 month??
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Vyas Sanzgiri wrote:First let me clarify - I work in a manufacturing environment where the only thing that is constant is change. Agile here - does not work for me.



That's an interesting statement, as Agile is exactly meant to be adaptive to constant change.

I have to change my design in between each sprint.



Are you implying here that a design needs to be fixed for the length of a sprint? What do you mean by design?


Projects are so short (sometimes not scoped) that I can't even define a sprint. If I try to imagine a sprint I would end up with useless code.



How short is "short"? How would you end up with useless code? Could, say, sprints of the length of half a week possibly work for you?


I work in Mfg so I know Kanban but in terms of software??



It's been adapted to software development by a couple of teams. Google should give you lots of hits. You might also want to search for ScrumBan, a hybrid between Scrum and Kanban.

Would agile work for shirt projects weeks - 1 month??



I have successfully worked on a two week project using Extreme Programming with two day iterations. Works like a charm.
 
Vyas Sanzgiri
Ranch Hand
Posts: 686
Netbeans IDE Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your comments!
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

rajen kumar wrote:Refactoring code is ok , but design is something I always hate to do.



I suspect this is the definition of design that means "that period of time, before we start coding, when we are taking lots of time to draw detailed models based on our understanding of the requirements." I don't enjoy that either. I'd much rather sketch a quick up-front design (at an inception level, i.e. without lots of low-level detail) for a given software release, and then continually increment the design, by practicing TDD with continual refactoring. It's far more enjoyable, it lets me code a lot more than I would otherwise, and it's very effective if done well.
 
author
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The interesting thing is that while we in the software world run away from front end design as fast as we can, the people in the lean product development space are moving in exactly the opposite direction. Michael Kennedy, for example, advocates spending more time getting the design right rather than diving right in with building.

I think we are in danger of throwing the baby out with the bathwater here - there is a middle ground. In a greenfield environment, I would want to start with a well-conceived low dependency architecture which allows incremental delivery and change over time. All too often, architecture is given and - even worse - tightly coupled. In this case also, jumping right in can be dangerous - or it can be a very good idea. It depends. But I would say our "traditional" processes have erred on the side of taking too much time at the front and not allowed for learning and feedback later. Let's not get to the point where we allow for no learning at the front, however. There is a balance, and it will differ in various domains.
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mary Poppendieck wrote:...the people in the lean product development space are moving in exactly the opposite

I think we are in danger of throwing the baby out with the bathwater here - there is a middle ground. ... Let's not get to the point where we allow for no learning at the front, however. There is a balance, and it will differ in various domains.



Greetings Ms Poppendieck,

Does your definition of architecture include class-level design? I wasn't referring to what I consider architecture--which to me includes things that are costly to change (for the most part, not class-level design).

There are very few agile proponents left (let's call these XP v1.0 diehards) who believe there need be no up-front design effort. While it's feasible to start with close to nothing (I've helped do this a couple times), it requires very high levels of discipline and skill, and so I don't recommend that approach for normal teams. Point being, the extreme was promoted and tried for a while, and most who were in that camp have moved away from the direction of throwing out babies. I'm not saying there should be no learning at the front.

What I find interesting is that when I visit development teams, design knowledge is often severely lacking. When I talk about minimizing up-front design in favor of more continual and incremental attention to design, I find that a good number of teams really don't do any useful design in the first place. These teams give me some strange looks, particularly when people start realizing that I'm saying they should pay *lots* of attention to design, all the time. Well, sure, that's a concern, particularly if they're incapable of articulating fundamental design principles.

There are of course many teams who are able to competently produce an up-front design. But they inevitably waste effort on some of the wrong things (e.g. on things that are easy to change later with minimal impact, and on things that do change later, often dramatically so).

Yes, there's always a balance to strike, and it will certainly vary depending on each domain, team, and circumstance. So the question becomes, err on the side of a little too much premature specification (waste), or err on the side of waste produced by incremental design (which necessarily generates some waste in rework)?

My experience has suggested that the up-front design waste is often far too costly. Investing more in up-front design concerns me for a few other reasons, including:
- it's speculation without realization; any feedback generated is of questionable value
- published paper products start to reinforce the dangerous idea to external parties that they accurately predict outcomes
- it promotes the mentality of increasingly moving in the direction of old comfort zones

A lot of programmers challenge things like smaller functions, TDD, and incremental design. "Well, 50-70% unit test coverage is just fine." Or, "200-line functions are ok." Or, "We need to fully specify the design to ferret every last possible risk." Working with systems built with these mentalities is endlessly frustrating. Over 99% of all systems are way off in the wrong direction with respect to similar measures. Programmers will argue to no end for their bloated limit on function size, and that their test level coverage is fine. But they don't understand how much waste these attitudes cost until they try going in the other direction, even perhaps a little too far. All I ask is that they stop holding onto their stubborn excuses and at least try moving in the other direction.

I'd be happier if the effort on producing bloated up-front system-level design (not architecture) was expended on better understanding of existing business rules, domain-level modeling, and transformation of needs into acceptance test specifications. Inability to communicate exactly what we should be building (and what we have!) is a far bigger crime in many places.

Jeff L.
 
author
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I take architecture as a tool to manage risks the user stories should define how much architecture I need in a Sprint. Architecture and refactoring are cousins to me. If refactoring is a central part of the process I don't have to do as much upfront architecture. Without an efficient refactoring (because of bad understanding, politics, and the like) I would emphasize architecture in any case. Else the maintenance costs become quite high in the long run.
 
Mary Poppendieck
author
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I'd be happier if the effort on producing bloated up-front system-level design (not architecture) was expended on better understanding of existing business rules, domain-level modeling, and transformation of needs into acceptance test specifications. Inability to communicate exactly what we should be building (and what we have!) is a far bigger crime in many places.



I'm with you on that. I believe that design of the code must happen throughout development, and should be done by the development team. There's a case to be made that xUnit tests are not tests at all, they are the detailed design of the code. Class-level design is certainly not architecture - architecture is an overall view of - as you say - high-level decisions that will be costly to change in the future. And even in this case, the more costly a decision is to change, the longer you should wait to make it. These kinds of decisions are often best done by maintaining two or three options for as long as possible and learning which one is best as the design unfolds.

I think of it this way: Several times I have had some new tile laid on floors in my house. Each time I call the same tile guy, because he is a really good designer. He looks at the floor, knows where to start laying out the tile so that it ends up centered in the room, with neither too large nor too small a partial tile on the edges. He knows just what to think about and what doesn't matter. In a short time with a bit of measuring and placing lines on the floor, he gets to work. I am always amazed at the result - the little details that I would not have considered all come out exactly right. This is hardly the architecture of the building, or even the room. But it is certainly design - and because I had a good designer lay out the tile, I can always see when I look at tile whether or not any design went into the tile laying.
 
Mary Poppendieck
author
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If I take architecture as a tool to manage risks the user stories should define how much architecture I need in a Sprint.



I don't understand this. I would want architecture to precede thinking about what should be done in a sprint. I think of architecture at quite a bit higher level. What happens in a sprint is design, and there should be a lot of it, but a story would not generally "call for" design. Good design should be part of the professional competence developers brings to their jobs.
 
Rainer Eschen
author
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
During the discussion of the product backlog I'm able to recognize how much architecture (risk management) I need for the next Sprint(s). Dependent on the quality of the refactoring process I have to do more or less upfront architecture for future Sprints.

It would be nice if developers were designers, too. When we use agile architecture the architect has time left to coach the team during a Sprint ;-).
 
reply
    Bookmark Topic Watch Topic
  • New Topic