Chapter 2: Agile Methodologies and Approaches
28
Outsiders (other than developers, ScrumMaster, and product owner) are allowed to join the meetings, of
course, but they aren ’ t allowed to interfere directly in the project. What does “ interfere ” mean? Well, in
many software development projects, you see many business managers or complete outsiders dictating
requirements. These requirements don ’ t come from the customers, they just arbitrarily live in the minds
of senior management or outside stakeholders. Often, these arbitrary requirements impede schedules
and complicate matters.
For example, there is rarely any real value to a requirement like “ It must ship in Q1. ” In the mind of the
person who brought it up, it has importance, but not to anyone else. What does that mean? Well, on
somebody ’ s strategic plan, such - and - such a product must ship in Q1, and the stakeholder ’ s bonus
depends on it. The customer doesn ’ t care when the product comes out, just that it works the way they
need it to when it does come out. (This is not to say that you should totally disregard a powerful
stakeholder ’ s concerns about schedules and money. After all, they will hopefully be rehiring you or
referring you to another business in the future. Treat them seriously and with respect. Just don ’ t let their
concerns interfere with what you need to do to accomplish the project.)
What concepts are you going to take from Scrum? The idea of a backlog is key, as is the nature of sprints.
You ’ ll find that on many small projects, a sprint can last 1 or 2 days. You ’ ll also find that you don ’ t need
to have a daily standup meeting, especially if it ’ s just you working on things.
XP
The main thrust behind XP is to put in place daily practices that reconcile humanity and productivity.
What this means in practice is that there is more weight given to face - to - face communication and
feedback than to formal requirements’ gathering.
Furthermore, XP proponents expound on the value of doing something simple and clean today rather
than worrying about future problems that might entail complexity. For example, why worry about
scaling to 50,000 customers when you only have 5 customers today? Wouldn ’ t scaling out to 500
customers (or even 50!) be good enough to get something working now?
Another great thing from the XP movement involves the collegial respect between programmers.
Contributions are made in a give - and - take environment, and in fact, many programmers pair up to
tackle problems and work through issues. Finally, there is the matter of allowing programmers to take
ownership of their code. It is not unusual to see programmers refactor code to simplify even when it isn ’ t
needed.
What are you going to take from XP? Definitely the simplicity and communication/feedback loops. It ’ s
important to incorporate good listening skills to any Agile approach. When working with a client one -
on - one, you will need to interface often. Make sure that you allow a significant amount of time for the
face - to - face contact, as it can create a powerful bond between you and the client.
Modifying Scrum and XP
Scrum and XP (extreme programming), like all methodologies, are wonderful things, but one immediate
drawback for you right now, as you read this book, is that you ’ re probably a lone programmer or work
with a very small team. If so, you may be thinking that these approaches provide too much overhead