When not to go Agile

Recently, I attended a two-day workshop on SAFe Lean-Agile which is an implementation of Agile Methodology in a large-scale enterprise. Trainers Mark Richards and Karina Woolmer from  Context Matters were good at clearing our concepts. Some of us were new to the Agile world and this activity driven workshop was successful in relaxing our curious minds. Deep and dedicated thinking towards agile made me think, When not to go Agile.

Nowadays, especially in software industry everyone wants to go agile, from a start-up to a multi-million dollar project. Is this a white whale of productivity methodologies, from the management standpoint or it’s really worth it. Let’s talk through.

It might sound bad at first but agile is not for everyone. It’s the best answer to this problem.

It’s all about early feedback, moving faster by taking swift and unanimous decisions together.

Reasoning for the case against agile.

1. You are not mentally prepared for change.

You are not happy with what’s happening in your team. You are not happy with ways of management, nor are you happy with your subordinates. You just want to change things, you just want a perfect and correct world. Don’t you? But, are you ready for a change.

Adapting agile ways of project management is a tectonic shift in mindset. You need to have discipline and determination for doing things faster and have transparency within your team.

 So, in your organization if it takes a week to get a monitor for a developer. Or it takes few meetings to decide if we should deploy code to a certain environment. Or if getting right arrangements to communicate with you geographically dispersed team is a tough job. Take it from me, agile is NOT for you. You probably have a lengthy bureaucracy where everyone’s ego has to be massaged. Fix that first.

2. Does your team have the agile potential?

Agile needs self-organized and self-motivated people. A lot of this comes with the motivation of team members. Okay, now if you are a manager or a leader you will oppose this in all your capacity. You will say, that as a good leader I can always motivate my team. Bullshit. If you could, your team would never have been de-motivated, else, someone has done the damage already. You got to fix that first.

If you team is not motivated, you can’t trust them to be self-organized and be driven towards a common goal. If you can’t trust them, you can’t go agile.

3. You don’t understand THE agile methodology.

You don’t understand Agile Development Methodology, but you think you can attend a training and then everything will fall in place. If you think, agile tool like TFS or rally, few packs of post-its, a wall to stick random stickers and daily stand-ups is Agile, sorry, it’s not.

Just like any other management methodology, you need the thorough understanding of agile before implementing it. You need experts and experienced tutors around that can guide you at every step.

It’s very easy to slip agile to scrums of waterfalls. You don’t want to be doing this. At first it might look attractive, appealing and easy but you are doing damage to yourself. So be focused and open to learning from your own mistakes.

CONCLUSION

Big preparations are needed for big wars. Changing your way of working and thinking is a war within. The first thing you should be doing is believing in the concept and idea. Agile methodology is not a magical wand to fix everything and drive you on a success path. If you can’t believe in the idea, it wouldn’t work.

Measuring productivity of a software developer

A delivery manager of technology industry can’t be interested in anything more than this, developer productivity. They are always after that one silver bullet which helps them scale individual productivity and enhance it. I’ll help you – this is where interest is building.

Measuring individual productivity is NOT a new concept, this has been a topic of discussion since ever. Any industry you talk of – Manufacturing, Textile, Chemical, Automobile, there are well-defined ways of measuring individuals performance and productivity. It can be either units produced, units sold or anything in terms of unit, it can be calculated. Over the years these industries have established well refined ways of scaling productivity of their operating staff. Similarly, there is a want of identifying productivity of programmers. There is a want to measure how their work impacts company and client. Why not ! After all they are high paid workers and they are paid to write code.

There have been number of daring attempts to measure developer productivity, unfortunately all of them ended up being a failure, more or less. Not because these methodologies were immature but because ‘developer breed’ is too smart to play with these ideas. Let’s have a quick look to what are these methodologies.

productivity methodologies in practice

Line of Code (LOC)

Also called as SLOC. I personally feel quite irritated by this study  for productivity of developers and complexity of system. As a developer, I can extrapolate code and that might be one of worst code piece one has ever seen. There have been days when all I did was delete lots of code and still called it a productive day. Does that mean my productivity was negative? Oh God !!!

Hours Worked

Okay. So more time one spends in office, more productive you would call him. I have seen people, and I swear, they can stare at computer screen whole day and do nothing. Or may be play minesweeper for a change. Read this if you are not convinced.

Function Points

Now this is a measure. You have probably not heard of it and it would make almost no sense to you. It’s about breaking a high level requirement into small atomic work items (which is good) and then counting how many such logical requirements a developer delivered.

Want to read more about this estimation and productivity technique, start with Wikipedia, link is here. One would measure number of business functionalities that a developer delivers.

Bugs closed in a day

Don’t be surprised? I have seen people and have worked in teams where managers preferred counting number of defects fixed by a developer in a day. This doesn’t end here, targets were like 1.75 defects a day. Smile

How as a Project Manager you could justify existence of defects in your system and then target your developers on count of defects. Take my words for this, if you are following this in your project – “You are not doing the right thing

do the right thing, do the things right

I personally know people who were incentivized to fix more defects, consistently. Then there were controversies because of obvious reasons

  • Not all defects are same. You can’t compare complexity of defects.
  • One fix might resolve many defects. You agree?
  • Developers tend to fix easy defects than invest time on real issues.

It drives lot of negative energy in team. I personally hate this measure the most.

Story points

Out of this entire list, only sensible thing is Story Point estimation. However as I just mentioned, this is estimation technique not a measure of productivity. There certainly is a component around this called velocity but the nature of story points is very dynamic. Thus increased velocity doesn’t really mean that developer is delivering more. I will write a separate blog on Story Point, someday.

So, we don’t have a solution for this

Before we really try to find a solution, we need to understand what developers do.

Do you think developers are just an organism that converts caffeine to code.

CaffineCode

Or you believe, they are specially blessed to transcribe document to code. Believe me they are more.

Programming is a bit of science and a bit of art. It involves interpreting rough requirements and converting them into a very precise working system. Developers try and understand the problem in detail and then break them into very small and atomic work items. This is how a team of developers collectively solve a problem and achieve a common requirement set. As a developers, we make lot of decisions every day and that makes our job bit different than manufacturing industry.

The problem here is subjective and while measuring productivity of developers we target objective solutions i.e. hours worked, lines of code written, defects fixed. Wrong.

Rather than comparing developers to people in manufacturing industry, I would rather compare developers to Lawyers, Doctors, Poets, Journalists or even Painters. How do you measure their productivity?

So next time when you want to measure a developers productivity. Try these

  • This much work in given time frame looks fair enough.
  • Is this developer passionate enough for system and code he/she is writing.
  • Is the developer committed towards quality and delivery.
  • Does the developer has enough knowledge of work he/she is doing.
  • Is this developer collaborative enough?
  • What is my gut feeling about this developer?

Conclusion

At the end all I want to say is – “trust your developers”. These arrogant, shabby people in jeans and t-shirt, plugged in earphones are actually smart and know their job.

Programmers

You have invested a lot in hiring them and then getting them up to the speed. You can’t stick to Manufacturing Industry driven ways of measuring individual performance. Get rid of traditional KRAs and introduce more intuitive measures.

new Blog()

Let me accept this, I stuffed up.

Yet again.  I was lazy enough not to write the blog regularly. Blog lost a bit of context. And then I decided

renaissance rɪˈneɪs(ə)ns,-ɒ̃s/

So I came back, archived all my previous posts, except the first one. Updated the template, hope you like it.

Now we start fresh, I’ll try to post more regularly.

Welcome to my blog

Welcome to my blog….. 

I am a software professional earning my bread hanging over Microsoft Technologies preciously Web Application Development. Involving myself in every technical problem around me is my passions. I go through lot of technical stuff, books and blogs sometimes to resolve a problem, sometimes to understand the problem more and also sometimes to extend sphere of my knowledge.

For quite a sometime I was thinking about writing my own blog. Other than being a better teaching tool it also helps you showcase the problem from your eyes, solutions from your inner. So here, I present my blog (It took me more than 6 months to start this). You can expect write-ups relating to some of the technical problems I face, some of the topics of interest. Other than problems and there solutions I will try to concentrate on best way of solving a problem, comparison between different solutions to a problem. You can also see me talking about technical processes and there implications. Also, I will not mind writing about my philanthropic and social interest.

It will be really good, if you all can be interactive – putting up your comments and discussion here. I’ll also take comments section as the suggestion panel for myself.

Winding up this introduction and preface to my blog, if you are interested in knowing about me read about me page in this blog or reach here. My email is niks.dwivedi@gmail.com and linkedin link is this.