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


17

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


16

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

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


12

To your overall question, while Scrum can be applied in most projects, it is not necessarily the best approach for some projects. That said, it is well suited to complex problems that require discovery of the solution and adaptation to new information. Your project sounds like exactly the kind of project Scrum was designed to tackle. However, you raise some ...


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


10

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


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


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

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


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

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

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

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


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

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

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


5

Arguably, waterfall is a software development methodology (at least wikipedia thinks so). However, a methodology is a defined set of tools, activities, tasks that offer guidance on how to provide a set of deliverables. In this respect (as a delivery mechanism), waterfall breaks down as a methodology because unless the amount of work that needs to be ...


5

Waterfall is used successfully on the largest projects in the world e.g. 500 people over 6 years at a cost of $21 billion. These are mostly infrastructure projects (bridges, tunnels and railways), aerospace and defense projects (airplanes and weapons systems) and energy projects (pipelines, drilling rigs) It is not the methodology that fails, but the ...


5

I disagree with Deer Hunter almost completely. The SWOT analysis is a simple and very powerful tool and is an input to so many other pieces of business analyses: product selection, vendor selection, project selection, outsourcing, and insourcing to name a few. It is done at the organization level, and then decomposed at the division level, business unit ...


5

The word analysis in SWOT is wildly exaggerated. What you feel is most likely correct: "I really get the feeling that we are going through this process because someone read in a management book that it's a good thing to do" However, back on topic. Yes, Strengths and Weaknesses are static and mostly internal (unless your team is particularly favored/...


5

The task board is actually not part of Scrum. Scrum is a framework, primarily with a project management style (time/deadline) focus, which defines three named roles, two backlogs (sprint and product), four meetings, and various time-boxes for each event. Beyond that, the field is open to the team to determine what the best way to get the work done is, as ...


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