A few months ago I had an exact same issue but with a different table. This time tiki_sessions table crashed.

I still don’t understand what is causing the crash. Luckily I know how to get rid of this issue quickly once I discover it.

executing the following command fixes the issue:
mysqlcheck –auto-repair -u{username} -p{password} {database_name} {database_table_name}

output:

{database.name}.tiki_sessions
error    : Table ‘./{database.name}/tiki_sessions’ is marked as crashed and should be repaired

Repairing tables
{database.name}.tiki_sessions
warning  : Number of rows changed from 0 to 2
status   : OK

I used to think the only reason why Scrum is so popular today is coz of their “over-the-counter” certification programs. After thinking about it, I started to question myself, why others cannot see that the whole certification thing is so flawed? My best guess was, if I can see, I’m sure a lot of other people can also see through it. Then why is it so popular?

I talked to close to 50 companies that claim they are practicing Agile (read as Scrum). I tried to understand what was the driving factor for them to choose scrum. Some obvious points came across:

• Its easy to get Management buy-in coz Scrum is big on Project Management aspect
• Scrum is very simple, so we can start doing it without a huge change to our existing organization structure and culture
• Its easy to find training (certification programs)

Most people said it was a good starting point. After doing Scrum for a while, we realized Scrum alone will not help much, we need some XP practices for sure.

The I asked them, why did they not choose to start with XP? What was the biggest concern?

Surprisingly most people said that, we have heard that in XP you don’t need Managers. Most people who do XP, claim that middle-management becomes a big road-block for them. In most organization they cannot get rid of middle-management nor can they find something more interesting/valuable for them to do. So XP becomes a big No No for them. But with Scrum, what lots of organizations do is, they send their managers to Certified Scrum Master classes and make them Scrum Master. Some become Scrum Masters on teams, some become Scrum Masters for their Scrum of Scrums. This way they get middle-management on board.

So looks like Scrum has found a way to address the role of middle-management. Hence fill the gap. I’m not too sure if I agree with this, but its a fact of what I see out there happening.

Disclaimer: Personally I don’t care what people do, XP, Scrum, Crystal, DSDM, RUP, Spiral, V&V, etc. As far as it really helps them and constantly improves them its great. But if they are just doing/following some process for the sake of the label, it really bother me.

Often people ask me what are the tangible results of agile software development?

Following is my elevator pitch :

In my experience Agile leads to :

• Happier and more satisfied Customers and End-Users due to faster turn around time and greater visibility/involvement
• Happier development team due to heavy focus on people and team.
• Greater emphasis on quality (and testing) by building it into the process rather than having it as an after thought
• Self organization and empowerment of team leads to more responsible team and greater innovation
• Very effective at handling changes in requirements, technology, people etc
• With the large number of feedback cycles at various levels, it is very effective at adapting the project progress and hence addressing project risks

Obviously there are many more points, but these come to my mind immediately.

And this continues to puzzle me….

Through the Agile Software Community of India, I’m organizing three workshops by Mary and Tom Poppendieck in Mumbai, Bangalore and Delhi. As a way to ensure quality (passionate and committed) individuals get to attend this workshop, I introduced the concept of a position paper. To participate in the workshop interested people have to add their position papers to ASCI wiki. The position paper is a simple, plain text response to 3 basic questions. The idea is we have an index page (home page) for the workshop in each city. People are supposed to add their name to the table (index) and link their position paper page from this index. This helps each one create a position paper page on the wiki, add what they want to add to the page and then link it up to the index, so that anyone can see who all have signed-up and if they want to know details about any person, they can click on their position paper link.

This might sound a little cryptic, but when you have an example to see, it all seems to make perfect sense to me. But if you see what has been happening on our wiki with these position papers is:

• Some people don’t know wikis and they just email me saying here is my position paper. I’m happy at least these folks are not messing the whole wiki
• Some people can add their name to the index, but don’t know how to create link. Even if there are 30 other people who have create a link one line above their text, they cannot figure out how to create a link. There is a link to the guide, but that apparently is not helping people either.
• Some people don’t understand or don’t want to understand how to edit a table on a wiki.  Even if there are lots of other people who have added their rows to the table, some people cannot figure out how to. They keep doing wired things like randomly adding pipes and that messes the whole table up.
• There is a description on the top of the page linking to the position paper description page. Some people click on this link, delete the position paper definition and add their position paper right there.
• Some folks just clicking on the first person’s position paper, deleting the content on the page and adding their own content. So you click on person A’s position paper and you’ll see Person X’s position paper
• Worst of all, some people are deleting the whole index page and just adding their position paper without any name or any other details.

In all these instances, people are not try to knowingly mess the wiki, but unknowingly are doing all this non-sense. Now one might feel this is common sense, why is this so difficult? If nothing else copy what others have done and that seems to work. My big question is “How can these guys build complex software applications for their clients, if they can’t work with a wiki”?

You know what scares the shit out of me, when I think of over 1 million people in the Indian IT industry who are out there. At least these people are taking an initiative and trying to learn something by attending these sessions. But what about those over million software professionals who don’t even have the drive or energy to learn something new?

At XP 2008, during a panel on “There’s no such thing as Best Practice”, Joseph Pelrine talked about new emerging Agile methodologies called “XPLite” and “ScrumBud”. (heavily influenced by MillerLite and BudWeiser beer) Accordingly to him, there are lot of teams who claim they are Agile because they follow one of the most important Agile principles i.e. “Inspect and Adapt”. They read the book (inspect) and then adapt it by taking and applying what they think is most convenient to do.

Today Distributed Development is unavoidable and is the need of the hour.

My belief is that if you have the “right” set of people, motivated and happy on your team, it will be a huge contribution to the success of the project. But the problem is most often “right” people are distributed all over the world and not located in the same city. A lot of organizations have tried to move people to the same city so that they can be collocated. While this might work to some extent, this model cannot scale and is not sustainable. All of us would like to settle down in the location of our choice. We don’t want our work to dictate where we live and what lifestyle we choose. For example, I like to live in India close to friends and family. So far I have traveled quite a bit, but once my daughter starts going to school it would be very difficult for me to relocate to another city.

Also if you consider a lot of leading companies they are loosing a huge amount of people, because most of those employees don’t want to travel/commute any more and want to settle down in one place. While tele-porting is a few centuries away, employees have to live with stressful commute everyday. Not only this is a huge wastage of time, it also affects your productivity and makes your family life very stressful. Currently most of the successful companies have offices in multiple cities. One of the main drivers for having multiple office in different cities is to attract local talent. If your company does not plan to have a office in location X, guess what, your competitors will open an office and you’ll loose some of the smartest folks you could have other wise hired. And when you have multiple office, guess what, people in different offices have to work together. This is another reason why distributed development is becoming more and more important.

In Agile we talk about having development and business teams together. It is very critical to have constant business involvement. But what do you do when your Business is distributed? Because of the global economy most businesses have global presence.  Also each region might have slightly different business rules or market. Hence it is very important to have development teams close to local businesses and distributed. This again leads to distributed development.

Another point to be aware of is, if we consider what industrialization has done by building power centers in industrial cities leaving the rest of the country really backward. We don’t really want IT to do the same thing to the country’s economy.

If you consider these practical issue, collocated team model turns out to be unrealistic in the long run. The chances are you will have to compromise on the quality of people or have the team members travel a lot if you want all of them to be collocated. The alternative is to build a model where the team members can be distributed across space and time.

Unfortunately so far, we’ve not had great results with distributed development. A lot of people have published their experiences trying to effectively work in distributed teams. For some it has worked or some it has not. But for most of them its not as effective as collocated teams.

What has worked best of me so far is to start off a team by having them collocated for a couple of week to a month. Then created cross-functional self sufficient teams in each distributed location. Once this model seems to work, then try to fully distribute your team with team members spread all the world. This turns out to be a long and painful process. But this is the best I know of today. Check out my presentation on Distributed Agile which I gave at the IV Agile Gathering in Ukraine.

Next year I plan to kick off a few experimental distributed projects to try out different techniques to get Distributed Development work as effectively or may be even better than collocated teams.

At the last Agile Coach Camp I gave a lightening talk on “Process OVER People”. In this talk I requested all the coaches present at the conference to really think about their advice to companies. Are we trying to put a process boundary and become Process police? Is this coaching? A lot of coaches I meet, recommend “First do it by the Book, then deviate”. What does “First Do it by the Book” mean? I appreciate the book and I think there is a wealth of knowledge out there. But we should remember the book was written with some context in mind and at some point in time. One cannot blindly take what is in the book and try to apply it. That really feels like “Process OVER People” to me. You need to take your team into account. You need to consider what you are trying to build and most importantly you need to prioritize what needs to be fixed on your team or in your organization before trying to go and “Do it by the Book”.

Over the last couple of years I really feel Agile is gone into a mass-production mode and we’ve stopped innovating. Every company wants to be Agile. This has lead to a huge demand for Agile Coaches. And because of this you find all kind of people claiming to be Agile coaches. What surprises me is a lot of these folks have themselves never really worked on an Agile project. Forget Agile project, a lot them don’t really have a successful project delivery story to share. How can one preach something and do something else (or do nothing)? My belief is that one needs to lead by example and not my blabbering crap.

I asked the participants at the conference to tell me what new tricks, techniques, tips, practices, etc they have learnt in the last one or two. Very few people (may be 2 out of 50) had something to share. Are we getting so busy mass producing what onces worked that we have forgot to go back into the trenches and try new things? My fear is that if we continue this way, Agile will soon be the next CMM (at least the bad implementations of it, which is most common).

If you are interested in some background about where I’m coming from, you can read my position paper for the Agile Coach Camp.

After a 4 hr delay in my flights I finally made it to Ireland. But the airline lost my bags on the way. Looks like my bad luck is only bad! (This is a typical thing you would hear an Indian say when things go wrong.)

Well on the bright side, I got to walk for 2 miles at mid-night to go shopping to a 24 store here in Limerick called Dunnes Stores. I had absolutely no clothes left to wear today. To my surprise there was a father’s day sale running at the store. So I got a bunch of clothes quite cheap, about 40 EURO in all. Also I found really nice and friendly people in the city. I lost my way a couple of time and folks were generous enough to show me the correct way. One gentleman even gave me a drop in his car when I was way off the road I had to go.

Thanks to Agile Alliance for sponsoring my trip. I’m using my Gordon Pask award to cover the expenses for this conference. The award comes with a “travel to two conferences in two other continents” and all expenses paid by Agile Alliance. This is the first out of the 2, I’m using. I’m hoping that there is a conference in Australia or South Africa that I can use this award to go to.

This afternoon I’m running a workshop on Acceptance Test Driven Development. I was told that there are 16 people who have registered (paid) to attend this workshop. I’m really looking forward to meet those folks and to attend the rest of the conference.

This is my first time in Ireland and I must tell you, this place is awesome. Its really beautiful. Weather is great. Well I’m going out to enjoy my time. Will be back in Mumbai in a week’s time (hopefully, pray for me).

During the recent Agile Coach Camp, during one of the discussions, Chet Hendrickson talked about using Pollution as a metaphor to better explain Technical Debt. Following is my interpretation of what he proposed.

Martin Fowler explains Technical Debt as the following:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about the problem where the architecture of a large software system is designed and developed too hastily. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Another way of looking at this situation is that if your code base has a lot of code smells or bad design decisions that make it difficult to add new features at the same rate as you are used to, then you know there is something getting in your way and bringing down your efficiency. In this state you realize that you have borrowed way too much time from the system by cutting corners. You have not paid back the system by investing regularly in cleaning up the code base.

Even thought this metaphor is really powerful in conveying the messaging that if you continue to hack code, after a while the code and its design will get in your way and stop you from making any real progress due to the heavy interest rates you’ll end up paying.

As Martin points out

The tricky thing about technical debt, of course, is that unlike money it’s impossible to measure effectively. The interest payments hurt a team’s productivity, but since we Cannot Measure Productivity, we can’t really see the true effect of our technical debt.

Also what I have noticed on lots of teams is rarely a developer intensionally introduces technical debt. Today’s quick fix turns out to be a bad hack and that leads to adding to the technical debt. Also like financial debt, technical debt builds up slowly without the team members realizing it. Since you cannot directly measure Technical Debt, the only time you realize you have technical debt is when its too late.

If you really think about it, Technical Debt is a lot like Pollution. Like pollutants in the environment, quick fixes and hacks, degrades the system in which they live. They constantly bring down developer’s ability to build new features (harm people living in the affected area). Pollutants gradually affect people and as time passes by, makes it exponentially harder and costly to fix it.

What is interesting about the pollution metaphor is that few years back who realized CO2 leads to pollution and global warming. But today its all over the place. People driving 2 stroke vehicles never realized that they were polluting the environment. Similarly, few years back who realized Switch Statements are considered harmful? Now with so much emphasis on Code Smells, we can think about these things and avoid some of them.

Also like Pollution, one person introduces a hack into the system and all it’s neighbors (team members and customers) suffer from it. Note that you don’t suffer as soon as you introduce it, its only after delta T that you start feeling the pain.

The biggest problem I find in dealing with Technical Debt is that one man’s elegant solution might look like another man’s hack. Terms like “clean”, “simple” are very relative. To make matters worse, today’s elegant solution might look like a hack tomorrow to the same person. We constantly keep learning better and simpler ways to do things. Tools and languages are constantly improving and getting powerful. What bothers me the most is that people talk about Simplicity as if it were one thing. Unfortunately, simplicity is not as Black and White as I would have liked it.

Wow! What a great conference. The first Agile Coach Camp is now officially over. We had over 70 participants. The diversity of the participants was really amazing. Check out the Diversity Stats here.

Its a great sense of accomplishment and is always refreshing to organizer a conference where the participants go back very satisfied. I feel all those sleepless nights are worth it. Big thanks to all the sponsors and volunteers who made it possible. And a big big thanks to Deborah Hartmann, co-organizer of the conference. Without her, I don’t think I would have been able to put together such a wonderful conference. Thanks Deb, I learnt a lot from you.

Conference Highlights:

• Lightening talks was a big hit.
• Participants like the Position Paper concept
• Open spaces worked well. Big Thanks to John Engle for helping facilitate the Open Space.
• Complete list of Open Space sessions : http://wiki.agilecoachcamp.org/tiki-index.php?page=Sessions2008
• Conference Retrospective Notes

So, if you would like to organize Agile Coach Camp in your area, please get in touch with me or Deb and we’ll be more than happy to help you do so.