Magic Milestones

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

Champers at the city hall

This is more like it.. The conference was opened by the Major of Oulu who I suspect had not the faintest idea what Xtreme Programming was and probably thought it involved a computer and someone being naked. There was far too much booze to do justice to and so I only managed some champers. Anyway, after a few beers the agile conversations gave way to conversations about mosquitos again (there is a reason for this!) and the price of fish. When I asked for a small beer I got a large beer with some beer missing. I like the way the Fins approach things. Don’t worry Alex, the postings will get more intellectual once we get to the conference bit. I’ll have to get someone else to write them though..

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

Mosquitos, midnight sun and mad italians

No I’m not going to sleep. It feels like 5pm in the afternoon and evidently so do all the fins in the club downstairs judging by the noise. Have had a very bizarre day. The flights are so infrequent here that when the flight from Heathrow was delayed the connection to Oulu actually waited for us! I then hooked up with a load of mad, italian, seriel XP goers who very kindly took me to the hotel in their hire car. So what with the trees, mosquitos, 0 hrs of darkness and a conference dominated predominantly by male developers - this could be em.. interesting. These entries will get more bizarre throughout the week if tonight is anything to go by. I think after 5 days of no sleep one starts hallucinating…

#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 Day1