Software projects are by nature kind of scary for managers - you are investing a large amount of money without much in the way of assurances that you'll see anything for that investment, so being able to see red, yellow and green colored boxes show up on a chart can be calming. By tracking this information, in theory, one can actually ascertain whether a project is behind, and if it is, assign additional resources to shore up the problem area.Īgain, from the business perspective, this is a big win. Within this framework, a dance should then emerge in which the overall shape of the application comes into play, then successive levels of detail, then implementation. Related: Best Project Management Software & Tools Agile went from a rough manifesto to a formal methodology where a project manager (now with the weighty term scrum master) would work with managers to come up with "stories" that described what they wanted their product to accomplish (those things once known as requirements), and "tasks" that then became the steps necessary to complete those stories, and that formed the contract between the manager (through the proxy of the scrum master) and the developer or designer. Needless to say, businesses began to take note, and becoming Agile soon became the mantra of the week. This was about the time that the concept of a minimal viable product began to take hold - the notion that, beyond the first couple of sprints, the product would be useful even if development stopped right then, for some arbitrary definition of useful. They were also projects where, if functionality was lopped off, the application would in fact not be significantly degraded by that loss. They were projects that took between four and six months (eight to twelve two-week-sprints) to accomplish, and they were predominantly client facing (both in the sense that user interfaces were a big part of the experience, and the sense that the client could see changes occuring practically before her eyes). They used databases as a way of storing state, and the web developer usually had unfettered access to that database. Most were web based, where a web interface could be put up within a few days. Getty Becoming AgileĪt the time that Agile emerged, the typical software project fell within the parameters of what Agile does well.
The longer a project dragged on, however, the more likely that other demands would take more and more of that customer's time, to the extent that their involvement became cursory at best.Īgile has done more for the Post-It Note than any other technology in history. Open software projects worked because the tasks that were needed to complete one were relatively self contained - they could be coded quickly, functionality could be shown within a few weeks, design could be emergent because putting an interface up early and expanding that out was acceptable and even encouraged, and once it was done, maintenance was someone else's problem.Īs significant, in open source software the customer could end up staying engaged on a project for a couple of months, because those months were typically the ones that were most oriented towards design. Rather, small teams on small projects made it possible to follow a lean and mean methodology and have any luck at success. The Agile Manifesto had it wrong from the beginning - it was not so much that small teams worked better because they could follow a lean and mean methodology to accomplish a project.
Over the years, I began to realize a subtle but very important distinction. The alternative - "Waterfall methodology" meant that a client would often have to wait six months to see the product, and the unveiling at the end of that phase usually ended up with the customer hyperventilating in the corner somewhere.Īgile was hip, it was cool, and it involved Fibonacci Numbers. Meetings stay short, and having the customer in the room keeps them in the loop. Two weeks seems a reasonable amount of time to show demonstrable progress. When your team was that size, design could be done almost as a group activity. Many open source projects that did really cool things were done by small development teams of between a couple and twelve people, with the ideal size being about seven. If anything, beyond a certain point extra people just added to the communication impedance and slowed a project down. The core principle was simple - you didn't really need large groups of people working on software projects to get them done. The Agile Manifesto, like most such screeds, started out as a really good idea.
0 kommentar(er)
