Oct 24, 2008 / Friday's Digest #2 [Ideas, Tools, Economy]

0 comments

Some links I found interesting last week.

• 37 Ways to Design the Comments Form. Well, some forms are really ugly, but some are very nice.
• Mike Cohn launched new web site www.userstories.com: "The site is specifically aimed at soliciting reviews and ratings of the various product backlog / agile project management tools". Post small TargetProcess review if you have own opinion ;)
• One more interesting tool for ideas management.
• How small iterations may be problematic for your project. Amazing article from Alistair.
• Paul Graham wrote an article about Startup and a Bad Economy. Really, why investors sell when the market is bad? They should sell when market is good :)
• Interesting comparison of Twitter and Yammer. "In any case, the economic crisis might leave growth-oriented companies like Twitter with little choice but to start focusing on the bottom line [revenue]."

Labels: digest, links digest

posted by Michael Dubakov @ 8:04 AM

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

Oct 20, 2008 / Agile Development Future: Will Lean, Scrum and Extreme Programming evolve into one framework?

6 comments

People often ask questions like "What is the difference between Scrum/XP/Lean/Agile/You name it"? I don't see much difference between XP and Scrum on that matter. If you already have XP, most likely don't need to switch. Maybe adopt some Scrum specific practices for a better scalability like Scrum-of-Scrums. Almost all the other practices like daily meetings, iterations, roles separation, retrospectives, etc. exist in XP already.

In fact I am not sure if such separation brings benefits. It is better to spot what's going wrong in your development process during retrospective meetings and apply practices from any agile process (or create own solutions) to your specific problems. XP, Scrum or Lean give you a framework that helps to be adaptive and creative, whereas traditional processes give you a set of rules hindering any creative behavior.

Your team and your project IS special. Think and communicate to sharpen your development process.

I do understand why people are so enthusiastic about Scrum or XP. These processes provide tools and practices out of the box. You may just start doing it and see what happens. It is not the best way, since quite often agile adoption fails. People don't get the new way, they implement it without proper support and under the pressure. They maybe don't have a deep understanding how it should work. So it is expected that agile adoption might not be smooth for all.

Agile Development Future

I wish all agile methodologies evolve into one elegant, smart, simple framework. For me it is a natural trend and it should be something like Theory of Everything in physics. This framework should explain why agile processes work. It should based on natural laws of Complex Adaptive Systems. It should provide general guidance on agile adoption and a repository of possible practices that might be used to build your own development process. The framework should be simple and unobtrusive, since complex rules will not work for software development. The framework should empower creativity, communication, learning, feedback and self-organization. The framework should support nonlinearity, emergence and edge of chaos concepts.

Software development is young. Currently we are having transition from waterfall to agile. It is mainly based on practice rather than theory. Practice has proven that agile works better. However, there's almost no research explaining why. There are some blog posts and short explanations with reference to Complexity Theory. That is a right direction I think, but there's no depth behind these posts, they are quite superficial.

I expect we will have deeper understanding of the agile roots and why it works. This knowledge will simplify transition and help us to find better practices, patterns and solutions. I expect there will be a unified agile software development framework in the future.

So far Scrum and Lean are closest processes to this framework. Lean has a strong philosophy and nice background. It is general enough. Scrum is simpler and more understandable for mere mortals. XP has a set of best practices and heavier in general. All of them have strong and weak sides. But still I feel there's a deeper level and all modern processes are just a subset of some hypothetical (at the moment) unified agile software development framework.

Labels: agile, extreme programming, future, lean, scrum

posted by Michael Dubakov @ 3:25 AM

Oct 15, 2008 / Friday's Digest #1

0 comments

I read a lot. As a generalist I read about almost everything related to software development: design, UX, client-side, architecture, processes and business development. Quite often I find interesting articles, products, announcements, trends and want to share them. So I decided to gather this info and publish on a weekly basis. You have a good chance to know what bothers me ;)

• Open-source JavaScript logging and profiling utility. Author claims that you may forget about alert(). I tried it and looks good indeed. Well-thought utility!
• Conway's Game of Life is a very interesting thing. It is a very simple cellular automaton. The system based on four very simple rules and expresses emergent and very complex behavior. You may play online. I spent an hour yesterday :)
• Uservoice allows you to capture people feedback about your product. Looks nice. Web site too particoloured though.
• Nice Kanban overview from James Shore.
• Maybe you are aware about StackOverflow, but I just hit it last week. The idea behind the web site is simple, but implementation is really cool. They managed to create perfect Q&A web site. Quite often question answered in minutes. That's fantastic! I like it.

Labels: links digest

posted by Michael Dubakov @ 1:45 PM

Oct 9, 2008 / Burn Down Charts, Scope Creep and Forecasts

0 comments

Traditional burn down chart is a famous report in agile community. Indeed, it shows progress very well and reliably (I almost forgot the days when I used Gantt charts in my projects :) However, burn down charts got attacked this year. The author complaint that the chart does not show scope creep, bottlenecks in development and budget burning. Well, I don't think there should be one report for all needs, but changes in scope is a natural metric for burn down charts.

Mike Cohn introduced the concept of the new burn down chart. It shows scope changes nicely. The problem is that it is hard to draw such complex burn down charts manually.

Obviously, agile project management tools should draw enhanced burn down. If chart provides more valuable information showing scope creep (this is an important metric!) it should exist.

Let's take a look at the chart below. In the first day of the iteration (or release) we had original baseline and about 50 pts to complete. Looking at this chart we may retrieve some interesting information about iteration progress:

The history of the burn down is expressive and we can clearly say whether scope creep affected our iteration/release development or not.

The following example shows that we removed some effort from iteration, but are still unable to complete it on time (most likely some more user stories should be removed to meet the deadline).

I think such a burn down chart is much more valuable than traditional one. It will appear in TargetProcess v.2.12 (this month ;)

Labels: agile, burn down, chart

posted by Michael Dubakov @ 3:23 AM