18

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

I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved. I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge ...


12

checking SVN in a daily basis to review codes and to assess how much codes have been committed by each developer is a good way. is it fair and used in industry? The proposed metric is utterly unfair, regrettably is used in some organisations and is in my personal opinion a recipe for disaster. HasaniK and Jakub have already identified some very valid ...


11

First, remember that an estimate is highly unlikely to be 100% correct, so do the best you can with the information that is available to you. Second, break down the tasks as far as you reasonably can, and get figures for similar low level tasks from other projects that have been done in the past. Don't worry if they are not identical, as long as they are ...


11

You shouldn't be allocating story points to cards. The team should estimate the cards and agree on what to pull from the backlog based on their velocity. The team is accountable for making their own forecasts and sprint plans. You telling them what must get done in the next week is neither Agile nor Scrum. You're also likely demotivating your team ...


10

checking SVN in a daily basis to review codes and to asses how much codes have been committed by each developer is a good way. is it fair and used in industry ? This is definitely not a correct measurement for a PAR for Software Engineers. As Jakub has also mentioned, design takes time,sometimes there are blockers which prevent dev team from finishing a ...


9

The biggest problem is Brooks' Law You did not say why you are trying to add freelance developers to the small project temporarily. If your project is late and you are hoping to crash the time line, remember Brooks' Law, "adding manpower to a late software project makes it later". It takes some "ramp up" time for the resources added to the project to ...


9

Answers Question 1: "Is [finishing early to allow for testing] an acceptable request?" Answer 1: It is completely reasonable because in Scrum, the Development Team is self-organizing: No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality - Scrum Guide This means,...


9

Firstly, look at whether you can split your stories any more. Secondly, why aren't the engineers on your team cooperating. The way your describing your system sounds like a you've set a minimum work in progress limit of one story per developer. Of course your cycle time is high (cycle time = wip / throughput after all). Instead cooperate on things to reduce ...


8

David is absolutely right, there are very few instances whereby refusal to work can be considered acceptable, generally the accepted norms would be if to continue would compromise yourself and/or the organisation legally or as David has already said if to continue would constitute recklessness and present a risk to life etc. The developer’s behavior is ...


8

Disclaimer: I have never worked in a digital agency and I am aware that the role of Project Manager in Digital Agencies can be somewhat different to that commonly accepted in other I.T. operations whether in-house or software development suppliers. Furthermore I am not clear on the exact differences. Despite my disclaimer above, and taking the question and ...


8

Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories: As an SDK user, I would like to be able to grant permissions to a user so that I can manage what different users can do. and As an interface user, I would like to be able to grant permissions ...


7

There is a lot you can do that ensures that the code does what it's supposed to do, but aside from trusting the people developing it (including their reviewers) there is basically no way to make sure it does not do more. But it comes down to that trust in any other job, too. At some level, you need to trust the people. If you cannot, get others that you ...


7

TL;DR How to share developers between multiple agile projects? You don't. Doing so is inherently non-agile. This smacks of an X/Y problem, where X (the real problem) is likely to be an executive mandate to "do more with less" without prioritizing projects based on both business value and resource constraints. However, you or your organization may have ...


7

The "true Agile" you probably have in mind doesn't exist. Some teams are more Agile than others, some are less. For a bunch of other teams Agile is just a buzzword which doesn't reflect in their practices. Some even refuse to use the word Agile and prefer to say "move with agility", to detach themselves from the buzzword. Agile is a set ...


7

In my experience, outsourced projects only work if: you - as the client - stay involved in the development of the product. You don't just hand the provider something to do and expect them to deliver in 6 months or whatever. You don't just take "your paws" of the project. It's about continuous collaboration with the provider to work on your goals. ...


6

TL;DR I think the question of "requirements gathering" is based on a misunderstanding of the agile principles involved, and especially of how user stories are created and how the details of a story should be fleshed out into an implementation. Simply re-framing everyone's expectations properly may help a great deal. While it may not be feasible to have 10 ...


6

Sprints and Branches Are Separate Concepts Can we say that a Sprint and a source code branch are almost the same things? No, a Scrum Sprint and a Git branch are not at all the same things. While you can use an online Source Code Management (SCM) system like BitBucket or GitHub in the development process, there is no one-to-one mapping between the project ...


6

Using a Behaviour Driven Development (BDD) or Acceptance Test Driven Development (ATDD) approach means that the code is self documenting. So introducing functionality beyond the original requirements would be obvious to anyone who paid attention to the code base. What constitutes 'extra code' is a much more difficult question. It is quite possible that code ...


6

Welcome to PMSE! From the Scrum Guide: Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. So, your goal should be to progressively move away from the notion of "dev owners of features". Also, it is good to set aside bandwidth for handling unforeseen ...


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

Lead by example. You can't force people to do what they don't believe in, particularly in your role. But if you work the way you believe is right, and if you quietly show results, then you should eventually win people over to your side. Don't force anyone, simply work in the way you believe is right, mention your positive results, and if they are interested ...


5

There is a difference between estimates and planning values and I find most either ignore or confuse the two...probably the latter. Work effort is probabilistic and a proper estimate should reflect that and be provided as a range of possible results. For example, an estimate to build a wall might be six to 15 days, most likely nine. If you built that wall ...


5

You cannot refuse to do work. You can offer up an objection, you can propose a few other alternatives and state your case, but you must always support the decision and the team and continue. As a PM, you cannot allow a team member to "refuse" to do work. The only time refusal is remotely acceptable is when something catastrophic is predicted: safety, life ...


5

It's a very common situation and a very tough challenge. An agency works very differently from a software company, and many, many projects fail with the model end-client -> creative agency -> software company. I have worked for a number of years with agencies trying to solve this exact problem, and while I certainly haven't found a silver bullet, I can ...


5

A tool won't save you. Discipline will. Other professionals, such as lawyers, do it all the time for decades, with accuracy, and without a fancy tool.


5

First of all, faster isn't always better. One of the engineers I've worked with finished his stories extremely fast, way faster than the rest of the team. But he'd often use quick and dirty shortcuts, and the testers explicitly gave any user stories from this engineer extra attention. He produced different bugs than the rest of the engineers, more difficult ...


5

I don't believe it is possible to sort by status changed date. However, given that your requirement is "to have a list of the JIRA tickets that are not moving from one lane to another so that I can intervene on those tickets", you can find all tickets that have not moved in X days. For example: (status = "In Progress" AND status changed to "In Progress" ...


5

Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically. So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case. Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns ...


5

I second ctrl-atl-delor (+1!) - you should invest on automation. Agile methodology helps on how work is organized, but regardless of the methodology, you should automate as much as possible of your work. We have a similar scenario in our project - and I'd guess it's fairly common on legacy applications. You have two main fronts of work: SDLC automation:...


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