Honey, I Introduced Agile In My Company
proghammer.blogspot.com
proghammer.blogspot.com
I've seen too many organizations and teams try to use agile to "fix" things while completely ignoring issues like product development, customer development and even culture.
Any gains from applying agile will still be barely incremental when compared to addressing the real issue of product development and doing so holistically. I think lean and even lean startup make some significant strides past agile in doing this, but even that is starting to show it's cargo cult side (a/b test all the things anyone?).
Agile is bollocks and just another excuse for consultants to fleece money from companies.
> therefore x is fraudulent
I love your logic!
http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
But acknowledging that, I'd like to add two things:
First, as a developer, adopting Agile methods (in particular, Extreme Programming) made my life a lot better, and probably kept me from quitting the industry in frustration. And when I started a company, we gradually put together a custom Agile approach we liked a lot.
Second, any useful Agile method works mainly by surfacing hidden problems so that people can fix them. So if you are doing an Agile adoption right, things always appear to get worse before they get better. The test for me is whether people treat the adoption as a process and relentlessly fix problems as they appear.
I've had the same experience. It went as far as developers wanting me to negotiate every little thing with the product owner so stuff could be done in a later sprint - even when there was plenty of spare time left in a sprint. For me this removes a lot of fun in my work.
Same was with clients, developers tried to put all client incidents on the backlog. Even though some incidents could be alleviated with very little work and make a customer happy.
I'm a developer myself and I can't thrive in such an environment. It was actually not very agile with regards to fellow developers from different teams or clients.
This, I think, actually gets at the heart of the problem.
The vast majority of the problems I encounter with people complaining about agile are due to a team/process that has the "agile" label - but isn't actually following any of the fundamental principles of any agile process. Agile is suffering the curse of anything that becomes popular.
For example, Scrum teams that skip the whole inspect/adapt thing and seem to forget about basic stuff like the sprint review & sprint retrospective. The sort of team that adopts Scrum by sending off a project manager for a 2 day CSM course and think that's the beginning and end of it. Bah.
On the bright side fixing them has become a lucrative sideline for me :-)
Not to deny the massive importance of the customer/product development side - but I've seen places crash and burn badly when they don't have the core development practices to back them up.
Implementing good old-fashioned XP-ish technical practices can give you considerably more than an incremental change - since without it you can't actually execute your good customer/product dev work.
Obviously, with any severely dysfunctional team---I mean some teams still don't even use a VCS---any sort of productivity oriented training should arguably result in significant gains. But these improvements are often looked at in isolation. Being more productive at building the wrong product is still not going to add value. So it really depends what you are measuring and Agilists constantly focus on measuring completely meaningless things, like developer velocity, while expecting the rest of the organization actually knows what it's doing when it prioritizes backlogs or says things are ready to be worked on.
I was in a Scrum training session where the head of product management was concerned when the trainer explained that velocity was largely an arbitrary internal team barometer and couldn't be used to measure the relative performance of teams. He asked "then how can we [use Scrum to] measure their relative performance?" The irony of this was that the biggest productivity issue I could see was the lack of a clear and effective product development process. This meant that iteration after iteration we were constantly building in circles and with only a vague plan for the product. Scrum was not even beginning to address this.
Of course Scrumistas, always claim that these failures are just the result of cargo culting, "doing it wrong(tm)", or just not understanding "Agile". The problem is that these organizations are paying those same people to teach them and are still apparently not getting it, so who is really at fault? It's clear to me both Scrum and XP processes fail at teaching organizations how to learn and improve as a whole. They fail because they focus way too much on explaining the process and pay only minimal lip service to larger organization issues like continuous improvement, product development, customer validation and even basic planning (unless you want to count planning poker, ugh).
Bottom line is, they are oversimplifications at best but at worse are blatantly misleading organizations and software development teams.
That isn't to say there are no good ideas in agile. I still feel a learned lots trying to be a proponent of agile and even Scrum and XP. But after repeatedly going through the painful process of failing, I eventually learned there was more to this and am finally moving on. I should also state I'm still a big fan of the principles of the manifesto, but in the end I no longer see the relationship between the manifesto and the manifestations of agile, particularly in Scrum and XP.
But when I changed jobs in July last year, I met a different team. I call it a dead team. There is no collaborative development, no source code versioning and tracking. (I am comfortable with git and mercurial). No brownbags, no codefests, no freestyle. Everyone works like a cowboy. I tried introduce agile, the team was just rigid because of the head.
Now the head of the team is quitting early September. There are high chances that I may acting as the head of the team after he is gone. But even if I may not be acting, I think I will try again to bring back the culture I used to love. I am guessing it was the head who was refusing to change. Two months ago I tried to introduce git to some workmate, he liked it only that he could not do more with it since the team doesn't use versioning.
I have learnt something: some people refuse change.
I'm pretty much a cowboy, but I like version control. Although, actually, most people seem to view version control as some kind of Golden Stamp Process, instead of a "let me check-in regularly so I can go back to something if I screw up" tool.
In addition, we used ticket versus code check-ins during scrum sessions. It was great!
Normally getting management backing, developing the right culture, and having the right people are huge, difficult topics in themselves that are much larger and more fundamental than how a team decides to develop software.
If anything it goes the other way around. In order to get management support the team should first start doing agile and proving that it works. Having the right culture is a long term thing. Agile software development is a mere step in that direction as far as developing software goes. If anything agile software development helps the right culture emerge rather than the right culture being a prerequisite for agile software development.
And if you truly have the right people you don't need to to worry about agile, you are already doing so well that agile will only slow you down. Agile is probably ideal for larger organisations who unfortunately don't have the "right" people and need a framework or something to help them along. Once people get competent enough, "agile" just starts to feel dogmatic and restrictive. I mean they will still do the practices that make sense, but they aren't going to appreciate other aspects of buying into a whole "agile" approach.
I would also caution against "passing the change baton to higher ups". I have seen all the hard work undone when a fairly agile software development department decided to combine with the product department and include them in the change management process. The idea was to spread agility outwards, but because the product department had mostly more extroverted, managerial types they took control of the decision making (I was surprised how easily the software developers ceded control and retreated into a yes boss mentality) and their command and control culture swamped over any agility we had in the dev department.
When you say "[Aa]gile" here are you talking about a particular process (Scrum? XP?) or something else? I can't really understand the intent - especially since in my experience agile works better with smaller organisations than large ones.
It lays out a superset of the techniques and principles of what eventually came to be called "Agile," in the wee early years of the eighties, and provides the rational for the principles, grounded in experience, and featuring data.
Despite having been through Scrummaster training, I still believe in the power of creating a "destination" and iterating analysis-design-build util the destination is reached. Using short iterations allows for course corrections, and destination shifts. The abilty to correct sooner rater than later is the key aspect I appreciate in "agile."
I've also found that while interations are good for short term planning and for scheduling sprint retrospectives (to borrow from scrum), I find that a kanban/funnel approach works better than strict iteration boundaries.
If you can talk a bit more about what you're trying to deliver and how I might be able to give some pointers. I've never worked with any client where we couldn't get to delivering something useful every week or two.
(Very deliberately ignoring the whole sprint vs flow debate :-)