“Do people abuse the term #agile when they probably mean something different? Is it just a Job Spec / Tender buzz word? ‘We’re an Agile Team’”

The reason I tweeted this was that I see a tweet from a Development Companies CEO looking for an “agile developer”. Knowing people who work for said company I know they aren’t being agile, but are trying to do agile. Which is why I asked, has it become a buzz word, by people who don’t really get it’s meaning in the true sense. The word has become so abused in the software industry that people are starting to dismiss anyone who says they are agile.

What am I trying to get at, I believe there are two groups of companies in the larger agile term.

• Those who are doing agile
• Those who are being agile

Although the two sound very similar, I believe that the biggest difference is culture.

The companies / teams in the first group who say they are doing agile seem to be the ones who have read the principles of agile like the look of the agile manifesto and start to take the parts of scrum for example that they like (They may also take parts from XP and other agile methods and processes) They introduce Daily Standup’s, as a start then try to introduce sprints and other parts of the Scrum process. After sometime they find that these don’t work for them and they give up on Agile. Some may even send people on the Scrum Master course and have them help introduce the process, this will work in someways but will always have flaws in my opinion. They would be better off getting in an agile coach to help the whole team, and share their experiences.

You’ll find that this group will have standup’s that take over 15 minutes and give no real benefit to the process. Part of the process that I feel normally gets missed here is the retrospective, this is where the process and agile implementation can improve quickly and over time. When these companies say they are looking for “agile developers” they are hoping that these guys will just make there process agile, rather then empower them to help make the required changes.

The second group are the ones where agile really works for them, they get it, they understand it and they embrace it as a whole. The culture of the company / team is right for agile, they are open to changing requirements and the whole cadence of development sprints and releases. Their standup meetings takes 15 minutes or less, and are extremely informative and keep everyones attention as to where they are in the process. They may even have a dedicated agile coach(es) they help the team as a whole not just a Scrum Master to remove the impediments to the project but to help the team understand the different parts of agile, some very suttle like TDD, Pair Programming, Sprint Planning & Estimation etc.

If like me you work in a large enterprise and the whole company / department aren’t doing agile (or lean on my case) but your team is then you have to understand the hand off to these other teams, and as much as you try to help other close teams become agile they may not see the real true benefit of it especially if they are a smaller team. You need to work out the best way to interact with these teams so that it doesn’t become a bottle neck for your own agile / lean process.

To clarify I don’t want to confuse people with the terms Agile & Lean they are in my opinion very similar but also very different; I’ll cover this in another posting.

To summaries my thoughts, if the culture isn’t right for agile it’s either not going to work at all or will not work to full capacity. If you can get the right culture, like startups Agile and Lean will work as you’ll have full buy in from the outset. My team were very lucky as we started as a small number of developers 1 Managers and 2 Developers and an Analyst who just got Agile got it’s benefits and were able to implement and change the process as we went. When things didn’t work we changed them and yes I did the Scrum Master courses and now we’re doing Kanban (Lean) which for our teams works better and we are move productive, again because the team just got it.

What is the Mikado Method?

Simply put it’s a way to work on morphing a system to a better state in a structured away. It’s called the Mikado Method because it’s very similar to the name of the same name (also called pickup sticks) Where the Mikado (the goal) is what you’re after and you need to slowly remove all the other sticks that are in the way.

How does this relate to software development, we have all tried to implement a change to our software and we find it’s not as easy as we first thought, and the system breaks and as we keep trying to fix this errors there doesn’t seem to be an end to it.  The reason for this is that we as developers miss one key point, you can’t fix a system that doesn’t work fundamentally.

There are 4 key points to the Mikado Method:

• Set a Goal
• Experiment
• Visualize
• Undo

Set a Goal

If you’re going to make a change to your system you need to write down what you’re goal is and we do this on a piece of plain paper or on a whiteboard and we circle it twice to remind us that it’s the goal of what we’re doing.

Experiment

Just dive in and try to make the change you want to do, you will find that you have broken code but you note this on your Mikado graph.

Visualize

Using the Mikado graph by writing these things down it helps keep track of what we’re working on especially if you’re working on a large legacy system; it’s better on paper then in your head. Every time you find a something that breaks as you implement a change you make a note of it

Undo

The most unintuitive thing is the biggest key thing. UNDO once you have experimented and found something else is broken revert the code, it’s broken it won’t work. If you have a spent a while on some code and don’t want to lose the code you can patch it out so you can apply it later, but your need to REVERT the change out ensure you’ve put the item on your graph and then experiment again to fix this issue and if you find more again revert and note the error on your Mikado graph and then attempt to fix this error and continue you on.

Conclusion

For me the Mikado method means that you can morph an active system slowly and still have the system releasable. You’re improving the system slowly but surely and adding benefits to your customer / business although it may feel wrong reverting code you are always learning how the system works, especially if it’s something you’ve inherited from other developers.

My presentation is located here: http://nud.gr/mikadoSOTR
Also there is a booking in Manning prerelease, which you can grab from here: http://manning.com/ellnestam/
Also there is a video from Lean Agile Scotland in September 2012: Kev McCabe – Mikado Method – Making Code Changes Less of an Impact

My session will be a slightly improved session from the one I gave at Lean Agile Scotland in September, on the Mikado Method. This is a method of beheading the beast that is legacy spaghetti code. It’s extremely simple process and is mainly common sense but until someone gives you structure for this thought process it doesn’t really click.

When I say slightly improved session, I will have a worked example that introduces some basic unit testing to show the true benefit of the Mikado Method and Unit testing and how they go hand in hand.

So what is this method briefly, it’s similar to the Red, Green and Refactor for unit testing. When you have a change to make to complex code, and every time you change one thing it breaks another 2 things and you are stuck in a loop. The Mikado Method gives you a process to get out of that loop, allow you to still deliver value to your customer as you make actual progress that people can see rather then coming back to your customer weeks / months later after some very late and stressful nights to make this change that you thought would be very simple in the first to implement.

It’s all very straight forward and is easier to show the principles in action then it is to write about them. Since I found the method, I have found it help me fix problems quicker and produce a better code base and increase my testing coverage.

If all goes well I’m hoping to try a new technique in my session, but that will have to stay secret until closer to the time

So I’ve decided to start from scratch but keep the old blog up and running in an almost similar URL format for any search engine results but totally flat HTML and no commenting  

I’m still a ColdFusion Developer and Adobe Community Professional, but just wanted to host my blog and thoughts on a platform that allows me to do what I need to do and not have to support it. My focus now also includes Agile and Lean practices and I’ll be covering more of this over the coming weeks.

I have had a few changes in my personal life and as such will spur me on more to do more community driven items. I’ve ordered myself a shiny new Mac Book Pro 13″ retina display (Total Opposite of my 2007 17″ Mac Book Pro) I’ll continue to travel down to London for Family, Friends and London Irish so from this time I hope to pull my thoughts together and get them up on this new shiny blog.

So what’s the main principal about patching, it means that you only commit production code to the main codebase but you’re able to backup in SVN (And thus available to all) your work in progress.

Once I spoke to the Java team more about who they were using SVN Patches the penny dropped and I wrote two simple ant tasks to perform the job for the ColdFusion development team in ColdFusion Builder. The first was to create the patch, and there are couple of things that caught me out (I wasn’t thinking straight other things on my mind is my excuse and I’m sticking to it) When I released the two tasks, I had to wait until someone had the real world need for it. At this point I was hit with my gotcha, new files didn’t get included in the patch file. The reason being you need to add them to SVN in your working copy (NOT COMMIT THEM) so that the SVN diff would pick them up. Once this is done the task is fairly straight forward for the team. It asks for the users SVN credentials, asks for the Initials of the developers working on the task (Will do another quick posting on this), the JIRA Number, Jira Summary and then what the patch includes. The ANT task then automatically adds any new files to the working copy SVN, then create a patch file and places it in a folder at the top of our project called _patches it then commits only this patch file into SVN and leaves everything else not committed.

What this means, is that being good Agile Developers you don’t commit non-production ready code to SVN, so by using a patch you can put the work your halfway through working on into SVN without it affecting the main codebase so it’s all backed up in case of the dreaded Hard Drive Failure.  The second benefit is that another member of the team can use the other ANT Task which basically consumes the patch, this just requires the JIRA Number and it will apply the patch to the users local Working Copy and thus can check another developers code  or indeed work together on the same issue on their machine before the actual code is committed to the codebase.
Also as we perform pair programming, if the work isn’t completed by the time a member of the team needs to leave, they can perform the patch and the other developer can crack on and again commit their patch back in before they leave for the day. This then means if the happen to win the lottery that night and never come back the team still have the code to hand and can continue to work on it.

So to implement this ANT task I used SVN ANT and a windows port of the GNU Patch, so SVN Diff will create a Patch Diff File for you and basically GNU Patch will apply it to your working copy. (Subversion 1.7 has a new command to do this for you but we’re still on 1.6 until all our tooling catches up)

So that’s it in a nutshell, the power of SVN patching will help keep your codebase production ready without losing any code should the worse happen.