If life were a game...

It's been about 8 years since I got my Agile training from James Grenning and started an Agile Pilot with my team. Right from the start I was super keen and got people practising TDD and Pair Programming even though I didn't really know if that effort would pay off. I just knew we had lots of problems with the old way so I wanted to embrace the new. So I'd run my own little sessions with the broader team in Sydney sharing Agile concepts and ideas. Giving us a chance to discuss things and keep learning long after James had left. But often I would present new ideas and a few people in the group would respond "oh of course, that's just common sense". Initially I thought it was great as they were embracing these ideas as valuable even though it was not what we were doing before. But after a while I started to get frustrated because they we're not really listening. If some small part of a concept fit nicely with their "common sense" then they took ...

Last year I got to attend a workshop on the Toyota Kata by Hakan Forss  and I could immediately see how it could be useful but I didn't have an obvious place to apply it until recently. So what is the Toyota Kata? I see it as an alternative to retrospectives. It lets you define a collection of goals and run experiments to see if you can get progress towards that goal. Unlike retrospectives you can define goals that may seem distant (release to customers on every passing commit), may be simply something you want to maintain (have zero bugs in production) or be impossible (have zero wait time in moving a story from backlog to done). Once you've built this collection of measurable goals you decide what you're going to try and your expected outcome (we will to TDD and have 50% less bugs in production). You can define what the period is before you check in again and decide on the next step. But as with anything Agile; shorter is better. You can work it into a normal two week ...

I'm trying to build up my skills as an Agile Coach. In a way I've been doing this already now for about 8 years. But it's getting a bit more structure and organisation. The way I see it learning is part of software development. It always has been. Some people get comfortable with their knowledge and workload and stop learning but that has never been me. When I get too comfortable I start looking for something else to do. But my learnings are just a jumble in my brain. Sometimes it impresses me as I can pull out a name, a quote or apply a process to something specific. And sometimes it lets me down so I have to revisit and revise like I'm doing right now. I'm listening to Esther Derby talk about her Six Rules of Change and writing this at the same time. Not something I recommend but I just want a refresher as I've studied it before. I'll probably grab the slides later and use it as part of a mini-presentation. Sorry you just ran into my jumble. What I...

I’ve been running a 30 minute lean coffee session in my workplace every two weeks for 18 months now. Our first meeting for this year is tomorrow. I started the sessions when a bunch of people from work went to the Agile Australia conference and we wanted people to keep sharing ideas and other learnings. Now I invite any software developer in the building so my invite list has grown to 99 people but I typically only get about 10. How lean coffee works: A few people from work got to take part in one at Agile Australia but I missed it myself. So I just got online and read everything at http://leancoffee.org/ I grabbed a bunch of index cards and texters and was ready to go. I feel it’s super important to my company as it’s the only time people from all the software development teams can meet each other and discuss things. It’s helping break down walls between teams and helping ensure learnings can spread to other teams quicker. Location matters. I started off in the building’s ...

Start with a clean slate with simple goals Starting from scratch is such a rarely privilege in professional programming. We get to do it all the time when we’re learning and trying things out. In our early years getting stuck and stumbled on the most trivial challenges. And later being proud of the frameworks and architectures we can build in days (sometimes hours). But there is rarely any money to be made in building something from scratch. There is no value in doing something trivial because it likely has already been done a thousand times before. So we need to add something to existing code. Maybe it’s something we already developed ourselves or something we bought. If we’re lucky the existing code is modular enough that the new feature can feel like starting with a clean slate and give us that burst of speed. So you will often hear the cries from programmers that are working with that monolithic and aging code; “please, please let us rewrite this code from scratch”. I’ve mad...

I've had a few opportunities to put my TDD skills to use in this brave new frontier. So I wanted to share what I've learned, what pitfalls to avoid and where the low hanging fruit is. Why use TDD in Javascript? We've reached a point where few people can develop an application without there being a web interface included. And now it's not enough to build a website with a few forms and buttons it has to be a "web application" with the detailed user interface and responsiveness we would expect of a desktop application. Javascript is serious business. Clients are not going to compliment you on your stable and fully tested backend if the UI is painful. When should you  not  use TDD in Javascript? Javascript has a strange distinction. It is the most widely used programming language in the world. It is also the most disliked programming language in the world. It can be hard to get programmers to  learn  Javascript before they dive into writing Javascript. S...

I haven't been completely idle. Appart from my rambings on twitter and google+ I've also been making regular posts to a new facebook group on Agile Software Development . I will return to talk about RestScriptFixture, fun with NodeJS and are games (like movies) out of new ideas?

Anyone who has worked with me in the last 3 years knows I have a programmer crush on Uncle Bob and I got most of my initial training on Agile development from James Grenning . So it was just a matter of time until I started using Fitnesse . Now fitnesse (and fit originally) is an interesting tool to try and get acceptance tests OUT of code. After all why should programmers (or programmer-ish testers) be the only ones to write, read and review these tests? Acceptance testing is about making sure you deliver what the customer wanted so shouldn't the customer and other management people be reading them too? So fitnesse meets them in a middle ground. A wiki. A wiki is a good place to go because you can get a manager or customer to read a wiki. You can, with a bit of a push, even get them to start contributing to a wiki. Good luck trying to get them using jmeter or read what you created in cucumber ! Those are great tools but they don't scratch the itch that fitnesse was written...

Yes YOU . Company, team, manager or programmer. You tried to tell me your job requires "Proven track record in delivering features in agile environment". You listed in your linked in profile that you have "Extensive experience with Agile projects". You describe your company as "Practising the latest Agile development techniques". Bullshit! If you're not doing Test Driven Development you're not agile. You're not Scrum. You're not XP. You're not Kanban. You'd be lucky to be classified as LEAN. Okay so TDD didn't make it into the Manifesto and maybe it should have. But all the ideas that built towards that manifesto included TDD as a key part of how programming should be done. You can argue about being 80% agile or that an agile technique for one company shouldn't be identical to the next. Fine! But you damn well better have TDD front and centre of that plan! Why is it so important? Because agile development isn'...

I'm doing a presentation for the Sydney PHP group As a sneak peak you can see my presentation as I write it

Ok so I mentioned how I've been getting my head around TDD and Agile recently. I'm kinda late to the game since I only discovered it 2 years ago with a presentation by Uncle Bob in Chicago. So it's taken a lot of reading and talking to get to the point where I am now. But I'm also carefully watching trials others are doing and making notes about those who succeed and those who fail. So time to talk about the interesting one. The failures. Let's break them down to some common archetypes. I'll keep coding the same way and make some token effort with planning cards. Yeah you suck. You've got to change your ways! The order you do things isn't going to be the order you always did it. You've got to talk to the customer/designer/whatever and let them talk about what's most important. That's your new order! Don't spend for ever building some backend database bullshit. You may not even need it by the end. The whole design may change and become so...