38

I would like them to understand why I want to do something. [...] Any advice? Don't theorize, show them. Their current state of mind is that they know what they do works. And you come over and tell them that theoretically this is bad. You will never win anyone over by telling they are doing a bad job, while you could do a much better one. Everybody can say ...


24

According to Mike Cohn It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case. Accordingly to Scrum.org: The Scrum Goal is the creation of productive and creative ...


20

No project has a 100% chance of success. So there's that. For R&D, the project itself is not the product. It is research and development. It's a service-oriented project. Therefore, you would be reimbursed for the service, not what is produced or not produced. The output for a service-oriented project is a change in state. For R&D, that state is ...


19

If you reduce a team from 7 to 4, especially if the reason is something outside the team, the best course of action is probably to treat this as a completely new team. People will need to change into new roles, find a new way of working together, cover fresh weaknesses caused by those leaving, find out who is in charge of what, and all the other problems ...


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.


16

They should absolutely be doing QA. In fact, in the ideal agile team there are no specific roles. Agile development is quite the opposite of the "throw it over the wall" mentality of development vs. QA. Clearly the problem is: if a feature is not Done, should people get off the story and do something else? And if QA is not irrelevant (in other words, it ...


14

Use spike to reduce the risk of a story or increase the reliability of an estimate Spike is a term that comes from the Extreme Programming (XP) practice. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate. The duration and objective(s) of a spike should be agreed between the Product Owner (PO) and ...


14

TL;DR A Sprint enshrines your empirical process by providing a maximum delivery cadence It increases communication and alignment It adds some predictability to the unpredictable nature of software by evening the batch sizes. A Sprint is a container for planning! While the Scrum Guide says that you must deliver working software at least every 30 days there ...


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


13

The art of giving a SWAG estimate I have worked with many developers and development managers who are very reluctant to give an estimate with such limited information and limited time. They have been bitten too many times in the past. The main reason is even if the people asking for such an estimation understand the risks and give an assurance that it will ...


13

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...


13

TL;DR Part of any project management framework, but especially agile frameworks like Scrum, is the necessity of continuously managing stakeholder expectations. People want what they want when they want it, but a big part of project management is explaining to people what they can actually have within the various constraints impacting the project. As the ...


12

I would hope that by now you would have frozen scope as you have cited new requirements entering at the testing stage as a problem. That has to stop otherwise you are in an endless cycle. Once you have stopped the scope creep there are a number of areas you need to look at. But the one that leaps out at me is System Testing. If the users are finding issues ...


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


12

Directly and honestly. By the way, I think, this is a sales and negotiation question: As far as I understood, you would like to support your customer and maybe earn some money. You would like to do both by predicting the future and you are (for whatever reason, time in your situation) not able to prove your prediction. What is the worst case outcome? ...


12

The software project, already completed (and even then your historical data might be off by more than 10% depending on how you tracked it). Note: this is not a joke. See https://en.wikipedia.org/wiki/Cone_of_Uncertainty


12

Is it the responsibility of the Scrum master to intervene and interrupt a team member when he/she starts telling about points beyond those 3 that I mentioned? Technically speaking, no. The purpose of the Daily Scrum is to facilitate coordination between the the Team. It's not for the Team to call off those three points by rote. Many Teams don't use the '...


11

Let me challenge the frame of your question a bit: Why do you have such specific requirements that change for every ticket? Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole ...


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


10

Kanban certifications are definitely not as well established as Scrum training/ certifications. But they certainly are available. The Lean Kanban University, with active involvement of/ direction by 'Kanban Method for Software' pioneer David J Anderson, has been issuing 2 kinds of certifications - AKT - Accredited Kanban Trainer - and KCP - Kanban Coaching ...


10

The short answer is never give a fixed time estimate, always give a range. And then clearly document this in emails or the project plan (writing). Long Answer: Fifty some off years of software development has proven fairly conclusively that estimating an entire project, before any work is done, has a success rate of around 20% or less (based on 80% of IT ...


10

In Software Estimation: Demystifying the Black Art, Steve McConnell presents a table that is adapted and extended from Measures for Excellence: Reliable Software On Time, Within Budget, Industrial Strength Software, and Five Core Metrics: The Intelligence Behind Successful Software Management for line of code per staff-month for different kinds of software. ...


10

This issue is not just limited to developers or agile or even in the IT industry. This cuts across all industries and all types of roles. Providing estimates is about trying to predict the future as accurately and precisely as we can and the inconvenient truth is we have no ability to predict the future with any real degree of accuracy or precision. ...


10

Stop work immediately and get the work under a contract. Get a detailed Statement of Work that clearly identifies what is getting delivered, what activities will take place, what finished looks like, how you will invoice, how they will pay, etc. Your issue is not methods or communications or convincing them. You have no contract or are not enforcing your ...


10

Everything in your question suggests that you are exploring a new problem, not simply creating something you already know exactly how to build. Because waterfall asks you to create your design completely before you start building it, using waterfall would be inherently problematic. In Agile, and Scrum specifically, the goal of making a product increment and ...


10

I am personally adverse to the idea of ever saying a sprint 'failed'. Scrum uses the term 'inspect' 27 times, and 'adapt' 16 times over the course of the guide. Scrum also has no notion of 'failure', and the only reference to failure in Scrum is listed here: Failure to include any of these events results in reduced transparency and is a lost ...


9

The issue is not just that documentation was poor, rather that some of your planning deliverables were either not done or not implemented. Documentation in and of itself won't help you. That being said, documentation provides evidence that your team has thought through what you need to do and has developed a reasonable, feasible and achievable plan. The key ...


9

Should developers do QA? I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing ...


9

Of course you may! Scrum doesn't prescribe what concrete representation of requirements you should use. There is no such term as "user story" in Scrum Guide at all. Scrum Guide operate "Product Backlog Item" instead. Scrum Guide imposes three constraints to well defined (or "refined" in Scrum terminology) PBI: It should be clear to all Scrum Team members. ...


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


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