login
Blurts on the Art of Software Development

Today | RSS | RDF | Atom | Other Tags
Categories : All | All | CI | .NET | General | Humour | Java | Personal | Reviews | Ruby | SW Eng

Yep. Uh-huh. Right. Cool. The roadmap for IDEA 6 sure looks like I might have to give IDEA another try.

I just read the following paragraph from Mishkin Berteig's blog and remembered a draft I'd written after getting that chilly feeling of seeing agile methods being adopted without the people involved really knowing why their organization is doing it.

"I've seen organizations adopt Agile in some form or another for lots of different reasons. The best reason is because it is recognized as a means to succeed. However, as a means, you don't want Agile to drive change in your organization. Something else should be doing that. Some need, some failing, some gap or some pain. And that need should be measured."

Isn't it ironic how one of agile methods' key ideas, delivering value, is sometimes forgotten by the very people advocating and championing the adoption of agile methods in their organization?

Yes, it is ironic. Or would be if it wasn't so painfully true.

The fact is that people have developed software successfully with methods not too similar to modern day agile methods such as Scrum and Extreme Programming. Those people, when embarking on their first agile projects, are likely confronted with a pretty big slope in terms of productivity, project success even, as they learn a new way of doing things--even if they'd eventually recover to a whole new level of quality and productivity.

Organizational change is about people. People need to commit to the change in order to make it last. In order to truly commit, people need to understand the rationale for that change. Do not for one second think that what is blatantly obvious to you is obvious for everyone. Take care in making sure everyone involved and affected really understand why the change is important for the organization. Most of all, make sure you know the answer.