The last days I have noticed some interesting discussions about agile techniques/strategies/etc. Being interested for a long time on this topic and anything related, and reading daily on InfoQ the agile posts, I thought I would like to touch another aspect of agility.
Most of the discussions around agility are centered on what and how the developers must/should do. But, in my experience I have found out that managers and bosses have the real problem moving to agility (and it looks like others are having the same opinion). The problem is that most of project managers and bosses will not embrace agility (even if there are recommendations for them too). I don’t know the reasons, but I can understand some of them.
So, let’s see some of them:
- I don’t think it is really possible to go out and win a project without good schedules, timeplans, decissions and budgetting. Your participation in the auction will be simply denied without these.
- I don’t think it is really possible to have your PM go into a financial meeting and say that there are some guestimates, but no real schedules
- I haven’t met many managers that would spend time explaining their thoughts (as a form of requirements specification)
- it’s hard to believe that all clients you will meet are agile, so that you use agile techniques while collaborating
- many partner companies (the ones you do the project for) will not like to sit in the same room; they have already chosen to externalize the project because they don’t have resources and they consider they should to something else
In my humble opinion agility is not the silver bullet. I am not worried about some of its contradictions, because I know that methodoligies must be adapted and than applied, but sometimes I might get worried if or when finding out that agile never fails.
2 responses to “Agile boss, Agile PM and Agile developer”
I’ve responded to some of your points… but the comment became quite long, so I put it on my blog instead of clogging up yours 🙂
Let me speak up for an “agile boss” – I assume am one of the bread. What your points question is not agility, but rigility (pardon my English)
* If schedule is required to win the project, don’t be stubborn, make it so you get the project. But are you seriously gonna use the speculative schedule to actually run the project? Just because you got it? It’s rigile.
* When PMs are talking to $ bags, why teasing them with “we don’t really know when we gonna be done” as if they don’t know this too well their from experience of dealing with IT?
* Not spending time telling what you want is OK, as soon as you’re OK to get what you don’t want. It’s agile :-). Hoping to get what you want without telling anyone is rigile and outward stupid.
* What can be worse then your client is rigile? Your being riglie.
* “Must sit in the same room” is not agile, it’s rigile. Customers don’t want to sit with you? If you are agile, go deal with it! Sometimes it’s ok. I am doing shrink-wrapped software, I don’t want my few thousand customers sitting with me! But if customers don’t want to participate because they are not interested in the project then why would you? It’s a sure failure, and keep on working on it is rigile.
Agility is not a silver bullet. There is just no silver bullets. All Big-M Methodologies claims to be one, they cheat. Agility is evil then it becomes Big-A Agility. Small-a agility is common sence.
Cheers and don’t give up questioning Agile 🙂