Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
35

You're making a number of mistakes here. The first one is assuming that a Scrum Master is a manager. They're not. They're basically an administrator-cum-facilitator. They make sure things happen on the Scrum schedule, but they don't have to tell you how to, if you're a fully-mature Agile team. It mostly just happens. But they don't monitor the quality of ...


33

Testing is absolutely essential to agile, primarily because agile is based around incremental improvements: the difficulty is that it can sometimes be hard to see how the current changes will effect your old code. The best way to be confident that you haven't broken something is to test it, and to know HOW to test it. That way you find the bug immediately, ...


31

In my understanding a mature team is fully self-managing. Let's assume for a moment you're correct. I don't know one way or another, so let's not discuss it. The issue comes that even a self-managing team ends up with someone with good social and political skills that can represent the team to other departments. Someone who keeps track of what everyone is ...


26

The trick is not to avoid there being blanks. The trick is to fill in those blanks as early as possible in the process of development. You are correct that, if developers make assumptions, they will invariably be wrong and that will cost time redeveloping the software later. But, equally, if business people are expected to do a full up-front design when ...


21

Look into Kanban. It's more appropriate than SCRUM for your constraints. Edit: SCRUM is (very roughly) an ordered backlog with sprints and ceremonies to ensure that the volume of work 'in progress' stays under control and have something solid at the end of every sprint. If you ditch the ceremonies and the sprints cadence you end up with Kanban: an ordered ...


19

There's a lot of different styles, methods and mindsets related to the whole field development, and everything has it's own, shiny name. Agile is just a mindset that moves away from the usual, static programming models (like waterfalls) - it's primary goal is to achieve more flexible development and (at the very end) better software and happy customers. ...


18

You arrive home one day and you pay check does not... You want to take leave, but the team is too busy and has been for a year... Your wife or child is sick and needs you to cut back to 20 hours a week for 6 months. The finance department has called for a budget cut and someone has to go. The coffee machine broke and no-one can fix it. Your team is ...


18

Daily?? If you're following that strategy, you should commit far more often than that. The idea is that you commit early. Commit often. Sync often. Make commits small and easy to review. Conflicts happen because 2 people are independently working on the same thing - when you work in small fast units the window to conflict becomes much smaller. And the ...


17

In order to write the test in the first place, you have to design the API that you are then going to implement. You've already started on the wrong foot by writing your test to create the entire GameOfLife object and using that to implement your test. From Practical Unit Testing with JUnit and Mockito: At first you might feel awkward for writing ...


16

I see management as a total waste of time and a by-product of immaturity. Wow. You haven't worked with any good managers lately, have you? (We've all worked with bad ones). I have seen people occasionally make the mistake of assuming anything they don't fully understand is easy. (Business folk are especially guilty of this - have you ever received poor ...


16

In my view XP is a programming practices, Scrum and kanban are project management practices. They have a relation but do not replace each other. In our kanban project we use pair programming (mostly for complex sections and debugging), TDD, CI. So it is still used but management is pushing the project management side harder.


15

Break it down into high-level epics. Take each functional area of the application, one step at a time. Break one epic down into a group of stories (usable chunks -- anything that improves the application) and manage those as you would if you didn't have an existing application, with one exception: If it is possible, make it so that you can implement that ...


14

The difference between a push and a pull system is how the units of work are assigned to the person who will be carrying out that unit of work. The concept of push and pull aren't unique to software development - the idea originates from logistics and supply chain management. In a push system, some kind of task is created and then assigned to a developer. A ...


14

Technically, there are 3 cases here. It may increase the time. It may not, and it may have no effect. Not trying to be flippant, but this is an unprovable condition. There are cases where switching to an Agile method saved the project. Likewise, there are cases where that switch killed the project. There are too many variables involved to make ...


13

Agile deals with this by not doing that last 10% at all. We do the most important (valuable) work first, so by time you've worked your way through that first 90%, it's extremely likely that the last 10% is nice to have kind of stuff that isn't worth the investment to develop that last little bit. We tend to vary scope on an Agile project, not the schedule.


11

I'm a firm believer in the idea of No Silver Bullet. The two people that you are describing - the Scrum master and the XP coach - appear (based on your description) to be pushing their favored methodology as the solution to your organization's problem. No one idea is going to improve your time to delivery, quality, predictability, or any other aspect of ...


11

Probably the biggest difference is that you can be completely trained in scrum without even mentioning software. It is more about the process of choosing what software to write and when to write it rather than how. Conversely, extreme programming is primarily about the how, and specifically recommends certain programming practices, taken to the extreme. ...


11

Alistair Cockburn has a good article here that talks about this with the analogy of packing up a home for moving. Essentially I think the problem you are describing is when you ask the team to report "what percentage complete" they are and then use some formula to aggregate that into a overall project percent complete value. One of the most important ...


10

we just got through such an experience (me as scrum product owner). It took us two years to get to something releasable. But still, agile brought us many benefits. First: A total rewrite is by nature not agile at all. You should instead consider refactoring the existing product piece by piece. That has been discussed in another question. So let's assume it ...


10

Over-involvement with the customer in the process leads to the expression of customer wishes rather than needs. This assumes that the customer is some sort of perfect oracle for the requirements of the system. One of the fundamental principles of XP is that the customer is not a perfect oracle and that constant feedback based on real shipping software is ...


9

XP doesn't explicitly call for the creation of a model, but it doesn't say that one should never be produced. If developing a model helps you to build and then document your system, it should absolutely be done. The difference is that Agile Modeling has a different focus than system modeling in a plan-driven environment. In fact, the Agile Modeling site even ...


9

Agile projects can't fail. They are only bound by Time not scope. So if you run out of time you just deliver what you have. Eureka! Success!


9

QA Team Conversion to XP? This question you ask is one on which many traditional testers depend for career survival. Short answer is maybe. You are right to identify the work flow as an issue, but the work flow is simple compared with training for programming and development. Making testers into programmers may be a bridge too far. There are many other ...


9

What he's describing is a difference between unit testing (testing a unit in isolation, in this case a class but you can test each method if you're masochistic enough) and integration testing where you test the class and also how it works with other classes. That's not unit testing - you're not testing the unit but 'many units'. I believe the latter is ...


9

This felt odd as I was forcing the design of the implementation based on how I had decided at this early stage to write this first test. I think this is the key point in your question, Whether or not this is desirable depends on whether you lean towards codeninja's idea that you should design up-front then use TDD to fill in the implementation, or durron's ...


8

It's a common refactoring pattern called "Extract Method". Martin Fowler and Kent Beck explained the concept this way in their great book Refactoring: Improving the Design of Existing Code : Extract Method is one of the most common refactorings I do ... ... I prefer short, well-named methods for several reasons. First, it increases the ...


8

The highest profile one I know of is this: http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System


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