I’ve just started using the beta of the Netbeans 7 IDE. There are a few sharp new little features in there. The HTML5 support is much needed, but a nice one I’ve just found is the ability to launch a Terminal window (in Linux and on OSX). Just go to Window > Output > Terminal.
I was looking at my old big fat iPod last night, and was mulling over just what to do with it. Under Ubuntu, I can actually charge it, and then get to listen to the disk drive failing loudly. So it is definitely gone. I was hoping against hope I could maybe use it as a large portable drive, but it is too flaky for even that.
So what do I do with it? Should I bin it? Find a way to recycle it? Use it for a form of art? I’m lost for ideas, so any suggestions would be gratefully received.
Today I read a very helpful article, exploring Google’s hidden features. I particularly liked the shortcut to look up film times very quickly. However it doesn’t describe quite how to do it for the UK. So, to find your local cinema times for a film, type in “movies borat ox1”, replacing borat with the name of the film you want, and ox1 with whatever the first part of your postcode is. The first results will be the local cinemas and the times it is showing. If you are signed into Google, it will also offer to remember the postcode for you, so that in future you can just type “movies borat”.
Why is it useful to us? Because it is reflected in many Agile processes and ideologies.
14 Management Principles, split into 4 categories:
- People and Partners
- Problem-solving and Organizational Learning
The right process will lead to the right results.
Work has to continuously flow
MUDA – The continuous quest to find waste
Forms of muda in flow – Waiting. Transportation. Movement. Defects.
The quicker you expose muda, the quicker you can solve those problems.
Agile mirrors this: Little stories, short iterations expose little problems, little issues quickly. Flow in production can increase cashflow. So does Agile, in allowing you to create sellable product quickly.
Each step delivers at the rate that the next step can take it. Every 55 seconds a Toyota is sold. So, a Toyota rolls off the production line every 55 seconds. This is their manufacturing rhythm.
Forms of muda in production – Overproduction. Inventory.
Solved by the Just in Time nature of their production, on a part and full product basis.
Agile mirrors this: Just enough requirements to make a working product in each iteration.
Work at a steady pace. Be the tortoise not the hare.
Forms of muda in Heijunka: Muri (Overburden)
Overburdening breaks both people and machines. Find the right pace.
Toyota finalises its production schedule one day ahead. The majority is known beforehand, but the final figures go in the day before. All production lines are flexible, capable of building all models.
Agile mirrors this: Small stories. Flexible teams.
Jidoka – Automation
Use of intelligent machines. Machines help in indicating problems.
Also, use of intelligence. Everyone is responsible for quality, anyone can stop production line in order to fix problems. Higher quality, less waste. Don’t carry on producing defective products, stop, fix, then carry on.
Agile mirrors this: Automated testing. Programmers taking responsibility.
Tell people exactly how to do it. This is actually empowering. If you know exactly how you are expected to do your job, you can get on and do it, but also have more time to think about how to improve how you do the task.
Forms of muda in Standardized Tasks: Unused employee creativity.
Each production line makes around 1000 changes to how they do things each year.
Discipline is important. Hard and fast way of working. The automation does help to make this easier though.
Agile mirrors this: More input from the developers and the users throughout the project. Make just enough to start work quickly in a basic form. Both then suggest improvements as they work on or with the product.
Problems should be apparent to all, with information.
When the production line stops, different (soothing!) music plays depending on which part of the line has caused the stoppage. This then informs all the other sections as to how long it will be before it affects them. They will know if, say, it is two sections away from them, it will be 15 minutes before they stop getting the parts from the previous step. Also termed as Ardon indicators (from traditional coloured lamps).
Agile mirrors this: Indicators of success and failure in running automated tasks, green good, red bad. Also standups, the state of the stories give good indications of exactly where the project is up to, where something might be broken. If someone is having an issue with their story, you may have been planning on using their functionality in a days time. You can adapt to this, know the point at which your own production will now stop.
New machines are a higher risk than used ones. They know how well a used machine works, what will break it, what it does. Time must be spent researching the new, but they must not be implemented until they are known and trusted.
“It is never a people problem, it is always a process problem”.
People and Partners
Leaders – Sensei. Someone working and leading by example. In Toyota, a leader is always teaching two people to succeed them when they leave.
Agile mirrors this: Well sort of, it does have the concept of coaching, but it doesn’t really take it to the same level of building into its design that a coach should aim to teach the person to replace them directly.
Develop Exceptional People
There is presently an issue in Toyota where they are growing fast than they can grow leaders.
They believe in continuous training, which is also verified and tested afterwards. Much of their training is on the job itself, to ensure that it is learnt and applied quickly. One of their methods is to sometimes give a new starter an impossible task, to teach them their first and most important lesson, that of asking for help when they need it.
Challenge, Respect, Help Partners
Partners working with Toyota must perform at the same level as Toyota. 70% of a Toyota car is built externally.
Obeta — Integrate Partners, teach them the ways. For instance for Just in Time to work, their partners must supply at the appropriate speed.
Agile mirrors this: These are helpful practices that fit well into an Agile way.
Problem Solving and Learning Organisations
“If you want to know what is happening, go to where it is happening”. Manager should be on the shop floor, not in their office.
Look at the process directly, see it in action, see the problems for themselves.
Value Stream Mapping: Where are you adding value? Where do you create waste?
Hourensou – A process for staff:
- Hou Kaku – Report
- Ren Raku – Inform
- Sou Dan – Consult
Agile mirrors this: Daily standup meeting, keeps the leader a lot closer to all of the project.
Nemawashi – Gently dig around the roots of a plant, in order to transplant it carefully
Decision by consensus. Can take time to achieve, but once you have everyone’s buy-in to a decision, you can implement it much more rapidly and effectively than if you had dictated a change. Resistance to change can slow implementation. Delay commitment until the right time (set-based design). Keep your options open as long as possible. Integrate often, to see if that changes your views of the available options you have yet to commit to.
Agile mirrors this: Iteration, Integration, planning meetings.
Hansei & Kaizen
Reflection on what happens to improve & continuous improvement of self.
With any failure, ask 5 whys to get to the root of the problem.
Allows you to arrive at Poka-Yoka – a state of being mistake-proof.
Agile mirrors this: To some extent, but within the stated boundaries of the methodologies, Hansei & Kaizen are greater that what is available through agile. Obviously, be pragmatic, use elements of them to improve your agile methodologies.
Long Term Philosophy (deliberate leaving of the first until last, to reflect its importance).
- Value for customers/society/economy
- Decide own fate
- Accept responsibility for own conduct
- Maintain and improve skills to add value
It takes 5-10 years for a new factory to be running The Toyota Way properly. It takes patience. Agile mirrors this: Agile can be implemented very quickly, as a set of practices, but it takes longer for it to be understood and accepted, and it is when this happens that it will run more effectively.
So what did I think?
Pascal talks on his blog about how he had found it hard to capture all the necessary detail about the Toyota Way into a 60 minute talk. I thought it was a fantastic introduction to an often-mentioned, but rarely explained methodology. I liked how well he linked it into Agile, and pointed out where there was similar fit, where there was room for improvement.
I think there is more scope for understanding the similarities that a production line run in this way can have to a well-running Agile team. For instance, if you used continuous build systems, and you hit a set of errors, should someone press the button to stop development, and have the team work to fix it? I don’t know, but I would like to see if it could be an effective method of working.
Overall, I think it would be very hard for anyone not to get something useful out of this talk, and many will have got a lot. Simon at his Agile in Action blog seems to share my enthusiasm for it.
I’ve just started using Dean’s FCK WordPress plugin on this blog. I really am not a fan of the standard WYSIWYG WordPress editor, it is really flakey, and not very intuitive. The FCK editor is a bit more comprehensive, and as it happens, I am also more used to it, as it is in the Infoglue CMS which we use at work.
Thus far, looks a lot better, and editing HTML is a lot nicer as well. Will report later after I’ve used it for a while, but so far very happy with it.
During an onerous task today, I think I learnt a valuable lesson in choosing an appropriate software package. We’re moving from a Blosjom-based blog to a WordPress one. Now I’m happy with this change, seeing as this past year I’ve spent so much of my own time using WordPress. The issue we had was moving the content. WordPress supports importing from a lot of different blogging platforms. Blosjom is not directly supported, however WordPress does offer import from an RSS feed, so we were able to import the posts in the main.
However, the comments were unavailable in feed form. So it fell to me to sort this out, and after thinking through some options, the low volume of comments meant that the best way to do this was to just re-enter them into WordPress, and then edit the post dates for accuracy. This was straightforward, but took some times still.
And this was where I starting pondering. We used Blosjom for a year or so, and whilst it was the right choice for us at the time, did we consider what might happen if we wanted to migrate from it? A year on, it still doesn’t have a large user base (to be fair, being Java-based, it wasn’t likely to compete with the PHP/MySQL-style platforms, and being Java-based was one of our requirements at the time). Would we have chosen it if we had considered how easy it would be to leave it?
It happens all the time, with software, with websites, with hardware. Your requirements change, better competitors come along, brand new technology launches. In an ideal world you make your choice and stick with it, but sometimes you are wrong, and other times you are right until a better thing comes along. Something worth bearing in mind as you chose in the first place is what might happen if you wish to leave. Do the competitors for your database of choice support conversion to their software? Can you import your e-mail contacts from the webmail you want to use into Yahoo Mail, should they suddenly become the bees knees? Is your forum software built on the same base as the majority of its competition, or is it using something obscure? Obviously it is hard to consider every variation, but migration away is well worth considering when you make a choice.