From Boing Boing, some links to some fantastic cartoons
Xeni Jardin:
Cityrag has compiled video links for a list of The 50 Greatest Cartoons as voted on by the animation industry in 1994. Here's an excerpt:
1. What's Opera, Doc? (1957)
2. Duck Amuck (1953)
3. The Band Concert (1935)
4. Duck Dodgers in the 24½th Century (1953)5. One Froggy Evening (1956)
The complete list is here, and it's absolutely awesome: Link.
I’m finding myself increasingly troubled about the way in which the investigation of the multiple murders in Ipswich is progressing. Not in terms of what the police are doing, but the way in which the media is leading its own investigation in parallel, and in public. Yesterday a man was arrested. He has been questioned four times already, but he had been interviewed by a couple of journalists over the weekend, and those interviews were published on Sunday and Monday. Now it isn’t clear how they got to him, whether they got a tip from a friendly copper, or if they had tracked him down, or whatever. It is the way in which those interviews are seemingly being used to convict him before any further evidence appears.
The police don’t interview suspects in depth in the middle of the street, with a crowd of people around them. They do it in private, two of them, and usually a solicitor acting for the suspect. They do so in order to arrive at a more reasoned theory as to the guilt or otherwise of a person. They don’t have lots of people shouting “ooohhhhh, he looks very dodgy”.
The gentleman in question is still being questioned. A second man has just been arrested. Should the first man stand trial though, having had his name and image splashed front page all over, his interview played on news tv constantly, and his myspace account passed around, it could potentially be easy to call into question if he could receive a fair trial. And that would only be the fault of the media. Regardless of his actual guilt either way, the media could end up judging, convicting, and releasing him themselves.
Possibly one of my most surreal moments in a shop ever came this weekend, when I got a 20% discount for having a beard in Borders. I knew there was a good reason I hadn’t got round to shaving for a bit.
Playing a lot of Phantasy Star Universe at the moment. It is wonderful. Not the best graphics, not always straightforwards. Just so much depth, and some of the best multi-player gaming you will have. This weekend we’ve just started to tip over from our team being out of their depth in all but the easiest levels, to having a bit more skill and some things starting to get easier. We beat our first serious boss in an epic fight that involved most of us lying dead for a significant amount of time, whilst one person fought on valiantly and took us to victory.
Overall, I am really enjoying the 360, it has reawoken my interest in gaming. Not that it had fallen away completely, but I was getting a bit bored. I’ve now got some games with significant depth, but also a selection of light games on Xbox Arcade that make for great quick blasts. I also love the achievements concept, which awards points for completing certain things within each game. I’ve now just made it past the 1000 mark, which represents quite a bit of gaming, and gets me halfway roughly to catching up my brother-in-law, who has had his 360 a little while longer.
These notes are taken from the above talk on 28th November 2006, given by James Noble and Robert Biddle. Pretty much free-form soundbites, which was the manner of the talk in some ways.
We now best now. Order is best. Modern is best. Perfection – Repetition – Iteration.
BUT Why do the robots lose to the humans? (There was a brief Kraftwerk tribute around this point).
“We did it right, but the customer didn’t get what they wanted”. A technical success, but a business failure.
The fault lies with us, not the customer. Like Narcissus, we fell in love with our own image, our technologies, our methods, our knowledge. We couldn’t bring ourselves to look to them, so glorious are we.
In the postmodern age, Agile is Love. The danger is that it becomes self-love, in whatever sense you wish to read that.
Acceptance means more than just passing tests. Agile does have human tests. Planning Games, User Stories, System Metaphor, the On-site Customer. However these are in danger of being overridden by our love of the more empirical, definable, understandable. Automaton, tests, only looking to see the green bar of success for our tests which we have written.
New ideas too! One day iterations! Whole team (no customers)! Executable user stories! Automated acceptance! 80 hour week! 3 Month Crisis! Career Change Counselling! All in action, all inaction, too automated, not human.
The Modern Language of Love – points to Shannon’s model of communication. That communication is information being transferred from the lips to the ear.
The Post-modern Language of Love – we’ve learnt to how to communicate from developer to developer. The information isn’t always getting delivered to its final destination. The job of translation is a trial and error process, almost akin to bartering. Ideally, recourse to a grand narrative should be forbidden, small narrative is a far better form. Our tools should aid the translation between developer and user.
We should meet each others needs:
The customer knows business and wants software. The developer knows software and wants business. It can be a beneficial relationship. The customer also holds a lot more knowledge than we sometimes recognise, sometimes ignore in the appreciation of our own reflection.
If you do not love your customer, you are not doing Agile.
So what did I think?
I’ve read colleagues and other blogger’s views on this keynote speech, and going on those and other views I heard on the day, it would be fair to say it got a mixed reaction. The presentation style was loud, and disorientating. If you’ve read any of the Head-First & Head-Rush books by O’Reilly, well it was a bit like someone reading one of those and all the sidebars and speech bubbles at once. Repetition and reinforcement of their points through a variety of means. It was interesting they used Shannon’s model for communication, as it also indicates that the main barrier to verbal communication is noise. I think this was the case in getting their message across to everyone in the room.
I’m interested in how they are identifying some of the pitfalls and problems of modern development, and applying methods of literary criticism to analyse approaches such as Agile and XP. It shouldn’t just be technical and project management views driving how these methods develop, in order to achieve their goals of providing the right product effectively, they need to ensure they are keeping the knowledge of the customer involved, and that they are being sense-checked in a wider sense.
These notes are taken from the above talk on 28th November 2006, given by James Noble and Robert Biddle. Pretty much free-form soundbites, which was the manner of the talk in some ways.
We now best now. Order is best. Modern is best. Perfection – Repetition – Iteration.
BUT Why do the robots lose to the humans? (There was a brief Kraftwerk tribute around this point).
“We did it right, but the customer didn’t get what they wanted”. A technical success, but a business failure.
The fault lies with us, not the customer. Like Narcissus, we fell in love with our own image, our technologies, our methods, our knowledge. We couldn’t bring ourselves to look to them, so glorious are we.
In the postmodern age, Agile is Love. The danger is that it becomes self-love, in whatever sense you wish to read that.
Acceptance means more than just passing tests. Agile does have human tests. Planning Games, User Stories, System Metaphor, the On-site Customer. However these are in danger of being overridden by our love of the more empirical, definable, understandable. Automaton, tests, only looking to see the green bar of success for our tests which we have written.
New ideas too! One day iterations! Whole team (no customers)! Executable user stories! Automated acceptance! 80 hour week! 3 Month Crisis! Career Change Counselling! All in action, all inaction, too automated, not human.
The Modern Language of Love – points to Shannon’s model of communication. That communication is information being transferred from the lips to the ear.
The Post-modern Language of Love – we’ve learnt to how to communicate from developer to developer. The information isn’t always getting delivered to its final destination. The job of translation is a trial and error process, almost akin to bartering. Ideally, recourse to a grand narrative should be forbidden, small narrative is a far better form. Our tools should aid the translation between developer and user.
We should meet each others needs:
The customer knows business and wants software. The developer knows software and wants business. It can be a beneficial relationship. The customer also holds a lot more knowledge than we sometimes recognise, sometimes ignore in the appreciation of our own reflection.
If you do not love your customer, you are not doing Agile.
So what did I think?
I’ve read colleagues and other blogger’s views on this keynote speech, and going on those and other views I heard on the day, it would be fair to say it got a mixed reaction. The presentation style was loud, and disorientating. If you’ve read any of the Head-First & Head-Rush books by O’Reilly, well it was a bit like someone reading one of those and all the sidebars and speech bubbles at once. Repetition and reinforcement of their points through a variety of means. It was interesting they used Shannon’s model for communication, as it also indicates that the main barrier to verbal communication is noise. I think this was the case in getting their message across to everyone in the room.
I’m interested in how they are identifying some of the pitfalls and problems of modern development, and applying methods of literary criticism to analyse approaches such as Agile and XP. It shouldn’t just be technical and project management views driving how these methods develop, in order to achieve their goals of providing the right product effectively, they need to ensure they are keeping the knowledge of the customer involved, and that they are being sense-checked in a wider sense.
What follows are my notes on the XP Day talk given by Joseph Pelrine, on Tuesday 28th November 2006.
Scrum is nothing to do with software, it is to do with managing work.
In any project, requirements, technology & people are all changeable, all come with uncertainty. Scrum can manage and prioritise this complex domain. Joseph pointed to several non-software projects he had managed with Scrum, including his wedding (which was indeed delivered on time and within budget).
The waterfall method assumes requirements do not change during the project, encouraging a tendency to stuff in everything in one go, all at top priority. Scrum looks to not wait for all the requirements, but instead to look to deliver with what is known now.
Waterfall can actually work in manufacturing, you do know your end product, you know what is an acceptable level of waste (although if you look at the Toyota Method of Production you may well see this is not necessarily the best way). When you can’t can’t define things enough so that they run unattended and produce acceptable output, then control is through constant inspection and adjustment. The comparison Joseph made of these two ways was that of the flightplan made by an aircraft, compared to the way in which a large flock of migrating birds move. Apply, inspect, adapt.
Building the Scrum process
Start with a product planning meeting. Plan just enough to drive the first developer sprint to deliver product increment that provides business value. Requirements will emerge as the customer sees product increments. Refactoring of the design and product will cause the system and product architecture to emerge.
Scrum Master
They are responsible for establishing Scrum Practices. They act as a gobetween for management and the development team, and also a coach. A Scrum Master is the agile equivalent of an IT Project Manager. They should be outside of the team, although if the team is too small, the pragmatic approach is to adapt the role to suit.
Daily Scrum Meeting
This ideally should be no more than 15 minutes long, taking place in the same location every day. The aim is that everyone attending answers 3 questions:
What did you do since the last scrum?
What will you do before the next scrum?
Is there anything in your way which will help you achieve what you want to do before the next?
It is the Scrum master’s job to note and then sort any of the impediments raised in the meeting.
Scrum Teams
They are self-organised, with no roles. Responsible for committing to work, and with the authority to do whatever is needed to meet commitment. Almost like the “total footballers” of development. The ideal size is reckoned to be 5-9 people, not too big, not too small.
Product Backlog
This is a list of functionality and technology issues, maintained by the product owner. If there are multiple teams, there should still be only one list. Anyone can contribute to it, be it is the product owner who is responsible for defining what is going to be done, and when. Their decisions in terms of timing come down to their defining if it will be in this sprint, if it may be in the next, or is to be considered further down the line. The combination of the product backlog and the product owner that drives the scrum process.
The Sprint
A 30 day calendar iteration of development. The development team builds functionality that includes the product backlog, and meets the sprint goal. If the sprint should lose meaning along the way, it should be abandoned and restarted with a restated goal. 5-10% of the sprint should be spent researching ahead for the knowledge and information that will be needed to complete it, or further sprints.
The Sprint Planning Meeting
This should consider the following:
Items Processing Action
Product backlog
Team capabilities Review
Business capabilities Consider Implement
Technology stability Organise
Executable product increment
Sprint Burndown
This is a method of charting the progress of the sprint. It is designed to measure results rather than effort, and shows how much of the sprint is left to do each day. Each developer must devote a few minutes each day to updating the burndown.
End of Sprint Review
This is fairly self-explanatory, review the product backlog, and set the next sprint goal in the light of what was achieved in the previous sprint.
So what did I think?
I enjoyed it, very well-presented session. I think that compared to what I have seen of Agile and XP, it is a slightly more formal, heavyweight system. Obviously it has influenced some of the thinking behind both of them as well. It could be easier for a team entrenched in the Waterfall method of development to transition to this way of working, than say jumping across to XP.
Nice simple concept this, something rap, and where it was sampled from. First off, we’ve got I can’t go to sleep by Wu Tang Clan
And then the immense Walk on By, by Issac Hayes. This isn’t the full 12 minute version off the album Hot Buttered Soul, which has some more of the huge stabs of orchestration the Wu used, but it is still fantastic.
This is my second test of a code syntax highlighter, in this case the Geshi-based syntax highlighter plugin.
This isn’t very successful either. The problem is with multiline cut and paste, certainly in Firefox. Doesn’t behave how you would hope. I’ve manually added the line returns to the CSS example, and that behaves fine, but the CSS still isn’t working.
What follows are my notes on Pascal van Cauwenberge‘s presentation at the London XP Day 2006, about The Toyota Way of Managing.
Why is it useful to us? Because it is reflected in many Agile processes and ideologies.
14 Management Principles, split into 4 categories:
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.
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”.
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.
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.
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.
“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:
Agile mirrors this: Daily standup meeting, keeps the leader a lot closer to all of the project.
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.
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).
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.
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.
These notes are taken from the above talk on 27th November 2006, given by Angela Martin, James Noble and Robert Biddle.
The bulk of the first half of the session was an extended planning game, with several elements of chaos thrown into the mix. The intention was to give us all a good idea what it was like to be a customer. From the reactions indicated by many, the feeling wasn’t exactly pleasurable.
The answer being proposed by Angela, James and Robert was to build a customer team, in some ways reflecting the XP development team.
The Customer Team
Geek Interpreter
Technical Liason
Political Advisor
Acceptance Tester
UI Designers – Programmers focus on the system model, UI designers focus on the user model to design the system image.
Technical Writers
Diplomat
Super Secretary – intimately familiar with the stories, writes them down and keeps them organised.
Negotiator – The on-site customer.
Most of these are meant to be roles, rather than individual positions. The ideal customer people should have people doing all of these roles.
The Customer Practices
The customers need to adopt practices to manage their relationships.
Programmer on-site – Get them to understand and respect their users, and to understand the context in which the software is used.
Customer Apprentice – Have a developer writing up their stories, acting as their secretary, attending meetings with users and stakeholders. Have them walk a mile in the customers shoes.
Programmer Holiday – Customers sometimes need to give the programmers a project holiday, perhaps give them an iteration where they focus on technical refactoring/debt.
Story Standards – Use a common template for every story. Remember that customers need reasonable time to get their stories right.
Show and Tell (Demo) – To the customer. Programmers can learn much from user/sponsor reactions to their software. Also gives useful material for sales and marketing to use.
Customer Pairing – Yep, just like with pair programming, it can be beneficial to have a pair of customers dealing with the developement team.
Customer Counselor – Provides professional support to the customers. Just as XP programmers should have a coach, customers need one too. Should be outside the project, and not a manager.
Look before you Leap – Do just enough analysis upfront to make decisions and set expectations. See also Agile, Lean methodologies for more of this. Maintain continuous analysis throughout.
Three-Month Calibration – After three months, projects usually realise that their eyes were bigger than their stomach. During this crisis period, productivity and morale can drop. Need to be upfront when this happens, and prepared for it, be ready to change scope and embrace change. Possibly similar to the lull you get after starting a new job, once you’ve had your training and got used to things, round about the same sort of time people often find themselves suffering doubts as they assess the job properly, before building up again to fulfil themselves in it.
So what did I think?
I think some people, including myself, were put off slightly by an over-long and somewhat chaotic exercise at the beginning (although as I said, the chaos was intentional). However the second half had a lot more meat in it, definitely worth looking at your relationships with your customers, and seeing if they measure up to this sort of ideal. Chances are you could be a long way short, and keeping some of these in mind could help.