Disclaimer: I currently work for a company. That company does Agile. From my limited experience, I think it does it well. I am not talking about that company in any way, shape, or form in this post.<\/p>\n
I don’t recall when I first heard about Agile software development. I probably heard about it from Slashdot, when I was still reading it during grad. school.<\/p>\n
First up, the Manifesto itself:<\/p>\n
From: http:\/\/agilemanifesto.org\/<\/p>\n
”
\n We are uncovering better ways of developing
\nsoftware by doing it and helping others do it.
\nThrough this work we have come to value:<\/p>\n
Individuals and interactions over processes and tools
\nWorking software over comprehensive documentation
\nCustomer collaboration over contract negotiation
\nResponding to change over following a plan<\/p>\n
That is, while there is value in the items on
\nthe right, we value the items on the left more.
\n”<\/p>\n
Overall, it feels like a very human approach to software development. I’ve always enjoyed speculating about the situations which may have led to rules being formed*.<\/p>\n
It also feels like it was written by a group of people who were actually interested in solving problems, perhaps by cutting through Gordian Knots of rigid process and planning.<\/p>\n
Their conclusion was that problems will occur, things will change, and you want your process to accommodate that as much as possible, to enable and encourage people to talk about these earlier and more effectively. More of a ‘getting to yes’, rather than rear-covering or posturing.<\/p>\n
Now, they further broke down the above four statements into 12 principles:<\/p>\n
http:\/\/agilemanifesto.org\/principles.html<\/p>\n
1) “Our highest priority is to satisfy the customer
\nthrough early and continuous delivery
\nof valuable software.”<\/p>\n
This one seems pretty self-evident, but there are a surprising number of people who have job descriptions at odds or orthogonal to this, especially as organizations get larger.<\/p>\n
2) “Welcome changing requirements, even late in
\ndevelopment. Agile processes harness change for
\nthe customer’s competitive advantage.”<\/p>\n
This might be the toughest (it was for me, and I consider myself good at this), as humans are naturally lazy and resistant to change.<\/p>\n
Evolutionary Psychology : Laziness<\/a><\/p>\n I wonder if this can only be overcome through experience, by knowing how much more pain will happen if a particular shortcut is taken or some important stakeholder is ignored. (Even knowing that someone should be listened to instead of letting your lazy brain edit them out can be difficult.) Either way, a good argument for having at least one person (that you listen to!) with experience on the team.<\/p>\n But if you’re having requirements changing too often, your stories are likely not ready before you start, or they are too large, leading you to:<\/p>\n 3) “Deliver working software frequently, from a ‘Fail early, fail often’ goes the quote. Coupled with 2), it becomes much more difficult to be working on the wrong thing when you’re allowing for updated requirements every time you start a new short story**.<\/p>\n 4) “Business people and developers must work I feel like the people who put this list together had experienced a lot of communication problems where they worked. This one is really helpful. There are few things more annoying than being ready to work on something but not being able to reach the person who needs to make the decision.<\/p>\n 5) “Build projects around motivated individuals. From the people I’ve talked to, this is every programmer’s dream. All the best working environments I’ve been in have been like this.<\/p>\n 6) “The most efficient and effective method of Yes. And it drops off considerably, even to ‘face-to-face’ Skype\/<\/p>\n 7) “Working software is the primary measure of progress.”<\/p>\n Many people have different measures of progress, leading to organizational misalignment.<\/p>\n 8) “Agile processes promote sustainable development. As much fun as ‘feast and famine’ is, you’re probably not doing your best work souped up on adrenaline and coffee. (Or maybe you are. If so, you should take some time off between binges.)<\/p>\n 9) “Continuous attention to technical excellence ‘We put brakes on the car so that it can go faster.’ ‘Legacy code is defined as any code with inadequate test coverage.’ All the time you spend hesitating*** because you’re worried about breaking old crappy code is time you’re not building features or refactoring old crappy code.<\/p>\n 10) “Simplicity–the art of maximizing the amount Think Apple. Think Oblivion when they decided to voice all of the dialog, and all the streamlining that inspired\/required. Think about that super-expert programmer you know who can tell you why every single line of code they wrote is there, and also why everything not there is not there.<\/p>\n 11) “The best architectures, requirements, and designs Ask the people who know the most about something to make the decisions****.<\/p>\n 12) “At regular intervals, the team reflects on how Continuous improvement. Read ‘The Goal*****’. Really. It will improve your life. Also retrospectives.<\/p>\n *Similar to reading Wikipedia and trying to figure out the actual events behind the dry descriptions…<\/p>\n **I still remember the day when I felt I had ‘graduated to short stories’, as they tend to pack more large ideas per page. Longer novels tend to be more meditative\/escapatory?<\/p>\n ***And working around crappy code…<\/p>\n ****I’m currently most comfortable with some mix of Scrum and Kanban. They have a specific separation of powers between the team (handles estimation) and the product owner (handles prioritization). To me, this seems totally reasonable, but re-reading the manifesto above, there are many levels of Agile actualization above that. (Think Valve.) (Also, the product owner is part of the team, just with a specific role to play in addition to the general team tasks.)<\/p>\n *****https:\/\/en.wikipedia.org\/wiki\/The_Goal_%28novel%29 My favourite business book. Told in a novel format. Some of the story has dated references (before most of feminism), but is still very useful.<\/p>\n","protected":false},"excerpt":{"rendered":" Disclaimer: I currently work for a company. That company does Agile. From my limited experience, I think it does it well. I am not talking about that company in any way, shape, or form in this post. I don’t recall when I first heard about Agile software development. I probably heard about it from Slashdot, … Continue reading Agile Basics<\/span>
\ncouple of weeks to a couple of months, with a
\npreference to the shorter timescale.”<\/p>\n
\ntogether daily throughout the project.”<\/p>\n
\nGive them the environment and support they need,
\nand trust them to get the job done.”<\/p>\n
\nconveying information to and within a development
\nteam is face-to-face conversation.”<\/p>\n
\nThe sponsors, developers, and users should be able
\nto maintain a constant pace indefinitely.”<\/p>\n
\nand good design enhances agility.”<\/p>\n
\nof work not done–is essential.”<\/p>\n
\nemerge from self-organizing teams.”<\/p>\n
\nto become more effective, then tunes and adjusts
\nits behavior accordingly. ”<\/p>\n