AUP Chosen as Guiding Process

One of the best decisions made during our Studio program was making AUP as our overall process guidance. This was a critical decision because early in the semester we were wandering in what type of activities to focus on.

The AUP’s phased based approach mapped really well to the MSE program semester structure. In the high level perspective of the project it helped the team to do better planning. It provided the Go or No Go criteria to move from one phase to another. These exit criteria milestones in our plan, from which all the project tasks were derived from. The good thing is that by creating our plan with these milestones we streamlined the team effort toward a same direction, and we were following AUP process by enforcing its activities in our plan.

AUP also allowed us to embed iteration within phases, this allow us to use SCRUM like iterative process for our planning and extreme programming for our Construction phase. This allowed us to follow the AUP in the long term of the project and use other processes within each phase.

The Planning Race

Step 1. Figure out which features to implement.

Step 2. Specify the tasks that are required to complete the desired features.

Step 3. Peer review the specified tasks.

Step 4. Calculate team members' velocities based on the previous two iterations of accomplished work.

Step 5. Start the planning race.

The planning race is where team members attempt to fill their task queues (the upper limit of which is determined by the velocity) as quickly as possible. The faster you grab tasks, the more likely you'll get to do the things you want to do. The race should take place in a large conference room where loud talking is allowed. Bargaining, bartering, calling dibs, and talking smack are all highly encouraged. If you're doing it right it should almost sound like the commodities market where teammates are buying and selling tasks at fixed hourly rates. As punishment for taking more tasks than allowed by your velocity, other team members are allowed to cherry pick tasks from your queue.

Advantages: Dialing the planning knob to 11 means less time spent planning. I know how much you love meetings but the less time spent planning means the more time spent getting this done.

Disadvantage: The Planning Race requires a healthy backlog of tasks to pull off. There has to be at least enough tasks for everyone to fill their queue and ideally a few more left on the backlog. Tasks also have to be well specified, meaning everyone understands and agrees what needs to be completed.

The moment of Zen for the Square Root team was when we incorporated Step 3. Peer reviewing new tasks in the backlog streamlined our entire planning process and allowed us to plan faster and better than we had ever planned before. The result: not only were we spending less time planning but the quality of our plan increased dramatically. Some of this may be due to increased maturity and practice, but I stand by the Planning Race. It's super fun.

Before tasking peer reviews:

After tasking peer reviews:

Wicked Requirements

Rittel and Webber coined the term wicked problems (pdf) to describe a certain class of problems that were particularly tricky to deal with. Such wicked problems exhibit most of 10 specific characteristics. I propose that planning software within a fixed budget is a wicked problem.

At the start of our studio project we knew we had to gather some kind of requirements. Requirements are the first step in nearly every software lifecycle model but few processes focus any effort on describing how those requirements are supposed to be gathered. We were basically left to our own devices when building a process for requirements elicitation. Sure we had techniques we could apply, but those don't help us address the wickedness of planning the project.

There is no definitive formulation of a wicked problem. Depending on the methods we chose the elicit requirements, the solutions would change. Different techniques might prompt different reactions from the client and in turn give us a different view of the solution space. This was certainly true as the information we got from ARM, use cases, prototypes, and problem frames was always different.

Wicked problems have no stopping rule. When do you have enough requirements? Agilists subscribe to the pay-as-you-go model to deal with this issue. Knowing that we wanted to spend more time on design and didn't have a firm grasp of the problem domain, we felt we needed more information. Any requirements engineering process we built would need to provide guidance for stopping.

Solutions to wicked problems are not true-or-false, but better or worse. Any plan we create for the project based on our requirements will never be The Plan. Our requirements can only ever provide more or less information which allows us to make better or worse plans. Of course if the requirements are incorrect...

There is no immediate and no ultimate test of a solution to a wicked problem. How do you know you gathered the right requirements? The funny thing about requirements is that, though they may be testable, unambiguous, and precise, that doesn't mean they are right. The best part is that even if the client and team thinks a requirement is right, once it's implemented (the eventual, partial test) everything changes. "That's great but can it do this other thing instead?"

Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial-and-error, every attempt counts significantly. Normally this wouldn't be too big of a problem but given that our project is so short lived, we really only get one shot at gathering our requirements or we'll be so far behind that we might be unable to catch up. Like or not, our product ships in August.

Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan. What do requirements look like? We chose to record our requirements as use cases. Eventually we needed to add more information in the form of paper prototypes, work flow diagrams, and additional team communication.

Every wicked problem is essentially unique. Sure, folks have built web applications before, but no one has ever built a SQUARE Tool like what we've built.

Every wicked problem can be considered to be a symptom of another problem. It was not uncommon for our requirements elicitation discussions to uncover other ideas about the SQUARE Process or other ways the tool should operate (other than the specific feature we were currently discussing).

The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution. Our solution took the form of use cases. This worked well in some ways but was awkward in others. In particular, it was difficult to articulate, plan, and implement system-wide features such as quality attributes. We knew this going in and tried to compensate but our ideas didn't always work out the way we thought they would.

The planner has no right to be wrong (planners are liable for the consequences of the actions they generate). Ultimate responsibility for each requirement laid with the team. If we were unable to gather the right requirements it would impact our grades and our relationship with our client.


10 for 10. Requirements engineering and software project planning is absolutely wicked.

Requirements Engineering
We chose to focus effort in the fall on gaining domain knowledge and gathering requirements. Whether this was the right thing to do or not I leave to another discussion on another day. Instead I'm going to discuss what we did and how it worked out.

At first we started with a depth-first approach to collecting our requirements. I've spoken on my personal reflection blog about the importance of having proper affordances in software process and this is a case where the affordances were all wrong. Our original requirements process required that the team completely record requirements for the first three steps in the SQUARE process before moving on the other steps.

Given that requirements engineering is a wicked problem, this process was doomed to failure. There were two main issues with this process. First, the team had to wait for answers to questions from the client thus blocking the completion of other use cases. Second, not enough was known about some use cases to continue pursuing them until further research or experimentation could be completed. According to the process we would need to conduct those experiments before moving on to other requirements. This is obviously not satisfactory.

Almost a year ago to the day (November 14), as the team lead at the time I called an end to the original requirements engineering process and suggested a breadth-first approach in which a known set of use cases would be specified to an agreed upon level of quality (defined by a checklist).

The new breadth-first approach worked as planned. As a team we were able to gather information on a variety of use cases simultaneously and achieve a minimum level of understanding about the system.

Having the guts to make the change as a team allowed us to avert near disaster and let us have a complete (if not finished) set of requirements that were good enough for starting design work, prototyping, and experimentation. We nearly failed because we tried to solve a wicked problem with a tame process.