Archive for the ‘QTB’ tag
About 18 months on from the first ThoughtWorks QTB that I saw about offshoring, on Wednesday night I attended the latest QTB in Manchester titled ‘thetrainline.com – Scale at speed‘.
The presenters were thetrainline.com’s CIO David Jack and the Managing Director of ThoughtWorks India, Mahesh Baxi.
They took us on the journey that thetrainline.com have taken while working with ThoughtWorks to re-architect part of their system to allow them to quickly deliver new functionality on the 2,500 websites that their portal technology powers.
These were some of the key points that stood out for me:
- Early on in the talk David described how they needed to make a decision about whether to rewrite the system from scratch or build on top of the current one and strategically rewrite parts of it. The latter option was the chosen one and others seem to be in agreement that this is the best way to approach the problem.
The argument for doing this that I’ve often heard is that you end up playing catch up with the old system and eventually end up in the situation where you need to re-write the re-write but in this case David suggested that re-writing the whole system was not an option for the business.
- David described the early trainline approach to development where it sounded like the main goal was to get features out to market as quickly as possible. He spoke about the ‘first mover advantage’ whereby if you’re the only product available to customers then the quality of your offering isn’t the most important aspect since you are the only option.
James Shore describes this as ‘voluntary technical debt‘ and I think we need to at least consider whether it’s more important to get quick feedback on our work by getting it into production quickly and perhaps taking some shortcuts along the way. David was quick to point out that at some stage you do need to address that technical debt otherwise you’ll end up in a world of pain.
I’m not sure how exactly you know where to draw the line with respect to this because it would be very easy to just get into a hacking culture until you get to the stage where it’s almost impossible to add any new features to the code base.
- A bit of time was spent talking about various metrics which were used including looking at the cost per story point delivered. They didn’t go into further detail on that but it seems like it’s the dangerous area of metrics which are easy to game that Dan North talks about in his ‘Our obsession with efficiency‘ presentation.
I’ve not really come across a good low level metric which allows you to accurately tell how well a team is doing. The best measure seems to be just looking at whether a team is consistently delivering valuable features to their users. That’s often considered a bit wishy washy so it’d be interesting to know if anyone has a better way to measure performance that works well.
- They both spoke of the need to ensure effective communication between 13 teams operating across 3 different locations (Bangalore, Pune and London) and suggested that rotating people and making extensive use of video conferencing allowed this to be achieved.
The rotation included having subject matter experts from thetrainline.com going to India and working with the teams and David suggested that you still need to have a big commitment to a project if you want it to be successful even if it is being done offshore.
- In his summary David emphasised the importance of releasing frequently into production. In a lot of organisations releasing into production ends up becoming a big deal and so it happens less and less frequently but David suggested that thetrainline.com are releasing new features every 6 weeks and are aiming to get that down to every fortnight.
I guess the ultimate is to have continuous delivery as described by Timothy Fitz in his blog post.
Overall this was quite an interesting talk to attend and gave me a bit more insight into some of the similar and different challenges that are faced by projects operating across multiple time zones.
I went to watch the latest ThoughtWorks Australia Quarterly Technology Briefing in Sydney on Wednesday where my colleague Lindy Stephens, Suncorp’s Josh Melville and Lonely Planet’s Nigel Dalton presented on ‘Agile Governance – Managing the Enterprise Issues‘.
I was actually unsure of how interesting it would be to me as the title seemed a bit dull but it was actually quite entertaining and not at all what I expected.
These are some of the things I picked up from the presentation:
- Lindy started out talking a bit about the illusion of control that waterfall plans can lead us to, referencing the intial paper on waterfall written by Winston Joyce which actually criticises the idea of designing everything up front and suggests an iterative approach would work better.
A recent article by Tom De Marco where he retracts the idea that you “can’t control what you don’t measure” was also referenced. The most interesting part of this article for me is where he points out that projects which provide minimal return are the ones that need the most control but perhaps we should be considering whether we should even undertake them in the first place.
The idea of having software that is production ready at any time is also a very nice thing to aim for:
So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product.
- Traditional measurements of progress derived from a more waterfall process actually only tell us if we’re proceeding not if we’re succeeding – it’s much more useful to keep our focus on whether we are delivering value to the end user instead of just focusing on whether we have hit our targets on delivery date and promised scope.
The transparency and visibility that we typically have when following a more agile approach was mentioned by a couple of the speakers – progress is much more visible throughout and we don’t suddenly have a project going from status ‘green’ to status ‘red’ right at the end.
I think we need to be a little bit careful that we explain things carefully when showing this types of data to people who are new to the agile approach as it can very easily give the impression that we are totally failing when actually it’s fairly normal for initial progress on a project to be slower than it will be once we get going.
Nigel Dalton described a story where even the Lonely Planet chef knew how one of his teams was doing because the information was so transparent!
- Nigel also spoke about the idea of outsourcing agile and suggested that the best way to ensure success with this is to work with people in a country on the same longitude so that the timezone difference isn’t too great. He also suggested that having people from both locations going to the other works well for ensuring better communication.
- The general idea behind what Nigel presented seemed to be that the individual teams effectively provided the governance of projects and that it wasn’t necessary to have massive reports detailing progress every week.
Josh Melville stressed the importance of looking at the value of all documents and getting rid of them if they don’t provide anything useful. Nigel described how they had massively simplified one of their reports after listening to Josh’s advice!
Lindy pointed out that sometimes we’ll be executing projects in an agile way in environments which more traditionally follow a waterfall methodology and that in this case it might be necessary for the project manager to spend some of their time converting the data into an appropriate report.
In terms of the lean approach this seems to me to just be waste, but perhaps a necessary waste.
- Josh also talked about the importance of moving away from a process centric view of the world to a relationship based one when it comes to managing projects whereby problems could be talked through instead of just writing off a project as doomed because a ‘checkpoint’ wasn’t reached.
He also suggested that considering whether we delivered features and also whether they were actually used were more useful things to look at rather than looking at budget and time.
- In the questions afterwards one suggestion to the speakers was that the metaphor of software development as being similar to industrial manufacturing is not really helpful and that perhaps movie making is a better one to use because there is a level of creativity involved and the aim is to deliver something of value each day.
Nigel pointed out that while traditional manufacturing didn’t have much to teach us, lean manufacturing was a different story as it helps us cope with variation rather than just cost which is quite important in software development.
There seems to be quite a few books out at the moment about how to introduce a more agile approach into your organisation – I’ve been reading Lean-Agile Software Development and Becoming Agile and there is also a book called Scaling Lean and Agile Development – so I was intrigued to see whether the messages from this talk would be similar to those in these books.
What did I learn?
- I often find when listening to Martin Fowler speak that although what he says is quite similar each time when speaking about agile there always seems to be something different that stands out for me each time.
This time what stood out was his mention of the Dreyfus model with regards to people’s level of skill when it comes to agile – when you first start out as a novice it’s quite hard to keep the principles in mind so you spend a lot of time focusing on the practices and getting better at these but if you want to keep improving then at some stage you need to move up to a level where the principles do become more predominant.
- Andy made an interesting point that IT and in particular software development is pretty much made for people who want to learn new things and he also pointed out the myth that ‘learning finishes at school’. I never really considered this before but for me it definitely applies – the process of learning new ideas appeals far more to me than the results and outcomes of projects so it was interesting to hear this coming from someone else.
- Transparency with regards to bad news was something else which was pointed out as being fairly important and it’s certainly an area where we often run into trouble – often organisations aren’t used to bad news being delivered to them early and they get the impression that if it’s going badly now then it’s going to keep on going badly, rather than seeing that it’s quite good to get bad news early because then you have time to fix it.
- Martin described the ‘pilot project anti pattern‘ which he has come across where organisations make use of agile on a project which noone really cares about and use it as a training ground. It was suggested that this is not an effective way of introducing an an agile approach as it doesn’t matter to anyone so there’s no incentive to work out whether the new approach is really beneficial or not.
- I liked the question that Andy posed about success and failure. He first of all asked anyone in the room who had seen an email from their CEO talking about a really successful project and congratulating the team to put their hands up. Pretty much the whole room did.
He then asked who had received an email from their CEO talking about a failure and the lessons learned from that and only one person’s hand went up!
Andy is definitely right when he suggests that “if you’re not failing you’re not learning anything” and this is something which I’ve also come across from Andy Hunt in Pragmatic Learning and Thinking and more recently I’m trying to get into the ‘improvement ravine’ with regards to learning F# as I’m still writing object oriented F# which I think is missing the point a bit. Thinking in a more functional way is the key for me there.
- A question was raised about how agile can fit in with fixed price projects at the end where it was pointed out that if the price and the time are fixed then the scope has to be variable – it can be infinitely flexible. It’s actually often the case that a lot of value can be delivered with reduced scope even though it doesn’t seem that way when you’re told that all three of them are fixed!
I’ve been reading quite a bit of lean related material lately but I thought it would be interesting to hear about it directly from the perspective of two people who have been involved with applying the concepts in organisations.
What did I learn?
- It was pointed out that lean thinking is particularly relevant at the moment with the global financial crisis requiring organisations to come up with more effective ways of operating with little cash at their disposal. Toyota of course derived the Toyota Production System when they were in big trouble and needed to find a way out of their own financial crisis in the 1950s.
- Lean is not just about manufacturing, it is being applied in many other industries as well. Paul pointed out that KMT are introducing it to the service side of many organisations. I think it is a different challenge introducing it into software development and while the Poppendiecks have written some excellent material on lean software development, there is still more for us to learn about how to do this successfully.
- Although I’ve read quite a bit of material about lean I’ve never been convinced with the normal definition that I hear of lean in that ‘it’s about reducing waste’ but I didn’t have a better definition until Jason came up with ‘it’s about engaging everyone to solve problems‘. It does still feel a bit generic but I like it better than the other definition.
- The most interesting part of the presentation for me was when Jason spoke about the different types of waste in lean in terms of software development:
- Extra features (Over Production)
- Delays (Wait and Queue) e.g. waiting for business sign off of stories
- Hand-Offs (Internal Transport) e.g. passing work onto someone else
- Re-learning (Over Processing) e.g. the same problems coming back when we have already previously learn about them. The first time we find a problem that counts as learning.
- Partially done work (Inventory) – e.g. work requiring late integration which hasn’t been done yet. At an extreme I think this could be taken to mean any work which isn’t in production since it is only when we put something into production that the value from it is realised.
- Task switching (Motion) – e.g. doing several projects at the same time. Here we end up with the problem that all of these projects are delivered late. Jason pointed out that just because people are busy doesn’t necessarily mean they are adding value.
- Unused Employee Creativity
The book ‘Learning to See‘ was suggested as a particularly useful one for learning how to identify waste.
- There was mention of set based concurrent engineering which Brad Cross has an excellent post about. The idea is that when there is doubt about the best solution to a problem we pursue several different options at the same time before deciding on the best option at the last responsible moment.
- Jason spoke about the difference between authority focus and responsibility focus, the latter being a more lean approach where we focus on ‘What is the right thing to do?’ and ‘How can I help?’ rather than the far more common approach I have noticed of ‘Whose job is this?’ and ‘Not my problem’. If we can get the responsibility focus going then suddenly the working environment becomes much more pleasant. Related to this I quite liked Liz Keogh’s recent post where she talks about rephrasing the language we use when talking about problems to avoid the blame culture.
- Value streaming was also mentioned with relation to how our goal is to find added value for our customer and that most organisations only achieve around 20% of value added activity in their value streams. A comment which really stood out for me was how ‘no problem is a problem‘ in lean thinking. People like to hear good news and you can often be referred to as being negative when you point out problems. In lean we recognise there are going to be problems and get these raised and sorted out as soon as possible.