Are bugs hurting your backlog?

I ended up in a discussion with the team last week on how bugs cause a unmanageable link to the Technical debt. The debate was how should bugs be treated. my argument laid with bugs that hurt the current development and the future backlog. As a agile team a product backlog is key driver in defining what we do for in every release, the known unknown here is the bugs that are generated out of the current development. Let's say your product backlog is 200. If your team of 10 is burning say 100 user stories in a release of 10 days we can say that the velocity is around 10. But if in the same situation your team is burning 100 user stories in 10 days and creating 20 bugs that take 5 days to fix, your velocity is dropped to less than 7 + on the release day your backlog increased from 100 to 110 say a 20% increase.

Gauge the effect bugs can have in your system. Now go a bit deeper, assume you can only only resolve 10 of the 20 bugs in 5 days. The other 10 bugs go sit in your product backlog. When you cant get them in the current release and put them up for the next they take 20 days to resolve (Due to the time spent in between it no longer is hands on) your velocity rate with the bugs regards is then 100 user stories in 25 days (Just around 4?) Now if these 10 bugs are mapped for a future unknown release???? The technical debt it had created can be high, very high and would lead to say 10 more bugs getting created [causing you 8 days or maybe 10] your velocity with regards has now gone to ?????? less than 3 and forget about the qa and discussion cycles, customer unhappiness, quality quotient. Your product backlog spanned to 120 which is 20% more than what you expected to burn.

So next time when your release user story is generating a bug, go shout on your developer and tell him/her that the bug is a part of requirement and when you go live you want the feature to be done, not debted.

Obviously for those "Think Realistic" atheists this wont sound good. But remember your product backlog is piling up with the bugs, your velocity decreasing, your debt increasing and your cycles of qa increasing... in other words nothing in favour of better product.

What do you do to bugs that get created from your development bug and found during the release?

Read More

Want to learn Agile? Get to the source code

If you are confused with the title No I am not kidding here, and if you are making fun of my knowledge about Agile there are not many better ways of knowing what Agile is than watching this smart movie "Source code". My last weekend was busy, tied with flock, lot of work , shopping and busty busy release. Hence I picked time on Monday night (Yup a school night) and watched the Duncan Jones directed "The Source Code". If you are in India then the stars are not so known lead by Jake Gyllenhaal (Prince of Persia) and supported by Michelle Monaghan (Made of Honour) and Jeffery Wright (The CIA guy who funds James bond in Casino Royale when he is loosing the poker game).

To cut the story and theme you a bit about what kind of learning's on Agile you get with the movie.. the story revolves around a guy Col. Stevens who sees himself alive in a capsule lead by Dr. Rutledge (Jeffery Wright) and Col. Goodwin (Vera Farmiga). There is a system named source code that gets Stevens to life and is planted in a body of a teacher who is travelling with his girlfriend in a Chicago train ONLY for 8 minutes. Source code lets people go in past to find things out [not change them]. The objective of the mission is to get Stevens into the train and find out the person who bombed the train and what are his next targets.

The story moves on Stevens several attempts of 8 minutes on how each time he goes and finds a different clue to find out the next target and find his own identity. Watching the movie was pleasant as flavours of Inception took the movie to a supper height while there was no confusion left in the movie due to fantastic writing. Every 8 minutes spent by Stevens in the train improvises his actions and in turn the result. Just like Agile.. every iteration give you ability to learn from your mistakes, let you improve, help you improvise and of course definitely improve the quality of results...

Unlike in source code where you cannot change the past, Agility allows you to revisit your code and refactor it. Agile is the theme behind source code... though I would keep the climax and rest of the details of the movie hid to let you see it and experience it.. I have to say that Agility is all over... Its one thing that can help you do things better and better.

Design Agile...

Build Agile

Review Agile

Sell Agile

Earn Agile ;) ... I think you should watch Source code if you want to know better on what Agile is...

Read More

Say NO TO AGILE

I had a 15 minute debate today with a very good friend. While I started this blog, I had just finished the conversation and while I finish this blog I have decided to give him a call and tell him DONT THINK OF AGILE..To give a bit of a background to this... I received this call just 30 minutes ago where a friend banged greetings and then asked "Is this Agile any good?".. A few questions and I was sure that Agile is not working for him... Going over those thoughts and discussions I really feel pity when people without understanding the need, necessity and requirement of Agility rule out the benefits, perks and values of Agility. I have no hesitation in saying that Agile is not just about a process... I think Agile is more than a attitude... And if you want to find and enjoy benefits of Agile.. you need to be prepared to learn, invest and work on Agile Teams.

So what are those things that should act as a hint to you.. so you can make this decision to say NO TO AGILE? As a manager, lead, stakeholder, product Boss or CEO.. you definitely need to understand when and where you SHOULD NOT do Agile...

1. When your Sr. Management thinks every feature has a fixed number of developer days.

2. When your Organization thinks that a product is just fully ready as a requirement document or mockup is

3. When any of the following do not understand what Agile is CEO, CTO, Product Manager, Development Lead

4. When any one in your team thinks Agile is ONLY for co-located teams

5. When anyone in your team thinks Agile means no due date

6. When anyone in your team thinks Agile is a PROCESS and it should be strictly followed

7. When anyone in your team thinks PROCESSES and reports make products and Agile is just another one

8. When your Product owner does not know how to progress with the product

9. When your product team thinks that the feature can evolve as the development proceeds

10. When your product team does not document clearly on what they need from development

11. When your development think that Agile is for extended development time

12. When your developers value completion of feature more than quality of the product

13. When your development is only about coding once and re-visiting back only when needed.

14. When Agile is just not going down your throat.. and you are making decisions in your team.

15. When Agility is only for a brand new product development

16. When Agile is a way to hide your incompetence and quality issues

I asked my friend to revaluate WHY Agile.. and then decide to do Agile or not... Do you think it is a right suggestion?

Read More

Agile Myths?? No Agile excuses

My last post for the year. While I will retrospect this year on the Objectives page.. I want to mention that this year has been one hell of a year. One of the farce thing that came and strike me every time this year was the myths that surround Agile...

I drafted a few of the Agile myths or maybe we can say excuses used under the name of Agile... lets see what Agile is not..

1. A requirement document is not Agile, Agile is a discussion you have to build a feature with its flow and pro's and con's over a white board, which you then slice to develop items.

2. Agile is not a requirement that is changing every now and then. It is a requirement that is built with a smaller set of features and then evolved in later releases.

3. A working code is not a complete feature, a part of the demo-able piece that can be improvised.

4. Bad programming to meet deliverables is not agile. Agile instead is a program that can be improved and improvised. And of course same steps / mistakes dont occur again.

5. Agile is about improvising.. not making mistakes as habits.

6. Agile is not just a concept... its a mind set.

7. Agile is not testing what is written, It is testing what is not written.

8. Agile is not just about 2 weeks iterations, kick off's , plans and releases. Agile is about collaboration every day, white boards every week, demo's every few days, feed backs every now and then.

9. Agile is not CHANGE. Agile is improvement, tweaks, functional improvisation.

10. Agile is not FREEZE. Agile is define a Minimum Viable Feature and achieve it in phases.

11. Agile is not INDECISIVENESS. Agile is starting with a shorter sight to build a grand vision.

If Agile is just a process for you, You should be dead by now.. if you ain't you will surely die. Agile is a life style.

Read More

What is blocking your Innovation Path?

I was questioned by a colleague yesterday, a question I determine to answer through this blog post. The question was "do you remember of any Innovations we did in the last 2 years?". My answer is NOT REALLY. And I have no hesitation in saying this. I think while the whole world is claiming on Developers been Gods - @Scobleizer in his latest post, How Facebook is made by Developers - Techcrunch, And how Google Dev community is the maximum value driver in Innovation. While there are success stories of how developers really make the future of Innovation bright in any organization... I think many of them forget to mention the determination from the Management, The Vision to Innovate, The attitude to learn from failures, and the readiness to accept failures, the faith in developer community and last but not the least the work load on your teams. I believe there are multiple more elements that drive Innovations... many of them written in the posts previously written.

My answer to the question raised is going to come in a series of blog posts, while this post is going to be focused on the Agileness as a potential blocker to Innovation. Please note that I see Agility as a potential blocker only. So the short and frequent but shippable product takes the precedence, the Team get busy in finishing the tasks planned for Iterations, their visibility to the product and the vision is limited to the set of iterations and releases. Obviously if you are going to have a busy team of developers just working to get a feature right out of the developer machine to the customer, they are going to loose an important element of their attitudes... Innovation.

In my experience agility has all potential reasons to create enough blockages to Innovations... here is why:

1. Multiple short and frequent releases mean that those releases are focused to get small issues / bugs fixed for your customers, maybe some small features that are likely to help your product improve. This means that the focus of your team is on that release and those set of small items. Development or Product teams, both are going to fence themselves into the barriers of those monthly / 2 monthly release cycles.

2. Yes the quality and the speed of development increases with effective agility, but then it also increases the iterations in building requirements, delivering those requirements to a complete set of functional piece. All in all you are working fast and quality, but with no newness.

3. Products may have roadmaps, however the long term features that are going to be a part of your 1-2 years roadmap is not getting resourced. Majority of your discussions are restricted to what is coming in the next release, and many times it is doing something this release to win a deal. Majority of times these items that are big chunky development or Innovation pieces get outdated, Thanks to the market conditions, Technology updates or competitors.

4. If you are catching up, You are not Innovating. A major set of companies/products who tend to catch up with competition have failed to be ahead in the race, as they are always in a mode of catchup.. they are making their Teams to work on those things that the competition has and that is taking the energy out... remember this catching up never ends... I see this race for Myspace... though the new Myspace is really nice.. I believe it is just trying to catch up with Facebook... same thing happening around with Yahoo for instance. So while you are busy catching up with 1 competitor... a whole bunch of competition is busy not catching up with you instead Innovating... Imagine what would happen if you want to catch up with RT like function of Twitter, Like like function of Facebook, A gooogle like search , A Quora like simplicity.... Gosh.. you gonna be One hell of a busy Team.

5. Innovation is not copying. SAP-Oracle is a recent example. If you are busy copying features, you are taking your product years back.. because that is when those products started thinking of it, and did it. In the process of agility many people tend to copy smaller set of features into short releases... this causes Teams to defocus.

6. Innovation is not 1 person telling and other people doing. You cant just free up 1 person to tell you what your product needs... there is a whole lot to do. Agility drives responsibility of Product Innovation on a few less. This is one big trouble... if you dont have 100 ideas every moment, you are going to work on 1 Idea which is probably not well validated or Innovative.

7. Iterative Freeze is needed... One of the problem of been agile is that there is always a backlog... believe me or not.. run an eye on past few releases of your agile team and see the amount of backlogs, Technical debts... many of these are due to the indecisive, iterative feedback sets. One or the other team member will have one or the other change and this change is going to get a lolly in your backlog.

Having said this.... I also want to say that some of these issues can still be tackled to keep the Innovation momentum up in a agile Team. A few of my thoughts...

A. Have streams of development. 1 that focus on short term goals, another that is always working on Innovation items with a longer release plan. This is not catching up though. Had Facebook tried to get into the Phone market, they would have lost focus from the Social Business, the vision of which is to be Social leader and not collaborative struggler.

B. Leave Agile teams with lull releases. Yes everyone wants CUSTOMER DELIGHT. But keep a set of releases empty.. so your teams get time to breathe...this breathing period can really help them Innovate.

C. Small inputs can turn into Big Innovations.. Promote and Provoke your agile team members to Innovate.. Appreciate the items they do on their own... If they are taking you away from your product vision, Guide them but dont reject them hard. Recently a developer bought a cool module for customizable design and formatting. This input was bought down with a statement that it is not needed for the product, Disappointed developer kept another cool Idea of real time previews undisclosed.

D. Make agility your strength, not your weakness... Break up your Innovations into smaller phases, instead of going on a all out war on it. If you are able to get a cool thing for your product increasing the customer UVP.. even if it comes in phases.. Your speed can get things in time, your attitude and quality will give perfection to your Innovation. people will like it. As YT said...Think whatever you do is your Version 1.0 while 2.X is waiting in queue.

E. Imbibe a Innovation culture... Not a THIS IS NOT YOUR JOB CULTURE. If Facebook is successful it is because it has a great Team to support great Ideas and great vision. Unlike Yahooo whose better technology just cant be met by its product ideas and vision. Unlike Myspaces scalability that just is useless as the product doesnt have a great usability and vision further. Unlike Zoho's apps whose Technology is just not able to catch up the cool features and usability of the product...

Now.. that you are one hell of a Agilist.. take a step back, retrospect how Innovation is going in your Team.. and take a leap to improvise the Innovation process.... Let Agility be your glucose in this short sprint.

Read More

My Five on Agile and the famous Myths

4 events today and I end up writing the famous Agile Myths....

Event 1 : Developer walks to me and asks me to change a requirement, Quick decision expected

Event 2 : Someone emails me over and says "Do you know any Developer who knows Agile?"

Event 3 : Back home I have a guest who turns to be a IT Pro and says "Our company is going Agile now, I need to learn it now"

Event 4: I hear that a scrum has to be only 5 minutes.

So I thought I would write something about the myths that people carry when they enter the Agile arena... Eventually I faced the same issues when I first moved Agile way and had similar myths in mind....

So to start the post I would like to say..

1. Change of requirement across the development cycle is must, As long as the developer is in the area of development he can accommodate that change, many times we hear the changes and put them into the iteration plans immediately or in further releases...

2. Agile is a methodology, A Principle.. not a technology.. somebody can know what Agile is.. but not as a technology but as a foundation to a process..Agile Developers are expected to be Independent, Intelligent brains that can take things up on their own, split them to some level and build it iteratively to be accurate (Remember Code , Test , Code and Refactor algorithm)

3. Please don't learn Agile. Read it , adapt it , evolve it.. but never try to fit what is written on Agile web sites to what you do... instead fit what you do into the Agile principles... e.g. Agile says iterative development , break up items that can be released frequently... But what if your product doesn't demand it? for instance if you have a thick client that needs to be rolled out every release, would a clear agile help you? No it would add overheads.. OVERHEADS do you hear me?

4. Scrum maybe of 5 minutes.. but imagine if I say

"I worked on Java yesterday, I work on Java today and I have no obstacles" I am sure you would know as much enough as the word says and nothing more... A standup to me is a place where the Project Manager really gets to know whats going on with each of the developer.. , what blocks is good to know but not necessary that what not blocks you may not block others... moreover it is important if the PM knows what can potentially affect others too?

So in a chocolate wrapper if I have to say this I would say that Go Agile, Not by books.. take the Lean principles and then start putting them in the flow, evolve, learn and evolve. Eventually I gather it may be interesting for you to know the myths I had when I got into the Agile principle adoption...

My List of Myths I had

1. Agile, Where is the process?

What I learnt over years : In a Agile mode you are into the process, every day , every hour... You dont start doing the design at first and then start development, instead you define your design iteratively.

You don't run into the age old Initiation, Planning , Executing, Controlling and closing phases... instead you get into a combined phase into shorter periods which in short term is a working feature and in long term becomes a working product.

You dont write a 10 page document to define a requirement, instead you write a one line behavior .

You dont log a change request, you adapt the change in the Iterative feedback.

2. Agile? where is the Project Plan?

There is nothing called a Project Plan... your story board is your Project plan, your story chart is your project plan. We define a master list with members allocated and thats the high level plan. Every thing that we code is in some form of user story, sometimes functional sometimes technical.

3. Agile? Chaotic Development?

Yes.. Indeed. It is to all those who are not involved. Agile demands involvement and ownership. If you own something and are involved, you wont feel chaotic. Read the famous Chicken and Pig story.

4. For any development methodology , there has to be a minimum process

Agile is a value system. Care about the values and principles. Take inputs from the manifesto... but NO there is set of rules / processes that would make you agile. Agility comes with the principles, not with processes.

5. Not Co-Located ? Not Agile?

Agile works well distributed. If you just have the right set of people. it just works well with co-located teams.. but can work better with distributed teams too :P

Now shall I leave you to go visit the Agile Manifesto and ask yourself one question if you really want to be Agile...

WHAT MAKES ME AGILE?

If you dont get an answer.... Lets talk!!!!

Read More

DOING A JOB or DoING it RIGHT

"When there's a gap between someone doing a job and doing the right thing, then management has failed"

Now I don't remember which Article or Blog I read this and unfortunately not able to find the exact place even after doing so many searches, I am actually forced to link this to the Harry Potter book specially because of the incidences happening over there... BTW This post was written when I was in the Godric's Hollow where Harry has just survived the Deathly attack.I am having a feel that its the Voldermort's mismanagement that is killing him. Be it not managing Snape to kill Dumbledore or be it not getting hold of the Undesirable one while leaving the dudesley's. Anyway forget it, coming back to the Fun. The root cause of failures in management are linked to doing wrong things at right times.Yes say for example "Taking your kid out in rain when he has just come out of cough and cold" Or "Having a quarrell with your wife when she is in a real bad mood" too many more things really, yeah wrong things at right times....

So while we think that its a managements failure when the right things are not done and the jobs are just done as a Project Manager certain things really can be credited on the path to "Why My Software Projects Fail". Lately while realising and analysing the follies and faults a Project Manager can do while reacting to situations can definately lead to the worst. Through a Project Managers career comes occasions like :
1. Biz critical situation needs to be responded by a Software support.
2. Risks need to be managed by playing with resources (doesnt only include Man Power).
3. Values need to be staken at the cost of situations...
more of course that you wont like me to write here.... under these situations the Best Manager's takes a call that can suffice and satisfy the needs and what plays a major role here is the time taken between the agreement on decission and actual implementation. If you are a cricket fan and had watched the 2nd day play of cricket Test Match between Englad and India you will agree Vaughan's decission to let Panesar continue a longer spell of bowling thinking that his spin will bowl out India short;) Unfortunate the decission was wrong. I have seen Managers who want to do everything in one shot right from decission to implementation and 11 out of 10 times it results into failures (however there is NO MANAGER IN THE WORLD WHO SAYS I DID THIS WRONG) If you dont believe this ask your Manager why a person who was fired recently becuase he been not productive or having other issues was HIRED at all? Well the answer wont be My choice was wrong it will be "He was better now he changed" so anyways.. taking decissions hastily is a art of Mis Management that can kill success... And I believe it is "JUST DOING THE JOB"

Yet another place to measure how it can affect in doing the right thing or just doing the JOB. A Father of an Indian girl's decission to hurriedly (without proper investigations or checks) of the groom she is marrying can result in disaster of a spoiled marriage, while if the fixing of marriage and the actual marriage takes long its possible that you might find the defects of the groom/bride way in time... definately leading to a find of successful marriage.

So next time you are to make a decission just dont make it "IT WILL BE DOING YOUR JOB" take time and then implement no matter it gets late it will be a right thing ;)

Read More

Creating a Bug?

I always think that Management is all about investing keeping in mind the ROI. Eventually lot of the Managers today know investing but not sure if they understand how and where to generate the ROI from... Well the reason why my post hits the blog is a recent incident that happened... Around a month ago I met a mother of a kid from my son's nursery school and while talking to her I realised that she was planning to get her child out of the school to a new one because she thinks that the school is putting too much pressure on her son and she wants her son do some painting and dancing along with swimming. Lately when I saw her again while going to drop my son to the school we had a chat that hit my mind badly.... She wanted to invest some more time so that her son learns been a bit pressured to study and manage things out...

Goshh.... Well you don't need to meet a mother to know the problem we have here... darn.. I think it sheer BAD Management well in our day to day lives as Project Managers we face similar things... things that can hurt damm hard... wana know How?

Tom is a Manager by mind, Developer by heart, QA by lungs and a Leader by Ears and ofcourse a Dictator by attitude... To be honest he is Jack of All and King of None... His Manager Harry invested time on him to create a backup, while everything went fine.. the Jack attitude took Tom to mis understand and interpret things negatively... eventually it resulted into a Over head for Harry.... the final outcome of the investment was Tom was out working for another company in the same way he started with Harry...

So whats the problem here? Lets relate the 2 stories to find whats the ROOT Problem here...

Read More