I’ve been working and speaking with whole bunch of people who want to “go agile.” They are not set up for agile. They have gates for approval. They don’t have teams that projects flow through; they assign people to whatever project whenever. (growl. People are not fungible. growl) They have geographically distributed team bits (I discussed this in Manage It!), not cross-functional teams at each location. They believe in their evaluation systems that reward individuals, not teams. They assign people to many projects and believe multitasking is the answer (!!). The only thing they measure about their projects is the schedule and that’s all senior management is interested in.
In many cases, agile is too far a stretch for these people, unless they are willing to invest heavily in training and coaching for each team and each manager, including some training for senior management. But that doesn’t mean they can’t be more effective.
I suggested a staged delivery lifecycle for several of these clients (and potential clients), as in What Lifecycle? Selecting the Right Model for Your Project. For others, I suggested the iterative-followed-by-incremental lifecycle also in that article. For some other clients, I suggested they use timeboxes for each phase, and try to use continuous integration–those two changes were so foreign that I thought starting there would help everyone realize they had other options.
Each project has many options from which to choose. Lifecycles are the way you arrange your project. The practices are what you do. Anyone can use timeboxes and continuous integration. They are practices that might fit for your project. But using those practices doesn’t mean you’re agile.
I understand that agile is the new buzzword these days. I prefer to be effective, rather than buzzy. If agile doesn’t fit for you, don’t try to force it. Instead, start with what makes you most effective, realizing that effectiveness arises from delivering chunks of business value frequently. If it makes sense to use staged delivery or design to schedule so you can fit the beginning of the project into the way your organization funds projects, then do so. You can timebox feature development and have something that looks a little like “waterscrum”, where you start with waterfall, but move into timeboxes where you deliver completed features in timeboxes. Maybe the best thing you could do is pair people so you don’t have so many specialists (originally published as generalists). Maybe the best thing you could do is prototype some features to test that the architecture actually works.
But I really don’t understand why people don’t find a way of working that makes sense for them, rather than climbing on a bandwagon. Isn’t being more effective what we really need to do?
