This morning I watched a really great key note from Robert Martin (Object Mentor) about how test driven development is very important to a language, not just in terms of writing clean code but as part of an professional approach to project delivery and relations with the wider industry.
In summary, Smalltalk was an amazing language but its community built walls to keep out the rest of the industry and did not accept that they needed tools to keep their work maintainable through testing (TDD).
I hope you enjoy this 1 hour keynote as much as I did: RailsConf 09: Robert Martin, "What Killed Smalltalk Could Kill Ruby, Too"
Saturday, 24 April 2010
Saturday, 20 March 2010
Six thinking hats - a collaborative thinking system
Edward de Bono devised a simple thinking system called 6 thinking hats which defines how you can approach a problem without descending into argument.
For a long time we have always used argument as a way of discussing ideas and looking for solutions, however argument is very inefficient as its mainly negative and attacking. The argumentative stance can lead to point scoring and antagonism between the persons discussing the idea, leading to a break down in communication.
With the 6 thinking hats approach, people are thinking in the same direction for a short period of time. This same direction thinking, often called parrallel thinking, is highly collaborative and productive. To cover all aspects of the problem, the direction of thinking changes but everyone changes thinking at the same time, maintaining the collaborative nature of the discussion.
This approach helps to open up the topic in discussion and helps avoid any narrow thinking. When considering a problem from these 6 different perspectives you are more likely to establish a robust solution to that problem.
My typical approach is to start with the blue hat to define the objective of the discussion, followed by the white hat to cover all the facts regarding the subject matter.
I perfer to cover the positive thinking before critical thinking, so would follow with the green hat and yellow hats to establish a list of ideas and benefits.
I would then finish off with the red and black hats to help focus on what could practically be achieved and what the team feels is the general approach.
There is an interesting Knowledge Gene on 6 thinking hats for an agile retrospective.
For a long time we have always used argument as a way of discussing ideas and looking for solutions, however argument is very inefficient as its mainly negative and attacking. The argumentative stance can lead to point scoring and antagonism between the persons discussing the idea, leading to a break down in communication.
With the 6 thinking hats approach, people are thinking in the same direction for a short period of time. This same direction thinking, often called parrallel thinking, is highly collaborative and productive. To cover all aspects of the problem, the direction of thinking changes but everyone changes thinking at the same time, maintaining the collaborative nature of the discussion.
This approach helps to open up the topic in discussion and helps avoid any narrow thinking. When considering a problem from these 6 different perspectives you are more likely to establish a robust solution to that problem.
My typical approach is to start with the blue hat to define the objective of the discussion, followed by the white hat to cover all the facts regarding the subject matter.
I perfer to cover the positive thinking before critical thinking, so would follow with the green hat and yellow hats to establish a list of ideas and benefits.
I would then finish off with the red and black hats to help focus on what could practically be achieved and what the team feels is the general approach.
There is an interesting Knowledge Gene on 6 thinking hats for an agile retrospective.
Sunday, 21 February 2010
Getting started with BDD and Kanban
I am starting writing entry points for getting started with BDD and Kanban, now that Blogspot lets me have pages on this blog.
On the BDD page I have done a quick mind map using Freemind in preparation for the BDD immersion workshop with Liz Keogh on the 26th Feb.
On the Kanban page, there is a quick intro to KanBan and some pointers on how to build a KanBan board and the artefacts that you could add to make the board more expressive.
These pages will evolve as my understanding and experience grows. Any comments or ideas for these pages are very welcome.
On the BDD page I have done a quick mind map using Freemind in preparation for the BDD immersion workshop with Liz Keogh on the 26th Feb.
On the Kanban page, there is a quick intro to KanBan and some pointers on how to build a KanBan board and the artefacts that you could add to make the board more expressive.
These pages will evolve as my understanding and experience grows. Any comments or ideas for these pages are very welcome.
Sunday, 14 February 2010
Acceptance-test driving development by John Smart
A summary of the Acceptance-test driving development talk presented by John Smart, principal consultant at Wakaleo Consulting - held at Skills Matter by the Agile Testing user group on 11th February 2010:
Acceptance testing is a a key agile practice, especially in practices such as behaviour drivend development (BDD) and test driven development (TDD).
The main benefit of acceptance tests in agile are not the tests themselves, but the ease in which they allow people to commuicate. The language of the tests is expressed in the business language (industry domain) usually in a simple to understand structured natural language (often with spreadsheet style tables for typical and edge case data examples).
As the tests are expressed in a business language, they can easily come from the business (customer / product owner). As the language used to write the tests should be universally understood in the team, it is easier for the whole team to work collaboratively on them.
Using the Given-Then-When structure of BDD, the acceptance tests are also in the perspective of the user. The tests focus on what the system does and not how the sysem does it (as was mentioned previously at the last agile testing talk by Gojko - this helps keep a seperation between the acceptance tests and the details of the code written).
Acceptance tests are executable!
EasyB, Fitnesse, JBehave and Cucumber are examples of tools that allow you to execute acceptance tests very easily.
Being able to run the acceptance tests at the drop of a hat is a very powerful way to determine when a feature has been implemented in code. The tests can generate (html) reports as well as being integrated with continuous integration systems eg. Hudson CI and web testing tools such as Selenium. All these tools can be integrated as one build process, so when code is checked in or acceptance tests added, every aspect of that change is managed.
How far do you go?
Acceptance tests are very inefficient to debug your code, as are testers and coders. Finding bugs is wasteful, preventing bugs is much more effective.
When writing acceptance tests think in terms of a story, a happy path of how the system would be used. Then elaborate your tests as you become more in tune with the users of the system (users also include other systems)
By writing acceptance tests in terms of what the system should do, avoids those tests becoming a lag by having to refactor your acceptance tests for code changes.
Please review the slides and the video from the event for examples of using EasyB and how easy it is to use the BDD style language of Given-Then-When for writing your acceptance tests. Also, visit the Agile Testing user group and get involved in the agile testing community.
I would encourage to you to visit the Skills Matter website for lots of upcoming talks on agile testing, BDD and many more excellent topics. I am attending a BDD workshop on the 26th February by the formidable Liz Keogh, I recommend looking this course up if you are interested in learning BDD effectively.
Acceptance testing is a a key agile practice, especially in practices such as behaviour drivend development (BDD) and test driven development (TDD).
The main benefit of acceptance tests in agile are not the tests themselves, but the ease in which they allow people to commuicate. The language of the tests is expressed in the business language (industry domain) usually in a simple to understand structured natural language (often with spreadsheet style tables for typical and edge case data examples).
As the tests are expressed in a business language, they can easily come from the business (customer / product owner). As the language used to write the tests should be universally understood in the team, it is easier for the whole team to work collaboratively on them.
Using the Given-Then-When structure of BDD, the acceptance tests are also in the perspective of the user. The tests focus on what the system does and not how the sysem does it (as was mentioned previously at the last agile testing talk by Gojko - this helps keep a seperation between the acceptance tests and the details of the code written).
Acceptance tests are executable!
EasyB, Fitnesse, JBehave and Cucumber are examples of tools that allow you to execute acceptance tests very easily.
Being able to run the acceptance tests at the drop of a hat is a very powerful way to determine when a feature has been implemented in code. The tests can generate (html) reports as well as being integrated with continuous integration systems eg. Hudson CI and web testing tools such as Selenium. All these tools can be integrated as one build process, so when code is checked in or acceptance tests added, every aspect of that change is managed.
How far do you go?
Acceptance tests are very inefficient to debug your code, as are testers and coders. Finding bugs is wasteful, preventing bugs is much more effective.
When writing acceptance tests think in terms of a story, a happy path of how the system would be used. Then elaborate your tests as you become more in tune with the users of the system (users also include other systems)
By writing acceptance tests in terms of what the system should do, avoids those tests becoming a lag by having to refactor your acceptance tests for code changes.
Please review the slides and the video from the event for examples of using EasyB and how easy it is to use the BDD style language of Given-Then-When for writing your acceptance tests. Also, visit the Agile Testing user group and get involved in the agile testing community.
I would encourage to you to visit the Skills Matter website for lots of upcoming talks on agile testing, BDD and many more excellent topics. I am attending a BDD workshop on the 26th February by the formidable Liz Keogh, I recommend looking this course up if you are interested in learning BDD effectively.
Thursday, 21 January 2010
Lean reading - a my current book list of lean
My current reading list is loaded with some highly recommended books on Lean System thinking and the theory of constraints. There are a lot of cross-concepts between these two areas and its been good to compare the ideas together.
Theory of Constraint books:
Theory of Constraints - Eliyahu M. Goldratt
The Goal: A Process of Ongoing Improvement - Eliyahu M. Goldratt
It's Not Luck - Eliyahu M. Goldratt
Lean system thinking books:
Lean Thinking: Banish Waste and Create Wealth in Your Corporation - James P. Womack - I started with the audio book, but have got the paper copy for reference as there was a lot of good stuff to process.
The Machine That Changed the World - James P. Womack
After I have finished the above it will be on to the poppendieck books by that time it will hopefully be time for the new book by David J. Anderson on lean and kanban that is rumoured to be in the works.
Theory of Constraints - Eliyahu M. Goldratt
The Goal: A Process of Ongoing Improvement - Eliyahu M. Goldratt
It's Not Luck - Eliyahu M. Goldratt
Lean system thinking books:
Lean Thinking: Banish Waste and Create Wealth in Your Corporation - James P. Womack - I started with the audio book, but have got the paper copy for reference as there was a lot of good stuff to process.
The Machine That Changed the World - James P. Womack
After I have finished the above it will be on to the poppendieck books by that time it will hopefully be time for the new book by David J. Anderson on lean and kanban that is rumoured to be in the works.
Saturday, 16 January 2010
Personal Kanban for Just-in-time skills development
It is not uncommon in IT projects that you are required to learn something on the fly or you see an opportunity to introduce a new technique or tool that would bring great benefits to a project.
How do you manage the learning curve required for something new without major impact to the project?
After reading comments from my previous personal Kanban post by Jim Benson and Bruce, I thought I would expand on the Just-in-time aspect of Kanban.
I currently use my personal Kanban (LeanKitKanban) to drop small size cards into my backlog that are designed to tell me what I need to learn about a subject or tool quickly. The cards have a set goal that should be manageable in a short time period. Each card would have the relevant resources links to help me achieve that goal.
When I get a spare hour I can select one of these and have a focused, time-boxed cards and get up to speed quickly. If I have met the goal and feel confident that what I have learnt was beneficial (either personally or for current work) then I mark that card as a success. If I don't meet the goal, then I will mark the card as incomplete and review it in a mini retrospective. The goal of the retrospective is to help me write better cards quickly, as well as check that the topics I am learning are coheirent.
An example would be good right now:
I was at the Agile Testing user group in December and there was some discussion on continuous integration. I realised that this area has really flourished since I last set up Cruise Control, so I created a group of cards on my Kanban to look at what's new in continuous integration and to reaffirm that I was up to date with the latest practices. In that same week as the meeting I had manage to review the theory (Google, Wikipedia) and learnt a new tool called Hudson (great tool, I recommend it, neatly integrated with Netbeans). All this was pretty easy to fit into my busy schedule as I could easily visualise all my work on the Kanban and see what was important that week and what could wait.
I still have several continuous related cards in the backlog, but for now I have refreshed enough theory to work with Hudson effectively in my project work. If I need to learn Team City or some other CI tool, then I have a model to quickly tackle that learning.
This approach works for me at present as I break down the task on the card to something managable. I am curious to find out how well I can break a large subject area down with this process, for example learning the whole of Spring 3.
For now I will be using this JIT Kanban learning to review and extend my Behaviour Driven Development (BDD) skills as I have a BDD immersion workshop in February with Liz Keogh at SkillsMatter and want to make sure I get the most of the workshop. It should be a great day of learning as Liz has done a great deal of work defining BDD and adding lean system thinking into the topics that will be covered. There will be some homework to take away from the course, so I'll be using my personal Kanban to organise that work into my busy schedule.
How do you manage the learning curve required for something new without major impact to the project?
After reading comments from my previous personal Kanban post by Jim Benson and Bruce, I thought I would expand on the Just-in-time aspect of Kanban.
I currently use my personal Kanban (LeanKitKanban) to drop small size cards into my backlog that are designed to tell me what I need to learn about a subject or tool quickly. The cards have a set goal that should be manageable in a short time period. Each card would have the relevant resources links to help me achieve that goal.
When I get a spare hour I can select one of these and have a focused, time-boxed cards and get up to speed quickly. If I have met the goal and feel confident that what I have learnt was beneficial (either personally or for current work) then I mark that card as a success. If I don't meet the goal, then I will mark the card as incomplete and review it in a mini retrospective. The goal of the retrospective is to help me write better cards quickly, as well as check that the topics I am learning are coheirent.
An example would be good right now:
I was at the Agile Testing user group in December and there was some discussion on continuous integration. I realised that this area has really flourished since I last set up Cruise Control, so I created a group of cards on my Kanban to look at what's new in continuous integration and to reaffirm that I was up to date with the latest practices. In that same week as the meeting I had manage to review the theory (Google, Wikipedia) and learnt a new tool called Hudson (great tool, I recommend it, neatly integrated with Netbeans). All this was pretty easy to fit into my busy schedule as I could easily visualise all my work on the Kanban and see what was important that week and what could wait.
I still have several continuous related cards in the backlog, but for now I have refreshed enough theory to work with Hudson effectively in my project work. If I need to learn Team City or some other CI tool, then I have a model to quickly tackle that learning.
This approach works for me at present as I break down the task on the card to something managable. I am curious to find out how well I can break a large subject area down with this process, for example learning the whole of Spring 3.
For now I will be using this JIT Kanban learning to review and extend my Behaviour Driven Development (BDD) skills as I have a BDD immersion workshop in February with Liz Keogh at SkillsMatter and want to make sure I get the most of the workshop. It should be a great day of learning as Liz has done a great deal of work defining BDD and adding lean system thinking into the topics that will be covered. There will be some homework to take away from the course, so I'll be using my personal Kanban to organise that work into my busy schedule.
Thursday, 14 January 2010
Personal Kanban to manage personal development
Having an inquisitive minds is a great thing but there can be a tenancy to be interested in too many things that you never learn something deeply enough. How do you stop the inquisitive monster in you mind and get on with just one thing?
I have been using a Kanban system to plan my study and added work in process (WIP) limits to manage the flow so my monster is tamed and I focus on one thing. Any future interests are quickly dropped into my backlog so my monster is satisfied that there is lots more to learn.
I started with a basic design for my Kanban, with the lanes Review, Study and Blogging which nicely followed the plan-do-act design that is often used for visual boards.
After a week of this Kanban design, I felt that something was missing between review and study. When I completed a study task there was not a clear set of tasks I could choose from which I new I wanted to study. I would end up looking at review tasks that I had not finished (or started) meaning more time planning rather than studying. As duplicating planning of study tasks is wasteful, I modified the board design to include a Ready to Study lane so I could quickly choose the next topic.
I renamed Study to Deep in Study to indicate that this was generally a bigger process and I would need to set aside more time. I reinforced the idea that deep in study was a bigger task by limiting the WIP to 2 tasks (I am allowing 2 tasks as I am still detoxing from multi-tasking for far too long).
Once I had completed a study task, the plan was to blog about that topic to help retain the knowledge I had gained. I found it useful to add yet another lane called Evaluating to help me review what I had learnt and had a better idea of what to blog about.
Using a Kanban approach has also helped me develop skills in a just-in-time approach. By adding small tasks to my backlog to help me evaluate new areas of study or tools, I have a pool quick work that I can fit in when I need a break from deeper study. Carrying out a brief review of something new allows me to work out what I need to learn, how much effort it would be to learn and most importantly if it is really worth learning yet. From this quick analysis I can create a number of study and exercise tasks in my Kanban backlog that would help me learn efficiently, indicating effort and priority of each task.
I have been using a Kanban system to plan my study and added work in process (WIP) limits to manage the flow so my monster is tamed and I focus on one thing. Any future interests are quickly dropped into my backlog so my monster is satisfied that there is lots more to learn.
After a week of this Kanban design, I felt that something was missing between review and study. When I completed a study task there was not a clear set of tasks I could choose from which I new I wanted to study. I would end up looking at review tasks that I had not finished (or started) meaning more time planning rather than studying. As duplicating planning of study tasks is wasteful, I modified the board design to include a Ready to Study lane so I could quickly choose the next topic.
I renamed Study to Deep in Study to indicate that this was generally a bigger process and I would need to set aside more time. I reinforced the idea that deep in study was a bigger task by limiting the WIP to 2 tasks (I am allowing 2 tasks as I am still detoxing from multi-tasking for far too long).
Once I had completed a study task, the plan was to blog about that topic to help retain the knowledge I had gained. I found it useful to add yet another lane called Evaluating to help me review what I had learnt and had a better idea of what to blog about.
Subscribe to:
Posts (Atom)
Posts
