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.

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

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