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


9

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


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

You're not qualified to second guess your developers. And this is too complex a question to ask on the internet. I'm sure this is a thing that impact your work, but why do you feel you need to come to some decision on technology. Do you have a very junior team? Either 1) Trust your people. 2) Hire some better, more senior, more expensive people who you ...


5

Another prioritization schema you can use is to score each feature using over value--benefit and penalty--and cost and risk. The picture below is a sample of what this would look like: Each criterion is scored 1 through 9, 1 being low and 9 being high. Benefit criterion is obvious; this is how the feature would add overall value to the system, ...


4

From the Scrum Guide: During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment. So basically, in each Sprint it's not enough to keep yourself ...


4

Patterns are things that have been observed in the world and found to be good. The idea has their roots in Christopher Alexander's work in architecture and planning, primarily books like The Oregon Experiment and A Pattern Language. They were popularized in the software field by the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) ...


4

In my view, any necessary labor that was exhausted in order to build the finished product or provide a service deliverable would be chargeable to that project as a direct expense. The test would be, would an employee perform the questionable task if it were not for the product being produced? If the answer is no, then it should be a direct expense to the ...


4

Scrum intentionally does not layout exactly how the team will build the product. There are a number of reasons, but most pertinent to this question is that what works for one team may not work for another. Similarly, what works with the tools of the early 2000's may not apply as well today. One of the reasons we work in iterations is because it gives us ...


4

I think DevOps defines the best practices here: specifically the principle of small batch sizes. In other words, if the batch sizes (code commits) are small, then the code reviews can be frequent and short. I would live with the frequency because that's more of an Agile thing and it's OK! Build a team culture that supports it. DevOps also tells us to ...


4

One possibility would be using a tool like Slack. Create a team news channel. Anyone who hears any relevant news or notes any significant comments/events during the day will add them as a message on the channel. People returning to work after having been away can scroll back through the news.


4

Practically everything you've said is a cause for concern but the project should be salvageable. I suggest you concentrate on two things. Firstly, as Mark also suggested, it seems from your description that you don't have clear ownership of the project. Someone will need to set priorities and be accountable for costs and that isn't your job as PM. If it's a ...


4

A FFP is not appropriate for your customer or you. If you pursue that you have to load it with a ton of contingency in both money and time that it would make it unfeasible for a normal customer. And it would ruin your reputation. A T&M is perfectly appropriate for this scenario. Insist on it or walk away.


4

I initially didn't want to answer this question since the comments do a proper job of capturing the gist of it (i.e. discuss it with your SM/colleagues), but since I don't like neither of the currently existing answers, I'm just going to throw a wrench into the works here. One of the answers basically says "How does the Scrum Master dare to do this", while ...


4

[...] you have 10 options, but only time and budget to realize only a pair of them You hit the nail on the head with this: "time and budget". You need some technique that accounts for these two factors. The SWOT analysis doesn't really account for either. You may do your analysis but then how do you chose? Do you go for the highest opportunities? The lowest ...


3

A failed sprint means you did not reach the sprint goal. That can mean all stories but one were completed, but that one was critical to reach the goal. Only you can know whether this is the case here. Keep in mind that the stories pulled into the sprint are a forecast of what the team should be able to do. Saying "all stories must be done" as some ...


3

IT IS! People forget this or gloss over it all the time. Pushing authority down the hierarchy has a lot of benefits for the organization and the individual but it is definitely harder - and for some people, it isn't worth it. For those that find it worth it, some of the most common reasons are: 1) Pride - Along with ownership comes a pride in the work that ...


3

If you are making large scale changes to your underlying infrastructure code then The Mikado Method might be useful. Methods and Tools did a review on it. There is a book on it Mikado Method for Legacy Code by Ola Ellnestam & Daniel Brolund Another book Working Effectively with Legacy Code by Michael Feathers is also a useful resource.


3

I don't see that SAFe and traditional agile are really comparable in an apple-to-apple sense. Traditional agile is terrific and when in doubt doubling down on the agile framework is a great idea. But at a fundamental level when you need to have 10 agile teams working in the same direction on what's essentially the same initiative you need a way to ...


3

It depends. It's important to realize that Kanban doesn't have anything to say about code reviews. It's simply a set of tools for visualizing and improving the workflow and flow of work through a workflow. There are a few key concepts - the Kanban board which provides a visualization of the workflow, work on the board, work-in-progress (WIP) limits, work ...


3

I suspect there is no single answer to this question. Individuals are different. Some may find that doing a code review is a welcome distraction from their coding tasks. Others may struggle with the context switching or may not enjoy doing reviews. Teams are also different. I can see the nature of code reviews varying depending on many factors including: ...


3

I've experienced similar issues with literally every team I've worked with. I've learned that the problem is not the lack of a great tool to solve it. Daily standup meetings are pretty common and useful if executed correctly. The most common problem I've seen in dailies is that everyone is rushing to express himself/herself and make sure that he/she has ...


3

Without detailed and fully agreed requirements, you have a load of assumptions. I suggest you document the assumptions as fully as possible, then structure a contract on a time and materials basis with the assumptions clearly stated. Then you can test the assumptions and document them as risks or issues as necessary. As an alternative to this you may prefer ...


2

Let us assume that you have a completed Technical Spec, where everything is well defined. Note that the answers overlap and complement each other. How many front-end developers are needed? Assuming you are going to use the same language for both platforms, but it's completely different code then the answer depends on how fast you want it completed. If ...


2

TL;DR Refactoring is a natural part of iterative and incremental development methodologies. However, a high ratio of defects in a product indicates one or more fundamental process problems. Such problems represent a cost to the project by consuming budget, schedule, and resources. High defect rates also create a drag on productivity that increases over time....


2

(From the linked Question) For instance, Sprint N+1 Planning the day before Sprint N Demo/Retro would fix my problem, but is probably a bad idea This is a commonly-used convention (not just in Project Management), where "N" means "some exact number, but for our purposes we don't care exactly which number", while "N+1" means "one larger than that number ...


2

Project is 75% done - still no sales agreement Why would anybody in your company move a finger without a contract in which the customer agrees to pay (whether it's for a feature or by the hour)? You tell them you start working as soon as the contract is signed. It's that easy. Anything else is silly and yes, losing money. Even with genuine well-meaning ...


2

If you read the Agile Manifesto and its principles, you will see wording like: Individuals and interactions ...; Customer collaboration ...; Business people and developers must work together daily throughout the project; The most efficient and effective method of conveying information to and within a development team is face-to-face ...


2

Todd covers quite well (+1!) the reason from an agile team perspective. I'd like to add a parallel perspective to it - why a developer would want to work on an agile team. First of all, agile is not for every developer. Not that's a problem per se, as there's still a lot of projects out there that are follows Command and Control approaches (some even using ...


2

It is possible for you to break jobs down into multiple levels of subtasks if you use the Hierarchical Task analysis method. Hierarchical Task Analysis is a detailed examination of the tasks users must do to achieve particular aims. This document explains how to carry out task analysis: http://www.idemployee.id.tue.nl/g.w.m.rauterberg/lecturenotes/UFTtask-...


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