The business and architecture challenge behind creating effective user stories

Question

A friend of mine in another department had a problem and came to me with a question that I wasn't sure how to help him with. He recently became promoted to architect and he was put in charge of design and leading a team of developers that are of questionable quality and little to no experience with following a project plan. This team got in the habit of starting development as soon as possible before business needs were even evaluated, and then hacking the software to pieces when requirements finally became clear near the end of the deadline. Because of this they have tried formulating design standards in the past but never bothered following them later in the project when the heat was turned up.

He aims to change this and asked me about the best way to handle these challenges. My perspective is that the project is doomed before they start because management sets a tight deadline before the requirements are clearly known or understood. Dithering from the client exacerbates the problem further. I told him that Agile was MADE for these kinds of problems, formulate user stories based on the customer requirements as you are aware of them now, and then as more user stories or as they change just add to the backlog and readjust your sprint plan accordingly.

But then I got thinking about what really is the best way to handle this? The client has no way of knowing exactly what they want from the software now, but they know they want it and are willing to pay for it and they want at least some kind of working release by a specific date. They are given a quote with a breakdown of what will be delivered (it is a guess for both vendor and client), price is agreed upon.

When formulating the quote a deadline of some kind must exist even though it is soft at this point. User stories aren't even known and certainly not tasks and the ability to provide a reasonable estimation either. How do you approach this challenge?

When this quote is taken and agreed upon is it normal to use the rough deliverables as outlined in the quote as a basis for formulating your user stories?

Further do you have any advice on how to "keep the design patterns and documents alive" throughout the project as requirements change drastically?

EDIT: It seems many people assume that the client involved should be the one to provide the user stories as if it were a given. I don't have any personal experience with a client willing to put this kind of effort into being involved with the development process. Due to this, it seems to make sense that because of their lack of input into the development process, they are not a very good stakeholder for the project itself. The stakeholders at this point become the business analysts and application managers who are supposed to squeeze whatever trickle of information they can get from the client and turn it into usable information for the developers. This is clearly not working though so perhaps the ONLY way that Agile or Kanban can work is to have direct client involvement in user stories or else the project is doomed to failure?

Answer 1

He aims to change this and asked me about the best way to handle these challenges. My perspective is that the project is doomed before they start because management sets a tight deadline before the requirements are clearly known or understood. Dithering from the client exacerbates the problem further. I told him that Agile was MADE for these kinds of problems, formulate user stories based on the customer requirements as you are aware of them now, and then as more user stories or as they change just add to the backlog and readjust your sprint plan accordingly.

The fact that management is setting deadlines and making commitments before the project is well understood is a problem, and agile methods can't solve that particular problem. Agile lets you deal with poorly understood requirements, highly volatile requirements, and improving visibility to all stakeholders. However, if you have deadlines, agile can't make you magically meet them.

This is going to have to be a negotiation process with management. Perhaps they don't understand the nature of software development, or they simply don't care about the process of developming software.

The client has no way of knowing exactly what they want from the software now, but they know they want it and are willing to pay for it...

Do they not know what they want, or can they not articulate what they want? I have a feeling that the customer knows that business objectives that they want to achieve, and creating a vision and scope and capturing these high level business objectives would help a great deal. This should be done as part of project planning, even before you begin your chosen project life cycle - it exists at a higher level, and understanding this information can help you choose an appropriate life cycle methodology for each project.

When formulating the quote a deadline of some kind must exist even though it is soft at this point. User stories aren't even known and certainly not tasks and the ability to provide a reasonable estimation either. How do you approach this challenge?

First, understand the difference between estimates, targets, and commitments/deadlines. Also consider the cone of uncertainty when providing this. Knowing high-level business requirements can allow you to begin to estimate. As you know more user stories that are required for completion, you can slowly estimate project duration. As you track velocity (or some other progress metric), you can determine how long it takes you to complete user stories of known size and difficulty, thereby allowing you to estimate what iteration each requirement or user story will be started in.

When this quote is taken and agreed upon is it normal to use the rough deliverables as outlined in the quote as a basis for formulating your user stories?

You can't formulate all of the user stories from rough deliverables or business objectives. User stories need to be driven by specific requirements that are elicited from the customer and users of the software. You can probably come up with some, but not nearly all of them. As you begin to add functionality, it's likely (almost certain) that more user stories will be created and prioritized.

Further do you have any advice on how to "keep the design patterns and documents alive" throughout the project as requirements change drastically?

A good process methodology and discipline. Keeping documents in an easy-to-edit format and versioned helps a lot, as well.

It seems many people assume that the client involved should be the one to provide the user stories as if it were a given. I don't have any personal experience with a client willing to put this kind of effort into being involved with the development process. Due to this, it seems to make sense that because of their lack of input into the development process, they are not a very good stakeholder for the project itself. The stakeholders at this point become the business analysts and application managers who are supposed to squeeze whatever trickle of information they can get from the client and turn it into usable information for the developers. This is clearly not working though so perhaps the ONLY way that Agile or Kanban can work is to have direct client involvement in user stories or else the project is doomed to failure?

Many clients don't see the need for involvement. However, you can try to get them involved by rapidly showing them working, potentially shippable deliverables, asking them if it meets their needs, and correcting or improving the software until it adds sufficient business value. Demonstrating the value of involvement is usually a pretty good and convincing argument.

Now, involvement doesn't mean that they are always present and walking with you. For example, you might only meet with the client after a handful of iterations. You do, however, need someone to represent the interests of the client and can communicate with them on a somewhat regular basis so that they can be informed of the state of the project and product.

Answer 2

Being also a good development approach, Agile is also a perfect way to make the customer care of a project. All the developers need is to refuse to work out of the framework.

A client has set up no user stories? Okay, then we do not do anything useful, hacking around software as we wish (there always is something to refactor, some bugs to fix, some new libraries to study and try, etc).

"Why are you slacking?" the customer might ask. "Because the software is ready," the team answers (and I imagine this is the claim that may provoke the necessary input). "Wait, how come it's ready? It's missing the X form! And the operator has to wait for 5 minutes while Y loads, while the time should be decreased to 1 minute."

Here, you have two user stories. Repeat until deadline.

As for "keeping the design patterns and documents alive", rubbish bin is a key tool for this.

Answer 3

Help your team; help with sales.

The tough part about this situation is someone who has the skills to be an architect may not be a good team leader. Unfortunately for your friend, solutions to this company's problems are going to require the skills of a team leader. Seems like they are inncapable of executing even the best of designs.

The first step is going to be with the team. Everything is easier with talented developers who get things done. Keep the good ones. Attempt to train the redeemable ones. Get rid of the rest. Everyone needs to know where they stand as soon as you can provide an evaluation.

Take control from the very beginning. It's easier to let up over time. Require that standards are followed. Failure to follow will have your code tossed out and eventual dismissal. This is part of the first step.

There's not point in building a functioning team only to have it torn down by poor senior management decisions. You'll eventually lose them. Get involved with the client meetings. Of course the client wants a fixed fee, schedule and requirements. That's what my wife wanted when we remodeled our kitchen. It didn't happen (Kitchen construction has been going on a lot longer than computer programming.). As an expert you can help make those decisions based on information. Be there to let them know what can possibly be built and by when, but only after you've done some preliminary work. Give a confident, "I'll get back to you." Nobody starts building a building without involving the architect.

Let them know what your expectations are of the client. They have to provide information. Identify who is going to be available for meetings, questions, review, testing, sign-off ect. Force them to get more skin in the game than just writing a check. When they find out that they will have a time crunch as well, the schedule relaxes. They want to just dedicate some time for a few weeks and then be done with the process for several months until you come back with the entire project. That doesn't work. Let them know that this is to insure they get what they are paying for. Be confident and act like this is the standard way of doing things. Ask a client if it is all right to create poor software that probably won't work just to meet a deadline. Nobody will agree to that at the beginning (Of course they panick when the end is near and put their head in the sand and pray.).

There will be resistence from the rest of the company. Investigate this company's past performance on client satisfaction, the amount of promises they broke. The poor quality of the code and inability to make what should be easy fixes and upgrades. Use this against them. Sales people like doing what's easy for them. They need to understand that your involvment with the process will keep them from having to bring the bad news to the client.

Building a quality team along with helping sales people manage client expectations attacks this problem from both ends. Your friend has his work cut out. I hope he can juggle both of these roles.

Answer 4

This sounds like a situation where your friend is accepting a fixed price contract without a fixed scope which is a recipe for disaster no matter what process you use. You need to at least have an understanding of the minimum value to be delivered for a fixed price scenario to work - which it sounds like sort of exists, but not in a usable way. If you can't get that up front, then you need to have a plan for negotiating the scope and know when the last responsible moment is that this can happen.

I'm a huge fan of using Kanban in scenarios like this for a number of reasons, but mostly because it acts as a catalyst for change. There are several benefits I see to using Kanban in this situation.

1. Bottlenecks are obvious and visible. If you notice that a lack of user stories is a bottleneck, this is hard data you can take back to your customer to make a change early, when you still have a chance of delivering.

2. Kanban is great for helping teams who traditionally struggle with process to become better. I have read several accounts where inexperienced or less-than-stellar teams became some of the best teams in the company because of the visibility afforded by a Kanban system. Basically, there was no where for people to hide which helps the team help themselves. Further, because you are constantly shipping and can see progress happening, it boosts morale which helps the team even more.

3. The team follows the process on the board. So a story can't be coded, for example, until after it's been through the other steps - e.g. analysis, design, peer review. The team decides the gates between phases and because it's visible, accountability is easier to do.

4. Hand in hand with Kanban is Kaizen, "continuous improvement". This attitude is one of the things that helps make mediocre teams great.

As far as keeping design patterns and documents alive... why create them at all? Since things are in flux, the documentation should be in a format that is easily changeable. Wiki is great for this, whiteboards and paper/pen is even better. Documentation strategies like the Refreshed System Metaphor and architecture haiku are great for this scenario. The goal is to have lightweight ways of capturing information that are comprehensive and can change easily, and that can be recorded more formally later when you are preparing for hand-off, maintenance, and moth-ball mode.

Answer 5

The client has no way of knowing exactly what they want from the software now, but they know they want it and are willing to pay for it

Part of the thinking behind TQM and BPR was convincing corporations that the price of the product includes the cost of quality. That is, if the customer is wishing to pay for the product, why not include quality processes into the building of the solution? Is the barrier to collecting requirements a financial issue or is it a time issue?

The facts your are stating in your description raises high risk.

Unless you are using a tool that can generate most of your code automatically, the risk in your described scenario will never go away.

There is no substitute whatsoever for understanding the requirements (at least core functionality and business rules) and determining with confidence what can be delivered in the deadline.

Even if you use the approach of generating a solution by evolution/prototyping, you'll need time and user interaction.

Some ideas that come to mind here are:

0-Clearly identify the reason why you can't have requirements defined up-front.

1-Attempt to educate the main players in the value of requirements determination. This can be done by showing the cost of fixing bugs vs. the cost of building the right software in the first time. There are some interesting charts for that (I can dig at least one for you if you want).

2-Attempt to involve the customer as a responsible party in the solution not just as source for requirements and a point for acceptance testing.

3-Attempt to quote based on time and effort rather using a fixed price contract

4-Attempt to break the systems in several small components (subject areas) and deliver each separately and frequently. While this adds more work on your team, it helps you add more interaction with the customer, an interaction based on a real product not just documentation.

5-Find tools that speeds up development as much as possible

Addition Few references and charts that show the value of catching errors early and that encourages front end analysis and requirements gathering: References: What do we mean by "design" in software engineering?

https://softwareengineering.stackexchange.com/questions/104232/how-do-you-address-or-avoid-problems-with-new-features-being-quickly-added-to-the/105600#105600

How to explain that it's hard to estimate the time required for a bigger software project?

Charts:

http://www.codinghorror.com/blog/2005/03/on-software-engineering.html

http://www.isixsigma.com/index.php?option=com_k2&view=item&id=520:defect-prevention-reducing-costs-and-enhancing-quality&tmpl=component&print=1&Itemid=95

http://www.birditcorp.com/pierson-training/

http://www.stickyminds.com/sitewide.asp?ObjectId=12529&Function=edetail&ObjectType=ART Chart on left hand side of page at: http://www.cogenit.fr/ressources/livres-bleus/smv-agile-method-for-it-projects/

http://silicontaiga.org/home.asp?artId=3394

http://www.sophist.de/en/requirements/studies.html

https://softwareengineering.stackexchange.com/questions/93974/criteria-for-good-architecture-analysis-and-design

page 11 of: http://media.wiley.com/product_data/excerpt/84/08186773/0818677384.pdf

page 9 of: http://www.itq.ch/pdf/sqm/07/sqm_moths_pr.pdf

Answer 6

have direct client involvement in user stories or else the project is doomed to failure

Correct.

That's excellent. Stick with that. It's perfect.