It’s all my fault – own All your work


It's not how good you are, it's how good you want to be.
What more can you ask for…
This post springs from one of the ideas in “The world’s best-selling book”, some of which are listed here. Rather pithily, this one states: It’s all my fault.
Which is the author’s way of asking you to take total responsibility for any piece of work you have touched. As the book continues: “If you accept responsibility, you are in a position to do something about it … … There are no excuses.”
This should apply to all members of an Agile team, more so to the developers. The decisions taken right from the beginning – whether its the technology to use, the practices to follow, the stories to develop and those to discard etc – they all matter and decide in the end if the team ends up using their skills to work through non productive issues or if they used their judgement to avoid them and get more work done in the longer run. So from the start of the project, take responsibility – be involved in the conversations and decisions – so far as you are concerned, it’s on your head if things don’t work out as needed.
This also applies to the project you are part of right now – there is no opportunity better than the one in hand. Working on a legacy project with no unit tests and no structure to facilitate them? Implement refactoring to at least get unit tests around anything you put in. Not getting time allocated for refactoring stories? Include them as part of the normal tasks. The cost of a story includes maintaining a healthy codebase for future work.
Your team members not aware of or interested in good design/practices? Educate them – hold lunch time talks, try to understand their fears (change is usually scary) and help them overcome those. If this is done in a respectful way, it will become increasingly difficult for the holdouts to continue insisting the way it’s been done is the right way. Be aware that a lot of resistance can be explained by ignorance – I’ve had to explain things like why objects should contain behaviour, not just properties, why that behaviour is important to work out before deciding on the database structure etc.
“If you are using arguments on the left to justify
refactoring, you’re screwed” – Martin Fowler

By letting go of the excuses and taking responsibility, one can look for and find ways to do what’s needed. An example would be to follow the experts in the field and figure out where things may have been done wrong, as I found out when I came across the tip from Martin Fowler given in the picture on the right/above.This should lead to widening your horizons and looking at beyond your role in the team and appreciating what restrictions those higher up the chain are under. Helping them work around those without stepping on their toes would be an ideal solution, if possible.

An important idea here is to embrace constraints: there’s never enough to go around.  It is unlikely that any project you work on has everything provided ideally – from the resources to intangibles like motivation/knowledge of the team/management. For example, a team/company that has not experienced an Agile workflow or the benefits of a loosely coupled, well written code base will not immediately agree to Scrum/Kanban or TDD respectively. Assessing what’s possible and implementing that change in a way acceptable to the majority can be a worthwhile goal in a difficult situation. To take the first step on that journey, the idea of owning all that you work on would be a good start.

Another way this kind of responsibility can be expressed is by looking out for ways around potential blocks you can visualise in future. I’ve had a chance to do this by volunteering to work on porting a MVC2 project to MVC4 along with replacing the DI layer over the Christmas break. More recently, when that project had to increasingly call our second big application, on the suggestion of another developer,  we’ve started implementing micro services for the newer functionality as a start of breaking down the two monoliths instead of tightly coupling them by dll references.

Having personally worked with people who do put in this type of commitment to their daily work, I am certain this is something everyone should aspire to. Even if not all that is desired for is not achieved, the project and the team members are better off for such efforts, as I hope you’ll find out if you give this a try. If you do, try and let me know how you get on.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s