18

A methodology is a set of principles, tools and practices which can be used to guide processes to achieve a particular goal. A framework is a loose but incomplete structure which leaves room for other practices and tools to be included but provides much of the process required. If we look at the software equivalents, for instance, where applications are ...


17

Following on Tiago's answer, the issue is not the methodology but how the methodology is being tailored on your projects. Based on my experience working on biodefence projects for US govt, as the complexity of a project increases so to does your need for upfront planning and thorough project oversight. Regardless of your use of waterfall or agile or ...


16

Being new to Agile can be overwhelming with all of the different terminology that you hear getting thrown around. I had difficulty grappling with these two words in particular at first, as well. I'll try to lay out the major methodological differences, without getting into the philosophy, where I'm not quite so strong. Scrum: Teams work in sprints, ...


15

You have three factors: Money Time Requirements If money and time are fixed and requirements can change then you would go after SCRUM. If requirements are fixed then you would go after waterfall.


13

Agile is a new term on decades old concepts. I've blogged on this very topic recently with a blog titled "Gorillas can be Agile with any project" (PMI recently reposted this on their Agile Community of Practice). My blog isn't just an opinion. I used agile principles at the program level in a hardware company that had both Japanese business practices and a ...


13

If you are working alone, a software development methodology might be a bit expensive (time and additional research) for you, because the currently available methodologies were developed for teams which are cooperating and the need some ground rules in order to that. If you are working alone, you cannot really cooperate. My advise is cherry-pick those ...


10

Will the software ever change after its first release? Waterfall is for building bridges and houses -- physical, rigid things that you don't expect to change much over time. Agile and Iterative approaches fit naturally with software development and its fluidity. You should expect and embrace change. I understand not everyone agrees with this, but using a ...


10

Asking if there's a methodology that works fine for a large project sounds like asking if a map route can take someone from South America to Alaska. Is there any (methodology or map)? Yes. Will it do it (work or travel) by itself? Definitely, no. A methodology is a guideline. But, as the map, it's only suggestions of how to reach something or somewhere, ...


9

Scrum is probably the more difficult of the two to implement from scratch. Here's what I would suggest: First Phase: Preparation 1) Spend some time grooming and prioritizing your backlog. The key here is to break the backlog items into small enough pieces. Most new Scrum teams fail early because they are unable to deliver software at the end of a sprint, ...


9

Classic X/Y Problem In the comments, the OP elaborated on his project environment. He said: [T]he major problem with our project is not that it is either big in KLOC/FP or "complex"...The problem is that the project is more like a "bowl of paperclips" more than a bunch of independent features - you can't touch any feature or issue without impacting most ...


9

Have you considered a Squad system? The always-excellent Henrik Kniberg has an article that you may find useful on how this system is used at Spotify. The basic principle is as follows: Vertical multi-skilled (product, development, design) teams work on a single product or area of product development (e.g. infrastructure, customer feedback) - these are ...


9

Lean is to Kanban as agile is to Scrum. One is a concrete implementation of the other. Using the term "lean kanban" is just an attempt to court favour from Google/Bing for keyword density and is the result of copywriters rather than an actual thing. All Kanban is Lean... But not all Lean is Kanban...


8

PMBoK 4th Edition, glossary, page 437: Methodology: A system of practices, techniques, procedures, and rules used by those who work in a discipline The term "framework" is used over 20 times in the PMBoK but is not in the glossary. I find that somewhat odd... Since we don't have a PMBoK authority reference, I prefer the defintion from WhatIs.com: In ...


8

One of the most important things when managing yourself, is to maintain focus. Do enough planning to know what and why you're doing this, but not so much that it becomes unwieldy or an opportunity to procrastinate. Not only in the sense of perseverance, but also in the sense of not taking on too much at once. For a single person, I think that a kanban ...


8

Let's tackle your questions from the last to the first: 3) Is there a reason why it seems like there isn't a lot of attention dedicated to this topic specifically? Yes, there is. The whole thing of project-management processes is about solving problems like inner-team communication, work sharing, team conflicts, responsibilities, ... the complexity of ...


8

Here's my TL:DR answer: No! The engineer shouldn't be working on something if the business value isn't already defined. It's the voice of the customer (product manager, product owner, business analyst) that should be defining the business value. Said business value should be agreed to by the business before asking engineering to size the work for ...


7

Waterfall is a software development method because it is a process which provides structure, planning, and control for software development processes. It is not so easy to tell you if it's suitable to implement in your situation without more details. If you expect lots of changes in requirements that can comes during the time, and if you want to be able to ...


7

Waterfall is a software development life-cycle. It can be used in conjunction with project management frameworks and methodologies. Since the waterfall life-cycle depends on each phase to be completed in full to continue to the next phase, it is typically recommended only if there is a rigid set of well-defined requirements. If there is still a ...


7

TL;DR It is important to differentiate between kanban (the artifact) and Kanban (the methodology). Kanban Defined A kanban is actually just a sign-board. In many agile methodologies, a kanban is used to hold kanban cards, which generally contain user stories. In manufacturing, the kanban cards are a signal to pull parts or supplies into the process at the ...


7

TL;DR TANSTAAFL. If you want to scale, you need to add more teams. However, if you add more teams, you have to manage the additional complexity and communications overhead that comes along with that. Direct communication channels scale poorly. The formula is generally expressed as N(N-1)/2. If you don't have a project management model that addresses this ...


7

Back in the 90s, Watts Humphreys developed a "Personal Software Process", first outlined in A Discipline for Software Engineering and subsequently adopted and promoted by the Software Engineering Institute. Regardless of its actual content, the key insight of the book was in taking the processes of development in groups and scaling it down to the individual ...


7

If you assume an employee puts in 8h days, this rule would mean that a task takes no longer than two man-weeks and no less than one man-day. This ensures that the task is large enough to be meaningful, but not so long as to have no visibility into what is happening. In other words, a task that takes 4h may not be worth doing--it could be wrapped up with ...


7

I think questions like this need to be answered with great care. PMBoK is not necessarily incompatible with Scrum but it has to be said that PMBoK started out very much as a predictive planning approach to projects. You could argue that "initiate, plan, control etc." is being applied to each sprint but that was not how PMBoK evolved. The fact that PMI have ...


7

Short answer: yes, it is perfectly fine to account for negative cases. I'm used to seeing this a bit differently. Usually a User Story is one step up like: As a user, I'd like to be able to add a meeting on the calendar so that I can track my schedule for the day" Then I would have both of these as acceptance criteria on that story. This ...


6

A Prince2 practitioner might view Scrum as being contained neatly within the delivery level. A Scrum practitioner, on the other hand, might see Scrum extending into multiple aspects of the management and executive levels. So, Prince2 can use parts of Scrum, but Scrum, as a complete package, may not be able to comfortably co-exist within Prince2. Scrum ...


6

The big difference between software projects and infrastructure is lead time. For example if you need to build a new datacenter it might take years. Even something as simple as ordering disk drives right now may be long lead because of the floods in Thailand. Agile is great, and if you think about it, that is what using cloud servers is all about. For a ...


6

Unfortunately, you aren't doing Scrum. You simply apply certain practices, but not following the mindset. You are close when you are saying that "... every sprint gives us a version, a product which we can use but that we need to improve". However, sprints not necessarily produce versions and in Scrum we are aiming for feedback at the first place. So, we do ...


6

Here are some pitfalls I've seen with the MoSCoW model. Managers are worried that their requirements will fall into "should" or "could", and won't get done, so they make up reasons why their requirement is a "must". This ends up delaying business-critical functionality. (This is usually caused by, or exacerbated by, bad KPIs at an organizational level. I'm ...


6

There are so many classic issues contained in this approach it is hard to know the best place to start! Firstly I will say this, an Agile approach may suit you better because of the way it handles functional requirements and technical debt (bugs and issues) however I personally have no direct experience with that model. I'm sure someone will come along and ...


6

Why should a developer want to work Agile? Because a properly-implemented agile framework improves the pacing of a project and the sustainability of the developers' work efforts. It also increases collaboration between developers and stakeholders. If it doesn't do all of these things, then the team (or the organization) is probably Doing Agile Wrong™. ...


Only top voted, non community-wiki answers of a minimum length are eligible