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.

Fighter jet, toothbrushing and agile rituals

When I am in position to talk about the topic that is so “obvious” to me while struggling to find the right words to explain it to the others, I often escape in metaphors, looking for inspiration in nature, other people quotes or anecdotes. Agile philosophy is one of these topics, as it has truly become part of my nature – or it probably always was. When I start talking about it, I very often find myself in kind of schizophrenic mood: saying that agile is a flexible but strict discipline at the same time.  At first, it looks as agile methodology is full of controversy, probably because it insists on practices that look conflicting at first sight:

  • It requires strong discipline of all members while it claims that it is a flexible methodology
  • It requires empowered teams and strong leadership
  • Some people (who actually don’t do agile) compare it to a cowboy coding although agile movement has brought so many novel testing practices

So, the real question is: How to find the right balance between stability and agility? 

Let’s start with my first metaphor for tonight:

The new generation of fighter jets have one design feature in common. They are designed unstable, which is intended to increase agility.

High stability and highly effective flight controls are therefore incompatible requirements. In stable aircraft a compromise has to be made. However, no concessions need to be made in unstable aircraft.

Any pilot will find it very hard to control an aircraft like this without assistance. A computer (“fly by wire system”) is needed to provide necessary stability.

Practices such as standup meetings, iterative development, continuous integration, pair programing, TDD, serve as “fly by wire” system in agile. Although most of these practices should be applied to any methodology, there are crucial to agile, without them agile can’t fly. 

Great, it is all good and settled, so let’s check how it goes with one typical agile team during retrospective meeting:

What was I thinking first time my mother asked me to brush my teeth? I can’t remember, but I don’t think I really enjoyed it. Toothpaste doesn’t taste that great and rubbing your mouth with a toothbrush is not that exciting. While I still do it, I don’t think about it any more (unless I try to write some silly blogs) and that is why we call such activities “ritual” behavior: you do some things not really thinking about how and why you do them.

When you start working, no matter where, on no matter what, there will be things you like to do – aaaaand other things. The same is true for other people around you, sure about it. You may say: hey, hold on a second, how about motivation? Isn’t it all about autonomy, accountability and stuff like that? People will just do it, give them some space, right conditions  and things will happen, no? Well, noooo. Doesn’t really work like that – always. You see, some people confuse motivation and toothbrushing, and this is not the same thing. Your job as agile manager is to do both things, keep people motivated and engaged, and at the same time, sometimes, annoy people by asking them to be consistent. That is most of the time hard with things that they don’t like, part of the job that is not natural to their nature. In that case, motivation really doesn’t help, you need to use some other tricks, or like I put it here: “If you want to keep the ball rolling, make sure it is ticking.” In order to create a ritual behavior in the group, you need to do two things: make the outcome of the activity clear to everyone and fix the frequency when this activity is performed. So, let’s see how to do it:

  • Make the goals clear to everyone
  • Make sure everyone understand his/her part in the big picture
  • Give people space, autonomy and accountability (don’t ask folks to play piano with handcuffs around their wrists)
  • Make the checkpoints visible to everyone – such as percentage of the code tested, the number of bugs found in time, logging of activities in tools (in case you have multi site)
  • For each checkpoint define the activity and fix the frequency at which you want to review the results
  • Check the outcomes
  • GOTO 1

 

Tip: you can use the same methodology if you wish to loose some weight or prepare for the next year marathon.