Join In (Registration)

To register for XpDay, add a comment to this page.

We’d like you to do two things. First to tell us something about yourselves, then to consider a voluntary contribution to the running costs. We’re doing TSTTCPW to implement our MMF, which means using an honour system.

Who are you?

This is a practitioner’s event. We want every attendee to have real-world experience of Agile development, so we’re asking everyone to write a comment on this page that describe some aspect of their recent experience. It doesn’t have to be a Big Idea, just something useful. This gives everyone a view of who’s coming and will help seed the discussions. We’re especially interested in hearing about failures, although successes are useful too.

In your comment, please follow this structure more or less:

  1. Background context
  2. What we wanted to change
  3. What we tried
  4. Something that succeeded
  5. Something that failed
  6. Something that surprised us

This is our admissions priority list. We’ll close it after about the first 100 comments, so don’t miss your window

Help us out

XpDay is underwritten by the eXtreme Tuesday Club, but it still costs money to run. Following the lead from the Citcon Conference, we’re asking for contributions. Our suggested levels are:

Participant cost + donation towards evening event £140.00
Participant cost (venue, food) £120.00
Food costs only £70.00

The most convenient payment for us is a bank transfer to:

Account Extreme Tuesday Club
Bank Unity Trust Bank
Sort code 08-60-01
Account number 20187725

Add something to the reference that will help us figure out where the money came from.

If you need any help, for example because you need an invoice for your company, you have a non-UK bank account, or you’re an impecunious student, get in touch at xpday2012@xpday.org


98 Comments on “Join In (Registration)”

  1. Karishma says:

    Background context
    Enhancing in house product where the system is almost 6-7 years old. Developing the software using recent technologies, and architectures for new change requests whilst legacy code still exists.
    What we wanted to change
    Adapt to “agile methodologies” and changing mind sets from traditional developments by practising agile, and reduce dependability on the legacy code while developing new business requirements around legacy code.
    What we tried
    Tried having unit test coverage for new code (extract the code change around legacy to cover newly added code)
    Tried few agile methodologies such as TDD whenever possible and pair programming
    Increase early and more frequent interaction with product owner and and have scenario based acceptance criteria
    Something that succeeded
    Unit testing helped to test various scenarios while developing even though end to end functionality was not yet developed
    Defect leaks reduced considerably
    Tried covering legacy code as well with unit tests
    Something that failed
    Difficult to cover all scenarios in acceptance criteria at micro level else it led to FRS kind of document.
    Many times legacy code prevented unit testing the code change

  2. Seb Rose says:

    Background context
    I’ve been developing software on and off since 1980 part time and full time, permanent and contract, finance and engineering. There’s always been the nagging doubt that any of it was worthwhile.

    What I wanted to change
    I want to wake up in the morning eager to start and get home content that I’ve contributed to something worthwhile. I want to be proud (or at least not ashamed) when I tell my kids what I did during the day. But I still need to earn a living.

    What I tried
    I’ve tried many forms of employment (see context). After graduating I spent 5 years dipping in and out of programming while working as a tree-planter, crofter, salmon farmer, grape picker and dishwasher. I ran an organic box scheme on the side from 1994-2006, and concentrated exclusively on this for the last 3 years. I’ve taken time out to build houses (from straw, wood and block). My wife and I still operate a smallholding. Since 2008 I have been working with software development teams that are trying to improve, often helping them adopt agile practices (which seems to increase their pride in what they produce).

    Something that succeeded
    A couple of years ago I ran an after-school club within the First Lego League in the Edinburgh region. It was exhausting, especially after a day at work, but was very inspiring, especially since my kids were keen to be involved.

    Something that failed
    Growing the organic delivery service into a business that employed 5 people and turned over £250k p.a. ticked many of my boxes, but ultimately failed to be financially viable. And I did spend most of my time on administration – suppliers, customers, employees, accounts etc – which was a drag after a year or so.

    Something that surprised me
    Helping people realise their potential, whether children or adults, professionals or enthusiasts, is much more fun than it sounds. I used to think that learning the next cool thing would make me happy, but now I find that training/coaching/teaching last year’s (or last decade’s) methods is far more rewarding.

  3. I will be talking about the Strangler Pipeline at XPDay 2012

  4. Sean Hosking says:

    We are a software development team who practice in an ‘agile’ way.

    I am constantly looking for ways to improve practices within the team, whilst still delivering quality software as efficiently as possible.

    “Stand Up’s” have improved collaboration and communication though has been difficult to get people to speak at the appropriate level (ie. without going on too much or giving not enough information).

    We used monthly cycles (sprints) to plan our work. For some people this has worked well, but others, who are working on bigger, longer tasks, we have found it difficult to break their tasks down into smaller chunks.

    I attended XPDay 2010 and was extremely pleased and suprised to meet others with similar experiences. It was great to stand back and talk about the issues.

  5. Jon Hill says:

    Background context
    I’ve applied agile approaches to areas such as architecture, infrastructure and technology management.

    What we wanted to change
    Being able to visualise the work in progress; changing focus on delivering valuable “pieces” in the context of a bigger picture rather than focusing on large and long programs while ignoring the day to day reality; being able to learn something and do something different in response. All the stuff that we hope to get from agile within development, just applied to other areas – imagine that your IT management team used a Kanban board or held retrospectives.

    What we tried
    Stand ups, Kanbans, retrospectives with architecture groups, infrastructure teams and project managers

    Something that succeeded
    Agile 101 – Working with a new infrastructure solutions team in a FS company. Starting with a Kanban board, looking at the internal flow of work, and then the upstream and downstream interactions. The output of the team improved markedly both in terms of quality and quantity, and the perception of the team did even better

    Something that failed
    A Kanban board with an enterprise architecture team. I could have chiselled it in stone, as nothing moved or change until the day it was taken away…

    Something that surprised us
    Treating people with openness, compassion and dignity while being burdened with an expectation that visible improvements will emerge is exceptionally hard

  6. Hi there,

    Background context
    I was the Change Agent in my prev company. My responsibility was to transform the organization from some kind of Waterfall to Agile.

    What we wanted to change
    The mindset, the processes. I wanted to speed up the development and to train the business side to write deliverable user stories instead of non-deliberate “specs”.

    What we tried
    Introducing Kanban with some Scrum-based ceremonies. (Daily standups, retrospectives, Kanban boards, Estimations, User stories+Acceptance criterias, UATs, …)

    Something that succeeded
    The whole process. The visualized workflow.

    Something that failed
    There was no management-support. The business side still can’t write deliberated user stories.

    Something that surprised us
    The speeding up -> we could double the delivered ticket number (even if the business side didn’t help us…).

  7. Dan Woodhead says:

    Background context
    I started six years ago as a developer in the IT department of a theatre publishing company. At that point I was the third member of department after the manager/senior dev and the IT dogsbody and what we did on the website was pretty much up to us.
    Now I am the Scrum master, we have an Ops team of five, a CTO, a QA plus five devs and rising and if the website has a hiccup or we release a bug, part of the industry can’t do it’s job and everyone starts shouting.

    What we wanted to change
    The plan has been and is to move from legacy ASP code to fully Unit and integration tested code released in a controlled manner.

    What we tried
    Outsourcing to an external company (lots of planning meetings and waterfall documents)
    My boss writing it on his own whilst I kept the legacy code going
    Pseudo-agile (stand-ups plus impossible, arbitrary deadlines) with contractors
    Just get it done
    Agile / Scrum

    Something that succeeded
    Stand-ups to stop people disappearing down a rabbit hole
    Planning with high-level stories and story points (see below for how we first tried planning)
    Using an online tracking tool (Pivotal) to capture the information rather than just cards
    Hiring a QA
    Having a board with Backlog, Doing, Review, UAT then Done (so code has to be developer reviewed and then accepted by product owner and QA before it is Done)

    Something that failed
    Our original approach to Sprint planning: start with a vague idea, break it into stories, then further break down to the level of “Implement method foo on class bar” with an estimate in minutes. These were entered into bug-tracking software and then added to the board as post-it notes…
    Business buy in: they pushed for Agile, but what they had been told by consultants was Agile had large elements of waterfall and didn’t teach the business the importance of product ownership or how to write user stories
    Having multiple product owners based on the existing heads of department (at one point we had six backlogs for one team) who saw a Sprint as “theirs” or “their turn”

    Something that surprised us
    Even though we are using an online tracking tool having a physical board to meet around is so helpful
    How much having constant conversations with everyone makes a difference to delivering something that works, is supportable and most importantly is what the customer wants

  8. Bernard says:

    Background context…
    Scaling agile in a rapidly growing organization.
    What we wanted to change…
    Not having to split teams while new people are joining every week
    What we tried…
    Seeding new teams with experienced people and having other members being brand new
    Something that succeeded…
    that worked to some extent
    Something that failed…
    CI/CD got much harder
    Something that surprised us…
    How embedded the optimise locally concept keeps coming up vs optimise the whole end to end

  9. Paul Shannon says:

    Background context
    I’m jointly responsible for our self managed technology teams and we’re trying to scale, both in terms of team sizes, geographic application distribution and number of products. We’ve scaled our infrastructure quite well to cope with a new influx of users but the same ideas don’t seem to be able to continue our growth.

    What we wanted to change
    Diversity of products and global distribution of their content.

    What we tried
    Using a CDN, using our infrastructure team to “stop trying to code ourselves out of every problem”, getting developers more involved in infrastructural “webops” type things.

    Something that succeeded
    The CDN meant the geographic distribution of our core product was achieved, and the quality of the service was good.

    Something that failed
    The complexity of the solution meant we had some knowledge silos and it couldn’t be used it other aspects of our products.

    Something that surprised us
    That working more closely between infrastructure teams and developers really worked. We’re now trying to expand that capability by having cross-functional teams and that’s what I want to find more about.

  10. What we wanted to change
    We wanted to get the devs to gain more focus on testability, and the testers more technical

    What we tried
    We paired devs with testers with the constraint that the testers should only write production code, and devs only automation code

    Something that succeeded
    Some of the participants showed an amazing curve in their attitude and skills

    Something that failed
    Some of them just could not be bothered after all

    Something that surprised us
    Testability is still a school of dark magic that is not common

  11. Background context
    – I was involved in an ‘Agile’ re-write from scratch when one company bought the other and wanted to combine the two systems into one. A new team as most devs has left when the company almost went bust.

    -What we wanted to change
    We wanted something better with fewer bug and enough automated tests to allow us to release often.

    -What was tried
    Strangling parts of the old system.

    Started with a team of 17 devs with something a bit like Kanban without WIP limits, then something a bit more like Scrum (because people felt ‘deadlines’ would help), then split into smaller teams with Kanban-ish again (because devs are optimists so ‘deadlines’ wouldn’t help), then Scrum-ish again (because we still weren’t getting enough done and it was believed that ‘commitments’ would help ).

    Debates about whether there were too many layers of architecture up front.

    Proving the risky parts of the architecture in 3 timeboxed months, but we didn’t get enough done so they extended the ‘timeboxes’.

    -Something that succeeded
    Smaller cross functional teams, rather than having a separate group of architects.

    -Something that failed
    When practices are dictated by management they tend not to go down so well.
    Taking on too many people too soon at the start of the project.

    Something that surprised me
    -That the project was described as Agile :)

  12. **Background context**

    I’ve been developing software in what might be described as agile contexts for several years, and have worked in a variety of different teams and projects. I consult in technical architecture and agile management and was the owner of the ruby agency Eden Development for several years.

    More recently, I designed the hosting infrastructure and was one of the principal developers on the UK Government e-petitions website, and I’m currently working with GOV.UK on their new Inside Government portal.

    The notes below cover a period in 2008 when we discovered more agile way of working at Eden.

    **What we wanted to change**

    Originally when starting with agile we wanted improve delivery reliability and avoid death-march fixed-cost projects.

    **What we tried**

    Moving to weekly billing for projects, rather than fixed scope contracts.

    **Something that succeeded**

    The team embraced XP methods, particularly pairing, with great enthusiasm. Delivering on time and on budget became trivial when the scope is flexible.

    **Something that failed**

    Selling the approach to customers. It was difficult to wean prospective clients off their fixed cost approach to software. In hindsight that was because we took on projects that had smaller budgets, which put more pressure on the customers to stick to methods they were comfortable with.

    **Something that surprised us**

    How much the agile approach, particularly pairing, changed the company development ethos.

  13. Peter Brown says:

    Background context
    Both management and development are committed to agile development.

    What we wanted to change
    We wanted to improve the flexibility of the code, so that customer
    value could be increased more quickly.

    What we tried
    We actively practise pairing, refactoring, continuous integration
    and test-driven development.

    Something that succeeded
    After years of development, it is still possible to extend and alter
    our codebase with low error rates.

    Something that failed
    The high-level design of the code has not improved. It is still
    much harder to make changes than seems reasonable.

    Something that surprised us
    How hard it is to balance the improvement of code structure with
    delivering customer value. (To put it another way: once you’ve
    got into serious debt it’s very, very hard to pay it off.)

  14. Hi,

    We’ve been trying out elements of Agile recently in the development of our product “Piero”. We wanted to be more organised but flexible in our approach to software engineering, especially with communication amongst the team.

    We introduced sprints and stand up meetings to our experienced team and found a balance that worked for us: daily stand up meetings seemed to be too often for our small well informed team, but every other day works well. The sprints worked well for us in monthly cycles but any more than this seemed to be too much of an overhead.

    We’ve thought about pair programming but found that experienced programmers don’t need this apart from occasional use. Maybe it’s a better approach for inexperienced/new programmers? I’ll be interested if others agree in the world of XP? Also how does pair programming work in the new world of working from home?

    Steve Poynter.

  15. Irina says:

    The IT department had not a very good reputation in the company because of delayed projects and lower than expected quality of software. We wanted to change development process so that IT department starts delivering good quality products fast. To do that we tried hiring project managers with Agile experience, inviting consultants, shuffling people between teams. In the end introducing very small changes to the process over months and trusting people to do their job properly has helped to create a process that actually works. On the other hand inviting consultants to set the whole process in one go only made people resent Agile. The most surprising thing is that what helped us was not theory from books but simply treating employees as human beings.

  16. I work at 1e, where we have a lot of exeperience of agile. Still, we find improvements to the way work every week.

    We had a gut feel that we were doing unnecessary testing, or testing that removed so little risk it wasn’t worth the effort. We practice Acceptance Test Driven Development but the QAs on the team would also need to run some manual regression tests from our manual test debt backlog. The decision about which tests to run were taken by manual QA alone which resulted in black box style testing. We moved the conversation about those tests into planning. Initially it was a difficult transition for the QAs to allow themselves to be challenged in this way. Within a couple of attempts the conversations allowed the QAs to understand more of the architecture and to develop the trust with the developers. Through improved trust and understanding QA stopped running the manual tests that didn’t remove any risk.

    Once we made this change, to our surprise, manual QA suddenly had a lot more time. Instead of the bottleneck in QA, the bottleneck is in Dev. We’re working to help QA to take work off the devs that the QAs can do. Hopefully we’ll go faster…

  17. Ivan Moore says:

    Background context:
    I work for Team Optimization Limited at a variety of clients. My current client is a small French company called IS2T who produce embedded Java products.

    I was a glamourless assistant at a TDD workshop at the very first XPDay and have been glamourless ever since.

    What we wanted to change:
    Keeping documentation in sync with the code. (At a previous client)

    What we tried:
    Rather than use a wiki or similar, we used html files in a folder in the same source tree as the code.

    Something that succeeded:
    We could send links to our documents, served straight from SVN, to our collaborators. SVN supports links to specific revisions as well as the latest revision, which was sometimes useful.

    Something that failed:
    We occasionally forgot to set the mime-type which meant that although a page served from SVN would render in some browsers, it wouldn’t in all.

    Something that surprised us:
    I’m just surprised that more people don’t do this (and so many people use wikis or similar instead for documentation related to code). Managing documents outside of the source control system that you use for the code it relates to, will inevitably make it difficult to keep them in sync.

  18. Background context
    I am Abdul. I am a PhD student in software development using agile methods

    What we wanted to change
    Our research focus on using agile development methods for distributed software projects. Specially, for customisation process for backlogged software products.

    What we tried
    We proposed framework to address challenges and issues of using agile methods fot that purpose.

    Something that succeeded
    We are in the validation process.

  19. Background context

    We adopted agile around a year ago. during this period our delivery process has been continuously evolving. we had applied TDD practices to some extent on a number of our projects, but still relied on a lot of higher level manual testing.

    What we wanted to change

    increase the quality of our end product, reduce the amount of manual testing required, and catch defects earlier

    What we tried

    engaging with BDD across the company, and improve our understanding of TDD best practices.

    Something that succeeded

    shifting more of the responsibility of testing onto developers themselves, so they were confident they’re changes worked as expected before promoting them through environments
    educating our business strategists on what BDD was and its benefits
    getting a common language across user stories, test scenarios and even in the code itself.

    Something that failed

    developing behavioural test scenarios collaboratively during meetings….it can be time-consuming when you’re new to the practice and frustrating

    Something that surprised us

    how difficult it is to distill BDD down into a simple explanation that is clear for someone new to it. it was also hard to point someone to a decent introductory blog post or online article, without confusing them with references to other related concepts they hadn’t heard of.

  20. Tom says:

    Background context

    The nature of projects we’ve been taking on has shifted markedly since the company was founded 2 1/2 years ago. We’re increasingly delivering mobile applications with large web back-end components, or fully-fledged web applications.

    What we wanted to change

    To improve our test strategy as projects scaled, and make it less labour-intensive. Also finding the right balance between test coverage and time spent developing tests.

    What we tried

    1. Writing manual test scripts against requirements (in Excel!)
    2. Using ‘Pages’ docs to store results with screenshots taken from testing
    3. Up-skilling in TDD and BDD processes to reduce the amount of manual testing required

    Something that succeeded

    Implementing a testing taskforce, to come up with a strategy for different types of testing at different levels. Educating the whole company on BDD, and how many teams use it in practice.

    Something that failed

    Our manual testing scripts often missed edge cases. We found it difficult to estimate time required for manual aspects of testing.

    Something that surprised us

    The level of complexity of larger web projects, and the added difficulties around testing them.

  21. Background context

    We began the transition to a more Agile process, about a year ago
    We deliver applications for corporate clients, and before this transition the clients would sign off on requirements up-front…these were then locked down
    Despite this, clients would still request changes late on

    What we wanted to change

    we wanted to be able to handle change but still deliver on our commitments
    we wanted to improve client satisfaction

    What we tried

    Putting together an Agile taskforce tasked with learning more about Agile and then spreading this knowledge
    Running a pilot ‘Agile’ project
    Using statements of work that didn’t fix scope
    Agreeing sprint plans on a sprint-by-sprint basis

    Something that succeeded

    we reduced the amount of panic at the end of projects
    client satisfaction definitely improved

    Something that failed

    it wasn’t always easy to negotiate with clients to de-prioritise some existing requirements when changes/new requirements were requested or priorities of other requirements increased.

    Something that surprised us

    the variance between clients, and how differently each must be handled
    how important it is to educate clients on our process, and Agile software development in general

  22. Tim Checkley says:

    Background context

    One year ago, the company started the transition to Agile development.
    Previously our projects had followed fairly traditional waterfall phases.

    What we wanted to change

    a particular problem we had was our UX designers would move onto other projects after the design phase, but we still needed changes during build and there was often still work to be done to ‘slice’ design assets so they could actually be used by our code.

    What we tried

    various different approaches to resourcing
    different handover techniques and approaches
    a more Agile process with designers producing initial designers but sticking with a project to work on it until completion.

    Something that succeeded

    designers and engineers worked together much more effectively
    iterative designs led to better solutions and a better flow of work
    putting together an Agile taskforce to drive improvements in our process, and piloting a more Agile methodology on one project initially before spreading it

    Something that failed

    getting client approvals for designs sometimes delayed sprints and created blockers for developers
    planning resources was difficult, as it was unpredictable how much of a designers time we’d need in latter stages of a project

    Something that surprised us

    the benefits we’ve got from being more Agile…and how well its worked!

  23. Ben Hoskins says:

    Background context
    The teams have been working with agile methodologies (primarily with Scrum) for a while and decided to move more to a continuous delivery model, in order to produce consistent value.

    What We Wanted to Change
    Move from a Scrum approach more to an XP approach, such as test driven development, continuous deployment, pair programming etc. This was so we could evolve on a codebase which could readily accept change, and be built upon.

    What We Tried
    As the teams were distributed, we flew people around the globe and had remote tech leads regularly interface with teams

    Something that succeeded
    Levels of unit testing rose, but never got to the level of TDD.

    Something that failed
    Subsequently code re-use suffered. Also, early and often releases were sometimes hampered through areas where we had no influence.

    Something that surprised us
    You can get quite far with test last, and release at the end of a sprint

  24. Francesco Pratolongo says:

    Background context:
    We are a team responsible for making substantial technical improvements in our back-end platform. We started working together less than 2 months ago.

    What we wanted to change:
    We want to improve the performance and increase the scalability of our platform, delivering a bug-free code that is efficient, clean and easy to maintained and extended..

    What we tried:
    We are trying to apply all the best practices we know (pairing, TDD, BDD, Continuous Integration, Continuous Deployment)

    Something that succeeded:
    Too early to say as we’ve been working together for only a couple of months but pairing seems to be helping in sharing the knowledge and increasing the quality of the design and the code

  25. Kostas Stamatoukos says:

    *Background context*
    I am a young software engineer, and I recently joined an agile team at eBay. We are following the SCRUM methodology for developing a series of cool products. I still have a lot of things to learn about agile methodology, and I believe this meeting is a really good opportunity to do so.

    *What we tried to change*
    We tried to change the way of pushing our code to the common repository, in order to achieve higher code quality and knowledge share and synchronization between the team members.

    *What we tried*
    We adopted github workflow based on code reviews

    *What succeeded*
    Code quality was indeed improved. Issues are more likely to be detected and the team members start trusting each other more.

    *What failed*
    When two members worked on rapid Prototyping a UI there were a lot of conflicts resulting on a lot of time being wasted for code reviews.

  26. Background context:
    A new team was formed from people never working in Agile.

    What we wanted to change:
    Deliver constant value by doing frequent releases, collectively own the code, develop common design values, reduce the number of bugs.

    What we tried:
    Code reviews, daily stand ups, unit testing was introduced (!), TDD, drop requirements documents.

    Something that succeeded:
    After a week of work, everybody loved the code review process. It helped a lot to develop common software design values.
    Pair programming for complex code.
    Unit testing.

    Something that failed:
    The team never accepted TDD.

    Something that surprised us:
    We’ve worked on different parts of code almost independently. The code was well tested. One day we gathered all together and glued the parts together. The app started working from the first run.

  27. Alicja Kobusinska says:

    Background context
    A new team has been formed with very strong headed devs with different expirience with TDD and pairing

    What we wanted to change
    Have proper CD system, high quality code, introduce BDD, practice TDD and pairing

    What we tried
    red-green game, pomodoro, dedicated qa dev for BDD, TDD, pairing

    Something that succeeded
    red-green game, keep both devs focused, TDD

    Something that failed
    having dedicated qa developer (we endup revriting all BDD) , dev in pairs its really slow, and our velocity constatnly droping :(

    Something that surprised us
    that ppl are not keen on TDD, and how often I heard ‘This bit of code can not be tested’ :(

  28. Mat Johns says:

    Background context:
    New team developing in an agile fashion both green and brown field developments.

    What we wanted to change:
    Providing better confidence to our brown field refactoring to ensure extremely high levels of quality.

    What we tried:
    TDD, BDD, Paired Programming, CI, CD.

    Something that succeeded:
    Hooking up a physical notification of CI build/test failures (red lights).

    Something that failed:
    When the red lights stopped working and the tests failed without being addressed!

  29. Background context:
    Running 7 offshore outsourced XP teams in Ukraine alongside 4 internal teams in 2 regions.

    What we wanted to change:
    We wanted to avoid the traditional mistakes associated with outsourcing, i.e. throwing it over the wall, hoping it works and complaining when it doesn’t.

    What we tried:
    We’ve evolved from 1 to 7 teams and have found that there’s a much greater management overhead. We introduced Release (project) Managers to improve communication and reduce the size of feedback loops.

    Something that succeeded:
    The internal facing projects with customers who are not on-site, but at least are directly available in time-zone and willing to spend a lot of time on the phone.

    Something that failed:
    When the pressure piled on for many customer deployements of one product, the team lost sight of XP and allowed in large scale duplication. Without a large investment in travel and time, XP practices and values drained away in several of the teams, leaving a worst-of-both-worlds development model.

    Something that surprised us:
    We have had to make some changes to cope with language difficulties. Developers would often leave a meeting giving the impression that everything discussed was understood, when they had filled in gaps in verbal understanding with their own assumptions. Now, the story is still a token for a conversation with the customer, but we log the decisions made during that conversation, to allow the team to digest the outcome at their own pace.

  30. Ben Pitman says:

    Background context

    We build applications for corporate clients, with budget often allocated for development but harder to extract for maintenance.
    We also work with specialist contractors on many of our projects.

    What we wanted to change

    make maintenance less painful, and manage clients expectations around this better

    What we tried

    being strict with our recruitment of contractors, to make sure we ended up with good ones that felt a responsiblity to deliver quality and drive projects to success
    ensuring we agree some of contractors’ time even after they move onto other projects
    involving in-house/permanent staff with a project from the start, to work alongside contractors
    maintaining ‘pragmatic documentation’ i.e. documentation on the most important aspects such as setting up local environments, running tests etc
    finally, convincing clients of the need to think about maintenance early in a project

    Something that succeeded

    pragmatic documentation has worked well – with the basics in place, other things can often be picked up as and when needed
    involving permanent members of staff from the start of a project has been effective when possible….they generally take responsibility for knowledge diffusion amongst the rest of the team

    Something that failed

    haven’t always managed to get permanent staff involved with projects regularly enough from early in a project

    Something that surprised us

    some clients don’t seem to expect any maintenance costs or give any consideration to this
    how difficult it is to educate non-technical stakeholders on the real complexity of our systems

  31. David Puleri says:

    I have been in the web industry for over 10 year, I am eager to keep up with the industry latest.
    I want to contribute so the various team composing our engineering department can work together toward a cross component service architecture model.
    It is Early stage at the moment. we are defining very solid process (deployment, agile) and aiming for the best coding practice (tdd, xp, review) to prevent tech debt
    We are using Ruby (capybara) to deploy and integrate with Jenkins. Ideal language for that tool. We tried to package with RPM, but it wasn’t the smoothest way.

    We are however facing impatient business unit which were used to work with 3rd party digital agencies. But a good management (cucumber report, demo, interaction with the team) of BU make them acknowlege the benefit of inhouse engineering team against remote foreign agencies.

  32. Johan Dindaine says:

    Background context
    we are trying to build a really dynamic CMS system that can handle so many content types on different channels.

    What we wanted to change
    We want to move away from those isolated instances of drupal with content repository per site to something more service oriented that can be accessible on several channels.

    What we tried
    we try to introduce agile in this company (although we all experience it in previous experiences) but we are still in the learning phase.

    Something that succeeded
    We defined our minimum set of stories for a viable minimum product and are now iterating through it.

    Something that failed
    The most important thing that failed make understand the not-technical part of the business the concept of minimum product that could be improved as they push for everything that currently exists to be available from the begining.
    Also there is only a fixed amount of business values that can be delivered on any print and BU don’t realise that if we keep developing and support intensively on the legacy system they won’t get anything done on the new product.

    Things that surprised US
    We’re still too early in the process for this project to have had any suprise but they will come up for sure any time soon.

  33. Background context
    Background in control engineering, neuroscience and music. Software developer for the last 13 years. Currently responsible for build and deployment at thetrainline.com. I want to help teams deliver more rapidly and effectively by providing the infrastructure, tools, communication channels and social environment etc. for rapid cycles and good team dynamics to thrive.

    What we wanted to change
    We [before I joined] moved to an “any team can work on any subsystem” model, but this did not work.

    What we tried
    We’re moving to an alignment of teams with “products” or services, starting with alignment to subsystems. We’ve seen clear improvements in ownership over the last few months.

    Something that succeeded
    “Empathy Snap” – an ice-breaker for retros which gets the team considering other team member’s likely views of the past iteration:

    http://blog.matthewskelton.net/2012/11/15/icebreaker-for-agile-retrospectives-empathy-snap/

    Something that failed
    Test automation has been a struggle to get right, particularly around ownership.

    Something that surprised us
    A collection of nerf guns improves team productivity!

  34. Zenon Hannick says:

    Background Context
    A newly merged company building a global platform to replace disparate systems developed and supported by teams in the three companies that have been brought together by acquisition.
    Mobile Front End built in London (PHP), Messaging layer speaking to mobile aggregators all across world built in London (Java), Mobile Content Delivery Platform built in San Jose, USA (Java), Web Front End built in Sao Paolo, Brazil, (.Net), central black box controlling all interaction between other components/layers built by outsourced company in two offices in Buenos Aires & La Plata, Argentina (Java). All managed by centralised technology management group based in San Jose, USA. All components developed in silo-ed teams and to be brought together in a big-bang integration phase.
    What could possibly go wrong?

    What we wanted to change
    Silo-ed geographically independent teams delivering pieces of the puzzle.

    What we tried
    Creating multiple feature teams with members from each tier of the system.

    What succeeded
    The feature teams worked better than silos. Video conferencing and trips to other offices brought team closer together and led to some shared understanding. Ultimately though it would be a stretch to call it a success

    What failed
    Attempts to create consistent story point values across all feature teams. Lots of effort to create a nice looking management report, ( and also judge the effectiveness of each team). Even before gamification started affecting numbers it was doomed to failure.

    Something that surprised us
    The positive effect seeing each other during skype stand ups had on the commitment between team members.

  35. marcj says:

    Background context
    A team of 10 developers (5 pairs) working on a rewrite of an existing system, roughly half of which are experienced in agile software development, the others this is their first project.

    What we wanted to change
    Whilst we were pairing, people rarely rotated between stories, which given that our stories sometimes took over a week, we felt that didn’t allow for sufficient context sharing. We wanted people to rotate more often.

    What we tried
    We use avatars on our wall to represent people, we removed all of them from the stories in our stand up every morning. Then each person goes to the wall and chooses which story they want.

    Something that succeeded
    Everyone has to participate in establishing pairs, more discussions are had about who should stay on a story and who should rotate or if rotate is appropriate.

    Something that failed
    Some of the people still stay on stories until they are finished, this means some of the less assertive members of the team get less choice of story.

    Something that surprised us
    Sometimes completely inappropriate pairs are selected, for example, two people who have no context on the work. The really surprising thing is that people didn’t seem to notice, or at least not be willing to engage in a conversation about it.

  36. Satish Srinivasan says:

    Background context: Large legacy codebase grown “organically” from a prototype, with very hairy threading behaviour. This had given us grief over a number of years.

    What we wanted to change: Having had approval for the rewrite, do it “properly” this time.

    What we tried: GOOS-style TDD. Merciless refactoring. Focus on code quality and SOLID principles.

    Something that succeeded: High-quality codebase. The rewrite went live.

    Something that failed: Took a good order of magnitude longer than originally estimated.

    Something that surprised us: In retrospect it shouldn’t have surprised anybody, I guess. Delivery took so long that business priorities had changed by the time it went live and the product got canned a few months afterwards.

  37. Been “agile” for many years, been to XP days for the last few years, often seen at XTC.

    Always try and be more productive in the right direction whilst doing less.
    Tried: changing how we did things
    Succeeded: pleasing more people
    Failed: pleasing all the people
    Surprised: doesn’t matter what you change, you’ll never please everyone, you just have to try your best.

  38. Background context:
    A startup company building a software for managing an sharing research papers(250 millions of them). The current software needs to be improved. All the old developers who put the system in place have left and a new Java team of 6 developers is now taking care of it.

    What we wanted to change
    We wanted to reduce the number of technologies used and simplify the architecture

    What we tried
    Instead of refactoring old code we are rewriting small parts of the system following ‘good’ software development practices.

    Something that succeeded
    TDD
    New deployment process
    Adopting dropwizard for our serving layer.
    Using Cascading as a complement of standard Hadoop.

    Something that failed
    Still depending on lot of low quality/buggy legacy code. Therefore some of our team time goes to maintenance of old code and bug fixing.
    In our particular case we don’t see real value for Unit testing the map reduce jobs.

    Something that surprised us
    How much improvement in terms of time we gained by improving our deployment process (now taking 10mins instead of days).

  39. Charlotte Philippe says:

    Background context
    Software engineer in a consultancy company where Agile practices are key in project development.

    What we wanted to change
    Bringing the client facing the reality of the project as soon as possible, allowing flexibility to reflect the changes that (always) happen.

    What we tried
    Kanban/scrum style approaches according to the project – adapted to fit its need.
    Mainly scrum style with good visual representation of the project state (backlog and sprint board accessible from team and client) and scalable feedback loops (Sprint planning – daily standup – show and tell – retrospectives ).

    Something that succeeded
    Continuous and incremental delivery that regularly adds value to the project and keep both developers and client happy.

    Something that failed
    This cannot work without real client/product owner involvement – which can be difficult in big organizations used to have different layers of responsibilities – need to convince them to really manage the backlog and story priorities.

    Something that surprised us
    How easy it is for a – relatively small – team to self-organize with the right tools and structure.

  40. Chris Turtle says:

    Background context:
    I was working as a software engineer on a licensing system for our company’s products, more or less following Agile practices.

    What we wanted to change
    Two of the members of my four person dev team wanted to move overseas. The business didn’t have a problem with it so long as we could accommodate our working practices accordingly.

    What we tried
    We continued holding daily standups using conferencing software and chatted/screenshared on skype amongst ourselves.

    Something that succeeded
    Overall productivity didn’t suffer too much (perhaps because there was less socialising and more working going on)

    Something that failed
    Pair programming and group discussion were a big part of how we worked before the team was split up. While we were able to continue this to some extent, online meetings are no substitute for chats over tea/coffee for generating ideas.

    Something that surprised us
    Those who moved abroad and worked from home every day did actually work…

  41. Jose D says:

    Background context

    Sometimes with software development Is difficult to establish a collaborative relationship or make some people understand your point of view as a qualified engineer. But when the things goes right, you really get paid for the hard work you’ve done.

    What we wanted to change

    Software development as a career needs to be recognized as a highly technical profession and because of this, find the respect and communicate effectively the impressions we’re getting (sometimes) from the “battlefield”.

    What we tried

    Make strong team relationships in and out of the office. Trying to set up, on a regular basis, technical meetings to keep everyone updated with latest trends. Communicate other layers with the everyday work done and also with achievements and concerns allowing quicker reaction times.

    Something that succeed

    Really made good team and we were able to really change the way of work, improving cohesion and collaboration, making unit tests and all of that keeping a very fun and enjoyable work environment.

    Something that failed

    Try to radically change the things when everybody says they want but nobody really wants to afford the change. At the end you’re pushing alone.

    Something that surprised us

    There’s a community and lots of companies out there that are really making it, in which people is collaborative, helpful and the environment is agile. Simply awesome !

  42. Lee says:

    Background context

    – We are part of a larger team that has had some success moving from a
    pure waterfall environment to a more Agile one, however there is still a
    lot of work to do.
    – We deliver an embedded application on a consumer device, and quality is
    extremely important – but so is responding to customer and competitor
    feedback.
    – We have delivered several high profile releases this year (which is
    great) but they require a lot of effort and we want to make it even easier
    to get features out the door.
    – As we have many dependencies on other teams, coordinating change is a
    challenge

    What we have tried

    – Adding more “agile” experienced people to our team to work alongside
    domain experts

    Something That Succeeded
    Continuous builds on our test farm containing lots of target hardware platforms. Very good at finding bugs in real world scenarios

    Something That Failed
    Grouping people into expert groups on components – depending on the sprint content this restricted the work that could be done down to specific individuals -v- Not grouping people into expert groups on components – meant anyone can jump around the code but the learning curve is sharper potentially with each card.

    Something That Surprised Us
    Introduction of pairing was fairly ropey to start with. After some discussions and experience it has been beneficial as long as it is not deemed to be mandatory 24/7.

  43. Tim M says:

    Background context

    – We are part of a larger team that has had some success moving from a
    pure waterfall environment to a more Agile one, however there is still a
    lot of work to do.
    – We deliver an embedded application on a consumer device, and quality is
    extremely important – but so is responding to customer and competitor
    feedback.
    – We have delivered several high profile releases this year (which is
    great) but they require a lot of effort and we want to make it even easier
    to get features out the door.
    – As we have many dependencies on other teams, coordinating change is a
    challenge

    What we have tried

    – Adding more “agile” experienced people to our team to work alongside
    domain experts
    – Having a single backlog and one large team, having separate teams and separate backlogs
    – Pairing, TDD, CI, retrospectives, offsites etc.

    Something That Succeeded

    – focusing on improving our build scripts and streamlining how we can deploy code
    – re-arranging our team into a bull pen configuration
    – moving back to paper cards and walking the board in a standup
    – focusing on better collaboration with other teams

    Something That Failed

    – early team history had written lots of tests but they flicker and so don’t always give the confidence required to prove changes. It’s been hard work replacing/fixing these with something more suitable. Fortunately we have good manual testing but this gives a slower feedback loop

    Something That Surprised Us

    – every day is a surprise
    – delivering at scale (millions of users) causes interesting challenges

  44. Jakub Jamro says:

    Background context

    – We are part of a larger team that has had some success moving from a
    pure waterfall environment to a more Agile one, however there is still a
    lot of work to do.
    – We deliver an embedded application on a consumer device, and quality is
    extremely important – but so is responding to customer and competitor
    feedback.
    – We have delivered several high profile releases this year (which is
    great) but they require a lot of effort and we want to make it even easier
    to get features out the door.
    – As we have many dependencies on other teams, coordinating change is a
    challenge

    What we have tried

    – Adding more “agile” experienced people to our team to work alongside
    domain experts

    Something That Succeeded

    – The experience people brought into the team added a new energy to the group dynamic and the lots of work has been done to minimise our technical debt

    Something That Failed

    – Grouping people into expert groups on components – depending on the sprint content this restricted the work that could be done down to specific individuals -v- Not grouping people into expert groups on components – meant anyone can jump around the code but the learning curve is sharper potentially with each card

    Something That Surprised Us

    – We’re surprised everyday. The highly asynchronous nature of our product results in very complicated interactions with and within our codebase which we deal with on a daily basis. It’s important to note all of these learnings properly or we would have to relearn everything each developer has learned while working with us when they leave.

  45. (Nader et al, I can only make it to the first day so if someone wants to come to both and you need the place, let me know and I’ll drop.)

    **Background context**

    Most recent experience: coding dojo with the client devs

    **What we wanted to change**

    I wanted to learn Javascript, they wanted to improve TDD etc. too

    **What we tried**

    The LCD numbers exercise, where numbers are portrayed as LCD characters

    **Something that succeeded**

    We got the first 3 tests passing! I also really loved having Matt Wynne there; it challenged me to be really good at refactoring, naming etc. I find going back to these exercises so useful, even though I don’t code so much these days any more.

    **Something that failed**

    I thought that a few people in the room had a very clear idea of how they wanted the code to fall out and were doing a bit of ‘back seat driving’, rather than allowing people to follow their own design and make their own mistakes. I didn’t give that feedback at the time, or even immediately afterwards, so *I* failed.

    **Something that surprised us**

    Javascript turns out to be very easy and fun to work with. I was also pleasantly surprised by the aptitude of the devs with TDD – many client devs I work with aren’t that good. Awesome sauce, really loved learning with them.

  46. Background context

    – We are a company delivering primarily mobile and web applications for corporate clients, with typical projects lasting around 6-8 weeks.

    What we wanted to change

    – we wanted to improve the accuracy of our estimation to improve delivery within given timeframes.

    What we tried

    – we experimented with using High, Medium, Low measurements for stories; using story points; and just estimating everything in hours.

    Something that succeeded

    Using high, medium, and low for backlog-level estimation – this was clear for our clients and reflected their level of precision. Using hours for sprints has worked better than any alternatives – normally at a sprint-level, the hour estimations turn out roughly correct.

    Something that failed

    Using story points hasn’t worked for us – we have a lot of short projects and the team composition tends to change on a per-project basis, so not enough time to develop a stable velocity.

    Something that surprised us

    We found little literature that mapped well to the type of projects we have and domain we exist in.

  47. Clive Evans says:

    Background context
    – Having taken over a large, poorly maintained legacy application, we’re trying to use the vast amount of valuable data it has stored to create a new (more easily saleable) application
    What we wanted to change
    – We wanted to get close to our (theorised) users, and provide them with value quickly (and cleanly).
    What we tried
    – Rapidly building a prototype application while trying to engage with sales and marketing to find us potential users we could use to test our theories.
    Something that succeeded
    – Including “sketches” in the prototype application to indicate the presence of stories that were not yet begun
    Something that failed
    – Getting salespeople to include us in conversations with their customers.
    Something that surprised us
    – Quite how difficult it is to keep the amount of time spent on maintenance of the existing application to a sustainable (low) level.

Follow

Get every new post delivered to your Inbox.