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


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


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.


15

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

Stories are about concrete aims you want to achieve with your product. Of course, refactoring may well be required by concrete aims! There is really no specific way of handling large refactorings in agile on purpose. Let me give you two examples of large refactorings; one is perfectly fine, the other isn't: Change an old and broken data access library and ...


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

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

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


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

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

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

As you've mentioned, it needs to be an elevating vision or goal. In light of the latter, I think the SMART principle and Time Map philosophies apply here. Let's start with the Time Map (to learn more, check out Time Management from the Inside Out by Julie Morgenstern): You know you can't devote all your resources because client projects take precedence. ...


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

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

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


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


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