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


11

How to roll out pairing in a Scrum team? I am afraid there is no right answer to this. It all depends on the existing team dynamics. Nevertheless, what is almost always relevant is to understand whether pair programming is something your team will benefit from? If you have good reasons for it, discuss them with your team during the retrospective meeting and ...


10

XP and DevOps are different things. They don't contradict with each other, they can be used together, but they have different base concepts inside them. XP: many people wrongly thinks that XP is just a list of 12 practices. But in reality, XP is much more than these 12 practices. Extreme Programming is complex, consistent programming philosophy, with own ...


9

To pair or not to pair is a decision that the team should make and own. "Rolling out" any technical practice, and especially one that brings with it such strong personal preferences as pair programming, is pretty much guaranteed to backfire. To encourage people to try pairing, I would keep an eye out for situations which commonly breed misunderstanding, or ...


8

Shouldn't any completed task be tested before and after it integrates into the whole system? Why would you call an untested task "completed"? Completed doesn't mean just developed (which I think is how you are looking at it). If something is completed then it means it was verified as working. Thus, it can be integrated in the rest of the ...


6

An architectural spike is a fixed time/variable scope PBI which is added if the team feels that more investigation is needed in order to maximize velocity (or to get better estimates). Practically, the spike consists in a series of investigations centered around finding solutions to one or more problems. It's not about writing code. The deliverable at the ...


5

Whether it's good or bad idea depends on how you manage risks connected with it. From what I have experienced the risks are: refactoring effort is often hard to estimate and leads to planning problems it's hard to define acceptance criteria for the refactor there is a lure to deliver half-ass stories (rather than half-done) at the end of the sprint with ...


5

Hardening Sprint should only be for stabilizing the system and getting it ready for release In my previous job we ran a one week hardening sprint prior to deploying the content of 2 or 3 two-week sprints to a production web site. At that time we were doing manual regression testing. There was not enough regression testing done within the sprint to be sure ...


5

TL;DR Within the Scrum framework, you are a member of the Scrum Team (which includes the Scrum Master and the Product Owner), and also a member of the Development Team that forms a third of the Scrum triumvirate. You have no other title within the framework, and the distinctions you are making are invalid within the team-oriented structure of Scrum. Extreme ...


4

Many tools can be useful without utilizing all the facets; however, the price is often reductions in benefits such as effectiveness, efficiency, and quality or an increase in costs and risks. One should not call something what it isn't. If one removes the handle from a hammer, it may still work for nailing; however it certainly won't be as effective or ...


4

Yes. In fact, it has been said a number of times by the creators that the reason they didn't specify how to do the work in the sprint is because they wanted it to be open to different types of work and they felt like the problem was already solved by other solutions (like XP).


4

TL;DR I'm not aware of much formal research in this area, but empirical results show that both models can be effective under the right circumstances. Flow and pair programming are somewhat orthogonal in the sense that they can't be performed simultaneously. They also represent practices that optimize for different things. Different Optimizations ...


4

I'm usually in the opposite position - when developers want to do so much refactoring that it starts to encroach on delivering business value. That being said, refactoring is a process like any other, and I have had teams fearing process change. It's about convincing the team to come with you. The link that you have pasted tells your team why refactoring is ...


3

It's good to care about the quality of your work, and refactoring (if well done) is a good way to provide quality but... let's face some inconvenient truths: Continuous refactoring is a learning process, simply deciding to do it it's not enough and if you're at the beginning you immediately realize it's going to take time before you get used to it (and you'...


3

Delegate authority of Coach is harder. Should it be Scrum Master, because he controls compliance the methodology. Or Scrum Master responsible only for Scrum, and XP Coach should be another person. Unfortunately best answer for above part would be: it depends. You need to take into accounts couple aspects of your question: Scrum and XP operate on ...


2

I'm afraid I can't give a comprehensive answer to that question on a forum like this, but I'll try to give the general idea. First, between Scrum and XP. Scrum provides a framework for projects with a focus primarily on team collaboration and delivery of value on an ongoing, incremental basis. It's pretty light-weight a provides a couple of roles and a set ...


2

I don't know what they are doing there. There are a few potential possibilities. 1) They are just enjoying a large screen. I find it incredibly hard to believe that it is truly IMAX. It is probably just a projector or a big screen. I like screens over projectors because I find the screens to cause less eye strain. 2) Maybe they are doing Mob Programming. ...


1

Open source software for Scrum/Kanban Here are two open source options for software project manangement using Scrum/Kanban. Tuleap ALM: See the Explore Tuleap Community Edition section for more details. Taiga on-premise self-managed However: You need to pay for the hosting provider. You need in-house skills to install, operate and maintain these software.


1

I am assuming that the projects you are working on are small / medium Scrum projects. Google spreadsheets or Excel Office 365 (to enable online collaboration) could be an alternatives. You could google search for managing small/medium scrum projects using Google Spreadsheets templates(free) or MS Excel templates to be used with Office 365 for sharing(paid). ...


1

As with practically any change to workflow, your first step is to get buy-in from the Team. If I were you, I'd bring the problems you're trying to solve up during a Retrospective meeting, and ask for suggestions. It's possible one of the Development Team members will bring it up themselves - this will make it go down much easier than a mandate. It's also ...


1

Refactoring is a skill, like any other skills you need to practise it often to learn it well and be confident with it. Here is what I would do to increase their refactoring skills: Execute the 4 example TDD coding dojo sessions, which rely heavely on refactoring: https://app.pluralsight.com/player?course=the-coding-dojo&author=emily-bache&name=the-...


1

Fear of refactoring implies unrealistic expectations in your work environment. I would work to remove that fear first of all. If you want an automated enforcement tool then you will probably find that a suite of unit tests, that reports code coverage, will be the most-recommended approach. However, all that really enforces is that unit tests are being ...


1

You have a hypothesis, now you need to decide: How will you measure success? What will be your criteria for stopping the experiment? What will you do if one or more team members does not like this approach? Trying new ways of working is a great idea, but it needs to be done in a way that you get the most benefit. For example, you could set your measure of ...


1

A hardening sprint is a tool. If you use the tool correctly it is a good idea. If you use the tool without knowing the problem you are trying to solve it may or may not be a good idea. That's a vague answer so in practice: If you have a team that isn't ready to continuously build quality into their product (i.e. they have accrued a ton of tech debt or ...


1

There is no process which is applicable to all different kind of projects. For example scrum will not work support projects where we support calls get logged every hour. This is because we cant establish a sprint goal for such a kind of project. Also scrum may be applicable for projects which are involved in work related to innovation for the same reasons.


1

In many ways Scrum and XP are complementary. Scrum is focused on the project/product management side while XP has a lot of focus on the engineering practices (like test driven development, continuous integration, refactoring, pair programming etc.). There is an argument that good engineering practices are necessary for the success of Scrum. This is ...


1

An interesting question that a lot of people raise when faced with Scrum rigid guidelines on team roles. Firstly I believe you should should be aware of the distinction between what a team lead and a tech lead might do. See Technical Lead != Team Lead. Scrum teams still need leadership like any other. The Scrum master should furfill the traditional team ...


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