The Insufficiency of Scrum is a Fallacy

the insufficiency of scrum is a fallacy perpetrated by teams that don’t step up their practices in concert with their planning and don’t really want to make it work anyway. you can fail doing kanban, xp, merise and ssadm just as easily unless you have good engineering practices as well.

the goal of agile it to have you fail sooner and for it to cost less. so what happens when you try to make your management practices more agile but forget about your engineers practices?

well josé manuel nieto contacted me on twitter after joining a team that was suffering from what he called the insufficiency of scrum and asked for thoughts and after a conversation some advice.

@ mrhinsh hi, what do you think about the thoughts i published? "the insufficiency of scrum" wp.me/p33uli-5k

— josé manuel nieto (@superjmn) march 23, 2013

when we fail at something it is only human to look for something to blame other than ourselves as the implementers and the things that we did not take care of.

we have to accept the fact that no process is perfect and that we will need to work hard at anything to make it work. unfortunately we worked at traditional software development for over 40 years to prove that it did not work. but that is not really true…. it works in the small scale or if we are building something simple. i can’t think of any modern software that is either of those things. however agile is not a silver bullet. i will say that again… agile is not a silver bullet and you should read scrum is hard to adopt and disruptive to your organisation .

@ mrhinsh it was agile until bugs started to riddle the app. scrum only has short-term planning.

— josé manuel nieto (@superjmn) march 23, 2013

most of the agile frameworks only cater for planning the ‘what’ and tells you to let the team decide on ‘how’ to build the software. scrum, kanban & scaled agile all focus on the management process not the engineering practices. this does not mean that you don’t also need good engineering practices, and in fact the scrum guide explicitly tells you that your team needs “good engineering practices’ in order to succeed.

figure: testing is core to inspecting and adapting your engineering practices

if you don’t have those good engineering practices then you will spend more time sprint on sprint struggling with the technical debt that is built up and you will end up down an engineering blind ally.

@ mrhinsh right. it lacks all of those -able adjectives. but, how to recover from the mess. how to refactor?

— josé manuel nieto (@superjmn) march 23, 2013

but now i am hosed, how to i get out of this?

step 1: hold effective retrospectives to prevent the insufficiency of scrum

on of the reasons our team gets into this position is that they did not know that they was in a broken state until it is too late. if our organisation fails to understand the purpose of the retrospective as an inspect and adapt moment for ‘how’ we worked during our sprint then one will fail to improve.

@ mrhinsh it was as soon as i entered the team. 6th sprint.

— josé manuel nieto (@superjmn) march 23, 2013

the accountable and responsible party here is the scrum master. without an effective scrum master to guide the team you will fail. if you do not have an effective scrum master then you or they don’t fully understand the 42 tasks for a scrum master’s job .

according to the scrum guide the development team can ‘choose’ their scrum master to make sure that they get some one as effective as possible.

yes, this also means that they can ‘un-choose’ their current one.

step 2: stop creating technical debt to prevent the insufficiency of scrum

you need to first stop creating technical debt. to do this you only need to focus on one thing; working software at lease every 30 days . if you are not able to create working software every sprint then you need to stop and look at why that is.

note i prefer ‘working software on every checkin’ and ‘continuous delivery’. that way i can ship working software at any time.

now i am not talking about that flaccid rendition of working software that lead you to this place of horror and despair. but instead take ‘working software’ at face value and have it mean ‘everything that i have delivered works with no further work required’. does that mean that it meets the customers expectations? no it does not; unless their only expectation is for what you show them to work with no errors and that if they say ‘ship-it’ you can deploy what you have. if you have to reply with… “well, maybe next sprint as we still have some bugs.” then you have failed as a professional and as a team to deliver the minimum bar.

but if we do get into that state then you are in the very same ‘brownfield’ situation as software that have been built over years with no unit tests. so if the primary goal now is working software that meets our customers expectations and we augment our definition of done to reflect that then we will be delivering less features of higher quality.

figure: there is 1000% return of investment for every test written in tdd

while we are still paying back our excessive build up of technical debt, using those engineering practices that will prevent future build up, we will be delivering less value to the customer.

conclusion

remember that the software that you are building is an organisational asset and decisions to cut quality affect the value of that asset and thus must be reflected in your organisations financial statements .cutting quality in your software without first gaining the approval to do so from your financial executives is unprofessional at best and fraud at worst and always incompetence.

don’t be incompetent. don’t commit fraud.

be a professional…