Posts Tagged SCRUM
… or “What have we learnt so far?”
So, I feel it’s time to get down on “paper”, what we Projectplace and especially the R&D department, have learnt so far from working with a remote development team in Bangalore.
First of all, what is the set up and starting point?
We have one team of developers in Stockholm Sweden together with a team of Interaction and Visual Designers, a team of Testers, a Scrum Master, a Product Council and the Project Owner.
In Bangalore we have a team of developers, a tester and
(soon) a Scrum Master.
Early yet, but we can learn a few things anyway
A developer is a developer is a developer.
Yes there are culture differences and we embrace them, but most of the stuff is the same all over the globe it seems. A developer needs to feel part of the team, have the possibility to learn and grow, be able to raise issues and be listened to. Let the developers in Bangalore find their own way of going by their work, but be crystal clear about the core values and the company strategy! This is not something that is negotiable, if we have agreed on something, stick to it!.
Have someone from the head office onsite, values applies for all!
We have learned that is is vital that someone who knows the company, has deep knowledge about the product and is an ambassador of the core values, is working in the remote site. All the meetings, mails and all can never replace the daily conversations and good examples of behavior.
The core values must of course be implemented everywhere the company operates, they are global for all working for Projectplace. We are on the same team!
Meet as often as possible.
Online meetings, video conferences, telephone calls, however plenty, can never replace in real life meetings! The developers needs to connect with each other, the most efficient way of doing this is face to face. We have had developers in Stockholm going to Bangalore and Bangalore developers going to Stockholm. The longer the stay the deeper and better the results.
Make the remote team independent.
To make the remote team perform, make sure that they feel they have the power to take decisions, especially things that impact their working day. Remove all the obstacles that make decision-making hard and slow.
Communications channels needs to be up and running.
The remote team needs to know what is happening, and especially things that affects their work. It’s frustrating to wait for answers or feedback.
We have tried using Skype, gTalk, MSN, Yammer etc to stay in contact, but we still have a long-way to go.
By the best I do not mean the developer that can write the smartest or fastest piece of code. The best in my mind is the developer with the best drive and attitude, the will to share and lead or really any other trait that will make the group perform and become best. It is totally true that the group will always outrun the best individual, so make sure that the group is happy and performing!
In Bangalore there are a lot of developers and Scrum Masters that have done this before, listen to them, they have the experience that you have not (if you are new to this as we are).
Be crystal clear about the purpose of outsourcing.
The remote team needs to know the agenda! Are we looking long term or is this a short venture? Can you expect more commitment from developers if the company is looking for a long-term relationship? Hell yes!
My impression is that many Indian developers working for medium sized service companies are usually tired of bureaucracy, so they love to be treated as any other employee of the offshoring company rather than as mere consultants. So give them the freedom they need and treat them as you would any other employee. Now you can expect and, and in the long run demand, commitment.
…. to be continued.
I have yet to observe a process that wouldn’t benefit from a dash of Agile. Or why not a really healthy dose. From being frowned upon by many in the late 1990:s, it has become mainstream to realize that there’s something really important in the agile message. Whole companies are run with agile values at the core. Like IKEA. Like H&M. (Yeah, I’m from Sweden.) Or Toyota (Lean is very, very similar to agile. I’d say that at the core it’s the same thing.)
While more and more people are trying to relate to the concept of agile, we also run the risk that the meaning is devalued and kidnapped. It’s highest fashion to label yourself Agile. There are several problems with that. If you fool yourself you run the risk of not going at your full potential. Or if it’s just “play pretend” you risk really fooling others and they might not realize for a long while that they could have ran so much faster. And of course, false agile also risks giving the “movement” a bad name it truly doesn’t deserve.
You find lots of people that say they are agile. Yet, when you probe it some it’s clear that it seems to have totally different meaning to many. Like it didn’t matter. But it does matter! Agile is a stance, an attitude, a philosophy, a core value even. It’s something you must comprehend. Something you must give some time to soak your being. Something you must truly believe in before you have the right to use the label. I’m totally sick of hearing people excuse shortsighted moves with a sloppy “we are agile”. That’s wrong in so many ways. Agile is all, 100%, totally and utterly about sustainability, about the long term.
All “casual” agilists out there should be forced to really try an agile process. Why not Scrum? Of course, running Scrum doesn’t make you agile. But you can’t give Scrum a real chance without starting to get an idea about what the concept of agile is about. Then hopefully the casuals will be humble enough to first stop calling themselves agile and then working hard with themselves and their views to really earn the label.
Or maybe they’ll find that it’s not for them. I don’t think agile leaves many people indifferent (given that they given it some thought and started to grasp it). Rather, you either love it or hate it. When the agile values become clear to you there are no longer any gray areas. If you have a strong belief in your fellow human beings you’re likely to find agile being your thing. At the very core of agile there is this strong conviction that most people really want and can contribute. In agile land there’s no room for cynics.
Does your organization want the agile label? Then start with removing all processes that are in place for monitoring that people contribute or are doing their jobs. Install mechanism that make it clear to people what’s expected of them and what they can expect from others. Make each and every process fully transparent. Demand authenticity from everyone, including yourself. Make sure you learn from experience, good, bad, in-between. Yours and others. Don’t save any effort, whatsoever, to enable communication. And keep asking yourself, every day, every breathing moment. Are there some remains, somewhere, of your non-agile past? Hunt them down. Remove them! Ban phrases like “that’s not how we usually do it” and “we’ve already tried that”.
I blame the financial crisis on our disability to learn from our experience. We’re in it because we overstimulated the economy (I think few people actually argues with that.) And we were in the last mess for the same reasons. Yet, when the leaders of the world, people who supposedly should be the best we have for dealing with these big issues, when these leaders tackles the problem all they can think up is to stimulate it more. People are demanding more. Already stimulus worth 5 trillion US dollars has been launched or decided and they plan to make that a lot more. Now if that isn’t a failure to learn from mistakes, then what is?
Learn from your mistakes. It’s said often. Yet, when I try to focus my surroundings on what we can learn from the situation we’re in right now, I feel like I’m often not heard. Almost like if people (probably including myself) shy away from thinking too much about the past. Nextopia, by Micael Dahlén, seems to explain why this is so. Evolution has favoured looking forwards, rather than backwards.
I have to agree with Nextopia here. When you’re about to do something of any importance it’s crucial to focus forward. But I’m equally sure about how important it is to also learn from the past. And when better to do it than when the past is just a few hours, days or weeks away? Håkan Åberg correctly identifies this in his blog about drawbacks (sorry, only in Swedish). Though I wouldn’t limit the importance of learning to mistakes. It doesn’t really matter if things went extremely well or disastrously bad or anything in between. You have to make sure you learn from experience, your’s and other’s.
Agile, stay agile!
Being a big fan(atic) of agile values and principles and having good experiences from running and participating in SCRUM and XP projects I’d say that you could probably skip all SCRUM principles, but one, retrospectives. Correctly applied, even if you’re running the most rigid process to begin with I bet that you’d end up with something rather SCRUM-like after a few years or so. However, running SCRUM by the book in all but retrospectives you’ll probably end up in a big mess instead. Well, no, daily stand-up meetings, lots of communication and other things important in SCRUM will probably save you from drowning, but you won’t go at your full speed possible.
Play to win or don’t play at all
To reach full speed you need to learn from experience. And going at your full speed is what it takes to win and keep harvesting victories. I’ve found that it’s good to train your awareness about when you’ve just experienced something. When the bell rings it’s time to take a few seconds to ponder; “what took me to here?”, “where could I have ended up instead?”, “what would have taken me there?”. And this should be a recursive process. You’re looking for the root cause, not just some symptoms on the way.
At Toyota (whohoo, you saw it coming?) they take this with finding the root cause really seriously. They apply a technique called The five whys. Keep asking why until you find the root cause. This sometimes takes five whys, sometimes less. Say you’re manufacturing ski jackets. A customer calls complaining about a loose button on her almost new jacket. That I’m-experiencing-something bell rings. Why did we ship a sub standard jacket? Because the button was probably not loose during the quality assurance. Then, why is that button loose? Because the sewing thread gave away. Why did it give away? Was it because the thread was too weak? No. Then why? Because the edges of the holes in the button are too sharp. OK, so inform the subcontractor that we need buttons with smooth hole edges. And make sure the subcontractor applies five whys too find out why they shipped those buttons. But.. why didn’t we find this problem when we tested the jacket design? Because back then the buttons where different, we changed it later when we found out that they were hard to use with bare hands in the cold. Why didn’t we rerun the button stress test when we changed the buttons? Because we forgot. Why did we forget that? Because our checklist doesn’t enforce it. Fix the checklist. But also take some time to reinject the awareness of your company’s high quality values in your organisation. This shouldn’t have happened regardless of the shape of that checklist. Buttons are probably popping from lots of those jackets out there without the customers telling you. You’re brand just took a blow. Don’t let it happen again. Learn.
Movie sequels often miss because?
Alright, so that was a bad experience. Evaluating a success also should seek that root cause. But to my experience that’s not as linear as five whys. It’s more about not jumping to conclusions. I know not all agree with me, but I just don’t think The Matrix Reloaded was nearly as good as the first Matrix movie (which I hold as one of the best movies ever made). They reloaded it with the wrong things. They jumped to conclusions I think. It’s like they thought that the really cool thing with the first movie was those never-seen-before special effects. Wrong! Those were cool, but not the really cool thing. Personally I think that what made The Matrix so cool was something about the story itself. I think that if I had been in charge I would have encouraged my team to not spare any effort in evaluating what really was the thing. And then of course to think really hard about wether it was even possible to advance things with a sequel. Maybe it would have been better to try find out what caused that story to emerge and see if it was possible to find more good stuff at the well.
In big and in small
Five whys. Sounds heavy? It isn’t. But even so there are lighter practices that one can apply too. Like before you go to sleep, think a bit about the day. Figure if there where good stuff that can be improved even more and/or you should do more often. Or were there some drawbacks that you really could have avoided. Did you remember to spread some happiness around you today? You get the picture. When you’re going to sleep it’s not a performance anyway so looking backward some won’t hurt. When you rise to meet the next day you can apply full focus forward again.