Tag Cloud

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Agile Lab Courses

Scheduled Training Courses

Date	Title	Location	Fee	Contact
Wednesday 20th January 2010	Building the Lean Web Development Team	The Hatton, Central London	£350	Email mark.stringer@gmail.com or phone 07736 807 604 (book online)

Training, Coaching and Consultancy in Agile Methods

Agile Training Courses

Introduction to Agile Methods

We all have to deal with change. Development using Agile methods provides a principled approach to software development in an environment of constant change. More info...

Agile for Programme and Project Managers

How does the job of a project manager change in an Agile environment? How can knowledge of Agile methods complement the project management skills that you already have? More info...

Technical Aspects of Agile

We all want to write better software, we all find it hard to do. Test Driven Development (TDD), pair programming and refactoring are three clear and easy to learn techniques that can transform software productivity and realiability. More info...

Consultancy

"Just wanted to say thanks, for the advice. It transformed something that seemed a little hopeless and misdirected into something positive and definitely doable."

What can an outside perspective bring to your organisation? Find out. Contact Mark on 07736 807 604

Negotiations and Difficult Conversations in Software

What conversations are you avoiding? With your customers? With your team? With your boss? What would life be like if you could comfortably, confidently and effectively have those difficult conversations?

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Agile Lab Contact

Mark Stringer:
email - mark.stringer@gmail.com
mobile - 07736 807 604

Agile Lab People

What is your name?

Mark Stringer

What do you do?

I'm a consultant with Agile Lab. I've been a software developer, a researcher and a project manager.

Which other companies have you worked for?

Soda Creative

What I did: I worked as project manager on several web–based projects, mainly for clients who didn't have much understanding of the web.

What I learned: Your clients often don't know what they're talking about. Now I realise that they shouldn't have to. Writing software is a creative endeavour, you should be willing to learn with them what it is that they actually want. They don't necessarily know what software, or software development is. Why should they? It's not their business. But when you go quiet for a week or two (while you write the software) they'll start to panic. Many, many people, once you've shown them a photoshop mock–up of something, will assume that it's implemented. This is when I started to read about extreme programming and Agile methods. The only way to explore their understanding and arrive at any kind of satisfactory solution is to design and implement working software in short iterations. You've always got something to talk about that actually works. This reduces the risk, both for the client and the developers.

What I achieved: I learned about Agile methods and started to implement them in the projects that I was managing.

Cambridge University

What I did: I did research on novel uses of Tangible User Interfaces in an Educational setting, I also taught Human Computer Interaction to undergraduates.

What I learned: The seemingly chaotic system of University departments and colleges at Cambridge actually seems to work better than the hierarchical organisation of more "modern" Universities. Mediaeval isn't always an insult. Cambridge University Computer Science undergraduates are very clever, but they will do anything to avoid talking to users – just like most other computer programmers I've ever met. Schools are complicated environments, designing for them has to be an iterative process, you get the most interesting and generally useful technological results when you design iteratively for a specific complex environment and then test against it (this was the seed of being Agile, but I didn't know it yet).

What I achieved: We designed and delivered a new way of interacting with computers that not only helped kids learn something useful – how to structure a discursive argument – but also did it in a way that allowed its use to fit inside the labyrinthine requirements of the National Curriculum.

Xerox

What I did: Worked on a bunch of research projects using mobile technology such as mobile phones and PDA's.

What I learned: Getting innovation "over the fence" and out in to the real world is very hard. Innovating from inside a giant corporation is really hard. It's difficult to stop them from seeing what you're doing as a threat. If you take the innovation and keep it a long distance away from the everyday activities of a company it's always going to be treated with suspicion. That's why the way Google do innovation and actually get it out into the world where potential customers can see it is so exciting.

What I achieved: I wrote some patents. I got some little bits of innovation out into the real world. On one day at the height of the first internet boom my little bit of innovation was credited with causing Xerox's share price to soar.

IBM

What I did: This was my first software development job. I did all the bits of a traditional waterfall methodology, from writing design documentation through to running acceptance tests and maintenance. For some reason most of it involved sitting in a freezing in a portacabin outside Portsmouth.

What I learned: You can't keep a Portacabin warm in an English winter, not even if you set it on fire. Some of the most profitable software projects I worked on were traditional waterfall projects that had nearly crashed – they'd got to the threats and litigation stage and had then been rescued by negotiation. I didn't know it then but what they were doing was a kind of back–to–front Agile.

What I achieved: I arrived at IBM a Philosophy graduate and left a computer programmer.

Why do you work for Agile Lab?

I co–founded Agile Lab because I'm fascinated by the idea of different ways of doing things. Agile methods are a powerfully different way of doing things. New ways of communicating and working together can be discovered and they can change everything.

For further information, contact Mark@agilelab.co.uk (07736 807 604)