There is a real challenge to improve the way you work whilst still retaining and increasing the amount of value you can deliver to your organisation.
The more people have the opportunity to step back and consider how they "get things done" the more opportunity there is for improvement. It is tragic that most people are of the mindset that they are too busy to consider how they work as they have deadlines, this mindset is often driven by the system that is the organisation.
Until you can step back and really understand the work you have little appreciation of the wasteful activities you do and therefore can really only "solutionise". Anything you that is not based on some "fact finding" seems little more than guess work or just following a trend and hoping for the best.
Wednesday, 23 March 2011
Saturday, 19 March 2011
Smallest Responsible Change (was Minimal responsible feature)
Whilst discussing the merits of Behaviour Driven Development at one of the XTC gatherings, I started using the term minimal responsible feature as a way to express how to decide what piece of work to tackle next. I promised Liz Keogh many moons ago that I would write a blog post about it.
In the time it has taken me to write this post (its been kicking around in my backlog for a while) I have evolved my thinking on the term and now prefer to use smallest responsible change (SRC).
The smallest responsible name was triggered by looking at the term minimal marketable feature (MMF), considering what that term expressed and the values that I associated with it. I still like the MMF term as a more specific way of expressing a similar concept. With the smallest responsible change I have a term that I am happy to use in a wide range of contexts which helps promote discussion on how to be effective and make value flow.
Smallest responsible change is a nice general expression of how I like to tackle the work I do, so that the work flows more smoothly and I get more done. Creating a very effective way of turning large body of work into a series of value deliveries.
Smallest
I try where ever to tackle a series of smaller tasks that one big task. This approach tends to earlier feedback from the results of that work.
For example, when writing some new functionality, I will pick out a single piece of behaviour from the requirements (user story, use case) and express that behaviour in a scenario / example (a.k.a acceptance test / unit test). Once the behaviour is defined and implemented by code, I am already getting feedback on the work I am doing. Any feedback from running the behaviour scenarios (a.k.a tests) I receive shapes the next task. If a failing test still fails, I know I need to work on the implementation code. If a passing test now fails, I know I have to look at the code and design and maybe refactor.
Responsible
What does it mean to be responsible? You ask ten people you will get 10 different answers. This is not surprising as our experiences and feelings about a situation come from a unique history - our life to date.
The decision on what is a responsible action to take is therefore based on our current circumstances and our previous history, with hopefully a good dash of holistic thinking.
To be able to define and select the next most responsible action to take therefore requires you to think about your circumstances and base your actions on achieving value.
For example, if you a person next to you collapsed it may be the most responsible thing to try and give them immediate attention if you had basic first aid training. If you had no first aid training, then a cry for help may be the most responsible thing. If there is no one around, then a call to the emergency services may be the most responsible thing to do.
In software development, if you submit code that breaks the build and the build bunny shames you, it could be the most responsible thing to roll back you code. It could equally be the most responsible thing to call over some of your team and ask them what is going on (someone may have forgotten to tell you about an API change). It could also be possible that this issue is always happening with the team and you suggest the team get together and find the root cause to the problem.
Change
Change is happening all the time around us and we need to manage and filter all those changes so we can actually move forward (without a break down).
If you consider the way the brain works with the eye, the eye captures a constant stream of change so the brain has to filter out and focus on just what is important. If it were not for this filtering effect our brain would be overwhelmed.
It is important to limit the amount of change we are dealing with at any moment in time, so the changes are experienced at the rate we can acceptance and deal with them. It may be seen as heroic to work 12 hours a day and multi-task like crazy, but that is less likely to deliver significant value to your company than if you work at a pace you can sustain. If we can find a way to filter out changes (tasks) that are of no value at this time, then we can really focus on those few changes that have real value.
Example from a personal development context
If I want to read a book, what is the smallest responsible change I can do. Well, I often define a card on my kanban board to define the value I believe I will get from reading the book and some idea of how to attain and check that I gained that value (or perhaps see if there was anything else I gained). This is the smallest thing I can do and it is probably the most responsible thing to do as well.
Part of this first smallest responsible change may be to decide how to read the book and I have a common approach of reading chapter by chapter and also treating the book as if I were reviewing it for others. So the next smallest responsible change would be to read the first chapter and start to write down my impression of the book and anything important I had learnt.
The feedback from reading the first chapter may be that I think the book has mislead me about the value I would gain and I would therefore abandon reading any further. This feedback would then save me much time in the future, as not only would I skip read the rest of the book but I would have a reason as to why I dont want to try read the book at a later date.
If I tried to do this with several books at the same time, increasing the amount of change I was dealing with, there would be a lot of context switching between the information in each book, even more so if the books were on different topics. I would have to unload and reload different ideas from each book as I switched over. It would be very easy to mix my impressions and feedback from one book with another and hence make an incorrect value judgement.
In the time it has taken me to write this post (its been kicking around in my backlog for a while) I have evolved my thinking on the term and now prefer to use smallest responsible change (SRC).
The smallest responsible name was triggered by looking at the term minimal marketable feature (MMF), considering what that term expressed and the values that I associated with it. I still like the MMF term as a more specific way of expressing a similar concept. With the smallest responsible change I have a term that I am happy to use in a wide range of contexts which helps promote discussion on how to be effective and make value flow.
Smallest responsible change is a nice general expression of how I like to tackle the work I do, so that the work flows more smoothly and I get more done. Creating a very effective way of turning large body of work into a series of value deliveries.
Smallest
I try where ever to tackle a series of smaller tasks that one big task. This approach tends to earlier feedback from the results of that work.
For example, when writing some new functionality, I will pick out a single piece of behaviour from the requirements (user story, use case) and express that behaviour in a scenario / example (a.k.a acceptance test / unit test). Once the behaviour is defined and implemented by code, I am already getting feedback on the work I am doing. Any feedback from running the behaviour scenarios (a.k.a tests) I receive shapes the next task. If a failing test still fails, I know I need to work on the implementation code. If a passing test now fails, I know I have to look at the code and design and maybe refactor.
Responsible
What does it mean to be responsible? You ask ten people you will get 10 different answers. This is not surprising as our experiences and feelings about a situation come from a unique history - our life to date.
The decision on what is a responsible action to take is therefore based on our current circumstances and our previous history, with hopefully a good dash of holistic thinking.
To be able to define and select the next most responsible action to take therefore requires you to think about your circumstances and base your actions on achieving value.
For example, if you a person next to you collapsed it may be the most responsible thing to try and give them immediate attention if you had basic first aid training. If you had no first aid training, then a cry for help may be the most responsible thing. If there is no one around, then a call to the emergency services may be the most responsible thing to do.
In software development, if you submit code that breaks the build and the build bunny shames you, it could be the most responsible thing to roll back you code. It could equally be the most responsible thing to call over some of your team and ask them what is going on (someone may have forgotten to tell you about an API change). It could also be possible that this issue is always happening with the team and you suggest the team get together and find the root cause to the problem.
Change
Change is happening all the time around us and we need to manage and filter all those changes so we can actually move forward (without a break down).
If you consider the way the brain works with the eye, the eye captures a constant stream of change so the brain has to filter out and focus on just what is important. If it were not for this filtering effect our brain would be overwhelmed.
It is important to limit the amount of change we are dealing with at any moment in time, so the changes are experienced at the rate we can acceptance and deal with them. It may be seen as heroic to work 12 hours a day and multi-task like crazy, but that is less likely to deliver significant value to your company than if you work at a pace you can sustain. If we can find a way to filter out changes (tasks) that are of no value at this time, then we can really focus on those few changes that have real value.
Example from a personal development context
If I want to read a book, what is the smallest responsible change I can do. Well, I often define a card on my kanban board to define the value I believe I will get from reading the book and some idea of how to attain and check that I gained that value (or perhaps see if there was anything else I gained). This is the smallest thing I can do and it is probably the most responsible thing to do as well.
Part of this first smallest responsible change may be to decide how to read the book and I have a common approach of reading chapter by chapter and also treating the book as if I were reviewing it for others. So the next smallest responsible change would be to read the first chapter and start to write down my impression of the book and anything important I had learnt.
The feedback from reading the first chapter may be that I think the book has mislead me about the value I would gain and I would therefore abandon reading any further. This feedback would then save me much time in the future, as not only would I skip read the rest of the book but I would have a reason as to why I dont want to try read the book at a later date.
If I tried to do this with several books at the same time, increasing the amount of change I was dealing with, there would be a lot of context switching between the information in each book, even more so if the books were on different topics. I would have to unload and reload different ideas from each book as I switched over. It would be very easy to mix my impressions and feedback from one book with another and hence make an incorrect value judgement.
Whats in a name - Lean Agile machine
I chose the name lean agile machine for this website and my company in part as a parody on the term lean mean machine. I was looking for something that expressed the concepts I was interested in at the time lean system thinking and agile software development.
I try approach everything in a lean manner, by focusing on those tasks that provide the most value and guide me towards my goals. Goals are set in terms of my own direction but also along the lines of reciprocity, aiming to deliver as much value to my clients and to colleagues I work with.
The agile aspects of my approach get people involved as they are best placed to achieve goals when they are empowered and are allowed to define and carry out meaningful work.
These two practices combine to drive much of the social interaction of my life (work, play, cycling, etc) and help me define my values and goals in life. They also just happen to be useful approaches to sofware development and IT in general, which is lucky as that is the world in which I mainly work in.
Lean and agile principles provide many practices to help shape the effectiveness of the services I provide to a customer or employer. To me, delivering a software solution is a concequence of social interaction and understanding generated with clients and colleagues. The actual goal being to build relationships that are productive and help those people involved reach there respective goals - whether that be a big house in the country - married with children - a global traveller - a successful and sustainable business.
I try approach everything in a lean manner, by focusing on those tasks that provide the most value and guide me towards my goals. Goals are set in terms of my own direction but also along the lines of reciprocity, aiming to deliver as much value to my clients and to colleagues I work with.
The agile aspects of my approach get people involved as they are best placed to achieve goals when they are empowered and are allowed to define and carry out meaningful work.
These two practices combine to drive much of the social interaction of my life (work, play, cycling, etc) and help me define my values and goals in life. They also just happen to be useful approaches to sofware development and IT in general, which is lucky as that is the world in which I mainly work in.
Lean and agile principles provide many practices to help shape the effectiveness of the services I provide to a customer or employer. To me, delivering a software solution is a concequence of social interaction and understanding generated with clients and colleagues. The actual goal being to build relationships that are productive and help those people involved reach there respective goals - whether that be a big house in the country - married with children - a global traveller - a successful and sustainable business.
Friday, 4 March 2011
Kanban games night
Karl Scotland and I will be running a free games night at Skills Matter on the evening of 7th March at SkilsMatter - London, UK.
Karl has kindly volunteered to run the games night before his talk at QCon later in the week. Karl will be running the ball flow game to help us learn and experience kanban and system thinking concepts in a collaborative way. It will also be a lot of fun, as fun is an effective way to learn.
You should get a lot out of this evening whether your experienced practitioner or you are completely new to kanban, lean, system thinking and theory of constraints. The evening will be a welcoming and safe environment to everyone.
Rough plan for the evening:
6.00 pm An opportunity to networking, chat to people
6.30 pm Start to the evening proper: Introduction and games
8.00 pm Retire to the Hat and Feathers for further discussions (optional)
Event sign-up
The hat and feathers is on the corner of Clerkenwell and Goswell road. You are free to join us there if you cant make the event.
Thank you
John Stevenson | @JR0cket | JR0cket.co.uk | JR0cket.com | LeanAgileMachine.com
Karl has kindly volunteered to run the games night before his talk at QCon later in the week. Karl will be running the ball flow game to help us learn and experience kanban and system thinking concepts in a collaborative way. It will also be a lot of fun, as fun is an effective way to learn.
You should get a lot out of this evening whether your experienced practitioner or you are completely new to kanban, lean, system thinking and theory of constraints. The evening will be a welcoming and safe environment to everyone.
Rough plan for the evening:
6.00 pm An opportunity to networking, chat to people
6.30 pm Start to the evening proper: Introduction and games
8.00 pm Retire to the Hat and Feathers for further discussions (optional)
Event sign-up
The hat and feathers is on the corner of Clerkenwell and Goswell road. You are free to join us there if you cant make the event.
John Stevenson | @JR0cket | JR0cket.co.uk | JR0cket.com | LeanAgileMachine.com
Subscribe to:
Posts (Atom)
Posts
