How do you handle scheduling with developers who always come up with new cases in specifications?

Question

We are a small mobile development team (6 developers, 3 QA, 1 team leader). We're a little new to agile, and are just learning the ropes/making mistakes as we go. The whole team reports to a project manager in another country, who in turn talks to the client directly. This is done because of language barrier issues.

We are currently trying to adapt an agile procedure, where we do weekly scrums. For each release, here is the current flow:

1. The specifications are taken from the client in the beginning.
2. After studying what the client wants to do, we prepare prototypes and questions/clarifications and have the project manager in the other country reword and prepare for the client.
3. After the client replies, we either proceed to step 4 or repeat step 2 until everything is aligned.
4. We start implementing the specifications.

I'm aware that not every issue or error case in the specifications is determined in step 2, and may still arise in the later phases of the current release. However, there are times when, in step 4, the developers still get cases (sometimes edge cases) that they assert that the cases need to be handled and we should repeat step 2 again. It's currently giving the team a bad reputation to the manager, and most likely the company a bad reputation to the client. For these kinds of issues, is it better to:

1. lock the specifications and any questions once step 2 is done, and move all the other cases (unless critical) to the next release for fixing
2. add more time to step 2 (this, however, is also risky since giving more time for the developers give them more time to slack off (e.g. - the deadline is still far, I can take a breather for now))

I am aware this is a case-to-case basis, but on a general note, which would be better? Or are there any other possible solutions?

Answer 1

The main reason Agile came about is that people realised that change is inevitable in software development. This change comes from several sources:

• Requirements change - People are notoriously bad at defining requirements up front. They are much better at critiquing something they are shown.
• Technical risk - Development is a tricky business and you often find once you start on a solution that you realise things you didn't know before.
• The world around you changes - Team members get sick, meetings get re-organised, people change their minds. The world is full of change.

For many years people tried to fight change. They attempted to get better at doing requirements up front. They attempted to allow contingency for unexpected events. None of this really helped.

Your two suggestions follow this pattern.

That is where Agile came in. With Agile change is not only accepted it is actually encouraged. Once you accept change is going to happen you can build your processes around it happening.

My advice would be to go for an Agile solution. Expect change to happen. Don't lock down how long you think things will take, but allow flexibility. Expect every time you show something to your customers to get back feedback and to have to make changes.

Answer 2

So you're running agile. You have a sprint planning session and the client wants a stove installed in his kitchen on the north wall between the cabinets. The developers ask all the right questions.... Whats the size of the stove, whats the color, gas or electric, btu output.. etc.

Well... Lo and behold one week into installation the developers discover the countertop installers left some over hang on their counters and the stove doesn't fit in its spot.

Your proposed solution is "the requirements are set.... Get a tow truck and a chain and press the gas pedal until that sucker fits".

My question is, if the client isn't available, who is the product owner? A 20 minute conversation with a product owner would decide whether to:

• A) tear out the counter tops
• B) buy a smaller stove
• C) move the cabinetry over

It sounds like the problem is that the client is not available and no one is stepping up to act as the product owner to step into the clients shoes and make a best judgment call. Someone just has to say "get the smaller stove and tell the client why we did it". No one wants to take any ownership.

Answer 3

It sounds like you're doing Scrum. The Scrum framework offers you two answers, both of which you should implement as soon as possible.

1. Product Owner

The whole point of a product owner is someone highly available to the team who has the authority to make decisions. One quote: "A good product owner should ensure your questions are answered within 5 minutes 85% of the time." -Jim York.

Your project manager might be acting as the Product Owner, but this should be explicitly clear, and this person needs to be available and empowered to make decisions.

If you can't get a real Product Owner, you might want to consider doing something other than Scrum.

2. Empirical Process Control

Transparency, Inspection, and Adaptation are the pillars of Scrum. The point of Scrum (and Agile in general) is not to answer every question ahead-of-time in order to "get it right the first time." The point is to build something that works, get feedback on it, and then make it better.

You don't need to check every single decision you need to make with the PO prior to doing the work. The idea is that the developers make good decisions, present their work for feedback, such as at the Sprint Review, and then iterate to make it better.

An example

Let's say the PO asks that homeowners be able to provide the date range for how long they lived in their previous house.

Before taking the PBI into your sprint, you get some clarification that this should only cover date ranges in the past and that there must be an end date since this is about the house they are not currently living in (good job!).

After getting started, you ask and verify that the date range should include the dates selected (inclusive). The PO answers right away.

When you're almost done, you realize that your solution does not allow one-day-long ranges. The PO is out sick, so you make the decision to stick with your current solution since living in a house for a single day seems really unlikely.

At the Sprint Review, you point out that date ranges must be two days or longer. The PO admits that you had a reasonable assumption, but that there are numerous examples of single-day residency in the legacy system, so he wants to make sure the new system can also handle this. The PO creates a new PBI to allow homeowners to enter single-day date ranges and moves it to the top of the backlog.

Good job all around!

Answer 4

You build based off of what is known at the time. When something is discovered during development, it can go into another "step 2" discussion.

If the team or the product manager want the specification to be complete before work begins and changes to them are not acceptable, then the question is whether or not you are not doing agile software development.

Review the Manifesto for Agile Software Development: http://www.agilemanifesto.org/ The four values and twelve principles are powerful.

Answer 5

you are right, it is always a situational decision. The better you know what the client needs to receive from the project/phase/sprint you can start to learn as a team where within the application you, as a team, derive value.

1. If you start prioritizing with the client where value will be driven, then it is their time to direct you to get there the cheapest and easiest way possible.
2. The better you explain how long your design/approach will take based on this priority, the better the client can direct your time.
3. Always under promise and over deliver
4. Agile is a cycle, as a team: prioritize, discuss options based on time to deliver and value, make a decision and go.
   • Lock in on a decision per sprint, a measurable goal is always best, then evaluate the outcome.
   • Don't get into "analysis paralysis",
   • As your employees and the client team get better at priorities, requirements, time estimates and over-delivering, you will be better able to answer the question asked above.

Hope this helps.

Answer 6

Totally agree with @Barnaby Golden

These are the challenges that Agile is for. It's always difficult for a team transitioning and in particular when consulting for external clients.

The key here is training. Invest in some quality training for the whole team and include the BA's and sales teams as well so all is understood and conveyed to the customer.