New answers tagged

4

Long-Lived Feature Branches and Infrequent Merging are Anti-Patterns Which is better large feature branches or merging frequently? Which is better small work items vs large work items? This question has both engineering answers and project management answers. In general, though, the answers will be similar for both disciplines, although perhaps for ...


10

There is a lot to unpack in your question, but from what I read I see two main issues: the old guard (as you name it) doesn't want to change their way of working. What they did might have worked before, or not, but they found themselves a certain pace of doing things and the changes you want to bring forth are not to their liking. Since you mention a new ...


1

Remember: "user(!) stories" are exactly that ... a business/software requirement, expressed from the point-of-view of the user. "Users," however, are fully entitled to "expect a system to 'work,' without concerning themselves as to how it works." They have no idea how the systems which they use are internally architected ... ...


2

You can sense the difference by understanding the reason for the existence of the User Story. User Story represents the customer deliverable business value, and it is the basic item in the Product Backlog. The user story is written on the gathering requirement stage, and later injected into a specific sprint, after that the scrum team has to implement this ...


4

Is Task always decomposed from User Story? No. Tasks are often split from a user story, but that does not mean that a task can only exist as part of user stories and thus they always have a smaller size. Tasks can exist by themselves. You tagged the question Scrum. User stories are not a Scrum specific thing. Your Product Backlog isn't composed of user ...


-3

Those of you that are saying a mid-sprint review is the same as the daily scrum are just plain wrong. The daily scrum targets awareness, inclusion, and interaction through secondary meetings, those discussions and other interactions which come after the scrum and which are prompted by the increased awareness the scrum brings. The mid-sprint review has a ...


3

Here are some ideas that may be applicable: Rather than offering choices, present the situation to the team and have them deduce their options. Such ownership of the problem will make it easier for people to commit to a path—even if they do not fully agree. Make sure that dissenting voices are heard and their concerns acknowledged. Partner with them to ...


0

The idea of TDD is to code only what you really need and is a form of Test First. It's really a way of nailing down acceptance criteria for a user story more than it is a way to unit test everything that goes out. It doesn't really sound like this is what you're interested in to me, at least not at this point. Rather you may be looking at some more ...


0

Advantages of TDD: It should reduce the number of bugs and hence save on bug-fixing time It gives developers more confidence to refactor It can help get a better design (thinking about testability helps with design) Disadvantages of TDD: Extra effort in writing the tests When refactoring, the tests may also need to be refactored, complicating the process ...


2

TDD is more about how you write production code. If you need to write a large pice of code TDD allows you to split the work into small pieces. And tests guide you all the way. There are many cases when this approach leads to faster development, but there are also some cases when it doesn't (if you have too much doubts about the design of your code you may ...


1

To echo what the others have hinted at: Testing is not a necessary evil. Testing is a crucial component of delivering quality (or at least working) software. Keep in mind that you only get one chance to make a first impression and delivering buggy software destroys your reputation. So, to answer your question: You need to budget in more time for testing - ...


3

TL;DR The real problem here is that your organization is framing the cost of testing as unwanted overhead, rather than as an expected and necessary cost of doing business for product development, maintenance, and support. Focus on fixing that. Analysis and Recommendations for Reframing Would you have any tips on how to improve this process so that testing ...


11

My devs are not used to unit testing framework and are still learning This will improve over time as they gain more experience. There are only 2 of them and each with their specialty (Front-end and back-end) so they have to do both the coding and the unit testing for their side of the stories. That is absolutely normal. Who else would write tests? Even if ...


0

I too found this question confusing. Thanks for raising in this forum. After much consideration I decided to go with: Learn why the Development Team wants this and work with them to improve the outcome of the daily Scrum Acknowledge and support self-organizing team’s decision As a result I believe I got the question wrong in the exam. As an experienced SM ...


0

Agile is a tool, not a solution. In this case, I would phrase agile as a tool which can be used to help leadership understand the company they are running. If leadership not only does not wish to understand their company, but would go further such that we can say that they wish to not understand their company, there really isn't anything that can be done ...


4

I'll make an assumption here, but it seems to me that you are thinking about your Agile project from a traditional project management perspective, where you focus on layers of work or on work packages that you need to prepare, plan, and then build, with each piece having to be accounted for in the correct place. You are focusing on project work basically. ...


2

The agile approach puts the emphasis on cross-functional teams, often consisting of business, technology and everyone else working together on some common endeavour. Think about what you really want to achieve by categorising artefacts as either development or business. Many people will prefer not to split things up in that way in case such a separation ...


0

Realistically, the only way to deal with this is to be prepared to find a new job, and then push back with some non-negotiable standards your team will operate by. You have to realize that it isn't a matter of technique, but executives have put you and the team in a ridiculous situation so that no matter what you do they won't be satisfied. The alternative ...


5

Managers need to manage The truism of "good, fast or cheap - pick one" is always relevant. You can manage with that, so long as you know what's acceptable. If senior execs expect all three, managers MUST push back. That is literally the only reason for having middle managers. If it was as simple as just giving a task and a deadline to engineers,...


0

This sounds so far away from what Agile is supposed to be, it's almost unbelievable. Read https://agilemanifesto.org/principles.html and see if it sounds anything like the way your management is behaving, particularly "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.". ...


1

Arrange a meeting with the high-ups for a MoSCoW prioritization. The bosses want you to do Agile? Well, then you're going to do Agile, and that means MoSCoW prioritization. Split the task you're doing into pieces, use Story Points to estimate the amount of effort it would take these pieces, and arrange a meeting with the bosses to prioritize those pieces ...


0

Ex-Project Manager, ex-Line Manager, ex-Scrum Master, and ex-Product Owner here. 🤷‍♂️ A picture says more than a 1000 words, so give this to management and ask them if they want to risk business continuity planning by overloading your team beyond a division by 0: i.e. Does upper management want to risk the entire / partial / ... business ¹ when a disaster ...


4

I have worked in consultancies with a similar setup. They need to give the appearance of using agile methods to look cutting edge, but typically they only pay lip service to them. What I have found is that you can use elements of agile frameworks like Scrum to show them just how bad things are. For example, say the team is given a fixed-scope, fixed-deadline ...


8

I would recommend rethinking why you want to transform to agile methods. Agile methods are designed to deal with unclear, ambiguous, or changing requirements. If you have a fixed-scope body of work with a fixed-date delivery deadline, many of the techniques associated with agile methods will add overhead. In this situation, you can't just "implement ...


13

What is the best way to implement agile in these circumstances? You cannot. Agile is not a grass roots movement you can do "against" or without the respect of the higher ups. It's all about team work and if part of the team does not want team work, then you cannot make them. Especially not if they are your bosses. It's up to you to decide whether ...


23

You ask: What is the best way to implement agile in these circumstances? Before thinking about this question you should think about how to bring in some common sense into the situation. Having people work overtime isn't sustainable in the long run and with time people start to make mistakes because they are tired and stressed. They end up working more and ...


2

I see two possible solutions: Consider the UX/UI designer as part of the SCRUM team. Whatever he/she does is a story, like all other stories. Now you have reduced the problem to the usual challenge of breaking down a task spanning more than one sprint, or more than one required participants, into pieces small enough not to have those issues. He will be ...


0

In this situation I would make "UI design" part of the overall Sprint-based process.


3

In Scrum, you have a Definition of Done. Equally important is your Definition of Ready — that is, what work is ready for sprint planning. Now, since a level of “Done” may be applied to each station in a workflow, it is reasonable to surmise that this includes the transitioning of work into the Sprint Backlog itself. In other words, before work can be ...


2

Visualization ≠ Dependency Management Visualizing the work is a technique, and generally solves for a problem that this group of individuals may not actually have. To find value in a solution, you first have to determine what problem you're actually solving for. While I suspect the problem is dependency management, that's not self-evident from your original ...


11

I'd like to be "fully" agile and having design being part of the sprint [...] I think there is a misunderstanding here, which is that in Agile there isn't any "upfront anything" and that the current iteration is the only place that things must happen. If this misunderstanding exists, people try to plan and do work only for the current ...


5

You already understand that UX/BA activities should be done before the Sprint starts, as developers need stories for planning. Your real question is how do you justify this approach from Scrum perspective (it's always the question with Scrum). I can see couple of ways of justifying it: UX/BA tasks are part of the sprint. But their job isn't to deliver a ...


2

Todd already put almost exactly what I was going to say into a comment, but it's not in an answer, so here goes. Either bake the work into other stories, or write stories with the team as the value consumer or viewpoint persona. – Todd A. Jacobs♦ You have three approaches you can take here. Any (or all) are equally valid, in my opinion. Bake the work into ...


2

Short answer: you don't. User stories are for a specific purpose and you don't have to use them for all work. A user story is specifically for telling the story of a feature from the user's point of view. Since that is not what you're doing here, just put in "Write unit tests to cover catapult physics calculations" or whatever. Now, people promote ...


1

I would recommend that you reframe your hypothesis, and ask (your team) the question - "What is the problem we are trying to solve?" Based on your question, it would appear that your team is a software development team and is already doing Scrum. You are running this experiment because you are either trying to solve specific known problems or ...


2

Your list is really good already. I particularly like the last one; If the stakeholders and product people are happy, chances are things are going well. Other things you might consider would focus on the elements that differ between Scrum and Kanban. For example: How frequently do we need to make changes to priorities at short notice (if this happens a lot ...


Top 50 recent answers are included