Well, here goes ...
As a seed for further conversation, here's my reference-grab doc used to form my research essay. It is the set of summaries, quotations and paraphrases from the handful of texts that I grabbed intending to ponder the enablers for scaling a software dev operation. The headings mirror my essay's basic framework. (This is obviously not my essay, this is just the literature review snapshot.)
If you've already read these books, consider the exercise either passe or just a refresh. If not, worth a glance through I think. This isn't a "wikipedia" of these texts, it's just a grab of the slices out of them that helped me think about management challenges in running a scalable software dev business in general. I recommend reading the books!
There are inline comments (eg: [D01]) put in by the fellow who is the target audience of the essay. I don't know whether the links/anchors will work ... this is just what Thunderbird did after a cut and paste from Word.
Here's my reading list ...
Here's the snapshots I used. (No apologies for repetition, spelling or grammar errors.)
Scaling Software Development Teams
--
You received this message because you are subscribed to the Google Groups "Brisbane XP" group.
To post to this group, send email to brisbane-xp@googlegroups.com.
To unsubscribe from this group, send email to brisbane-xp+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/brisbane-xp?hl=en.
As a seed for further conversation, here's my reference-grab doc used to form my research essay. It is the set of summaries, quotations and paraphrases from the handful of texts that I grabbed intending to ponder the enablers for scaling a software dev operation. The headings mirror my essay's basic framework. (This is obviously not my essay, this is just the literature review snapshot.)
If you've already read these books, consider the exercise either passe or just a refresh. If not, worth a glance through I think. This isn't a "wikipedia" of these texts, it's just a grab of the slices out of them that helped me think about management challenges in running a scalable software dev business in general. I recommend reading the books!
There are inline comments (eg: [D01]) put in by the fellow who is the target audience of the essay. I don't know whether the links/anchors will work ... this is just what Thunderbird did after a cut and paste from Word.
Here's my reading list ...
| Leffingwell, D. (2007). Scaling Software Agility: Best Practices for Large Enterprises. Boston, MA: Addison-Wesley. |
| Shine Technologies. (2003). Agile Methodologies Survey Results. http://www.shinetech.com/attachments/104_ShineTechAgileSurvey2003-01-17.pdf |
| Larman, C. & Vodde, B. (2010). Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Boston, MA: Addison-Wesley. |
| Eckstein, J. (2004). Agile Software Development in the Large: Diving Into the Deep. New York: Dorset House. [couldn't obtain the book but would like to, took some ideas and a single quote from a 'net snapshot of the intro] |
| Fisher, R, Ury, W & Patton, B. (1991). “Getting to Yes”: Negotiating Agreement Without Giving In (Second Ed). New York: Houghton Mifflin |
| Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley. |
| Demarco, T. & Lister, T. (1999). Peopleware: Productive Projects And Teams. town, STATE: Dorset House. |
| Yourdan, E. (1996). Rise and Resurrection of the American Programmer. Englewood Cliffs, NJ: Prentice-Hall. |
| Yourdan, E. (1993). Decline and Fall of the American Programmer. Englewood Cliffs, NJ: Prentice-Hall. [didn't read the entire text, but will do] |
| Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley. |
| Gartner, M (2010). Markus Gärtner's blog: Software Testing, Craftsmanship, Leadership and beyond “Listen to the old ones, or re-invent the wheel.” http://blog.shino.de/2010/02/28/listen-to-the-old-ones-or-re-invent-the-wheel/ |
Here's the snapshots I used. (No apologies for repetition, spelling or grammar errors.)
Scaling Software Development Teams
1 Issue Analysis
1.1 Aim of this Section
Dutch Proverb: “A ship on the beach is a lighthouse to the sea.”
1.2 Issue Clarification
1.2.1 Current Drivers
(Demarco & Lister, 1999, pp3-4)
“We observe that about fifteen percent of all projects studied came to naught …For bigger projects … twenty-five percent of projects that lasted twenty-five work-years or more failed to complete.
(Demarco & Lister, 1999, pp3-4)
For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure, The cause of failure most frequently cited by our survey participants was …the project's sociology.”
(Eckstein 2004, p5)
“… question the feasibility of agile software development in the large, ….The reason most (large) projects fail is a lack of communication … Communication is one of the focal points of agile processes. But can effective communication ever be established successfully for large teams?” Eckstein (2004)
(Brooks, 1975, p14)
“More software projects have gone awry for lack of calendar time than for all other causes combined. … estimating … confuse effort with progress [scaling failure] … [unwillingness to revise schedule] … schedule is poorly monitored … [adding manpower slows progress – scaling failure]”
(Brooks, 1975, pp41-50)
a single dictatorial architect, all other follow the pattern faithfully and unswervingly
(Brooks, 1975, pp142-144)
top-down design and structured procedural programming
(Beck, 2004, p105)
the “building construction” metaphor of “design everything up front” is a failure for software dev, design on the fly and modify requirements, design and outcome together
gardening metaphor, rather than "building construction"
(Beck, 2004, pp131-133)
“Taylorism” or “Scientific management” assumes: plans can be run through to completion as written, micro-optimisation leads to macro-optimisation, and people are interchangeable or should be made so. Manifestation of this are the separation of design, execution and quality, all of which unite in an XP paradigm
(Larman & Vodde, 2010, p338)
adding more resources late in a slowing project while retaining the fixed end date is a almost certain catastrophe[DO2]
(Brooks, 1975, p47)
“… refrain from hiring implementers until the specifications are complete. This is what is done when a building is constructed.”
(Brooks, 1975, p74)
principal challenge in large-scale Waterfall is to control and enable the communications between the players
(Brooks, 1975, p16)
“Men and Months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.”
(Brooks, 1975, pp17-18)
the communications burden in Waterfall amounts to mapping the number of relationships created by the division of work and allowing for training, hand-off, and task-fulfilment communications
(Demarco & Lister, 1999, pp44-50)
• Count on the best people outperforming the worst by about 10:1.
• Count on the best performer being about 2.5 times better than the median performer.
• Count on the half that are better-than-median performers outdoing the other half by more than 2:1.
The top quartile, those who did the exercise most rapidly and effectively, work in space that is substantially different from that of the bottom quartile. The-top performers' space is quieter, more private, better protected from interruption, and there is more of it.”
(Yourdan, 1996, pp30,33)
the “social contract” of loyalty has been broken by the aggressive and unapologetic downsizing of the 1990s, so employees now don’t expect or give employment loyalty. Small companies have an advantage of closeness and a sensation of “shared risk”, reaffirming the “social contract of loyalty.
(Yourdan, 1996, p175)
Waterfall doesn’t work because “bored people don’t work hard”
(Demarco & Lister, 1999, p7)
formula for disengaging thought workers is to treat them like production line workers: eliminating error, being tough on “goofing off”, people being interchangeable and dispensable, optimising the “steady-state” rather than embracing change, standardising everything, and eliminating risk and experimentation.
(Demarco & Lister, 1999, p7)
formula for disengaging thought workers is to treat them like production line workers: eliminating error, being tough on “goofing off”, people being interchangeable and dispensable, optimising the “steady-state” rather than embracing change, standardising everything, and eliminating risk and experimentation.
1.2.2 Barriers
(Larman & Vodde, 2010, (pp499-545)
if contracts are involved, engage lawyers early and often and educate them in the Agile payoffs, avoid fixed scope/price/date contracts, try variable price/progress contracts or target-cost contracts where the costs and profits are declared up front and the pain and gain are both shared.
1.3 Impact on Stakeholder/s
(Leffingwell, 2007, p7,96-99, 101-187) agile core practices that scale natively:
- “Self-organising self-managed define/build/test component teams
- Two levels of work planning and tracking are in use
- Mastering (the internal mechanics) of the work iteration
- Smaller, more frequent releases quarterly, rather than 2 year
- Concurrent testing - unit and acceptance
- Continuous Integration – source control and automated builds
- Regular reflection and adaptation – iteration and release retrospectives”
(Leffingwell, 2007, pp7-8, 190-193, 195-326) supplementary practices required at scale:
- “Intentional architecture – breaking up the system into separable components with interfaces and skill boundaries
- Lean requirements definition – a vision, a roadmap, and a just-in-time requirements elaboration
- Systems of systems and the agile release train – immovably fix releases onto a date line and flex the content rather than the delivery date
- Mechanisms for managing highly distributed teams – tooling that supports time-zoned meetings – video conferencing, wikis
- Impact on customers and operations – consideration of the work required by marketing, sales, training, finance depts, to accommodate frequency and difference of releases.
- Changing the organisation – Agile tends to identify systemic weaknesses in the rest of the organisation not being able to keep up, requires executive buy-in
- Measuring business performance – score-carding systems”
Large scale Scrum using pattern “Framework 1” – up to ten scrum teams.
Large scale Scrum using pattern “Framework 2” – more than ten scrum teams.
1.4 Summary: Need for action
Regarding their survey of Agile users’ experience of Agile software development methodologies:
- “84.7% of respondents rated their Agile knowledge as average or above.
Of these respondents:
- 49% stated that costs were reduced or significantly reduced
- 46% stated that costs were unchanged, resulting in 95% stating that there was either no effect or a cost reduction
- Only 5% stated that Agile processes had a negative effect on cost
- 93% stated that productivity was better or significantly better
- 88% stated that quality was better or significantly better
- 83% stated that business satisfaction was better or significantly better
- these respondents were vastly more in favour of Agile processes. Only 1.8% of knowledgeable respondents found productivity degradations, but this increased to 3.1% when taken across all respondents.”
2 Proposed/Recommended Solutions
2.1 Aim of this Section
2.2 Managing the Methodology
2.2.1 Understand the Methodologies
(Leffingwell, 2007, p xxiii) waterfall needs more time for requirements and architectural runway
(Leffingwell, 2007, p20) waterfalls problems are that
- requirements are often unknown even to the final users
- requirements change as time passes
- the design cannot be so well constructed that integration of the many parts will be smooth
- innovation cannot be done to a schedule
(Leffingwell, 2007, p17) waterfall needs a significant prototyping phase to succeed, and thorough expertise on the part of the involved.[DO4]
(Leffingwell, 2007, p18) waterfall integration can be a looming disaster
(Leffingwell, 2007, p18) waterfall does provide an open book, up front method for known buildable systems
(Leffingwell, 2007, p26)
Agile responds to and accommodates these by
- Presuming that requirements need to be discovered during development
- Presuming the requirements may change during the development
- Use of continuous integration rather than ultimate integration
- Presume that innovation is risky and unpredictable
(Eckstein 2004, p4)
“The big difference between these more modern applications and more traditional applications is that the modern ones must be available in the market quickly. ... Heavy-weight processes of the 1980’s and 1990’s have difficulties dealing with these new requirements. They have instead occasionally been successful in domains with stable requirements.”
(Brooks, 1975, p45)
design by definition of the user interface, via the user manual as the driving document
(Brooks, 1975, p47)
externally set architecture frees the programmer to focus their creativity on maximally achieving their task scope
(Brooks, 1975, p117)
Requirements change on the fly and are only exposed during product creation
(Larman & Vodde, 2010, p68)
Agile used in nuclear power control systems
(Leffingwell, 2007, p85)
Frequent delivery of small segments uncovers risk early.
(Leffingwell, 2007, pp7-8) Summarises the key practices in XP:
- Five to Ten programmers, collocated, with a customer liaison on site
- Frequent build iterations, each fully releasable with an increment of functionality
- User “stories” are used to specify the increment
- Programmers work in pairs on a single PC[DO5]
- The design emerges through the process of development
- Small teams of eight or less are formed with all the skills necessary to fully complete a given list of feature implementations for a product
- These teams are long-lived, not disbanded after-task
- Iterations called Sprints are fixed duration, strongly recommended as two weeks, but from one to four weeks is known
- Work within the sprint is locked from outside influence once launched.
- All work for a product is centrally listed in one product-wide backlog list. Any number of teams can pull items off this single list when defining their sprints.
- The sprint team is self-organising regarding the work, and they have a person designated as a scrum master, who is not also a line-manager for the team
- A daily meeting called the “stand-up” is used to oblige conversation and identify slow-downs
- There is a strict focus on “time-boxing” – all processes are confined to defined times and enforced.
- Usually Scrum sprints are bundled into 3 monthly releases, so as not to disrupt customer experience with too-frequent releases.
- The team is responsible to solve all issues with their Sprint backlog
- The Sprint backlog is prioritised in must-do, should-do, want-to-do and not all work needs be completed.
- Team members are continually learning
(Larman & Vodde, 2010, pp120-121)
Product owner needs to be responsible for the release’s ROI, choice of content at each iteration according to market value, and can accept or reject the outcomes.
(Larman & Vodde, 2010, p305)
build a walking skeleton, then pack on the flesh
(Larman & Vodde, 2010, p307)
risk-driven development – “build the customer features that have the most architectural impact first”[DO7]
(Brooks, 1975, p111)
Conway’s Law: “Organisations which define systems are constrained to produce systems which are copies of the communications structures of these organisations.”
2.2.2 Choose your Methodology
(Leffingwell, 2007, p77)
Management in Waterfall is typified by initially fixing dates and scope, prescribing work, contractual sign-offs, enforcement of scope-of-works, demonstration on completion and reviewing by weekly status meetings.
(Leffingwell, 2007, p77)
Management in Agile is typified by initially teams bidding for work scope and selecting their means, collaborative learning, enforcing the date rather than the scope, demonstrating continuously, and reviewing by daily stand-ups.
(Leffingwell, 2007, p5) successful businesses are first to market, solve customers’ pain points, give required quality and functionality, adapt quickly to business and technology changes
(Larman & Vodde, 2010, p68)
Agile used in nuclear power control systems
(Larman & Vodde, 2010, p335)
legacy code has two sources – fixed scope for a date and poor development skills
(Larman & Vodde, 2010, pp346-347)
to deal with legacy code, clean up the neighbourhood while working and rewrite highly defective code
(Beck, 2004, p82)
pairs are more than twice as productive while paired
(Yourdan, 1996, p170)
recommends ditching Waterfall for Agile and particularly Scrum
(Yourdan, 1996, p171)
some elements can’t be planned prior to commencing work
(Yourdan, 1996, pp175-176)
many successful software deployments have been by “guerrilla teams” working in unorthodox ways rather than big IT houses,
2.2.3 Execute your Methodology
(Larman & Vodde, 2010, p81)
treat test code as being as important as production code
(Larman & Vodde, 2010, p386)
Avoid commercially-branded “versions” of Agile
(Yourdan, 1996, p137)
Airlie Council and Microsoft in some sections write the user manual first as the specification and then set about design and implementation
(Yourdan, 1996, p160)
the key to operating a waterfall plan effectively is to be prepared to dynamically change the mix of time, scope and quality and the customer should be the one driving this choice
(Yourdan, 1996, p167)
Do quality in-line with the task, not as an item at the start or end
(Brooks, 1975, pp155-156)
rule a Waterfall by PERT chart
(Brooks, 1975, p157)
mandatory reporting of issues up managerial lines is necessary to prevent project catastrophe
2.2.4 Scale your Methodology
(Larman & Vodde, 2010, p132)
Keep one product backlog for all work.
(Leffingwell, 2007, p39)
XP is best applicable to collocated teams of ten or less, however it can be scaled
(Leffingwell, 2007, p48)
Scrum becomes difficult in large and distributed teams, where continuous integration and testing are not feasible or where the culture resists empowerment or change.
Reference the texts, learn, don’t fly blind.
(Leffingwell, 2007, p7,96-99, 101-187) agile core practices that scale natively:
- “Self-organising self-managed define/build/test component teams
- Two levels of work planning and tracking are in use
- Mastering (the internal mechanics) of the work iteration
- Smaller, more frequent releases quarterly, rather than 2 year
- Concurrent testing - unit and acceptance
- Continuous Integration – source control and automated builds
- Regular reflection and adaptation – iteration and release retrospectives”
(Leffingwell, 2007, pp7-8, 190-193, 195-326) supplementary practices required at scale:
- “Intentional architecture – breaking up the system into separable components with interfaces and skill boundaries
- Lean requirements definition – a vision, a roadmap, and a just-in-time requirements elaboration
- Systems of systems and the agile release train – immovably fix releases onto a date line and flex the content rather than the delivery date
- Mechanisms for managing highly distributed teams – tooling that supports time-zoned meetings – video conferencing, wikis
- Impact on customers and operations – consideration of the work required by marketing, sales, training, finance depts, to accommodate frequency and difference of releases.
- Changing the organisation – Agile tends to identify systemic weaknesses in the rest of the organisation not being able to keep up, requires executive buy-in
- Measuring business performance – score-carding systems”
(Larman & Vodde, 2010, p10)
Large scale Scrum using pattern “Framework 1” – up to ten scrum teams.
Large scale Scrum using pattern “Framework 2” – more than ten scrum teams.
(Larman & Vodde, 2010, p135)
Large product, break up into Product Areas and have Area Backlogs.
(Larman & Vodde, 2010, p406)
spend money on improving rather than upsizing
(Beck, 2004, pp23-34)
shrink teams as they increase internal capability, form new teams with the departed
Multisite teams
(Larman & Vodde, 2010, p416)
Multisite is handled similarly to collocated teams – the teams are given a feature list to implement per sprint and they act on it in the same way as if they were local.
(Larman & Vodde, 2010, p417)
Synchronise iterations across the company
(Larman & Vodde, 2010, pp418-421)
Collocate members of a single team
(Larman & Vodde, 2010, pp422-423)
Train people at existing sites, rather than starting a new team site
(Larman & Vodde, 2010, pp423-424)
treat sites equally
(Larman & Vodde, 2010, pp425-428,469-473)
use video
(Larman & Vodde, 2010, p433)
cross-site CsoP
(Larman & Vodde, 2010, p433)
scrum masters act as common-interest “matchmakers” for team members
(Larman & Vodde, 2010, (pp437-438,458,467-468)
train people in cross-cultural negotiations
(Larman & Vodde, 2010, (p440)
use wikis
offshore teams
(Larman & Vodde, 2010, (pp448-450)
educate your sales dept and customers on Agile
(Larman & Vodde, 2010, (pp450-451)
matchmakers instead of intermediaries between foreign teams
(Larman & Vodde, 2010, (pp454-455)
visit the client or have the client visit your site
(Larman & Vodde, 2010, (p456)
agree to all speak English, rather than have interpreters
(Larman & Vodde, 2010, (p457)
have offshore teams do initial iterations onshore
(Beck, 2004, pp111-112)
scaling: break the problem into smaller problems, distribute and solve simply, clean up any leftover complexities.
(Beck, 2004, p115)
complex problems are solved by pairing complementary domain experts
(Beck, 2004, p115)
refactoring challenges are solved by slowly-but-surely refactoring
(Beck, 2004, pp149-151)
offshoring by merely stacking low-priced coders on a problem is likely to fail due to the inherent difficulties of delivering via the Waterfall model.
(Yourdan, 1996, pp8-9)
communication problems with offshoring dev (ie: in India) – international language problems, culture, requirements are usually not clearly known up-front by users, remotely located users specifying requirements
(Yourdan, 1996, pp12)
Indian/American salary differential is rapidly reducing
(Yourdan, 1996, pp14-17)
Threat is not from India, but from radical improvement techniques like Agile.
(Yourdan, 1996, p176)
IT infrastructures need to be dynamic
(Brooks, 1975, p24)
(Brooks, 1975, p21-26)
early pre-cursor to a Scrum team pattern, “the surgical team” made up of niche specialists executing their precise tasks in harmony under an overall Waterfall regime.
(Brooks, 1975, p21-26)
Scaling this is about having the team leads in those surgical teams come together as masters to agree the interoperations required between their segments.
(Demarco & Lister, 1999, p12)
bigger problems require more time allocated to thinking, planning, learning, etc
2.3 Managing the Environment
2.3.1 Provide the Right Workspace
(Larman & Vodde, 2010, pp208-209)
(Larman & Vodde, 2010, p394)
Remove walls, introduce numerous whiteboards
(Larman & Vodde, 2010, p398)
use open-space to foster ad-hoc meetings
(Yourdan, 1996, pp46-47)
(Demarco & Lister, 1999, pp37-41)
thoughtful arrangement of floor space to enable thought-workers to have both silent thought-flow time and team interaction time is essential and far more productive financially than economising on materials and space.
(Demarco & Lister, 1999, pp40,85,87)
people work better in natural light and with distant views to glance up to occasionally
(Demarco & Lister, 1999, pp42-43)
people only use after-hours time to get productive work done in the absence of interruptions and noise
(Demarco & Lister, 1999, pp44-50)
“Three rules of thumb seem to apply whenever you measure variations in performance over a sample of individuals:
• Count on the best people outperforming the worst by about 10:1.
• Count on the best performer being about 2.5 times better than the median performer.
• Count on the half that are better-than-median performers outdoing the other half by more than 2:1.
The top quartile, those who did the exercise most rapidly and effectively, work in space that is substantially different from that of the bottom quartile. The-top performers' space is quieter, more private, better protected from interruption, and there is more of it.”
(Demarco & Lister, 1999, p52)
Demarco claims that there is no evidence that open-plan workspaces or corrals of uniformally set cubicles improve work productivity, and substantial evidence that such settings decrease productivity by great magnitudes
(Demarco & Lister, 1999, p53)
The McCue study done at IBM recommends 100 square feet of floor space and 30 square feet of table space per person, and sound proofing by offices or noise barriers
(Demarco & Lister, 1999, p62)
The McCue study found that developers need to spend 30% of their time in private work, 50% working with one other person and 20% working with more than two others.[DO11]
(Demarco & Lister, 1999, p63)
“During single-minded work time, people are ideally in a state that psychologists call flow”.
This state requires 15 minutes to lock in and is broken by any interruption.
(Demarco & Lister, 1999, p69)
turn off telephones, PAs, email reading, IM, skyping
(Demarco & Lister, 1999, p77)
objective is “an ignorable workspace” not a glitzy one
(Demarco & Lister, 1999, pp78-79)
listening to music is acceptable to let people flow with repetitive work, but not creative work, as music pre-occupies the right brain)
(Demarco & Lister, 1999, p86)
similar noises to the ones the person makes in their work do not interrupt
2.3.2 Provide the Right Community
Build a community. Vulnerability. Coooperation. Non-competition.
(Beck, 2004, p63)
jelled teams are apex performers, retain them intact
(Leffingwell, 2007, pp110-114)
High-performing agile teams have these characteristics:
- “They have the right people on the team
- They are led rather than managed
- They understand their mission
- They communicate and collaborate continuously
- They are accountable for their results”
(Leffingwell, 2007, pp35-37) (Beck, 2004, pp17-22)
(Beck, 2004, pp23-34)
XP’s Core Principles: humanity of the involved, economic rationalism, mutual benefit long-term, looking for repeatability of technique, improvement rather than perfection, appreciation of diversity within the team, reflection on performance, continuous flow of value to the client, positivise problems into opportunities, employ systemic redundancy, as a safeguard, risk failure as a means to short-cut to success, velocity is not increased by decreasing quality, take “baby steps”, and responsibility is accepted rather than assigned.
(Leffingwell, 2007, pp35-37) (Beck, 2004, pp35-53)
XP’s Key Practices: the entire team sits together, a fully-skilled team, a task-informative workspace, energised work (intense 40 hour weeks), pair programming, task definition by “stories”, a weekly work iteration, a quarterly delivery to customers, slack is built in, the entire system should be able to be auto-built in ten minutes, all code changes are integrated into the system immediately, a failing test is written before the functioning code is written.
(Larman & Vodde, 2010, p31)
Avoid having a separate “test department”, integrate the task into the teams.
(Larman & Vodde, 2010, p34)
(Larman & Vodde, 2010, p35)
Communities of Practice.
(Larman & Vodde, 2010, p51)
Have the product owner write the tests
(Larman & Vodde, 2010, pp104,146-147)
product owner meets with team (inward) and customers (outward) equally and maps their paradigms together
(Larman & Vodde, 2010, pp106-112)
avoid the “game” of contract negotiation between product management and development around scope and date,
(Fisher et al, 1991)
where people take “hard” and “soft” negotiation styles and negotiate on “position”, instead use “principled negotiation on mutual gains”.
(Larman & Vodde, 2010, p123)
Short term POs undermine this, can install a “fake” PO to kick-start the process
(Larman & Vodde, 2010, p148)
avoid having gurus who aren’t attached to any teams or customers
(Larman & Vodde, 2010, p128)
Overall PO can be the chief engineer and hence have a good overall balanced view of business and engineering needs
(Larman & Vodde, 2010, pp166-168)
allocate a pure research or pure infrastructure set of tasks to each team for a sprint occasionally[DO14]
(Larman & Vodde, 2010, pp171-179)
define and seek to expand the teams’ DoD, as to how many aspects of the business’ interest (coding, testing, documentation, performance testing, marketing material, training, pricing, etc) need to be covered off to define the team’s Sprint as complete.
(Larman & Vodde, 2010, pp191-193)
teams are selected and evolved to be typically able to respond concisely and thoroughly to specific types of feature additions, and so teams are allocated tasks that more suit them and they can deliver them efficiently.
(Larman & Vodde, 2010, p308)
architects code spikes
(Larman & Vodde, 2010, pp308-310)
Tiger teams used to hit the killer issues, write an implementation guideline when done for others to follow
(Larman & Vodde, 2010, p314)
(Larman & Vodde, 2010, p386)
(Larman & Vodde, 2010, p393)
don’t use an in-line manager or PO as Scrum Master
(Larman & Vodde, 2010, p409)
(Larman & Vodde, 2010, (p466)
long-lived teams
(Larman & Vodde, 2010, (pp467-468)
teams can say “no”
(Larman & Vodde, 2010, (p474)
experts coach and review rather than just design and hand-off
(Larman & Vodde, 2010, (p478)
avoid a “factory” mentality
(Beck, 2004, pp135-137)
Toyota Production System advocates integrating quality control at the point of creation of any item of work
(Beck, 2004, pp157-158)
Community is essential to foster cross-fertilisation and “enable questioning and doubt”
(Yourdan, 1996, pp43-44)
encourage special interest groups and staff involvement, provide mentoring
(Demarco & Lister, 1999, p8)
imposing a penalty for errors decreases learning and imagination and demotivates thought-workers
(Demarco & Lister, 1999, p9)
thought-workers are switched off by “the stick”
(Demarco & Lister, 1999, p11)
(Demarco & Lister, 1999, pp119-120)
“Hawthorne Effect” - any [non-threatening] change induces an increase in productivity through motivation by novelty[DO19]
(Demarco & Lister, 1999, pp122-128)
teams that jell together in shared success are orders of magnitude more productive and create their own momentum. The goals set for them should be their internal work-outcome goals, not the company-wide goals which are often distasteful and crass to them anyway. The manager’s task is to set these internal goals in line with the company’s overall goals (alignment), but without overdue reference to them
(Demarco & Lister, 1999, pp133-135)
things that will poison a team’s chances to jell are:
· lack of trust in the team
· over-prescriptive systems
· managerial defences
· low E-factors
· sacrificing product quality
· managing by dead-lines
· stifling team or personal individuality
· physically separating the team
(Demarco & Lister, 1999, p151)
the factors that help teams to jell:
- “Make a cult of quality.
- Provide lots of satisfying closure.
- Build a sense of eliteness.[DO20]
- Allow and encourage heterogeneity.
- Preserve and protect successful teams.
- Provide strategic but not tactical direction.”
(Demarco & Lister, 1999, p155)
as a manger, don’t attempt to break into your jelled team as a peer, just be their obstacle-clearer[DO21]
(Demarco & Lister, 1999, p160)
when a jelled team approaches a steady state, boredom is a risk – reintroduce disorder by: spiking technologies, training, trips, conferences, etc
(Demarco & Lister, 1999, p146,148)
show trust by reducing direct oversight, send the team on a conference or outing
(Demarco & Lister, 1999, p179-180)
overtime ends up getting unbalanced and incites jealousy
(Demarco & Lister, 1999, p181-184)
competition will inhibit team “jell”, as will performance reviews and rewards for individuals
2.3.3 Scaling the Environment
Single site, multisite and offshore
(Larman & Vodde, 2010, p194,198,200)
the team is responsible for their own coordination within the company and other teams, competition within and between teams is discouraged, representative members attend a “Scrum of Scrums” to coordinate and navigate feature addition collisions
(Larman & Vodde, 2010, p370)
most implementation of CI systems fail through organisational sociology problems
(Larman & Vodde, 2010, pp234-235)
don’t have overly specialist groups that deflect non-specialist responsibilities
(Demarco & Lister, 1999, p118)
achieve convergence of method across teams by use of training, common tools and peer reviews
(Demarco & Lister, 1999, p113-114)
mandating work systems methodologies removes the self-healing nature that is brought by human inclusion in the work-flow – people are familiar with the underlying goals and will correct the systemic errors on-the-fly
(Demarco & Lister, 1999, p116-117)
overdoing methodologies ends in abrogation of responsibility at the implementation level
2.4 Managing the Person
(Demarco & Lister, 1999, p108)
[indifference] towards turnover and staff value induces turnover and disengagement
[indifference] towards turnover and staff value induces turnover and disengagement
(Demarco & Lister, 1999, p111-112)
companies with low turnover show high regard for staff value, but also a “preoccupation with being the best”, an reinvestment in staff, and an expectation that people will stay
2.4.1 Select the Person
Knowing what you are building – your company’s strategy.
Fit the people to the strategy.
Select the person – audition, test.
(Larman & Vodde, 2010, (p479)
interview by programming
(Beck, 2004, p82)
hire by having them work in the team for a day pair programming, tests technical and social skills
(Yourdan, 1996, pp37-38)
audition by giving a problem on the spot at the interview and asking them to solve it under supervision (advise about the process beforehand)[DO22]
(Demarco & Lister, 1999, p100)
audition prospective employees
(Demarco & Lister, 1999, p103-104)
aptitude tests for prospective employees only identifies their technical skill, you need to identify their sociological fit, invite his prospective peers to the audition, insist on a technical talk of relevance[DO23]
2.4.2 Develop the Person
Training, retention, planning Vulnerability.
(Yourdan, 1996, p50)
“have highly skilled people who are well managed and highly motivated”
(Larman & Vodde, 2010, pp56, 75)
Use A-TDD coaches, internal and external as required
(Larman & Vodde, 2010, p148)
POs should attend training on Agile methodology selected
(Larman & Vodde, 2010, p268)
learn and use a spectrum of analysis skills
(Larman & Vodde, 2010, p312)
architects teach during code reviews
(Larman & Vodde, 2010, p339)
schools, organisational support, self-study
(Larman & Vodde, 2010, p340)
“use your editor”[properly] is usually the most immediate gain available
(Larman & Vodde, 2010, pp341-342)
don’t trivialise programming – outsourcing, short-careers, salary depressions
(Larman & Vodde, 2010, p385)
learning by “infection”, maintain close contact with an Agile coach
(Larman & Vodde, 2010, p399)
external and internal agile coaches, structured training, stick with the methods tested and published recommendations
(Larman & Vodde, 2010, (pp468-469)
intensive coaching, buddying if high-attrition
(Beck, 2004, pp143-144)
use a coach
(Yourdan, 1993, p106)
CASE Research study reveals that “the typical software engineer needs between 1 to 2 years to become familiar and comfortable with a methodology”
(Yourdan, 1996, p33)
Taylorist arranged work is boring and disengaging
(Yourdan, 1996, p36)
let the software professionals decide their own training path, give them their own budget to spend[DO24]
(Demarco & Lister, 1999, pp20-21)
customers care less about internal quality than the author does
(Demarco & Lister, 1999, p22)
however permitting a builder to indulge in quality engages them, resulting in lower turnover and higher overall productivity
(Demarco & Lister, 1999, p24 -25
“Writing in 1954, the British author C. Northcote Parkinson introduced the notion that work expands to fill the time allocated for it, now known as Parkinson's Law. …
Parkinson's Law almost certainly doesn't apply to your people. Their lives are just too short for any loafing on the job. Since they enjoy their work, they are disinclined to let it drag on forever”
(Demarco & Lister, 1999, p103)
provide aptitude tests for internal staff as (safe) personal performance feedback
(Demarco & Lister, 1999, p177-178)
2.4.3 The Person in a Scaling Context
Fear, change
(Yourdan, 1996, p160)
processes are not as crucial to the outcome as the talents and engagement of the people involved
(Yourdan, 1996, p167)
lack of care for the people will flow on to the results
(Demarco & Lister, 1999, pp13-19)
thought-workers put under pressure are going to work faster, not better, and then they’re going to be leaving with resentment
(Demarco & Lister, 1999, p20)
unattainable deadlines make people compromise quality, which strips their pride in their work and disengages them
(Demarco & Lister, 1999, pp26-29)
study done at the University of New South Wales showed that productivity is most enabled, from lowest to highest outcome by the work estimates being done by: the supervisor, the supervisor and the programmer, the programmer alone, a systems analyst, and best of all when no estimate is made at all
(Demarco & Lister, 1999, pp192-201)
people dislike and are resistant to change and respond emotionally to it, people need to feel safe, and that the new state will be a better one for them
(Demarco & Lister, 1999, p25)
underperformance is usually due to “lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. In none of these cases is schedule pressure liable to help very much”
(Demarco & Lister, 1999, p26)
(Demarco & Lister, 1999, pp211-214)
protect and develop the middle mangers to be creative and feel safe, as they are the ideal locum of organisational change
(Demarco & Lister, 1999, pp215-219)
use meetings to resolve information gaps, not to establish power statuses
(Demarco & Lister, 1999, pp222-226)
2.4.4 Develop the Leader
You. Learning. Flexibility. Trust. Vulnerability.
(Beck, 2004, p57)
starting XP, change yourself first
(Yourdan, 1996, pp38-39)
determine why employees leave, turnover costs
(Brooks, 1975, p108)
managerial paperwork should be restrained to only a few deliberate documents useful in activating the business, and to avoid difficulties arising from misunderstandings in “common knowledge”
(Demarco & Lister, 1999, p1)
managers unwittingly tend to treat people as “modular components” because they come from technical backgrounds working with modular components
(Demarco & Lister, 1999, p4)
most mangers know they have people problems, but don’t manage as if so
(Demarco & Lister, 1999, p5)
managers prefer to manage non-people problems as it’s easier and safer for them
3 Evaluation Aspects
3.1 Aim of this Section
3.2 Implementation Phases
Commit to being a “learning leader”.
Solicit commitment from any other influential parties.
(Larman & Vodde, 2010, pp157,162)
to introduce Agile, emphasise “continuous product improvement” and “partiality” rather than “project-based work” and “perfection”
(Larman & Vodde, 2010, pp273-276)
avoid application life-cycle management tools early, do it manually so that the process is understood – cards on walls, spreadsheets, wikis, RSS feeds; don’t use centralised tools – scattered Word documents on file systems, or even document tools like Lotus Notes or MS SharePoint
(Larman & Vodde, 2010, pp299-300)
have architects attached to a team as members, or lead regular technical workshops with teams
(Larman & Vodde, 2010, p304)
(Larman & Vodde, 2010, p394)
(Larman & Vodde, 2010, p397)
introduce topic in big sessions to 200+ people at a time
(Larman & Vodde, 2010, p408)
disarm harmful entrenched practices or policies
(Beck, 2004, p95)
(Beck, 2004, p108)
clean up ratty code as you go
(Beck, 2004, pp113-114)
introducing in an existing organisation, team’s external liaison needs to explain the activity well.
(Beck, 2004, p142)
conditions under which XP usually starts up successfully: strong value alignment by all, or a recovery from shared pain in the organisation
(Yourdan, 1996, p173)
most businesses have moved to becoming totally dependant on their IT systems, but still live in an expectation that IT is a trivial concern to them, and hence IT workers are of little consequence
(Larman & Vodde, 2010, p335)
emphasise benefit of transparency via partial progressive delivery, rather than fixed scope/date
3.3 Costs and Benefits
Costs include training time, decrease in unpaid overtime,
Benefits include increased productivity, reliable delivery, increased repeat business, improved workplace demeanour,
(Beck, 2004, p113)
capitalising versus expensing SD work
(Demarco & Lister, 1999, p202)
attempt to have software development and training accounted as capital, not expense, so as to have the investment in people recognised as such
(Beck, 2004, pp114-115)
durability of results over time improved by high degree of refactoring and test coverage
(Yourdan, 1996, pp32-33)
corporate profit is unrelated to their IT spend, Yourdan proposes that it is a function of their internal chemistry of “people, skill, motivation and technology”
(Yourdan, 1996, pp38-39)
rather than increase wage, give time off or luxury projects as a bonus
(Yourdan, 1996, pp157-181)
provide “good-enough” software
(Demarco & Lister, 1999, pp44-50)
“Three rules of thumb seem to apply whenever you measure variations in performance over a sample of individuals:
• Count on the best people outperforming the worst by about 10:1.
• Count on the best performer being about 2.5 times better than the median performer.
• Count on the half that are better-than-median performers outdoing the other half by more than 2:1.
The top quartile, those who did the exercise most rapidly and effectively, work in space that is substantially different from that of the bottom quartile. The-top performers' space is quieter, more private, better protected from interruption, and there is more of it.”
Managing the working environment is one of the most immediately controllable factors able to directly influence the productivity of your thought-workers. The cost of the worker is estimated at 20 times the workspace cost, so the worker’s productivity is paramount over the workspace cost. (Demarco & Lister, 1999, p50-51)
3.4 Evaluation Criteria
Staff retention
Velocity
360 reviews
(Beck, 2004, pp23-34)
measuring XP team health by: defects found after development and the ROI lag (“investment to return”)
(Beck, 2004, p82)
either evaluate and reward by individual or team
(Beck, 2004, p139)
results from XP can take years to arrive
(Beck, 2004, p140)
XP teams misunderstood and sometimes laid off, because the standard corporate measures do not apply – working late and dramatically deploying large but broken code sets – work is undramatic, successful, gradual and in-hours
(Demarco & Lister, 1999, pp60-61)
provide a performance measurement mechanism for people that permits them to self-evaluate against the team, but is still anonymous, to retain self-esteem and sense of job-security.
(Demarco & Lister, 1999, p65)
track “flow” hours worked as a measure of internal productivity from effective environment management – “E-factor” percentage of time spent in “flow” over a week. Encourage people to find ways to get their “E-factor” up to 0.3 (30%) or above ..eg:
(Larman & Vodde, 2010, pp181-184)
teams estimate their “story points” and after a few iterations, you can measure their “velocity”, and move towards forecasting and tracking velocity
3.5 Summary
Manthey:
Waterfall requires a fully competent architect at the top, and obedient workers below, with mandatory upwards reporting and fragmented partial task setting downwards. The model is military in nature. Competition is rewarded with elevation. Momentum is embedded.
Agile is equally regimented, but competence and responsibility are distributed down into the worker layer. Cooperation is rewarded with innate business success. Agility is embedded.
(Brooks, 1975, pp120-123)
large systems built with Waterfall inevitably grind towards a slow death of unimprovability due to the massive maintenance cost in tracking regression bugs
4 Conclusions
(Larman & Vodde, 2010, p100)
‘lean thinking and agile principles are customer-focused for business success; they are not “development processes”’
(Demarco & Lister, 1999, p96)
it is extremely unlikely that you will change a person’s basic nature, but you can enable their performance through training and scene-setting
(Demarco & Lister, 1999, p171)
even one single major change to an organisation’s sociology is a huge achievement
5 Recommendations
(Larman & Vodde, 2010, p2)
Cargo cult
(Larman & Vodde, 2010, p4)
“There are no best practices – only adequate practices in context.”
(Larman & Vodde, 2010, p5)
The lure that there might be “fractal” practices is there, but is a false hope – scaling or transposing requires alterations to otherwise working practices.
(Larman & Vodde, 2010, pp374-381)
Adoption suggestions: emphasise people and interactions over processes and systems, ensure job security and personal respect, emphasise the principles and values of agile over the practices but don’t try to do agile without them, start slow, speed up and emphasise learning a lifestyle of agile rather than a project to “implement” it.
(Larman & Vodde, 2010, p391)
Gradual adoption by slow transition from component to feature teams, by introducing feature teams in parallel with component teams, some incompatibility. Recommended technique is “big bang” and accept the learning curve, although few companies are game to try this.
(Beck, 2004, p144)
killers of XP: culture of secrecy, isolation, complexity, timidity and disrespect
(Demarco & Lister, 1999, p210)
be a learning-oriented and adaptive organisation, and retain the investment in staff by working to reduce turnover
6 References
| Ref | Details |
| (Leffingwell, 2007) | Leffingwell, D. (2007). Scaling Software Agility: Best Practices for Large Enterprises. Boston, MA: Addison-Wesley. |
| (Shine, 2003) | Shine Technologies. (2003). Agile Methodologies Survey Results. http://www.shinetech.com/attachments/104_ShineTechAgileSurvey2003-01-17.pdf |
| (Larman & Vodde, 2010) | Larman, C. & Vodde, B. (2010). Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Boston, MA: Addison-Wesley. |
| (Eckstein, 2004) | Eckstein, J. (2004). Agile Software Development in the Large: Diving Into the Deep. New York: Dorset House. |
| (Fisher et al, 1991) | Fisher, R, Ury, W & Patton, B. (1991). “Getting to Yes”: Negotiating Agreement Without Giving In (Second Ed). New York: Houghton Mifflin |
| (Beck, 2004) | Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley. |
| (Demarco & Lister, 1999) | Demarco, T. & Lister, T. (1999). Peopleware: Productive Projects And Teams. town, STATE: Dorset House. |
| (Yourdan, 1996) | Yourdan, E. (1996). Rise and Resurrection of the American Programmer. Englewood Cliffs, NJ: Prentice-Hall. |
| (Yourdan, 1993) | Yourdan, E. (1993). Decline and Fall of the American Programmer. Englewood Cliffs, NJ: Prentice-Hall. |
| (Brooks, 1975) | Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley. |
| (Gartner, 2010) | Gartner, M (2010). Markus Gärtner's blog: Software Testing, Craftsmanship, Leadership and beyond “Listen to the old ones, or re-invent the wheel.” http://blog.shino.de/2010/02/28/listen-to-the-old-ones-or-re-invent-the-wheel/ |
7 Off-topic citations
(Brooks, 1975, pp93-94)
programmers can produce a consistent number of debugged lines of code per year in virtually any language, so if the language in use is terse, you will get more business outcomes for your investment
(Brooks, 1975, pp115-123)
plan to throw one away
(Brooks, 1975, p116)
chemical plant will build a lab-prototype, then a “pilot plant” before committing to a full scale installation
(Brooks, 1975, p116)
[paraphrased] “You will build a prototype. The only choice is whether you throw it away, or deliver the throwaway to the customer.”
(Brooks, 1975, p118)
reluctance to document systems is principally a reluctance to having to defend partial solutions born on-the-fly and under pressure.
(Larman & Vodde, 2010, (p474)
avoid producing/employing the “four-year programmer”
(Brooks, 1975, pp53-58)
beware of the “second-system effect” – architects/programmers who are onto their second build and want to overdo it perfectly with obsolete technologies that they learnt on their first build.
(Demarco & Lister, 1999, p106-108)
average employee stays two years, has a short-term view of the work being done, so isn’t committed to the quality of outcomes or to leaving no legacy code, and may be working towards a management job as per the “fourth-year” programmer.
(Demarco & Lister, 1999, p207)
productive ramp-up time for a technology worker can be up to two years - turnover is extremely costly in these cases
[DO1]Sounds interesting to me. I can definitely identify with just that simple phrase although I suspect the actual reality is a hybrid of the two, i.e. attempting to design and build a living organism, which requires constant re-evaluation due to unforseen properties of the organism or the unforseen interactions between the organism and it’s changing environment. Plus the fact that organism has the ability to change the environment around it, and thus destablise any ecosystem that existed around it prior to it’s conception / implementation. (Woah heavy..)
[DO2]I think I would definitely like this Larman and Vodde book. Anyone who thinks this is a good idea is a moron – thankfully we didn’t have this problem at [deleted]…
[DO3]Nice to know my experiences haven’t been unique then…
[DO4]Which is proof enough that it’s broken – well kind of. “Ah yes, to build this particular system we recommend the waterfall approach to software development, but we do also recommend an agile prototyping phase prior to finalizing the project schedule and scope.”
I guess I should caveat what I say above, that in some particularly large projects that might actually be a really good model, as agile projects IMHO have a higher reliance on the intellectual investment from particular individuals and the longer the project, the higher the risk that you are going to lose people along the way. A risk management and good resource allocation strategy might be to put your best talent on prototyping and scope definition for a project, and then allocate the lower tiers of developers to implementation of the actual project implementation… maybe…
[DO5]Honestly, I’ve always thought this is a silly idea. But then again it’s not something I’ve actually tried. The idea of two smart productive people being limited to a single set of tools seems counter productive to me. I guess though that they guys taking care of the roadworks have effectively been doing pair digging (one shovel between two) for sometime and our roads manage to get built ;)
[DO6]Personal opinion, but not grounded in experience from [deleted], is that this is one of the more common sense agile development practices. I’m using it in my development at [deleted], but given it’s only me at this stage, I don’t really think my experience counts for much there. For what it’s worth, it’s working really well in providing a framework for customer interaction and managing expectations.
[DO7]Agreed – this should be incorporated into any project. I love front-loading the tricky stuff – definitely did that with the guys at [deleted]. If I’m going to get a surprise, then I prefer it closer to the start of the project…
[DO8]Good advice I think. Certainly from my own experience, it was always easier to hit a customer with a single set of dramatic schedule changes, rather than oh, yeah that’s going to be a couple more weeks. Being on the client end with some projects where the project is just a couple more weeks from completion really means that it’s just completely busted..
[DO9]Yep – critical.
[DO10]Which shows that it’s obviously a balancing act – and if you read some of Joel Spolsky’s thoughts I think he favours offices over open plan to ensure people have appropriate working conditions. Personally, I think I’d like to go for 70% open plan with no fixed desks (i.e. you have a laptop and sit to work wherever each day), and then have some breakout rooms for when you are doing the intense stuff where distractions just stuff you around big time…
[DO11]Cool, just read this after my previous comment. I think my floorspace allocation is about right then J
[DO12]My take on all this – love the core values and principles of XP and the Agile manifesto in general, but the actual practices and implementation of most agile programs seems pretty broken (as the discussion on the groups list you pointed me too looks).
Many, many parallels between successful software teams and small churches but the growing pains when someone attempts to document a successful formula. It’s noble but it really just never seems to work quite right..
[DO13]Great idea, one that I think I will definitely try when I get to a size that warrants that.
[DO15]Tried to get this going at [deleted], and unfortunately it never really got that much momentum. Which I think points back to sociological issues as you said earlier..
[DO16]Yep – completely agree. If you haven’t already watched any of Dan Pink’s stuff from around the place, make sure you do. Definitely a good example in a TED session regarding the candle problem.
[DO17]As above.
[DO18]Make sure they have the goods as a coder though – I hired someone specifically for this purpose, but in the end they couldn’t code well enough to jell invigorate community in the development team.
[DO19]Must read up on this…
[DO20]This is potentially dangerous if you are building a company that will have incremental growth over time. It will be difficult for even talented newcomers to break in…
[DO21]Yep – completely agree. Probably one of the best pieces of advice for anyone who is transitioning off the tools into management.
[DO22]After reading a couple of posts on the topic of programmers who can’t program, I talked to the guy who took over from me in the dev team ([deleted]) and he has introduced a simple test called FizzBuzz. I believe it has prevented a few bad hiring decisions already J
[DO23]Cool idea.
[DO24]I like this approach – I think it will help motivate self-study also…
[DO25]LOL – absolutely. Unless they are suitably tongue in cheek – see some worth1000 competitions J
[DO26]Completely agree – and have witnessed this on multiple occasions. I’ve also seen that managers who attempt to take on this responsibility disengage the potential future leaders of the team by removing the opportunity for them to take on this responsibility…
[DO27]If only more people really believed in that, and we trained people to do it and demonstrated it was the best thing for their career many workplaces would be a better place.
[DO28]Nice – great way to encourage your people to learn new things and increase productivity through the Hawthorne effect which I just learnt about.
[DO29]Yep – I’m using Pivotal Tracker which is a great tool for doing this. Definitely need to catch up for a chat sometime…
[DO30]Interesting, not sure I agree with this one, but I definitely can agree that pen and paper is the appropriate domain for think-tanking thigs… Maybe another one for discussion.
--
You received this message because you are subscribed to the Google Groups "Brisbane XP" group.
To post to this group, send email to brisbane-xp@googlegroups.com.
To unsubscribe from this group, send email to brisbane-xp+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/brisbane-xp?hl=en.
