Magic Milestones

So, I’ve recently finished a project where we insisted on prototyping even though it sent the project a wee bit over budget (2 days as I recall). What were the results?

Frankly, it was a good move. By the time we got to the point of UAT the client had only usability suggestions to give. The key to this was constant feedback. He’d seen only a tiny part of the final product very early on in the project but at least he had an idea in his head what the thing he was commissioning was going to look like. The first couple of reviews would have been painful if I’d have approached things from a traditional perspective. Guess what? The client only wanted to change what he saw? “Surely not!” I hear you cry “They aren’t allowed to do that!” But under the agile banner they are and indeed, positively encouraged to do so. Funnily enough, once one accepts this fact, the project actually becomes easier – not harder. So the client makes changes early, based on what he sees and because it’s early, the developers can do it without it adding cost to the project.

UAT was a dream because of this process and there were no nasty surprises. So you see, Prototyping can really be a project manager’s best friend.

Mike Cohen’s User Stories for Agile Requirements

Synopsis

Software requrements is a communication problem. those who want the new software must communicate with those who will build the new software. To succeed, a project reivew on information for the heads of very different people: on one side are customers and users and sometimes analysts, domain experts and others who view teh software from a business or organisational perspective; on the other side is the technical team.

By now we’ve learned that we cannot perfectly predict a software development project. As users see early versions of the software, they come up with new ideas and their opinions change. Because of the intagnibility of software, most developers have a notoriously difficult tiem estimateing how long things will take. because of these and other factors we cannot lay out a perfect pert chart showing everything that must be done on a project. So, what do we do?

We make decisions based on the information we have at had. And we do it often. Rather than making one all-encompassing set of decisions at the outset of the project, we spread the decision-making across the duration of hte project. To do this we make sure we have a process that gets us information as early and often as possible. And this is where user stories come in.

What are stories?

• Card - Stories are traditionally written on note cards and these can be annotated. However, they aren’t the requirements themselves they are simply a reminder for a conversation with the customer
• Conversation - The details of the story are worked out in a conversation with the customer/ product owner
• Confirmation - Acceptance tests confirm that the story was coded correctly

Examples

“As a frequent flyer I want to re-book a past trip so that i save time booking trips I take often.”

Format of a story should be:

As a user, I want to x, So that I can x

Where are the details?

The details aren’t written on the card as this is the detail that will be the conversation with the customer. If stories become too detailed they can be broken down into other stories and the original card simply ripped in half. The other part of the detail is the user acceptance test or “conditions of satisfaction” which are written on the back of the card. e.g. verify that a premium member can cancel the sam day without a fee (a tick is placed next to the box when this has been confirmed by the user.)

How to write stories

Set up a workshop and brainstorm as many stories with the user as possible. There is no prioritisation at this point.

• User modelling - brainstorm all user types (could use personas here)
• Everyone is involved

Stories should exhibit some of these 6 features INVEST:

1. Independent - Each story shouldn’t carry 12 more along with it. They should be independent of one another
2. Negotiable - The story is not a contract
3. Valuable - The story should be valuable to the user or customers. What is the business benefit?
4. Estimatable - The story needs to be small enough and known enough to be estimated. If it can’t be estimated then a card of discovery can be written to drive the team towards the original story getting done.
5. Sized appropriately - Small stories for stuff we are giong to do now and larger ones for stuff we’ll do in 6 mths time
6. Testable - Stories need to be tested and verified that they have been delivered

How do I break down a story?

• Break it down in terms of operations
• CRUD - just deliver create first off?
• Look at data types being supported can you cut data types down?
• Break down everything that is required for the next iteration
• On big projects if you have some epics then leave them to be broken down. Staple stories together than run along a similar theme

When do I know that the card is finished?

• If a story drags on because of iteration and feedback can you break it down?
• Finish the story by best endeavours given the time available

Why are stories better than specs?

• No training required
• People remember stuff when they do stories

What happens if I get audited and they want to see the spec?

• Write some documents if you need to
• Photocopy the story cards

What about non-functional requirements?

Try to write these in the same syntax

mike@mountaingoatssoftware.com

Product and Process Archtiectures for Integrating Agile and Plan-Driven Methods

The talk summarised the experiences of the USC centre for Software Engineerings’s industry affiliates in using XP and other agile methods. They found that the agiel methods are effective on small proejcts, but difficult to scale up. the talk presents a set of product and process architecture frameworks taht the idnuctry affilitates are finding effective for doing risk-driven integration of agile and plan driven methods to fit the particular large-project elements’ needs to simultaneioulsy accommodate rapid change and high assurance.

Although it’s hard to scale an agile project over 100 people, big projects need to be agile in order to adapt to the changing business environment, therefore it’s acutally more important for large companies to go agile than ever before.

Barry came up with 5 critical dimensions to large scales systems which effect the choice of whether to go Agile or plan-driven:

1. Size
2. Criticality
3. Skills
4. Volatility (adaption to change)
5. Culture

It was found that in large scale projects both Scrum and XP elements were used. However, there was a need to re-interpret some practices. For example the metaphor was hard to sustain across a number of different communities and the customer ended up being more than one person or else a customer proxy. Collective ownership called responsible ownership as it wasn’t always possible for everyone to be experts in all parts of the system.

In order to scale up Barry cited the following requriements:

• Business process analysis
• Risk management
• Wall gantts (story based earned value)
• Independent reviews
• Big picture architecture

Some situation dependent difference in opinion

• Simple Vs Architecture - With some parts of the system simple was best but if changes are predictable one can architect to accommodate it. Architecture checks integration before it’s coded so tha 100 people can code in parallel.
• Optional Vs pair programming vs reviews - reviews required where safety criticality was an issue
• Contract issues - large organisations have change control so have to re-negotiate memorandems if the scope changes
• New build coupled with a legacy system - impossible to refactor
• Sarbanes - Oxley - this turns the agile manefesto on it’s head: following a plan is more important than responding to change! This is an auditor manifesto and causes issues with Agile

Example - Lockheed Martin

• Agile processes (mix of scrum and XP)
• Agile modelling
• Pair programming
• Risk Managment
• Time boxing

What went well:

• Team empowered
• Short cycle times - feedback
• Continuous integration
• Customer involvement
• Pair programming

Findings

• Increased level of stakeholder involvement
• Cost of making change wasn’t flat. Fewer stories were done in 30 days as the systems got bigger
• Agile organisational processes were required - keeping track of progress etc

Critical Success Factors for Scaling Up:

1. Timeboxed iterations
2. Stakeholder involvement
3. Adative specs and plans
4. Scrum of scrums (need more leaders)
5. Architecture essential but lighter
6. Set expectations early
7. Resist temptation to do the easy stuff first
8. Use risk anaylsis to determine how more agility, discipline is enough

Relevant Agile Practices

1. Short stabilised increments
2. Continuous customer/developer participation
3. Early test continuous integration
4. Doing these systems without any documentation at all isn’t feasibile
5. Welcome changing requirements
6. Simple design just for current increment but refactor to accommodate later capabilities
7. If parts of the system are stable and some unstable then determine which parts of the system are predictable and which aren’t
8. If parts of the system are changing rapidly then architect these so that they can be modified without a ripple effect

Conclusions

1. Agile methods scale up to 100 people until processes need to be adapted e.g. scrum of scrums
2. However, systems need agility and product and process architectures and that help. These do look like they are scaling.
3. Place for all people in the new process even though change has been hard. Put people where they feel most comfortable e.g. people good at building specs so put them where they can do this, where people are more creative let them go agile.
4. Customer participation is still the biggest issue in agile development