Scrum with pen & paper
A friend of mine recently asked me if I'd know any good freeware tools for use with Scrum. Well, I told him, I don't have any first hand experience with freeware Scrum tools but there certainly are a few.
However in the case that you're just starting with Scrum I would argue that you might be better off without tools. All tools force you into some kind of process that works for somebody else, but might not be optimal for you.
So instead of jumping to a fancy tool that comes with all the bells and whistles instantly, I'd recommend starting as low-tech as possible, learn the basics and discover your individual needs. After that you are enabled to get the Scrum tool that does exactly what you need it to do.
How do you start low-tech? Use pen and paper.
Estimation techniques compared
I was inspired to write this article by several threads in forums covering agile methodologies. The basic discussion was whether to estimate based on Story Points or time. To me - and most people participating in those discussions - there is no silver bullet and you will have to find out what works best for you yourself. In this article I'd like to muse about the various estimation techniques that I'm familiar with as well as the pros and cons that I ran into with each of them.
I will compare PERT and COCOMO, both being traditional techniques with a long history and Planning Poker, probably the most prevalent agile estimation technique.
All techniques have their pros and cons and it will be up to you to determine which technique will work best in your environment.
My comparison is purely based on experience, which is broader for PERT and more narrow for COCOMO and to some extend Planning Poker. Your mileage may vary. This article does not intend to be the definite guide on estimation techniques.
That being said, let's start shall we?
The power of free gifts
I'd like to share an experience with you that I had a couple of days ago. Although this happened in the physical world I believe there are a few lessons to learn for online business and online marketing / sales.
I own a bike here in India, the Royal Enfield Bullet. The apartment I live in provides each tenant with a (car sized) parking lot. So my bike spends quite a bit of time next to an Innova van owned by a business man.
The sheer number of people in India makes labour really cheap. Not to have a maid for house keeping is rare. Even employing a maid, a cook and a driver does not raise many eyebrows when you're in the middle management.
While I have none of those yet, the gentleman owning the Innova does employ a driver. The driver also washes the car every other day. That guy is a nice fellow and although his English is really bad, we're greeting each other and have a three half-sentence long chat every now and then.
My experience I'd like to share started on the day where he started washing my bike.
Responsibility vs. Freedom of Decision
I'd like to talk about what I call the "Responsibility vs. Freedom of Decision" conflict. You could also call it the "Delegation vs. Trust" conflict.
What I mean by this is: A job is delegated to you and it is made clear that you are responsible for the success of that job. This can be the implementation of a feature, managing a new client, bringing a certain amount of business this year, correctness of your project estimation, whatever. The responsibility is made yours, but you can't make the decisions required to get the job done most effectively and most efficiently. You have to stick to what someone else thinks is best.
In this conflict, the course is already set. You're standing on the command bridge of a proverbial ship where all controls have been removed. Yet you are responsible for the save arrival of all passengers. Sounds familiar?
It is important to me to make clear that this is not an issue only affecting non-management employees. It affects everyone in a hierarchy.
I recall one particular incident which I'd like to share. I was the assigned consultant for a new client. The responsibility was to identify all tasks required for that project and come up with an estimation. I did and do that regularily. The catch? We already knew the maximum budget the client had, and also the required release date. In fact the offer had already been sent and signed based on both. Even worse, a quick glance through the requirements made it clear that it was unrealistic to expect everything in good quality, for that budget, at that date.
At that time we did estimations mostly for the purpose of creating a realistic offer, only rarely were these estimations used internally for quality control and such interests. In that regards, an estimation was not required anymore. Think about this. If the goal of the job (a realistic offer) is already obsolete (offer had been sent and signed), the job itself might be obsolete as well. Nonetheless I finished that estimation as I saw a chance to track the actual efforts and compare it to my estimation after the project was over.
The estimation caused a huge uproar in the management, who claimed it was too high. I had a long discussion to convince them that the efforts are realistic - in the end it took a second estimation done by a colleague who came to a similar figure. Nonetheless the client had been convinced that time and budget were fine and no one wanted to change that. So there I was, responsible for a project that I already was convinced would not meet time, budget or quality (pick one), yet unable to do something about it.
I believe everyone of us can recall a similar scenario?
Of course I am not free from comitting the same crime. I have a vision for a new feature and stake out the route I believe is best and 'convince' my team to stick to that. But during development they might learn that another approach might be better. Yet, I staked the route, so they will tend to try to follow it. My fault, not theirs.
Yet I frequently see that if decisions are left to the team, after a learning period they usually come up with pretty clever ideas. They prove that I can trust them. Sure, guidance and mentoring is required every now and then but that is good - I hope not to become obsolete any time soon.
This is a call to all managers and leaders out there to trust your people. Give them the responsibility, delegate to them, but don't forget to give them the power and freedom do act as they see fit at the same time.
By no means do I want to advocate anarchy. Rules and guidelines are there in all but the smallest of organizations. They are there for a reason. So yes, we have to stick to that rule. Unless they make no sense and you can prove it. What is wrong with that? I don't see the point of sticking to a regulation 'because it is there', knowing that another approach might be better, faster, cheaper.
Managers! Trust your team! Let them make their own decisions! Ask for their opinion and listen to it! Mentor them instead of keeping them on a short leash.
Team! Learn to say no! Do what is right, not what is easy! Be opinionated and share your thoughts and doubts! Make suggestions, especially when no one wants to hear them!
How about you? Did you experience similar conflicts? Let everyone know how they were resolved. I'd really like to know so leave your comments!
Scrum and fixed price contracts
I'd like to draw your attention to a discussion that was in the Scrum Development group on Yahoo titled Scrum and fixed price contracts.
Go and read the thread for quite a few interesting points. In a nutshell though, the question was how Scrum can help in fixed price contracts. I think that's an interesting question since at first sight a fixed price environment - and hence a fixed time environment - is contradictory to the agility that Scrum offers in terms of rescheduling tasks that have not begun yet, replacing items with others etc.
The consensus in the Yahoo group seems to be that fixed price contracts generally are a bad idea, will fail and that Scrum will not help you with that other than in damage control.
Well, in part I agree to that. Fixed price environments are tricky. Maybe they come into place because the client does not trust the agency, maybe it is a new relationship. Maybe they come to be because the sales staff of the agency gives the wrong impression in the first talks and no one dares to tell the inconvenient truth to the client after that, before the contract is written.
Maybe it is just how it always has been and we've all grown used to the process and the suffering involved?
I agree that some clients are politically important, door openers, key players. Whatever you call them, you will want a contract with them. Not for the sake of that contract but because of the things you believe you can get after that first contract runs well. And yes, in that situation it might not be very important to make profit on the initial contract.
But let's muse a bit on that thought. What good is a disappointed door opener client?
‘Resources’ or ‘Team’?
My friend Raj just posted a new article on his website on 13apples.com about what I would call respect. I believe every one of us, working in IT or not has encountered a situation similar to the one he describes: Being called a 'resource' and how disrespectful that feels.
I can't help but think that this behaviour of considering the printer paper and the developer team as 'resources' alike must come from companies where the people that plan the work are so far away from where the work is actually done that there indeed is no difference between the printer and the system architect.
Luckily I use to work for rather small companies, where this is not so much a factor. Yes, there also is a 'human resources' department but it doesn't feel like that. If you meet the head of HR while fetching a coffee in the morning and the conversation starts like 'Hi Eva, how have you been?' rather than 'A very good morning Mrs. Koul, I hope you had a pleasant weekend?' and continues with swapping the latest gossip rather than stock market tendencies most of the battle is already won.
It is on each and every one of us to treat everyone with respect. A couple of years back I used to say that 'I'm not here [at work] to make friends' but I realized over the years that it is actually really helpful to be friends with everyone around you. Friendship is about give and take, we all should keep that in mind.
What I do is my passion and I realize that this is not necessarily the case for every other member of the team. For some, IT is actually just a job. It took me a while to realize that and to accept that it is perfectly ok this way. Probably most other industry sectors are much worse at that than IT.
Coming back to respect, I realized that it pays off to treat the people who work with and for you with respect. Kind of obvious when you think of it but knowing it and acting like it are two separate pairs of shoes, right? Treating people with respect obviously includes the team of developers. But I realized that this also includes a few other groups:
The back office people who book your train tickets for business trips and your hotels, they might actually see to it that you have a pleasant trip, not only that the company saves every possible penny.
The system admins who replace your defective keyboard without you filing a ticket in the support system first.
The graphic designer who might just give you those five icons you'd like to have in his free time because he likes the idea.
Notice that I didn't mention those people above you. I believe it is natural instinct to treat them well. But yes, that also pays off.
Bottom line for me: Realize that you are human and every one else is, too. I crack jokes during my sprint planning sessions these days. Yes, in the hierarchy I may be above the team, but who cares. I'm working on one project with them so we might just as well have a great time together while making the project a success.



