Tag Info

New answers tagged

4

There's a very serious problem with choosing a methodology on a "per-project" basis, which is that most Agile methodologies reject the notion of projects. A project implies fixed scope and fixed time, and for many of the more dysfunctional organizations, also a fixed budget. This is anathema to every methodology out there. Every role, every tool and every ...


-1

In my experience, most organizations use a mix of the processes that work best for it and its customers (business). While Agility is an organizational goal, that does not mean ALL its software projects need to be run using an Agile method (Scrum or others). Agility means being able to respond to change quickly and still deliver quality products and services ...


0

Agile vs Waterfall its not only about have a set requirements up front. There are other agile values aside from responding to change, for example: People more important than process. Deploy software that works in short iterations. If your company is agile i cannot see how you can abandon this agility for one project, agile its much more about a mindset ...


3

I don't see the benefit of trying to do everything the same unless you're willing to turn-down projects that don't fit your particular model. Otherwise, you get a bad fit and the client isn't going to be happy either way. If you're so sure you know the specs in one case and are very confident they won't change, you can still run it as an agile project. Just ...


2

(Just FYI - I am cofounder of a company (Digité) that builds and sells enterprise software to a variety of technology organizations, so I have some background on these topics :-) ) Agile and Scrum are related, in that they are software development methods. Agile is an umbrella term for specific methods such as Scrum, Extreme Programming (XP) and others. ...


1

All of them are software development processes. Scrum is very collaborative you discuss with your team constantly so everyone can be aware of what's happening. Helps to deal with problems efficiently as a team. Agile can be many things. But when I have experienced it it has been very fast development with iterations. So you get the product working then ...


4

It sounds like you've changed the definition, value, sensitivity of a story point (time, complexity, etc), so you're really doing a conversion and not a re-estimation. Unless there is more to it, it's no different then changing from entering in days and then changing to hours. Just do the math but it's really worth the same based on today's definition.


7

Let's pause for a moment and look at the fundamental issue here - Architecting a system where the architecture model is too coupled to low-level features in the system, causing the architecture to break frequently in the development process. I think we have to remember that the use of architecture and design patterns related to it have to be laid on a ...


4

Your friend seems to be facing numerous headwinds based on his anecdote. That is unfortunate, and can be a very hard environment to work in. Despite the difficulty, he was on the correct path of using patterns to make his life easier, and it is a shame that he left that path. The spaghetti code is the ultimate result. Since there are two different problem ...


2

I think it at least partly depends on the nature of your situation. You mentioned constantly changing requirements. If the customer says "I want this bee-keeping application to also work with wasps" then that seems like the kind of situation in which careful design would help progress, not hinder it (especially when you consider that in the future she might ...


3

A design pattern's complexity can bite you if the problem it was supposed to solve suddenly disappears. Sadly, due to enthusiasm and popularity of design patterns, this risk is rarely made explicit. Your friend's anecdote helps a lot to show how patterns don't pay off. Jeff Atwood has some choice words about the topic. Document variation points (they are ...


7

The question seems to be wrong at so many points. But the blatant ones are: For the Null Object Pattern you mentioned, after the requirements changed, you change a bit of the code. That's fine but it doesn't mean you 'murder' the Null Object Pattern (btw, be careful with your wording, this sounds too extreme, some people too paranoiac won't see this as ...


9

It would appear the mistake was more to remove the pattern objects, than to use them. In the initial design, the Null Object appears to have provided a solution to a problem. This may not have been the best solution. Being the only person working on a project gives you a chance to experience the whole development process. The big disadvantage is not ...


2

We've addressed this by adopting the Kanban approach. We have queues in our tracking software (Jira) with minimum and maximums. We groom 'as needed'. Might be once a week, might be 3 times, depends on the limits and the work that get done. This will help you in getting the product owner focused on keeping your queue with plenty to do and can reduce ...


82

I see some wrong assumptions in this question: code with design patterns, though applied correctly, needs more time to be implemented than code without those patterns. Design patterns are no end in itself, they should serve you, not vice versa. If a design pattern does not make the code easier to implement, or at least better evolvable (that means: ...


14

In your example of using the Null Object pattern, I believe it eventually failed because it met the programmer's needs and not the customer's needs. The customer needed to display the price in a form appropriate to the context. The programmer needed to simplify some of the display code. So, when a design pattern doesn't meet the requirements, do we say that ...


39

My humble opinion is that you shouldn't avoid or not-avoid using design patterns. Design patterns are simply well known and trusted solutions to general problems, that were given names. They aren't different in a technical manner than any other solution or design you can think of. I think the root of the problem might be that your friend thinks in terms of ...


1

I would usually relay that information to the scrum master during the daily scrum meeting. As soon as you know you're behind you should inform the scrum master so he can either get someone to help you (maybe someone else is ahead of schedule and has bandwidth to help), determine whether overtime is needed, or if it's an impediment outside of your team's ...


2

Yes, it makes me anxious. But I am usually both behind and anxious anyway. That's what daily standups are for -- so the team doesn't discover a week later that you're a week behind.


2

Ideally you want the product owner to be the person who signs off on the final product. They should be either the client you're selling the product to, or, if that's not possible, the final person who is selling the product to the customer. The idea is that this person knows what the final product should be and can guide it's development from afar by ranking ...


1

Agile is more of a brand then a methodology, which type do you mean in particular? In scrum for example, yes, it would be common to map a previous project manager to a product owner. Although much of the responsibility of the project managing would fall to the scrum master and the team, the skill set required to be a PO (communicating the customers needs, ...


5

Using agile in this situation is still a very good idea. There are many benefits to agile, only one of which is regular feedback from the customer and the ability to respond to changing requirements as you mention. One of the main reason waterfall projects are notorious for failure is the 'nearly done' problem - testing produced piles of bugs at the end, ...


0

You can always split the big release into smaller releases(sprints) and ask your client for feedback. This way you are sure that you're doing the right thing and the client can keep track of your progress. If there is something wrong, you can offer your client the chance to correct you sooner, which is very good. It is better to correct your mistakes as ...


14

Would this be considered as bad, cowboy coding, anti-pattern. Short answer: no. Doing "agile" correctly does not mean "no planning", it does mean not to overanalyse things. one of the major reasons why Agile is used is because clients often change the requirements. That's an oversimplifying statement. "Changing requirements" is also about how the ...


2

Agile is ideal if you need a frequent feedback loop with the client. This can be because the requirements change frequently, but it could also be for other reasons. On the other hand, Agile can work equally well if the requirements are fully stable and the client expects only a single big-bang delivery, but you might have to adapt things a bit for the ...


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


0

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


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


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


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


-2

You might like the references/links in this article about the FBI Sentinel case mgmt project. http://agilecomplexificationinverter.blogspot.com/2014/06/case-studies-software-systems-failure.html In general the Sentinel project was a $300M waterfall project with 400 devs running years and never delivered. It was halted - vendor fired - replaced with a 40 ...


9

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


1

I don't think it is quite as cut and dry as in smp7d's answer. The Definition of Done is created by the team, but may require the Scrum Master to enforce quality constraints if the team don't have clear development standards. For example, a team may not want code reviews or unit tests, but a Scrum Master may need to enforce them to ensure quality is ...


1

Why should this be all negative? New people bring new ideas and insights to the group: New tools Other ways of working By having to explain the ways of your team to them, people in your team get challenged: Why did we decide to do it like this? Is the reason above still valid? Explaining stuff to people get people out of their confort zone And the ...


1

Thanks for listing my book in your top 5. "Agile Project Management for Government" takes a fresh approach in that I describe real life, fully attributed agile successes. These are case studies at Enterprise scale. I do not favor DSDM (although the book starts with a DSDM case on a breakthrough in UK battlefield tech development). The spectacular use of ...


0

As far as I understood hierarchical backlogs: They are not meant to be organized by technical topics, but rather organized by abstraction level of the work item. The lowest levels are supposed to be the most technical, the highest the most business-value/business-goal related. In the MSDN documentation there is an example with the following hierarchy: ...


3

I think some of the challenge starts with your assertion of: Where a Major version is implemented whenever there are breaking changes And I'm pretty sure you mean "breaking changes" in the sense of significant API changes; client / server communication changes; protocol work, etc. "Big Stuff" (TM) in other words. But the problem is that it's not ...


1

Whatever you're using internally, externally you're still going to have a waterfall like release cycle. Whether it's now called a "feature release", "release to production", "customer delivery version", or whatever, it's going to be the combined product of a number of sprints and shorter internal cycles. That's where the high level numbers come in. So ...


3

If the user of your software is not able to update to the new version and use it without further manual migration steps (data, configuration, interfaces and the like), that is a strong indicator to increase the major version.



Top 50 recent answers are included