Agile Pitfalls

I must admit, I really don’t get some of the scrum “naming” conventions. First of all, what’s the first association  you have in mind when you hear a word scrum? What I imagine is a bunch of big guys, heads down, bottoms up, pushing hard. And Scrum Master? Sounds like a guy you need to obey, not really a service guy as you read in the role description. And then how about calling iterations – sprints? What was wrong with iterations? To me, software development is more like a marathon than a short sprint, unless you can run 400 sprints at once…

picture by © Chris Frazer Smith

Either because of the chosen names, or because of the of the way scrum was originally defined, there are few problems you might get into:

  • Having standup meetings where people report to the Master (if you see guys in the standup circle always looking at the same guy while talking – you have a problem)
  • PO playing an aggressive customer role and pushing folks into DemoDrivenDevelopment Mode (see one of the previous posts)
  • Team forgetting the big picture, with emerging design ending up in no design
  • Team replacing heavy waterfall planning with no planning (how often have you heard of “flat backlog?)
  • Developers feeling constantly under pressure, getting exhausted after “400 sprints”, not having time or energy to play or read

One of the biggest issues with agile introduction is the confusion people have between roles of the scrum master and the project manager. One needs to remove the obstacles in front of the team, while the other one needs to provide the planning to the stakeholders. From the moment that role is shared by the same guy, it is hard to avoid situation in which people see the Scrum Master as the Master. Be aware of that. That’s all I can say. The longer you work with the team and more trust you earn, the easier it will be to combine these two roles.

When it comes to the planning, this is a hot topic, and in my next blog I will explain how I do it. There are plenty of books around, and this time I will only recommend 2 blog posts:

And how about creativity and motivation? Ken Schwaber said once: “Scrum is like your mother-in-law, it’s constantly pointing out your shortcomings.” (for the record, I love my mother in law). It is true that we need to learn from the feedback, but it can as well be tiring and boring – even more if retrospectives are done too often leading to the same conclusions. In one of my previous posts I touched upon this topic “How to do Lessons Learned“, and unless really necessary, I suggest you don’t do them every iteration – you better go for a beer with the team and celebrate if you’ve done something great.

One way of embracing creativity is to introduce “Fed-ex” days. Atlassian folks today get all (TED) credit for it, but as far as I remember, they were not the first guys to try it out. Fed-ex approach is a great way of enhancing existing application with some cool features, or sneaking a new language or framework you want to try out – but you need to be careful there and avoid “pattern-happy” people abusing the concept.

So, put your rugby jersey on, heads up and be ready for the fun, the field is rather muddy first time you try it out.

Demo Driven Development or “Strange Case of Dr Jekyll and Mr Hyde”

Once upon a time there was a software development methodology called waterfall. People disliked it for many different reasons, but today I will only mention one in particular – that it was hard to see anything working, before it was too late.

So, people turned to agile development, delivering business value in increments, during complete project life-cycle, after every iteration. Although Agile Manifesto says quite few things, most of sales guys and PO’s remember only single one: there will be a demo every week or two: and then you hear them saying: oh, yes, yes, finally!!!! Even better, we can finally show something to the customer, get a feedback, bring it back to the development and in the next iteration show the new stuff again… Fantastic, great, beautiful. And it really is. But… there is a catch. Mr Hyde is coming….

What often happens is that agile teams are too focused on development around demos, since this is the only way they are getting evaluated outside of engineering. Obviously, more you show every iteration, assumption is that this team is more productive. Finally, rather than keeping eye on all aspects of software development, team might start making too many shortcuts, leaving dirty hacks and famous //TODO comments all over the place (if they still feel like doing it).

Just as a test, try this in your project, go to the root of your source directory and try this one liner: find . *java | grep -v todo | wc -l

First time I typed this command on my project and saw the number, I almost dropped the coffee on the floor. At first I was surprised, then felt angry, and then betrayed. After all, all these guys who left these traces behind were my good friends and colleagues, and they were excellent coders, just brilliant. So, how was that possible I wondered? Why would someone add reminder and never come back? Was this a message to himself, or to the next guy, like if you go to the toilet and read graffiti on the wall, or was it some kind of subconscious mea culpa sign?

And then I realized – it was me, it was mainly my fault. It was me who always pushed to the limits, who was too much into demo thing… And this is what happened:

Every day, Dr Jekyll would come into to the office and write something fast and dirty, and since he read the book “Clean Code”, would leave the trace behind him, as a reminder to come back later and clean the stuff. At the end of the iteration, Mr Hyde would suddenly arrive, show a demo, write down the feedback, erase the memory of Mr Jekyll that there was something still //TODO and move on again.

So, you may wonder how it all finished for us? Well, we were quite experienced group and we knew when something was really bad. If we couldn’t stand the code smell any more, or if it looked impossible to add a new feature without having a brain damage from trying to figure out how actually existing stuff worked, we would go back to PO and announce that we had to do “big re-factoring thing”. And most of the times it worked out, but unfortunately, sometimes it was too late – we rushed too much.

And finally, this post would not be complete, if I didn’t have 7 rules of how to avoid DDD (Demo Driven Development), so here we go:

  1. Be fast, but not crazy
  2. Review the code – always
  3. Have time to come back, some things are never 100% done (life is never perfect, so it is with some “done features”)
  4. Avoid re-factoring tasks, ask folks to refactor while coding
  5. Not everything can be done between demo’s – some features just need more focus and different planning – more about that in another post
  6. Never ever design API/SDK/NBI in increments
  7. Never add a feature that is half right (notice, I am an optimist, I didn’t say half wrong). Half right is always wrong.