Our brain filters and interprets what we see to help make sense of the World around us. Simply measuring the light coming from a surface is not enough to understand the surface. A white surface in shadow, for example, may reflect less light than a black surface in full day light.
I first came across Edward H. Adelson’s maddening checker shadow optical illusion while reading Kathryn Schultz’s fascinating book “Being Wrong”. The squares labelled A and B in the following picture are the exact same shade.
You don’t have to take my word for it, you can watch it on YouTube - in all its maddening glory!
This process appears hardwired. It doesn’t matter how many times you see this illusion, your brain still gets it wrong!
I recommend the book. It’s rather humbling to realise how wrong you can be; from what you hear, what you see and what you think!
Thanks to Sam Owen telling me about the YouTube video.
Does the language you speak impact the way you think?
This question has occupied academics for centuries. Some people perceive deep differences between languages, which affect the minds of the people who speak them. Others argue that the differences are superficial and, linguistically speaking, all humans are essentially equal.
I’ve often wondered how programming languages affect the people who program them, so I found Guy Deutscher’s’ delightful book “Through the Language Glass” both fascinating and enlightening.
He explores two centuries of research from William Gladstone puzzling over the lack of colour in The Iliad and The Odyssey, to the latest brain imaging experiments.
Gladstone’s noticed the black-and-white nature of the Homer’s world; blues or greens are never mentioned. One popular explanation at the time was that the ancient Greeks were partially colourblind and full colour vision had yet to evolve. Scientists even pointed to the lack of colour words in many primitive languages around the world as evidence. Obviously, we now know that evolution doesn’t work so fast. Differences in colour vocabulary reflect cultural rather than biological development.
So where are we on this debate today? Noam Chomsky has argued for the past 50 years that the universal rules of human grammar are encoded in our genes and variation between languages has no cognitive consequence - all languages are equally complex.
In fact languages vary markedly in complexity. In general small, illiterate societies have languages with smaller vocabularies but more complex grammatical structures. Such differences can affect the way people think.
The latest brain scanning experiments show that If a language distinguishes between two colours, as Russian does between dark and light blue, then its speakers experience more of a difference between them than people whose language uses the same word for both.
And, then after all this, I saw Mark Pagel’s TED talk postulating that language is a piece of social technology for enhancing the benefits of cooperation:
Thanks to Mark McKergow for recommending this book.
These are some of my favourite talks from this year’s TED Global Conference
I loved Matt Ridley’s meme of Idea’s Having Sex. A fabulous talk exploring the importance of collaboration and exchanging ideas - the power of the collective brain.
Lewis Pugh’s incredible Mt. Everest swim to highlight melting glacier ice. An amazing story. I’ve started sending this to people who ask me to help rolling out a standard agile software development process to highlight the pitfalls of a standard process.
The most captivating speaker was Elif Shafak, talking about the politics of fiction. Such a wonderful story teller. I’ve ordered a couple of her books as a result!
A mind-blowing bit of technology…
The first person to arrive, following a client office move, found he couldn’t access our new office.
He starts late so he can talk to people in Hong Kong. The door to our new “secure” office would only open during London Office hours.
Luckily, the other door to the same “secure” room did not have a lock.
We were so lucky to get Dave Snowden as an XPDay keynote back in 2004.
One of the memorable moments was when he used the metaphor of organising a childrens party to explain the various approches to managing complexity. It certainly resonated with the audience (based on the conversation in pub afterwards - a wonderful XP day tradition).
Dave’s now uploaded a version to YouTube… Fantastic stuff. I love the deadpan humour.
I have always been a fan of teams sharing experience and knowledge within a company. It’s a great way to learn new techniques, find our how people have solved similar problems and discover who’s doing cool things in your organisation.
Today I witnessed a session on agile software testing that made be rethink this.
The key problem was that the person had been told to do it. It was not something he volunteered to do. He had no passion about the subject.
He started berating the audience for producing “crap”. Not the best technique for wining people over to your point of view!
It also appeared that he didn’t have much experience in using test driven development techniques (as he had some rather strange viewpoints).
“Predictably Irrational: The Hidden Forces That Shape Our Decisions” by Dan Ariely is one of the best books I’ve read for a long time. Here he is talking about it at TED.
While on the subject of decision making, Joachim de Posada shares a landmark experiment on delayed gratification and how it can predict future success. With fascinating video of children trying their hardest not to eat the marshmallow.
I’m also interested in what’s happening as the worlds of TV and the internet collide. So this one by Peter Hirshberg also caught my attention.
After moving all my source code to GitHub, I wanted to build it on my Bamboo build server - especially now that it lets you run the build agents on Amazon’s Elastic Compute Cloud (EC2).
Bamboo does not support git repositories out of the box. I found this Git Repository Plugin by Atlassian’s Don Brown, but it didn’t like the GitHub style repository URL’s when I tried it.
So I wrote my own GitHub repository plugin that is fully integrated with GitHub:
See the plugin wiki for some screenshots and installation instructions.
A wonderfully clear and easy to understand explanation of the current Credit Crisis by Jonathan Jarvis. Reminiscent of Monty Python’s Terry Gilliam…
Mark has been explaining Solutions Focus to me for a while. It has some really compelling ideas and techniques that Agile people will find useful. So I thought it would be great to get Mark to come along to XTC and explain it himself.
Talk starts at 7:30 on the 13th Jan at The Counting House pub (50 Cornhill, London, EC3V 3PD). It’s free, but please signup on the XTC website.
Just to whet your appetite:
The Solutions Focus approach is creating a stir in the fields of psychology and management. Whereas conventional approaches assume stable environments and predicable outcomes, SF is bringing a new, simple and effective flavour to the workplace and the therapy room with a view on ways to make progress while everything changes. Surprisingly, the approach is as effective, if not more so, than conventional methods.
In this session Mark will share his experiences of using SF in many business settings and help us to experience the approach in some quick interactive exercises. We will discuss how SF sits alongside Agile, how the two philosophies reflect each other and how Agile processes like retrospectives might be even more agile with the inclusion of some SF techniques. This will be a session to appeal to both the pragmatist and the philosophical.
I remember having a rant at the eXtreme Tuesday Club a few years ago, “Who cares about working software, if it’s not what the business need? Delivering Business Value is the most important thing!”
This was triggered from seeing too many agile teams get bogged down in the minutiae of the process. They did not think about how the business would benefit from what they did or how they could deliver value early. Delivering working software was the only important measure they cared about. They missed the subtlety of the Agile Manifesto that talked about delivering valuable software:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
I saw several agile projects that delivered software the business did not want. Chris Matts and I made it our mission to bang on about Business Value back at the Agile Development Conference in 2003. We published a paper in Cutter in 2004 based on our experience of applying these ideas on our projects.
It’s great that this is starting to get traction in the agile community. There was even a whole track dedicated to this very subject at Agile 2008. This has to be a good thing.
On reflection, I think the moniker Business Value was a mistake as it confuses the conversation. People start assigning a Value to what they do. You see things like:
The greatest problem with these statements like this is that it’s impossible to re-evaluate the business value if market conditions change. There is no mention of the cost of generating this revenue or the amount of capital investment required to generate the revenue. It results in dumb behavior.
Several speakers at Agile 2008 talked about business value Story Points. Joe Little proposed assigning Business Value points to each item in a backlog. My experience is that this consumes a vast amount of energy and the business people start making up large values to game the prioritization process.
I really enjoy watching the BBC television series Dragon’s Den. Entrepreneurs pitch for investment in the Den from five Angel Investors (The Dragons!), willing to invest their own money in exchange for equity. When the Entrepreneurs provide a Value, the dragons always probe for the model:
It’s impossible for the Dragons to make a sensible investment decision from a simple value.
This is why Chris and I always say Business Value is a Model, not a number.
Software development is also an investment and, just like the Dragons (although I’m not suggesting our customers are dragons!), the Business need to probe the model to assess the value of the software investment.
Another problem is the model is is a state of flux. Few businesses exist in a vacuum. Markets change, assumptions become invalidated and competitors launch disruptive technology. If you assign a value to a story based on a model, there is a danger that the model’s assumptions have changed by the time you want to implement it. People take the business value number for granted and rarely question its validity.
I use the model as a litmus test to verify if the next chunk of work makes sense as and when you need it.
Creating solutions that deliver the maximum-business-value should be the primary purpose of what every development team does, regardless of their process. It’s more then just consuming stories or taking for granted that the items in the product backlog make sense.
One of my clients was telling me about the problems that they are having with “Aspirational Planning”.
I thought this was an excellent description of the problems lots of organisations have with planning.
Then it slowly dawned on me that he was serious - they really do create “Aspirational Plans”. They are fully aware that they don’t reflect reality (as they take so long to prepare), but the senior management love to spend lots of time and (other people’s energy) creating detailed plans of what may or may not happen one day.
The teams on the ground just roll their eyes when I ask about these plans. I’m going to have my work cut out on this one.
The old bambinos made me laugh with this suggestion:
An improvement on XP’s stand-up meeting, or scrum’s daily scrum is the New Bamboo Hang Up Meeting. You are only allowed to talk while performing pull ups from a steel girder. Not only does this keep the meeting short, but ensures the team reamins physically fit
These are fantastic.
See the full set at “http://www.redbubble.com/people/Balakov”.
David Anderson gave a talk about kanban at XTC a few weeks ago (11th March 2008). David’s pictures of projects using kanban struck a chord with me.
My current project is split across multiple locations (well, countries!) and we keep track of what we are doing in Jira. Jira is great for tracking and chunking work into releases, but it wasn’t highlighting our process bottlenecks. We’d been caught out a couple of times by juggling multiple streams of work and having too much work building up in UAT.
I emailed David’s slides around the team and asked people if they thought the kanban view of the project would be helpful. The technical people thought it was a great idea, but the business people couldn’t see the point - they already had this information to hand and did not think it would be worth the effort.
One of the guys (Paul Allton) did a little experiment using ruby to automatically create a kanban work-in-progress view of our existing jira data. It’s gone through a few iterations, but this is what it looks like now:
Taking the kanban picture to the standup was fascinating. The people who thought it was unnecessary suddenly became animated about the bottlenecks. This picture makes it very easy to see the state of the project and where people need to spend their energy.
The poor man’s kanban (because we’re not really doing kanban, and it would be much better if we had a physical board) has proved very popular with the team.
I enjoyed reading Keith Braithwaite’s post on tests and gauges. I like the way Keith uses the the metaphor of gauges in metalwork to describe Fit style tests:
You don’t work anything out from a gauge. What you do is apply it to see if the workpiece is within tolerance or not. And then you trim off, or build a bit up, or bend it a bit more, or whatever, a re-apply the gauge. And repeat.
I agree with Keith.
The fit tests I write are business facing</a> and for the benefit of the business customer.
On a recent project our customer got really enthusiastic about our fit tests and got extremely upset when I implemented a story without a fit test. He refused to let the system go live until we had the fit test in place.
The story in question was very technical and involved sending a particular xml message to an external system. We just couldn’t work out what a fit test would look like for this type of requirement. Placing the expected xml message, with all it’s gory detail, in the fit test wouldn’t have been helpful as it’s a technical artefact and of no interest to the business. We could not work out what to do. The customer was not around to discuss it, so I just went ahead and implemented the story (very naughty!).
The customer was using the fit tests to show him what the system was doing. In this case he wanted to be sure that we were sending the correct product information in the xml message. To resolve the issue, I suggested that we have a Fit test that shows how the product attributes get mapped onto the xml message using xpath; although I still thought this was too technical for a business user.
I gave the customer a couple of links to explain what xpath was so he could explore and decide if this was a good solution for him. To my amazement, he was delighted with xpath (I now know who to turn to when I have an problem with xpath) and filled in the fit test.
The interesting bit for me (and why I’m posting it on the blog) is that as soon as he knew what the message looked like and how it was structured, he realised that it did not really support the business - we were sending information that was stale and should have been supplied by another system. He was also sceptical about the speed the external team could add new products due to the complex nature of the xml.
Most agile people I tell this story to think we have the “perfect customer”!
I agree.
I though it was worth sharing some experience we are having speeding up our very slow build from 1 hour plus to around 10 minutes.
In the past we have spent a lot of time exploring why our tests are slow and have never really come up with a good solution. We’re continually extending the test suite, so any savings we make don’t last that long.
The unit tests are quick (~40 seconds), but it’s the acceptance tests that start up and run the application that are painfully slow.
We decided to group the acceptance tests into small logically grouped test suites that can run in 10 minutes or less. Then we added build agents (each running on a separate machine), so we can run as many of these small test suites in parallel as we can.
Every time the build gets too slow we break them down into smaller chunks and add another build agent. Hardware is cheap so it’s easy to sale this solution.
So far this is working really well.
I have just discovered an old post by Jim Shore (http://www.jamesshore.com/Blog/How-I-Use-Fit.html) about how he started out using FIT. He started out by switching from a unit test driven approach to a more story driven development approach.
I encountered a big problem with this approach, though: I stopped doing good TDD. “Storytest-driven development” blurred the line between Fit and unit tests. The “STDD” cycle largely replaced the TDD cycle and, as a result, I had far fewer unit tests than normal.
That was a problem because Fit examples are not unit tests. Fit examples are just that: examples of a business rule in action, from a business perspective. In TDD, I write tests for every line of code that can possibly break. In my Fit examples, I try to talk about every possible business case. That’s a bigger net than TDD, and without TDD, my code wasn’t well tested.
I had the exact same experience. I also found that the design suffered due to the lack of tests (it did not force me to refactor as often as I should) and it had a detrimental impact on my productivity. Story tests are larger in scope and take longer to run. Unit tests provide a much faster feedback loop when you break something.
I wish I had read this before I started using FIT.
As a follow up to my post on pair programming based interviews, I noticed this on a recent job advert:
In chess it is possible to place eight queens on a board so that no one queen can be taken by any other. Write a program to determine all such possible arrangements for all eight. I am not looking for a Chess Games Developer. I am looking for Java Developers who have the OOA and OOD skills to solve this problem….
Would you prefer a test that’s abstract and has nothing to do with the work involved, or one that that involves doing the job you are interviewing for?
I wonder if they have run this test on all of their existing staff to see if their is any useful correlation?
I noticed an interesting discussion on the IXP mailing list about pair programming with developers during an interview. I was surprised by the number of people who thought it was a bad idea.
I have done a lot interviewing for various companies and one of the best ways to find out the beliefs and values of a software developer is to look at their code. The best way to know what someone is like to work with is to work with them! This is why I really like pair programming interviews. It’s one of the best interview techniques I know.
Another nice feature of a pair-programming interview is the continual conversation you have with the candidate. It provides you with ample opportunities to ask sensible questions about the code you are writing. This gives the candidate a better understanding of why you are asking the question. There’s nothing worse than crazy interview questions that make no sense!
There are certain things you have to be aware of. You have to be very good at putting people at ease. You need to explain why you are running the interview like this. Some people get very nervous at an interview. You have to treat it as if you are pairing with a colleague. If people get stuck, you should help them out.
An interview is a two way process. The candidate also gets a much more realistic idea of what it would be like being in the team. They see what it’s like working with the team and experience the development environment first hand.
I recently had the opportunity to help Rachel Davies run a class on User Stories (I was more the unglamorous assistant). The class produced some wonderful examples that we wanted to share. Rachel has blogged them. These are some of my favourites.
As a boy I want a big garden that can house a kennel so that my mum can buy me a dog.
As a teenage daughter, I would like my own bathroom so I don’t have to share with my younger brother (Kevin).
As Grandma, I want big windows to watch what is happening in the neighbourhood so that I can gossip.
As a dog, I want to live close to the park so I can go for walks and sticks to play with would be nice.
Fantastic.
I came across a very strange number today while writing some unit tests. Apparently Java thinks “10WTF?” is a perfectly valid number and does not throw a ParseException when you try converting the string to a number.
Here’s the unit test to prove it!
I once had the pleasure of working on a team with Chris Stevenson. We had a ball. One thing I noticed was that he talked in keystrokes when you paired with him. He wouldn’t dream of saying, “let’s run all the tests and check in”, he would say “shift F10, Ctrl K”!
I must point out that Chris is not as geeky and dysfunctional as this may sound (in fact, he’s not dysfunctional at all :)). This was simply a great way to help you learn the keyboard shortcut keys and stop faffing with the mouse!
I have just found a fantastic Chris substitute. It’s an Intellij plugin called KeyPromoter that displays a big hint every time you use the mouse. It even prompts you to enter a shortcut key for things you do that don’t already have one.
So, if you're a loser who doesn't have anyone to code with ...
I wanted to vent about spring, iop, too much xml, framework hell… making testing difficult… Then I discovered this link.
A picture paints a thousand rants…
At long last, Luke Hohmann’s book Innovation Games has arrived. I became hooked on Innovation Games when I read an early draft of Luke’s book. That seems so long ago!
A software group is best measured by its customers’ success. Understanding what they really need is critical, but customers are human too which means that they’re fallible.
Customers can’t always tell you what they want because sometimes they don’t know themselves, so asking them to rank requirements or write stories might not be the best place to start.
The book is a collection of games you can play with the customer to gain a better understanding of what they need. Although the book is really about product management (working out what product a customer wants), I think these games are useful for agile teams trying to get a better understanding of what their customer wants.
Steve Freeman and I ran a really success session at last year’s XP day on this very subject.
Following on from Fit Lesson 1.
Organise the Fit Tests around your iteration’s stories
I like to take small baby steps when I write software. It makes life easy. I don’t have to merge very much code, I get regular closure on what I’m doing, I don’t have to carry too much around in my head, and I can discard mistakes without loosing too much work.
Automated acceptance tests, such as Fit, can throw a throw a spanner in the works.
I like to explore the problem by writing the Fit test with a domain expert before I start writing any code. I treat the acceptance test(s) as a definition of success. Before I start work on a new feature, I need to understand how I will know when the Customer is happy with what I have done. I flesh out the answer in the fit test (I often have several Fit tests exploring different aspects of the story).
Great, but Fit tests are course grained in nature. I typically make at least 20 baby steps (source code commits) before a story is complete. I don’t want to commit the Fit test before I start writing code as the Fit test will fail and break the build. Not good. I don’t want to wait until the fit test is complete as that will loose all the advantages of developing in baby steps.
Some teams use different directories to distinguish between the Fit tests that have been completed and should pass, and those that are currently being worked on. The tests get moved around when they have been completed. I guess that solves the baby steps problem, but I’ve never liked moving files around to indicate completion and it’s still hard to see how the Fit tests relate to the originating Customer Stories.
William Jones has a much nicer solution with his Agilifier project. There is not much documentation at the moment (well, it is opensource!), so I will give you a quick overview.
Download it and give it a try. You should be able to figure it out from it’s own acceptance tests!
I spotted this on information aesthetics. It’s a disk drive that changes shape to show how insync a data backup is with it’s source.
What a great idea.
Here is a nice podcast from Jason Fried from 37Signals.
He had an interesting view on co-location. I always thought distance hurts, and having everyone working together in the same location was critical.
Jason argues that if you can’t explain a design or a business strategy using IM or Skipe then it’s too complicated and you should choose something simpler.
It’s a really interesting point of view. I have been mulling this over in my mind for a few days now. I wonder what impact people’s learning style has on this? I’m very visual, I really like being able to jump up and draw pictures with collegues around a white board. I wonder if Jason is more of a words person?
Write the test so it reads like a requirement specification and not a test.
I was trying to explain a FIT test to a new colleague. It soon became clear that it had been written as a test. It didn’t convey the intent of what was required. Nor did it communicate why it did what it did. There was a lot of tacit knowledge in my explanation of what was going on. It obviously failed to communicate the requirement. It did, however, test that a particular feature of the system worked!
So, what is the purpose of a FIT test?
Brian Marick makes the distinction between Business Facing tests and Technology Facing tests.
A business-facing test is one you could describe to a business expert in terms that would (or should) interest her. If you were talking on the phone and wanted to describe what questions the test answers, you would use words drawn from the business domain: “If you withdraw more money than you have in your account, does the system automatically extend you a loan for the difference?”
A technology-facing test is one you describe with words drawn from the domain of the programmers: “Different browsers implement Javascript differently, so we test whether our product works with the most important ones.”, “Or,
PersistentUser#delete
should not complain if the user record doesn’t exist.”
The FIT tests should be business facing, they are a communication tool with the added benefit being executable.
FIT tests should explain the requirements so that people know what the system does. The collection of FIT tests forms an executable requirement specification. They should not really be called tests at all!
Our FIT test was clearly written from a developer’s point of view. It was technology facing. Fit is probably the wrong tool for technology facing tests. I would much rather write these in a more developer friendly tool such as Java or ruby.
I’ve uploaded the slides from Steve Freeman’s and My talk at XPDay.
http://www.pols.co.uk/papers/CustomerGamesV2.pdf
I really enjoyed the session. Here are some of the product boxes people created:
I particularly love the “official” Kent Beck endorsement!
Without any prompting everyone asked for free beer!
Bill Gaver gave an fabulous keynote at the recent XPDay conference. He talked about designing things for Ludic (playful) Engagement.
This included the Drift Table, a coffee table that enables people to slowly float over the British countryside from their own sitting room. The weight of objects left on the table control the slow drift of aerial photographs displayed in the table surface. This table suggests a ‘hole’ in the home connecting physical and virtual space. A display on the side of the table shows the location of the aerial image. See photos of the drift table in use
Check out this paper to find out more.
I bet you want one of those tables as much as I do!
I’ve been running several two week “challenge” assignments recently and really enjoyed them.
This week I’m trying to prove to a company that they can automate lots of their 3rd party vendor acceptance tests. They’re spending vast sums of money on manual testing - any reduction in this would be a godsend.
The first application is a java web app. That should be easy. It turns out that it’s using lots of really strange javascript.
For example, the login form looks like this:
The post action security_check simply returns an error saying you can’t post!! Why would anyone subvert the standard web form process like that? They have some javascript called from an image link that submits the form. If you don’t do things in a standard way you can’t test your application using standard tools.
Httpunit could not parse the javascript. If I clicked the link it simply returned to the same page (due to the href=”#”).
JWebUnit uses Httpunit under the hood, so was not really an option (although I did give it a spin).
Selenium did not work as I could not change the deployed webapp (the selenium javascript needs to be served up from the same server).
Then I discovered the lovely JExplorer library from MIIK. It basically wraps the IE components so you can embed Internet Explorer in a Swing application.</p>
It worked a treat! I can now automate all my acceptance tests using JExplorer.
I stumbled across this the other day. Bill Strickland is amazing. All organisations need a Bill Strickland. I recommend you give it a look.
http://stream.fuqua.duke.edu/Content/fuqua_events/2003/Strickland/Strickland.smil
You can find more about Bill at http://www.fastcompany.com/magazine/17/genius.html
I particularly like this observation:
Artists are by nature entrepreneurs, they’re just not called that,” Strickland says. “They have the ability to visualize something that doesn’t exist, to look at a canvas and see a painting. Entrepreneurs do that. That’s what makes them different from businesspeople. Business people are essentially administrators. Entrepreneurs are by definition visionaries. Entrepreneurs and artists are interchangeable in many ways. The hip companies know that.
Preston Smith has written a pragmatic overview from of why Agile works. I particularly liked the reference to Donald Reinertsen’s research that showed:
If requirements are going to change, wouldn’t we be better off acknowledging this and building our processes to accommodate it?
Some time ago Chris Stevenson and I wrote about our experience working on a legacy application. Martin Fowler liked our approach and decided to call it a Strangler Application.
Brian Marick includes it in his recent blog discussion about the different approaches to dealing with legacy code.
I have been thinking about this a lot lately. I have been working with a client where a strangler application would have been a good solution. It was an almost repeat scenario from when we first applied the Strangler Application approach to a legacy financial trading system.
One of the key aspects of the original project is that we left the legacy application alone. The legacy application was still maintained by the original team. A new team completed the replacement strangler application. The rationale behind this was that the original team had repeatedly failed to address the legacy problems and was holding back the business. A key problem was the team itself. The team appeared incapable of coming up with an alternative solution, but management did not want to change the team as they were the only people who knew how the legacy application worked.
The new client rejected the approach.
We can’t do that! There is no way we can get the budget for two teams
Asking for more money in this way highlights the problems of the original team and the fact that the project management do not know how to fix the original team (and have not addressed it before).</p>
I now realise a critical success factor of the original project was the way the Project Manager hid the cost of the strangler application by associating it against a different project that had spare cash available.
This is a real barrier to applying these ideas in this situation.
Michael Thorpe told me about this wonderful explanation of two stage commits (from the book Transaction Processing : Concepts and Techniques):
The chapter on two phase commit compared it to a wedding with the minister being the commit point. “do you take this man” (vote to commit) - yes, then PREPARE to commit, “do you take this woman” (vote to commit) - yes, then PREPARE to commit. “Anyone out there have a good reason not to do this?” no, then “I pronounce you man and wife” - transaction is committed.
I’m reading the excellent book Fearless Change by Mary Lynn Manns and Linda Rising. It’s a book of patterns for introducing new ideas.
I’m experimenting with the patterns to help me introduce agile developement into organisations. So far so good. I recommend it. They have an interesting quote from David Baum’s Lightning in a Bottle.
If your change process is like most, about 15% of your folks are going to be thrilled and will only want to know what took you so long. About 15% will utterly reject the need for change, and won’t be happy no matter what you do. The remaining 70% will sit on the fence and quietly watch to see who’s winning.
This middle 70% is where you need to put your most time and energy. That is where the victories really count. The 15% who are positively excited will need very little support and encouragement. They are already motivated by the change. For the negative 15%, there may be nothing you can do.
How true.
Continuing on the theme of breaking the self imposed rules I heard a wonderful story about a team working in an environment that involved a customer requirement to provide an audit trail of all project design decisions.
This was a real rule.
Many teams would interpret this as a requirement to have lots of heavy documentation and associated traceability. This would have been a self imposed rule.
This team solved the requirement in a wonderfully low energy way. They simply hung a long roll of brown butcher’s paper around the room. Whenever people on the team made a decision, they made a note of it on the paper, dated it and signed it. This acted as a short term information radiator of team decisions. Once it was full, they rolled it up, marked it with the date range and filled in it the corner of the room.
The auditor loved it as it was quick and easy to see what was happening over time.
Here are some tips I picked up this week from a friend. He has just started at a new company. His new company has lots of projects without any clear indication of their business value.
So he got them to draw a matrix like this and place their project in the appropriate box:
Low Value To Customer | High Value To Customer | |
Low Risk | ||
High Risk |
I have noticed a couple of common problems when the team meet the business to estimate what they are going to do next:
Here is a little technique that is worth trying if you find yourself in this situation:
The nice thing about this is that it is quick, fun and appears to provides reasonably accurate estimates (probably because it involves everyone).
Chris Matts and I are working on an article that looks at why IT management have a tendency to play to lose and not play to win. They tend to measure the wrong things and see IT as a cost and not a revenue generating opportunity.
The more I think about this, the more examples I see.
A friend just told me about a Bank who has told its IT contractors they must take 3 weeks (unpaid) holiday over Christmas. Apparently, this will save them £3 million pounds! This is staggering. Surely the revenue generated by these Contractors exceeds their cost?
I have just noticed an(other) article arguing that you must must be mad not to do waterfall development in the appropriately named website (http://db.riskwaters.com/public/showPage.html?page=195099
Steven Little claims IT projects must have the following process:
Step One: What do I have to do? (write the business specifications)
Step Two: How am I going to do it? (write the technical specifications)
Step Three: Do it (actually start implementation)
The print version has a wonderfully ironic photo showing the tools of the trade as hammers chisels.
I wonder why people still feel that waterfall is such a great idea for managing project risks?
Waterfall was first described by Winston Royce in the famous paper “Managing the Development of Large Software Systems”. Many people, incorrectly view this paper as the paragon of single-pass waterfall. In reality, he recommended an approach somewhat different than what has evolved into today’s waterfall concept, with its strict sequence of requirements analysis (Step one), design (Step two), and development phases (Step three).
In a personal communication with his Son (Walker Royce), Craig Larman (http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf) discovered:
He [Winston Royce] was always a proponent of iterative, incremental, evolutionary development. His paper described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects. The rest of his paper describes [iterative practices] within the context of the 60s/70s government-contracting models (a serious set of constraints).
Martin Fowler has blogged the idea of a Strangler Application based the work Chris Stevenson and I presented in our An Agile Approach to A Lagacy System paper.
Here are some interesting comments about our approach:
Much of my career has involved rewrites of critical systems. You would think such a thing as easy - just make the new one do what the old one did. Yet they are always much more complex than they seem, and overflowing with risk. The big cut-over date looms, the pressure is on. While new features (there are always new features) are liked, old stuff has to remain. Even old bugs often need to be added to the rewritten system.
An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.
The most important reason to consider a strangler application over a cut-over rewrite is reduced risk. A strangler can give value steadily and the frequent releases allow you to monitor its progress more carefully.
Kenji Hiranabe sent me the following embarrassing photo from the ADC closing party with my fellow partners in crime! It was a great night! Thanks Kenji!!
<img src=”/public/img/ADC_2004.jpg” border=0>
This morning at ADC2004 had some amazing papers (with links to the papers):
Yoshihito Kuranuki and Kenji Hiranabe presented a superb paper on the problems (anti-patterns) they had using XP. They used cartoons, play acting to totally captivate the audience. I felt sorry for the poor guys who had to follow them!
These include:
Paul Hodgetts talked about his experience with big bang adoption of XP practices vs doing it more incrementally - one practice at a time.
This matches my experience working with teams transitioning to agile.
Greg Luck talked about his experience on a project. I really didn’t like this paper when I first read it! They did not subclass XP, and he talked about only allowing refactoring at the end of the iterations! Really don’t like that!
Anyway, it turns out that he ment defer large design changes until the end of the iteration. Phew. Now I can see where he is coming from. He also talked about a pair being too small a unit to make large design decisions. I agree with that. I always use team white board sessions to discuss designs with the team. Shame the paper does not explain the story properly.
Chris Stevenson and I wondered how we could pair-present our experience report at XP2004. It seems appropriate that you pair on a XP presentation.
We are both very spontaneous and did not relish the idea of scripting the whole talk. If you don’t do some planning there is a danger that one person does all the talking, or forgets some key points. It can get real messy!
Chris hit on the idea of using a chess-clock (swing app on a laptop) to control how long we get to talk! We each had a minute of talking before we tapped the clock and passed control over to the other speaker. If we went over a minute the clock went red.
It worked. We finished dead on time. Lots of people came up to us and said they enjoyed it. Extreme Presentations anyone? I feel a book coming on.
Ron Jeffries posted the following (rather fab) summary of the various agile methods on the extreme programming news group… and I could not resist blogging them.
Go in that room there and do all 12 XP practices until you actually do know better. (XP)
Go in that room there, don’t let anyone screw with you, work on whatever you think you can get done for a month. Keep doing that until everyone is happy. (Scrum)
Go in that room there, in peace love and understanding, ship software every month, and think about it. (Crystal Clear.)
Its been a busy couple of weeks for me as experience reports chair of ADC. We had 31 papers to review.
An interesting point for me, and worth blogging (Tim Mackinnon suggested I blog it) for anyone interested in submitting papers to future conferences, is how we decided on the final papers.
We tried to be as agile as we could (difficult as most reviewers live in different time zones). So we:
The key aspect for me was using the Identify The Champion pattern for deciding on which papers to accept. This says someone has to advocate the paper for it to be accepted. To advocate, you have to be willing to shepherd the submission and make it happen. So when people said “we quite like this one, …“, I would say are you willing to advocate it? Most times the answer was no. It really helps focus the reviews and keeps the quality of the papers hight.
The end result is we have 16 really interesting papers. Hope to see you at ADC!
This made me smile today:
Commenting on a complaint from a Mr Arthur Purdey about a large gas bill, a spokesman for North West gas said, “We agree it was rather high for the time of year. It’s possible Mr Purdey has been charged for the gas used up during the explosion that destroyed his house.” (The Daily Telegraph)
Keith Braithwaite posted an interesting comment on the XTC wiki
XPDeveloper.com. He asked about problems with HR and pair programming.
They have noticed that our XP developers all log on to the development workstations (which are reserved exclusively for pairing on development tasks) using the same ID. They find this unacceptable. Their preferred solution is for the “driver” to be logged in, and then log out to allow the “navigator” to log in each time the keyboard changes hands. We find this unacceptable, for obvious reasons.
Imagine having to log out everytime you switch keyboards? It amazes me the “problems” that people make for themselves.
I had an interesting conversation with Tom Gilb at XTC. Tom pointed out something obvious (don’t you hate it when that happens). He argued that the phrase iterative is not that descriptive. Tom prefers the term evolutionary.
My dictionary supports his argument. It defines iterative as marked by tedious repetition, while evolutionary is defined as a gradual process in which something changes into a different and usually more complex or better form. Much better.
This got me thinking that Evolutionary Development is a much better phrase for explaining to new people what the whole thing is about. We are building software that evolves, not software that iterates!! I wonder why we started using the term iterative?
Some agile people have started using the term best practices to describe what they do (such as pair programming or TDD). There are a couple of problems with this.
Firstly, there is no such thing as a best practice! Practices always depend on a context. These practices are not best in all situations. Sometimes you may not need them; sometimes you’d be better off doing something else. People rarely place the best practice in a context.
Secondly it sends out a negative message; we’re the experts and you don’t know what you are doing. While this may be true, it is not the best way of motivating and inspiring people to change!
It turns out that principles are more important then practices for getting people to change. If people understand the principles behind something they are better placed to recognize which practices best fit their need and why a particular practice would be worth adopting.
A friend left some books at my place… This one caught my eye. Something opening with must be a good read:
When asked the question, what is consciousness? we become conscious of consciousness. And most of us take this consciousness of consciousness to be what conciousness is. this is not true.
The Origin of Consciousness in the breakdown of the bicameral mind by Julian Jaynes.