Archive for the ‘Lean’ Category

As I’ve been saying, we need to change a few things around and some oganisation  things are already happening.

But that will only work if the people involved change their daily habits and mentality. It is perfectly possible to work within a RUP organisation and still maintain silos of knowledge where each developer is an expert in an area and work stops if he or she is not around. And I am yet to see a projet methodology that ensures real quality, rather than documenatation indicating it. It is easy writing up a long test script and showing the results, but does that ensure the quality of the application? Andwhat about the architectural scalability, and maintainability?

These things can only be addressed by changing the way the people involved in the project work and think on a daily basis. The quality we are after only comes from people caring about what they do and catching any potential issues early.

So we’ve started to use some practices that have been around for a while.

  • Test driven development for all new development, and legecy apps where it is possible. We have an architecture that is stopping us though, it is about 57 years old and using EJB’s that are heaviliy reliant on the application servers EJB container, and we dont have a test harness.
  • Continuous integration. At the moment, since we have that ancient EJB solution  this only makes sure the compilation does not fail. But its a first step.
  • Code reviews, from now on we’ll be peer reviewing any new release, both to make sure we get a second pair of eyes on it to validate the solution (we’re still not pair programming) but also to spread the knowledge.
  • Quality metrics. A touchy subject, but if we can clean up the code and use checkstyle, code coverage, static code analysis, we can get rid of some low-level checks we’re doing manually, and also get warnigns if the code base is losing maintainability.
  • Automating functional tests. At the moment all testing is manual, but with a little effort, each manual test can be automated and in time a full suite can be developed and our testers can do some real testing.

We’ve also started some discussion forums and a more formal quarterly meeting where we can discuss what w can do better to ensure we’re not staying static.  Since we have a relatively low staff turnover, there are  few ideas coming in from other industries and companies so in order to evolve we need to continuously asses, evaluate and adapt. And read a lot of blogs to find out what others are doing, of course…

So hopefully, these efforts will lead to increased communication on the ‘shop floor’ and an increased attention to quality and detail. And once the codebase has gotten a bit better, some knowledge is shared and with some automation in place, things can start turning around a bit quicker.

But most importantly, we can stop wasting time on activities that are non value adding and start spending time commuinicating instead. By using tools and practices sensibly to assess we are building things right we can start building the right things.

And thats nothing a process can help us with.


Optimizing the whole

I read this blog post a while back and it struck me as having a lot af lean elements to it.
I see a lot of similarities between balancing throughput, latency and variance that Beck describes and the concepts of muri, mura and muda and how it is used here in this entry about the toyota production system.

Increasing throughput in the way that Beck suggests is one of the ways of reducing Muri, and Becks conclusion of this leading to reduced variance is in line with the Toyota experience (mura translates to unevennes, inconsistencies). When it comes to latency, this is one of the types of waste that is muda and lean software engineering theories is set to eliminate.  (I recommend attending Alistair Cockburns webinars or reading Corey Ladas or Karl Scotland on this )

An unbalaced approach to these three legs will have detrimental effects on the other two, and thus the main objective is to optimize the whole. Its not about getting the highest throughput in develoment or achieveing zero variance. Its about getting all three legs to balance as Beck points out and that is what eliminates waste which is key in the Toyota production system.

Thats just what I read into it, I might be reading too much into it..
But at the moment i am trying to set up automated builds, continuous integration and deployment in my workplace in order to reduce our variance ( in quality) and increase throughput (by getting rid of manual builds and releases).

I was always thinking of this as a step towards getting leaner, and this post was a great encouragement…