How come everyone in the room is an old white dude?
If you haven’t read it, you probably should. One thing I would like to is take it apart. My comments are in red.
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools (Great but we can’t forget we need process and tools) I know what it goes on to say about how we value the things on the right but people use this as excuse to get away from process. In the DoD, you have a requirement and responsibility to understand the process. Telling me “that I don’t get it” won’t change that you have rules to follow and if you don’t follow them you won’t have a job.
Working software over comprehensive documentation
Got it, we need to spend time working on the software but once again that isn’t a reason to ignore your responsibility to have documentation.
Bill:Hey, how did Jim set that up?
George: I don’t know Jim quit last week, he won the lotto!
Customer collaboration over contract negotiation
I love collaboration and I love to know what my customers expectation is. This is something that we have to do in the DoD.
Responding to change over following a plan
We have to respond to change and the plan should be altered accordingly but as they say lack of planning on your part does not constitute an emergency for me.
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick |
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
We have seen agile in action long enough to know that we need to temper our desire to be religious. In other words, the Agile Manifesto is not the bible and it doesn’t fit all situations holistically. If you think it does and you try to act on it and apply this concept as if it were a “catch all” and you are working in the DoD, you will be frustrated. Agile concepts need to be woven into the fabric of our work in small pieces. While we value being able to get the job done efficiently we recognize that rules, process and people are in play and that we must figure out for our team individually what Agile means. I am in favor of an “agile like” approach but I am not in favor of throwing out practically hundreds of years of engineering because developers aren’t patient.
Read on.. next post I am going to talk to the principles relative to the DoD.
http://agilemanifesto.org/principles.html
Principles behind the Agile Manifesto
We follow these principles:Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Hey Howie – I am the Golden God of Scrum! The Agile Manifesto is really not to be interpreted quite so literally. The Manifesto does not say Thou shalt not do documentation – rather is emphasizes that the documentation is not the end product. I agree that implementation of Scrum on DoD programs requires some tweaking of the process, but not much. There are some projects using Scrum (albeit not in it’s purest form) but they are moving in the right direction.
LikeLike