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

Is there really a moral stance for UCD?

I was talking to a guy called Robert Biddle at the conference who made this excellent point:

UCD practitioners qualify what they do from a moral stance saying that the user should be the centre of the development process because the user’s goals should drive the development process. However, there are two reasons why this isn’t true.

1. UCD practitioners aren’t always acting in the interests of the user. For instance, take the case of a parking ticket machine. The user’s goal is to park and go shopping. Their goal does not include paying for parking, this is in fact the customers goal (the company who own the car park/machine). Therefore, in making the user pay for a ticket the UCD practitioner is making the user act in the interest of the customer and not the user.
2. Secondly, who says the user has a “moral right” anyway? If one is designing a missile launcher it could be argued by the pacifist that the moral thing to do would be to make the missile launcher as unusable as possible so that people wouldn’t be killed!

In response to this I would also make two further points.

1. Although the user’s goal is to park and shop and NOT to pay for a ticket they also have another goal: not to pay more money than they need to. When looking at any system we place boundaries on where the system ends and the rest of the world begins. If one takes the system as a complete whole by including concepts of paying versus the concept of being penalised for not paying, the user’s goal becomes “to park, shop and pay for the least amount of money possible”. In which case the UCD practitioner is working in favour of the user in relation to this goal.

However, Robert’s example was not of a ticket machine but of an ATM. The user’s goal (he suggests) is to take money out (maybe more than he has) and not have the bank charge him for it. However, my point would be that this is including the outside world as part of the system rather than working with the boundaries that a UCD practitioner would normally work within i.e. within the system’s boundaries. By saying that the user’s goal is to take money and not be charged is presuming that not charging the individual is good for them. This is looking at the user goals outside of the system boundaries and within the world outside of it. However, if the boundaries of the system are stretched so far that we begin making moral judgements then I could then argue that there are instances where the bank is actually being moral by charging the ATM user. This is because the charge is encouraging the user to be better at handling his money by not going overdrawn and being in debt! In essence we could argue for days but this would be outside of the UCD practitioners boundaries of practice.

However, if moral judgements are outside of the UCD practitioner’s realm of practice there are other, more fundamental issues at stake. For instance, in response to point 2, Helen Sharp made the point that anyone working in IT or systems design should ask themselves about the values of the people they work for and the values of the user when using the systems they are designing. This would mean that within the UCD process there is a value judgement before one starts work as to whether the work being carried out is morally reprehensible or not.

This is a good point but again opens up the question as to how far the boundaries stretch. If the UCD practitioner now has to examine how the system he/she is designing affects others from a moral perspective, rather than simply from a user perspective they are dangerously close to:

1. being accused of straying from the User-Centred Design process altogether in favour of something else entirely (”Human-Centred Design” so that the good of humans not just users are central to system design). In which case they aren’t UCD practitioners at all and have to cope with the questions around which and how many humans are served.
2. In response to Biddle’s claim that they are not “user-centred” but “customer-centred”, they cannot use my previous argument of “setting system boundaries”. In this argument, it is the system boundaries that govern the user’s goals alone. If the boundaries are stretched to include the goals of other agents outside of the system, then the UCD practitioner is not only in danger of straying from the task in hand into the field of moral philosophy but also into value judgements about which agent’s goals are the most important or morally sound. Again, the inclusion of other agents outside of the system boundaries mean that the UCD practitioner fails to remain user-centric.

There is potentially only one way out of this dilemma for the UCD practitioner. The practice following acceptance of the assignment by the UCD practitioner, must be separated from the moral judgement that takes place before the assignment is accepted. If we take medicine as an example, a surgeon may turn down an operation which will result in active termination of a life (such as an abortion) because he is in effect “siding” with the unborn patient over that of the mother patient. In this instance, the “customer” could be seen as the hospital trust who have set the moral boundaries for the surgeon’s work if he accepts the assignment. However, he isn’t allowed to take the operation and then decide to act in the interests of the un-born child rather than the mother.

In the same way, when a UCD practitoner takes on an assignment, they are already accecpting the customer’s point of view and accepting that the user’s goal is convergent with that of the customer’s (at least to some degree). When a UCD practitioner is faced with having to design a missile launcher he/she must first ask whether they can morally work for the customer and in accepting to work for that customer they are sautomatically setting the moral boundaries in which they will work. In doing this they are also accepting the system boundaries, in the case of the missile launcher, accepting that the soldier working the launcher won’t suddently suffer a crisis of conscience and want the launcher not to work and in the case of the cash machine, that the user goals when taking money out of the cashpoint are to recieve cash in line with the bank’s expectations.

What could go wrong if bit10 went “agile”?

This was a workshop where we brainstormed common experiences of trying to implement agile methods…

Common issues for development

1. Developers who don’t wish to communicate as much as Agile demands
2. Developers who don’t like pair programming
3. Developers who don’t know how to test
4. Testers who don’t have automated tools
5. Senior developers who don’t want to change because they know best and they are good at what they do so why change?
6. Difficulties with test driven development - reluctance/ not understanding
7. Developers who amend code (behind the scenes) when this isn’t good for the team as a whole
8. Developers who don’t like stand up meetings

Common issues for customers

1. Not having time to devote to the project
2. Not being skilled in testing
3. Wanting everything in the first iteration
4. Customers who don’t have the real decision making power
5. Customers who test the version before it’s ready
6. Customers who don’t appreciate code that isn’t 100% ready
7. Too many customers
8. Who is the customer?

Common issues in culture and management

1. Some teams don’t want to be “self-managing” they want to be told what to do
2. Some project managers don’t know how to plan under agile
3. Any change is painful
4. People’s roles change
5. If the company values aren’t about communication then Agile won’t work
6. Visibility for senior managers

Tips

1. Link progress to something visible like a pie chart in excel
2. Create user stories for technical aspects such as backward compatibility as well as other user requirements
3. Use “information radiators” like whitboards etc
4. Take things slow, adopt Scrum first then XP practices
5. Let senior people help you implement Agile
6. Gain customer buy-in and they become an ambassador for your project

Philosophers and Potnapekkas

The first day of the conference started well. The keynote speaker was Pekka Himanen (no relation to Potnapekkas)…

“The Hacker Ethic - what drives human action at it’s best?”

The “Law of Linus” - what makes the unconventional way work?

1. Creative passion
2. Social network
3. Survival

A single innovator is not a revolution. Enrichment comes from interactions between creative people. If you are able to form a community of enthusiasts to belong to, something greater than themselves and they gain recongnition in this community, this is a rewarding process for them. This is what drove the Linux revolution.

There is basic security in a social network and this leads to a collective state of emergency when this collapses. Everyone in the community then feels under threat and becomes competitive rather than trusting. Therefore any innovative community needs:

• Ability of creative people to work in a network
• Recognition which leads to a sense of belonging
• Innovations built of trust

So what do the best creative communities look like?

• Each person wants to help the other
• Enthisiasts reign
• When others succeed individuals and groups are inspired by that

This leads to a chain of enriching interation. This is the image of “extreme creativity”. It’s like a musician in a band jamming. There is something “catching” about it. So a group of innovators should ask themselves, “what kind of band are we?” Are you an apathetic hotel lobby orchestra? - or something more?

The hacker ethic in an educational sense is an individual who doesn’t go by the usual norms. It’s about using the network you have not shunning it. These days education is about what YOU know and YOU know alone. You sit in a room and do an exam and can graduate with a degree without talking to anyone! One gets the impressions that universities feel they would function fine if it weren’t for the students.

Innovation does not thrive within the context of rules and regulations, however companies cannot help setting these. In practice this doesn’t allow free and direct interaction between people. It is easy for companies to use different words and talk about corporate values but it’s what happens on the day to day level that really matters. Freedom for innovation is based on trust.

#flickr_badge_source_txt {padding:0; font: 11px Arial, Helvetica, Sans serif; color:#666666;}
#flickr_badge_icon {display:block !important; margin:0 !important; border: 1px solid rgb(0, 0, 0) !important;}
#flickr_icon_td {padding:0 5px 0 0 !important;}
.flickr_badge_image {text-align:center !important;}
.flickr_badge_image img {border: 1px solid black !important;}
#flickr_badge_uber_wrapper {width:150px;}
#flickr_www {display:block; text-align:center; padding:0 10px 0 10px !important; font: 11px Arial, Helvetica, Sans serif !important; color:#3993ff !important;}
#flickr_badge_uber_wrapper a:hover,
#flickr_badge_uber_wrapper a:link,
#flickr_badge_uber_wrapper a:active,
#flickr_badge_uber_wrapper a:visited {text-decoration:none !important; background:inherit !important;color:#3993ff;}
#flickr_badge_wrapper {}
#flickr_badge_source {padding:0 !important; font: 11px Arial, Helvetica, Sans serif !important; color:#666666 !important;}

www.flickr.com  More of chambo’s photos tagged with Day3