17

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.


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


11

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

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

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


6

The idea that "everyone is a developer" and "everyone writes code" aren't the same thing. In this sense, "developer" does not mean "programmer", but "a person or thing that develops something". UX designers, programmers, testers, business analysts, and others are all involved in the development of a product. ...


5

TL;DR "Agile" isn't a methodology; it's a set of principles espoused by the Agile Manifesto. SDLC is an ambiguous term that can refer to a specific, waterfall-like methodology or a generic lifecycle. Either way, frameworks like Scrum or Kanban are more usefully classified as project management methodologies rather than lifecycles. Frameworks Aren't ...


5

Scrum doesn't mandate (or even suggest) any specific engineering practices so teams often adopt TDD, Pairing, Continuous Integration etc from XP. It's probably be more accurate to say the most common agile implementations use the Scrum framework for defining how work is specified and the process with which features are delivered while making use of XP ...


5

There is, of course, difference between method and methodology terms, since etymologically methodology is theory of methods. Saying it simply and not being entirely accurate, a method is a way of doing things, and a methodology is a collection of methods. Dictionary definitions describe briefly these terms: methodology: A set of methods, rules, or ideas ...


5

You ask a pretty large question, so forgive me if my answer is a little too broad. It sounds like you're starting with the .psd's and then your development team will be acting as an agile team from there to delivery. This may not be ideal, but I'll save that for the end. Given your circumstance, I want to first clarify that while agile promotes measuring ...


5

Kanban is a lean methodology focused on creating continuous flow of work while eliminating waste (muda) in the system. There is no difference between Kanban and Lean Kanban. Where there are some differences however... Kanban for software development differs slightly from the classic Lean Kanban formulated by Toyota in the 1980's and used in manufacturing ...


5

Leadership 101: Do not force the team to do something for the sake of doing something. On the surface, it seems to be a very nice idea, being poorly implemented. The straight answer for the question is no - it does NOT make sense to force engineers (coding-oriented people, who usually have collosal knowledge on programming but low communication skills) to ...


5

Is Scrum actually suitable for all kinds of projects? Like with many things in the software industry, Scrum is not a silver bullet. It works nicely for some types of projects, and less so for others. I've often seen the Cynefin Framework mentioned when trying to identify projects types where Scrum might be used, so maybe have a look at it and see under what ...


5

there are no roles on the team (a "cross-functional" team where "all team members are developers") One thing I want to note is what exactly cross-functional means: it is not a team where every member can do everything. Rather, it is a team that is capable of doing everything. What I would suggest foremost is confirming what exactly ...


4

Kanban is a set of three (and just three), simple, rules: visualize the workflow - use the board and map your processes into columns (in the simplest case: To Do, Doing and Done), limit WIP (Work In Progress) - Kanban limits WIP per workflow (for example you can limit number of items in your Doing column to one - the whole team can work only on one item at ...


4

On Scrum. You can NOT do a sprint of design, one of coding, one of testing. Every sprint must do everything to deliver some working functionality. On V-model That link is not to an image of the V-model. However it is popular misconception. The V-model has no arrow of time. It does have dependency arrows. You can not do this until you have done that. Scrum ...


4

When I moved into my current team we were in this situation, however I had the benefit of coming in as Application Development Manager. You will face challenges without the authority to make decisions, but a lot of what I suggest below doesn't have to be driven from the top down. To be honest, everything I proposed I asked the team, and got their buy in ...


4

Scrum defines three roles, three rituals and three artefacts. It is not a thorough software development methodology, but a minimal product development framework. While its phrasing is focused on software, what it actually defines is a power equilibrium between different stakeholders developing a product, and specifications on interactions and feedback to ...


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