Oct 21, 2008 / Are we agile yet? Grrrrr...
2 comments"Are we agile?", "How agile are we?", "Are we more agile than they are?" Honestly, I am getting tired of these questions. Why do you care? Will it make you happier when you are able to tattoo "100% agile" on your body? Is it a goal to be "agile"? Definitely not! All agile tests are just a garbage. All efforts on agile process certifications/assessments are useless.
There are so many factors influencing software development process that make impossible any certification. Your company is special, you have special people in the development team, you have special conditions, rules, and other external factors. CMMI, PMBOK, and other heavy approaches do not help to build legendary team. They only may help to build an average team and eliminate some quite obvious mistakes in the development process.
The right question to ask is: "How can we be more productive as a team?". It is your project. It is your team. You have goals to improve team productivity ("Done-Done" stories in a period of time), create outstanding software and make customers happy. Agile Tests that answer question "Are we agile?" shift the focus to the wrong direction.
Look, if your team has to pass an Agile "test", they will focus on passing it. That is a plain dumb goal and a waste of time. Let’s say a manager reads about a famous agile test and sets the goal to pass it. Development team, as a complex adaptive system, adapts to the rules and environment. It will change development process and apply practices to pass the test as effectively as possible. However the team’s productivity may suffer. Why? Simply because the test is too general and can’t be applied to any team. Remember, your team is special.
Let's take Scrum and famous Nokia test. The first question is "Describe your iterations" and the worst answer to the question is "We do not use iterations". Well, it is a Scrum test and Scrum insists on having iterations (sprints). But what if your team works more effectively without iterations? What if your team implements "by-feature" using Kanban? What if you have a large project and long iterations are a relief? What if your team holds retrospective meeting and decides to use iteration-less development? Hey, you will fail your "agility" test! Will you be less agile? Why do you care? You will be more productive, that is what you need.
Another example. Third question in Nokia test is "Describe your requirements at the time an iteration starts". The best answer according to Nokia test is "We have good user stories tied to agile specifications as needed". What the hell agile specification is? I don't know such a term. Is it "just enough" documentation? Is it executable specification? Who knows... Maybe your team is fine with just user stories and produces great results. But you will receive less points on the test.
The only good "test" I've ever seen is from exceptional Alistair's book. It contains seven properties of successful Agile development projects. Even in this very broad test some properties may not improve your productivity. So I can't imagine how it is possible to create general test that will work for all teams/projects/environments/etc. It is as achievable as perpetual motion machine...
Anyway, my point is to focus on real goals and throw away fake goals to pass an agile test, be "100% agile" and "agilier" than the team in a next cubicle.
Here is the very good quote:
From my readings of the literature on Japanese management practice, the focus appears to be on the "hows" and "whats" rather than why something should be done. Although there is some mention of "why", this appears to be almost incidental. This may be a result of the cohesive nature of Japanese society, the lack of industrial conflict that was endemic in the UK and many other Western countries, or a product of Japanese management thinking.
I do agree. We often fall into a set of practices, tools and "how-to" solutions. We often take Scrum, or XP, or any other process and apply it in hope to solve all the problems. We don't so often ask "why" indeed. Why we need to change our software development process? It is very important to develop a "need for change" message for your team, your product, your company.
Labels: agile, agile test, criticism, scrum
posted by Michael Dubakov @ 2:48 PM
Jun 25, 2007 / Erroneous and Dangerous Agile Criticism
20 commentsToday David Longstreet posted a comment in our blog with a link to the article with agile criticism. He mentioned that he doesn't like agile. It is always interesting to check opponents arguments, so I've read the article.
I should say that I was really disappointed. The article contains general speculations and almost no concrete comparisons. Common agile principles were disconsidered with strange comparisons and conclusions.
I can't resist from providing some quotes and my thoughts:
"Agile proponents believe discipline is not necessary and inhibits productivity."
This only phrase clearly shows how author is incompetent in agile software development. What the hell "discipline is not necessary"? How it relates to Extreme Programming where discipline is a KEY to success XP adoption? Extreme Programming is hard to adopt since it do require high responsibility and discipline to write all that unit tests, do refactoring, do daily meetings, track progress each day. If you've tried to release something useful and usable each month you know what kind of discipline it requires.
"Agile proponents believe documentation is an overhead cost and should be reduced or eliminated."
Documentation should be just enough. Large teams need more docs, while small teams can work almost without documentation. The main goal is to build and deliver working software. Nobody wants working documentation if software is a crap.
In fact, would you turn over 200-300 thousand dollars to have your home constructed using the same principles advocated by Agile or Xetreme programming. The answer of course is no.
What a dull example! What should I do to change color scheme on my web site? Yes, change several css styles. It will take 5 minutes. What should I do to change color of my house? Yes, buy several gallons of paint, take brush and spend next few days on that task. Changes in software are rather easy, changes in constructions are hard.
Look. If the building company may build 1 room, 1 kitchen and 1 bathroom ready for leaving within 1 month and then tell me that I may move into the house right away, I don't mind! (if they can build and decorate other rooms, cellar, garden, etc. without disturbing me). But building companies do not have such technologies. Software development companies have! That is the difference. The comparison above is pointless.
"Architects actively gather requirements and they study their clients. On the other hand, software developers passively gather requirements and often don’t have a clue about their customer or their business."
Such software development companies will die pretty soon. No way. Agile development is all about customers needs and business value delivery.
"Unfortunately the bulk of Agile software methods deal with coding techniques and testing. Those organizations that spend the least amount of time in coding are those organizations with the highest productivity and quality levels. It does not matter what you make if you spend more time testing than you did making something you have a problem. Testing should never be more than 50% of any project. In the future programming will become like welding, carpentry, and plumbing is today. The most prestigious professionals in the construction industry today are architects and the same will be true for software."
What about SCRUM? What about all these agile principles that focuses on productivity and quality? Unfortunately software industry is not in the phase to create products without coding. Model Driven Architecture (MDA) maybe promising approach, but not mature yet. So we have to code, sorry. What it means? We should optimize coding and increase productivity or invent better approach (like MDA). Why building companies still can't grow a house from a seed? I want to by a small 200 square metre house in my hypermarket packed in a nice small box!
"The primary reason why it is difficult to apply measurement to software organizations is because software organizations are chaotic. Every single time a development project is done it is done differently. [...] In other words, the entire process is just a mess."
Similar projects should be done similarly. Different projects SHOULD be done differently. Period. Agile strives for defined process that will evolve and adopt to any project. There is a deep misunderstanding of agile principles and ideas.
I don't know the reasons why the author wrote the article, but it is unprofessional. It does not show agile disadvantages, but looks like desperate attack on agile positions.
posted by Michael Dubakov @ 2:27 AM
