Mark Needham

Thoughts on Software Development

Archive for the ‘Lean’ tag

Agile: Slimming down stories

with one comment

On the project I’m currently working on we have several stories around writing the code that does various different calculations based on user input and then shows the results on the screen.

The original assumption on these stories was that we would be looking up the data of the business rules from a local database. The data would be copied across from a central database into that one for this project.

After some discussion about one of the stories, Christian pointed out that the only reason that we needed to have that data in the database was so that it would be configurable in production without having to make code changes and redeploy the application.

I’d been working with the assumption that these stories could only be considered done when the data was coming from the database but we’ve extracted the ‘configurability of data’ out into another story which the business can choose to prioritise if that’s more valuable than other features we’re working on.

It didn’t even occur to me that we could pull this type of thing out but it seems like a useful approach as part of our drive to deliver the core functionality of the application as quickly as possible.

If we then need to go back and put in the configurability of the data, the lookup of that data is all hidden behind an interface so we shouldn’t see too much pain by choosing to delay doing that.

Written by Mark Needham

April 14th, 2010 at 10:53 pm

Posted in Agile

Tagged with

Shu Ha Ri harmful?

without comments

I came across a blog post by Rachel Davies where she wonders whether the Shu-Ha-Ri approach to learning/teaching is actually harmful and I found Rachel’s thoughts around the teaching of principles and practices quite interesting.

Quoting Jeff Sutherland:

Only when you have mastered the basic practices are you allowed to improvise. And the last and most important – Before you have gained discipline, centering, and flexibility, you are a hazard to yourself and others.”

I’m uncomfortable with approaches that force students to follow agile practices without questioning. These approaches seem to violate the first value of the Agile Manifesto “Individuals and interactions over processes and tools.”

What I find interesting about this is that when I first started learning about agile I would read the principles and they would all make sense but I didn’t know what to do with that knowledge.

It was only after I’d used the practices frequently and in most cases taking the practices too far that I reached the stage where I could start asking questions that actually had any relevance.

For example Test Driven Development is one practice that I learnt and one of the principles which encourages this approach to coding is the need to get quick feedback on our work.

It would be quite easy to question whether we should test drive everything and you could quite correctly have the opinion that we shouldn’t use this approach for absolutely everything.

However, without spending some time following this practice that opinion wouldn’t be particularly useful because you would lack the experience that tells you which type of code we should or should not look to test first.

Having decided that TDD was the only approach to writing code I eventually got into situations where it didn’t seem to make sense to stick so rigidly to this practice and it was only then that the value of the underlying principle became clear to me.

I don’t think I was ever forced not to ask questions but I was just so concentrated on learning how to do the practices properly that I focused on that.

I often find that it’s useful to use practices too much until you cause yourself pain.

Martin Fowler has a nice graph which shows how people adopt meta programming when coding Ruby and I think this links quite closely to my experiences when learning a new practice.

For me at least this seems to be a necessary learning step before I eventually step back and think about the principle that originally led me to following that practice. I can then start using the practice again but in a more effective or intelligent way.

What I’ve described above is often the way that I learn new things but I’m sure that others’ experiences will vary so it’d be interesting to hear about other approaches too!

Written by Mark Needham

February 26th, 2010 at 11:53 pm

Posted in Lean

Tagged with

Set Based Concurrent Engineering: A simple example

with 6 comments

One of my favourite ideas that I came across while reading the Poppendieck’s Lean Software Development is set based concurrent engineering which encourages us to keep our options open with regards to the solution to a problem until we absolutely need to decide on an approach after which we probably can’t easily change that decision so we will most likely stick with it.

I like the idea but on the projects I’ve worked on we often seem to take a more point based approach – there will be some discussion up front on the potential solutions to a problem and eventually one of them will be considered to be the best solution and we go and implement that one.

Last week we were doing more work on getting an authenticated user into our system and on this occasion we were trying to work out the best way to get some of the user’s details into our ‘Service’ base class so that we could send down the user’s SAML token with specific requests.

We identified two solutions to do this – inject the user into the Service through a constructor or inject it via a property.

A colleague and I were in favour of the constructor based approach since it results in us creating an object which has all its dependencies ready at creation.

Erik and another colleague favoured the introduction of setter injection in this case since we could just add that to the top level abstract class and avoid the problem that we would have with constructor injection whereby every sub class would need to have that constructor defined.

public abstract class Service
{
	public Service(User user)
	{
 
	}
}
 
public class SomeService : Service
{
	public SomeService(User user) : base(user) { }
	// every sub class of Service would need this constructor
}

We decided to try out both of these solutions concurrently for a time boxed period and then go with the one which looked like it was working out better.

While pursuing the constructor based approach we actually ran into a problem trying to resolve the services – it seems to be a bug in Unity Container version 1.2 which doesn’t allow you to use parameters in the constructor of a type which is being intercepted by a ‘VirtualMethodInterceptor’ which we are making use of for caching some service requests.

We spent a bit of time trying to debug this to work out what was going on but the code eventually fails when trying to emit some IL code.

I tried the latest version of the container out separately and it seemed to work correctly for the same situation so I think the bug has been fixed now.

By this time the time box was up and my other colleague had got further with the setter based approach than we had managed to get so we decided to go with that approach instead.

I think it was still an interesting approach to take as we learnt a bit more about how the container works and we got to see the trade off that we would be making if we used constructor injection between keeping our objects ‘pure’ and creating a lot of boiler plate code to create the constructor for each new service class – we went through about 30 classes putting the new constructor in!

Written by Mark Needham

September 19th, 2009 at 2:24 am

Lean: Big Picture over Local Optimisations

with 7 comments

I recently finished reading Lean Thinking and one of the things that was repeatedly emphasised is the need to look at the process as a whole rather than trying to optimise each part individually.

If we phrased this in a similar way to the Agile Manifesto it would probably read ‘Big Picture over Local Optimisations‘.

The examples in Lean Thinking tend to be more manufacturing focused but I think this idea can certainly be applied in thinking about software projects too.

Individual vs Team Focus

For me on a software development team what we care about is the quality of the team as a whole not the individuals on it.

It’s all good being very strong technically but you have to be able to work effectively with other people to solve problems otherwise your value to a development team is much reduced.

I wrote a bit about this previously in my lean look at pair programming but I think it goes beyond just ensuring that we are sharing knowledge around the team by having people collaborating closely with each other.

When I first joined ThoughtWorks my former colleague Fred George was always talking about the value of being poly skilled – having the ability to carry out more than one role – and I think this is lost when we refer to people as being their role i.e. ‘you ARE a developer’ rather than ‘you CAN PLAY the developer role’.

If we have people on a team who are polyskilled or generalising specialist (although I think generalising specialist refers more to poly skilled across a role rather than being able to carry out multiple roles) then we can get away with building teams which are smaller in number and which are more resilient and able to respond when team members are ill or absent.

Horizonal vs Vertical teams

Creating teams of people by the layer or horizontal which they work on rather than the piece of functionality or vertical which they are working on seems to be one of the most obvious ways of locally optimising instead of looking at the big picture i.e. the delivery of a piece of functionality to the business.

I guess the theory is that if we put everyone working on similar things on the same layer in the same team then it will result in greater productivity than having people who are working on different areas of the system but have the same underlying goals.

The problem is that we create a lot of handover points – opportunities for context and information to be lost – and the ineffectiveness of this approach as a communication mechanism means that it takes much longer to integrate the components from each horizontal than it would have done with a team with people from each layer in it.

In addition any techniques used to try and increase the productivity of an individual team will be ineffective since they will only satisfy a local optima and will have a knock on effect to the rest of the system.

For example, let’s say we have three teams A, B and C and team B aren’t as productive as we were expecting. Applying pressure to team B may have an impact on their immediate productivity but it’s likely to affect the other two teams since team B will probably be less communicative towards those teams since they are trying to optimise their own performance.

Having a vertical team which is responsible for the delivery of a feature or features end to end works much better from my experience.

Colocated vs Distributed teams

One of my favourite agile ideas is having a co-located team, with the business people, analysts and developers all working in the same physical location.

Sometimes though the decision is taken to distribute teams across multiple locations – be it because that’s more convenient or cheaper to do.

The big picture i.e. project delivery is likely to become more difficult to achieve due to the increased cost of communication that has been created.

For me there is nothing better than face to face communication – even with phone calls/instant messaging/emailing it is still an extremely valuable form of communication. With any of the other three it’s much more difficult to read what someone is really thinking and you can come across as being much more aggressive than you intended to in any of those mediums.

My colleagues in India/China will certainly have some tools/techniques to bridge these gaps that I’m not aware of but I still remain convinced that if we have the choice then a co-located team is the best choice.

In Summary

These are just some of the ideas that came to mind when trying to apply one of the principles of lean to software development teams. Although many of these may seem obvious sometimes it takes another angle of looking at the problem to make that visible.

If you can think of any others feel free to mention them in the comments.

Written by Mark Needham

April 14th, 2009 at 10:10 pm

Posted in Agile,Lean

Tagged with

QTB: Lean Times Require Lean Thinking

with 4 comments

I went to watch the latest ThoughtWorks Quarterly Technology Briefing on Tuesday, which was presented by my colleague Jason Yip and Paul Heaton, titled ‘Lean Times Require Lean Thinking

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.
    • Defects
    • 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.

Written by Mark Needham

March 25th, 2009 at 12:36 am

Posted in OOP,QTB,Software Development

Tagged with , ,

Lean Thinking: Book Review

with 2 comments

The Book

Lean Thinking by James P. Womack and Daniel T. Jones

The Review

This is the latest book in my lean learning after The Toyota Way, Taiichi Ohno’s Workplace Management and Lean Software Development and seemed like the most logical one to read next as it came at lean from a slightly different angle.

I found this the most hard going of the books I’ve read on the subject so far.

What did I learn?

  • The underlying themes the book points out for successfully getting an organisation to adopt a lean approach is that we must have a change agent, lean knowledge and a lever for change. Interestingly that lever for change can often be a recession when a firm needs to make changes in order to survive – when times are good there is no need to change so it’s easier to just keep the status quo.
  • My favourite quote from the book is the following which talks about the mindset needed for lean thinking:

    Create a mindset in which temporary failure in pursuit of the right goal is acceptable but no amount of improvement is ever enough.

    I like this because too often the human instinct is to take the risk free approach where we are afraid of failure and therefore miss opportunities to get better. The lean approach allows us to get past this in pursuit of a greater goal.

  • One idea which really resonated with me as someone working in the industry was how Pratt & Whitney had to get past the managerial attitude of “ship on time and you’ll be fine [even if you’re shipping junk]” in order to make improvements. Often with software projects I have found that there appears to be a real focus on the data of promised delivery even though it would be beneficial to ship a bit later and ensure greater quality. Often there is no actual loss (except loss of face) from doing this either.
  • Co-locating teams is a constant thread throughout the book and I’ve found this to be an important factor in successfully delivering software as well. The author also talks about the need to look at the cost across the whole life cycle of the product rather than just the cheaper production cost of offshoring operations. Around the time I read this chapter I was drinking some Ribena which said on the label that the blackcurrants were picked in New Zealand, the drink bottled in China and I was drinking it in Australia. There were quite a lot of transportation costs involved in the life cycle of that drink! In software it is the cost of communication rather than transportation that we need to consider when deciding to spread a team across different locations.
  • The idea of takt time stood out for me – the idea here is to only produce at the rate at which the product is being demanded. This means that sales people shouldn’t go trying to create spikes in demand which I think is quite different to the way that typical organisations operate. Software wise I suppose this would be about delivering at the pace at which the customer needs the functionality and trying to release regularly so there aren’t spikes in the requirements.
  • In the Wiremold case study the idea of reducing the suppliers so that there are less integration points in the whole process is described. In software having less moving parts certainly makes it easier for us to go faster.
  • An interesting thing that is pointed out is that in all the firms case studied there are never any layoffs directly linked to lean improvements. This despite the fact that a lot less people will be needed once the process has been improved. It is pointed out that if people lose their jobs from lean then they’re going to do their best to sabotage it. The importance of everyone being involved in the continuous improvement is also emphasised. There are endless steps of improvement, we are never done.
  • The importance of having a standard language when talking about lean is emphasised, helping ensure that everyone is talking about the same things. I think the idea is fairly similar to that of the ubiquitous language from Domain Driven Design.
  • One of the wishes of the author is to create lean enterprises where lean thinking is applied all along the value stream from the raw materials all the way to the customer. The difficulty of getting all the firms to work together to allow this to happen is described but I can’t really see how this is going to happen for the time being.

In Summary

I found this book very heavy reading – it’s taken me almost three months to complete it! The stories hold good lessons but I found The Toyota Way to be a much easier read.

Written by Mark Needham

March 21st, 2009 at 10:36 am

Posted in Books

Tagged with

Lean Software Development: Book Review

with 3 comments

The Book

Lean Software Development by Mary and Tom Poppendieck

The Review

I’m keen to learn how the ideas from The Toyota Way can be applied to software development and as far as I know this is the first book which addressed this, hence the reason for me reading it.

What did I learn?

  • I found the idea of financial based decisions particularly interesting – I’ve often had situations when developing software where there are trade offs to make and it would have been much easier to make them if we had a dollar value associated with each potential solution. I’m not sure how willing the business would be to expose this information to the development team though.
  • There is mention of setting up incentives at one level higher than you would normally expect – Nicor is cited as an example of a company which does this. For example, a plant manager would be incentivised based on the performance of all the plants rather than just his plant. The thinking here is to try and get everyone thinking about the bigger picture. I’m not convinced that financial incentives work particularly effectively for motivating people to achieve goals although several colleagues disagree with me in this regard. For me making sure that everyone believes in the project and its goals is more important.
  • The role of the master developer is recognised as being key for ensuring the success of development teams. I’m not sure if this role maps directly with that of a Technical Lead, to me it seems to cover more responsibilities on the business side than a Tech Lead would typically have. It doesn’t seem to quite describe the Software Craftsmanship idea of a Master either. Toyota’s idea of a Chief Engineer most closely describes a role which sounds like that of the master developer.
  • There is a lot of emphasis placed on concurrent engineering – taking a breadth first approach to development over a depth first one. This would involve spiking lots of different ideas before working out which one is the most appropriate. While I have done this on agile projects, the way it is described in the book suggests considering even more options for longer periods of time. The key is to ensure collaboration with the customer and to design change tolerant systems.
  • The way to ensure systems are tolerant to change is to keep things which change together – in the same layer or module for example. Creating code which has high cohesion and separation makes change easy when it eventually needs to happen.
  • I liked the idea of considering development as a cycle of experiments with a test at the end of each cycle. As is pointed out, we are going to test our code anyway so it makes sense to capture the test so that we can reuse it. When written well tests can be very useful as documentation but as Jimmy Bogard points out, there are some important steps that we need to follow to ensure that our tests achieve this goal.
  • I found the reasoning around why we try to maintain a sustainable pace quite interesting. It mostly focused around the need to maintain some slack in the system so that if emergencies come up then we are able to respond to these. This would clearly not be the case if we already had our team working flat out. This seems to me to also be a case of non optimising locally at the expense of the whole system.
  • The ideas around product integrity were new to me but quite intriguing – perceived integrity is about the value of a product in the mind of the customer, while conceptual integrity is about ensuring that different parts of the system work together in a consistent way. The Chief Engineer/Master Developer would probably spend a lot of time ensuring this actually happens.
  • Towards the end of the book the authors talk about systems thinking and how we need to ensure that we solve the right problem correctly otherwise we will just end up creating even more problems. Reading this reminded me a lot of The Logic of Failure which talks of the difficulties humans have envisaging the effects of the actions they take will have on the world. The 5 Whys was suggested as a way to get to the root cause of a problem rather than focusing on the symptoms.
  • I like the ideas around not locally optimising systems by trying to allocate defects to individual developers for example. In this case we should look to create information measurements rather than performance measurements. I am still intrigued as to whether there are any types of measurements that we can use to evaluate the performance of developers but at the moment I’m not convinced that there are.
  • My favourite quote came from the last chapter of the book which described instructions for using the material contained within the book. ‘Think Big, Act Small, Fail Fast, Learn Rapidly‘ – a good motto to follow I think.

In Summary

Reading this book has helped provide some more relevant examples of how to apply lean thinking in my work. I think there is quite a lot of overlap between the ideas in the agile and lean worlds in that both are trying to achieve a software development process which results in an end product that the customer actually wants.

I am keen to see how the authors suggest introducing some of these ideas in Implementing Lean Software Development.

Written by Mark Needham

December 20th, 2008 at 5:29 pm

Posted in Books

Tagged with ,

Taiichi Ohno’s Workplace Management: Book Review

without comments

The Book

Taiichi Ohno’s Workplace Management by Taiichi Ohno

The Review

Having completed The Toyota Way a few weeks ago I was speaking with Jason about what books were good to read next – he recommended this one and The Toyota Way Fieldbook.

I struggled to see a connection to software development with a lot of what I read, but there were certainly words of wisdom that we can apply to continuously improve our ability to deliver projects.

What did I learn

  • Just in Time doesn’t mean exactly when the raw material is needed – it means just before it’s needed. This concept can certainly be applied in an agile software development process to ensure that story cards don’t spend too long in any column before moving to the next one. The reasoning in our case being that the knowledge behind the analysis/development of them is at its greatest just when the card has completed that stage.
  • If you make defects you have not worked – this is related to the idea of building quality into the process. You are not adding value if the work that you produce has defects in it. This is quite an interesting contrast to the more typical ‘hours worked’ approach whereby the productivity in these hours is not considered to be that important.
  • The job of team leaders is to make life on the gemba (i.e. shop floor) better. This has some similarities with the Tech Lead role on software projects where the person playing that role will spend a lot of their time reflecting on the development process and looking for ways to make it work better. This can be through driving pair rotation on a team, running analytics on the code to find areas of weakness, helping t setup test frameworks etc. Reflection on these types of things is the only way to drive improvement.
  • Stop defects moving through the system – this is achieved in agile by having story kickoffs and walkthroughs, the former to ensure that everyone is clear what is expected of a story and the latter to ensure that those criteria have been met. Catching defects early makes them much easier to fix since the story is still freshly in the head of the developers that worked on it.
  • Stop the line for defects – the idea here is to prevent defects from moving through the system, similar to the above point. In this case I’d have thought it’s more similar to not wanting code to be checked in on a red build so that the problems can be fixed before the line continues so to speak. It does seem a bit over the top to stop people checking in just because the build is red though, a better strategy perhaps being a team discipline to not check in when this is the case.
  • Don’t automate for the sake of it – look for manual improvements in the process before deciding to automate something. I think this is quite interesting as automating processes in software development is not as costly as it would be on a production floor. One area where maybe there is more debate is automated acceptance testing using UI driven tests. These can often take ages to run as part of the build when there may in fact be better (also probably automated) ways of testing the same functionality. In this case perhaps recognising that there are options when it comes to automating is the key take away.
  • There were several mentions of standardising the approach which is probably more applicable to manufacturing than software development, although there are certainly areas, such as debugging, where a standardised approach would probably be more effective.

In Summary

This book is fairly short but it acts as a nice contrast to The Toyota Way and presents similar information in a slightly different way.

Written by Mark Needham

December 9th, 2008 at 12:14 am

Posted in Books

Tagged with , ,

Dave Thomas on Managing Lean and Agile In Large Software Development

with one comment

No coding dojo update this week as Dave Thomas was in the ThoughtWorks Sydney office to talk about Managing Lean and Agile in Large Software Development.

It was actually a talk to the Geek Girls Sydney group but I sneaked in to hear his other talk after listening to the cloud computing one last week.

It was a much toned down presentation compared to the cloud computing one although still amusing in places. These were the parts I found most interesting:

  • If you’re using Selenium to test your application then you’re being lazy – he suggested that we need to define an API to make our application testable without having to go from the UI. I’m not sure where Javascript testing would fit into this – perhaps using a Javascript unit testing framework would be preferable. We had a similar discussion about acceptance testing at the Alt.NET conference in London earlier this year. I think there is still value in using Selenium to at least test the happy path cases of our application, with edge cases being tested further down.
  • I’ve never worked on a 5,000 person project but it felt to me like a lot of the ways to make this work were very waterfall-esque in nature. He spoke of Architecture Driven Development which sounded like it was drifting towards being big up front design although with a team this large clearly quite a bit of architecture up front is going to be needed to allow progression. My (perhaps naive) question is why do we need a team with 5,000 people in it?
  • He spoke about Planning Poker as a way to get more accurate estimates for stories – I think he suggested a 30% improvement could be gained by doing this. Fabio and Jason previously wrote about their experiences of using this technique on their projects. Other ideas around estimation included having a best – worst – likely case and that’s not possible then at least a best – worst case. This is something we have done on a couple of my recent projects and it works reasonably well in helping to identify potentially risks.
  • One of the questions asked at the end queried the value of test driven development. Dave’s response spoke about testing soon rather than first and he said he wasn’t a fan of testing trivial things like accessors. I wonder what exactly is considered trivial beyond that though – I have often written code which seemed like it would be trivial and I still made mistakes which wouldn’t have been caught if I hadn’t written the test first. He also spoke of an Object Mentor competition they sometimes hold whereby you present your ‘untestable’ code and if the Object Mentor guys can’t show you how to test it then they’ll buy you dinner.
  • He spoke about needing to perform a lean transformation on an organisation before attempting to introduce agile practices. The idea being that you cannot change productivity and quality alone, XP/Scrum are not enough. This obviously is following the organisational transformation approach to change which has heavy backing from people at the top of organisations. From my experience, we tend to take the other approach of introducing agile at the project level and showing the improved productivity we can achieve by using this approach. Clearly not on the same scale as Dave Thomas and co. though!
  • It was interesting that the most important and therefore first thing that he considered vital to successful delivery is having a continuous build server. Without this you can’t build quality into the application as well as the fact that you never know if it actually works or not.
  • He spoke of the idea of considering areas of organisations that we cannot change as being an API – you can’t step across that boundary, you just have to live with it. He gave the example of systems that our application may depend on – we can’t influence how they choose to develop their code but we can provide acceptance tests that they must pass. How these are passed is not up to us.

Another interesting talk although I think I enjoyed the cloud one more.

Written by Mark Needham

December 5th, 2008 at 12:00 am

Posted in Software Development

Tagged with , ,

Agile/Lean: All or Nothing?

with 2 comments

While reading The Toyota Way one of the ideas which stood out for me was the constant mentioning of organisations which picked bits of The Toyota Way, implemented them, achieved some short term gains but then eventually these improvements and went back to the way they were before.

I noticed a similar theme coming out in the series of posts in the last week or so about the decline of agile.

I have worked on several projects over the last couple of years with varying levels of agile being applied. I am aware that agile is considered to be something that you are rather than that you do but for this post agile refers to agile principles and practices.

I have noticed that it is much easier to get working software out the door when we follow these principles and practices but becomes way more difficult as soon as we are unable to follow some of them.

This is a similar idea to one I noticed in The Toyota Way:

Early on in the book the TPS House was mentioned – the idea being that everything must be strong from the use of the tools to the belief in the philosophy. It seemed to me from reading this that applying Toyota’s ideas successfully is an all or nothing game – i.e. it would be very difficult to be successful in the long term by just picking and choosing certain ideas without having the other ones to support them.

One of the common misunderstandings about agile is that writing tests makes us move more slowly and that removing them will allow us to go more quickly. While this may be true in the short term it eventually catches up with us and we can look forward to long sessions with the debugger trying to work out why the code isn’t working as we expected.

A couple of months ago I was considering whether there are any agile practices which are absolutely key to ensuring success. I ran this idea by several colleagues who all pointed out that it was the principles that were absolutely key and not necessarily the practices which are derived from them.

I believe we can therefore make a link between the practices and principles of agile, such that if we don’t believe in thoroughly testing our code, for example, then we are not adhering to the principle of delivering working software or paying continuous attention to technical excellence.

Having said that I have also worked on projects where delivering frequently was not something which the business considered beneficial and we only delivered software at the end of the project. We did take the time to carry out practice deployments more frequently than that to ensure we knew the deployment process but there was no actual deliverable until right at the end, and despite not completely adhering to this principle we were still able to successfully deliver.

As Jeremy Miller points out in his response to the original post:

In the early days, XP was roundly criticized because every practice only seemed to be safe due to the existence of the other practices. Take one out, and the others weren’t that great by themselves. I think that’s more or less a fair criticism, but my response is simply to adopt, and effectively apply, everything you need to make Agile development successful.

Life is made much easier if everyone involved into the project buys into the agile or lean approach but even if they don’t it is still possible to find ways to succeed, it just might be a bit more difficult.

Written by Mark Needham

November 26th, 2008 at 6:29 am

Posted in Agile

Tagged with ,