May 31, 2009 / Lean and Kanban Software Development Digest

4 comments
Work In Progress (WIP)

Lean and Kanban software development adoption is growing. More and more companies setup Kanban Boards, limit WIP and eliminate Muda.

This collection of links will help you understand all that buzz around Lean/Kanban and decide whether it is worth trying. I've read all the articles and posts below, so this list is a truly selected thing ;).

Articles and Blog Posts

  • Lean Software Development. Wikipedia summary about lean software development. It is a good start to digg into the topic (as usual).
  • Kanban Development Oversimplified. Most likely the best article to start with Kanban. Very clear, very detailed. Good work!
  • Kanban, Flow and Cadence. This blog post with many nice pictures describes three important properties of Lean: Kanban – Controlled Work, Flow – Effective Work, Cadence – Reliable Work.
  • Scrum-ban. Interesting attempt to mix Scrum and Kanban, taking the best from both worlds. Kanban with iterations is possible.
  • Beyond Scrum: Lean and Kanban for Game Developers. Article describes real Lean/Kanban implementation for game development industry. The section on how to improve The Flow (3 strategies: Time-boxing, Levelling workflow, Reduce waste) is especially good.
  • Adventures In Lean. Series of posts about Lean approach with focus on real problems solving (handling bugs and emergency fixes in Kanban, setup pipeline, bottlenecks, etc.).
  • Lean and Kanban. Several posts on the topics in this blog.

Presentations

Lean/Kanban Blogs

  • Agile Management Blog. Lots of interesting posts from David J. Anderson (well known engine of Lean software development :)
  • Richard Durnall Blog. Pull and Push systems, interviews, lean roots and principles. Nice reading with hand-drawn diagrams.
  • Lean Software Engineering. Corey Ladas and Bernie Thompson are blogging about Lean, Scrumban and Kanban, Theory of Constraints, software development and other topics you did not even hear about.
  • AvailAgility. Karl Scotland's posts are very interesting (and helpful) to read. Isn’t Kanban just a Task-board? Check the blog to get an answer.
  • The Agile Executive. Many insights into Kanban and summaries from the first lean conference.
  • Software Just in Time. Lean concepts and real lean applications posts by Alisson Vale.

Lean/Kanban People in Twitter

  • David J. Anderson. Lean/Kanban software development pioneer.
  • Corey Ladas. Product development methodologist. Author of Scrum-ban book.
  • Henrik Kniberg. Optimize, debug & refactor IT companies. Author of Scrum vs. Kanban presentation (which is very good!)
  • Karl Scotland. Agile Coach. He runs AvailAgility blog with great insights into Lean and Kanban.
  • Rob Lally. Renaissance Technologist.
  • Alisson Vale. Alisson implemented outstanding Kanban process in his company.

Tools

There are just several Kanban tools on the market. To be honest, I don't like TRICHORD UI. LeanKit: Kanban looks much better, but it can work for small teams only on my opinion. Anyway, it seems Kanban tools vendors' race just began.

If you know other tools that support Kanban, drop a comment and I'll happily include them into the list.

  • LeanKit: Kanban. In beta so far, but looks quite neat. Maybe useful for small teams.
  • TRICHORD. Desktop project management application with Kanban boards.
  • Radtrack. Registration does not work, but I found the screenshot via Google. Looks like LeanKit so far.

Did I miss something interesting? Drop a comment!

Labels: , , , ,

posted by Michael Dubakov @ 1:51 PM

May 26, 2009 / The Race to Performant Application: Designing Time and Flow

1 comments

Fact: Complexity causes 50% of product returns

Fast and easy-to-use applications are quite rare. Simplicity and Performance are two major properties of any killer software product. We, as software developers, should pay attention to these properties as non-functional requirements, but in real life we often tend to implement more features, more functions, more settings, more, more, more... The race is hard to win with this strategy along the whole way.

I must confess we've done almost the same to TargetProcess. We went on with providing more and more features and options. Definitely we tried to keep the application simple and fast, but these goals were secondary. We've stopped. And changed.

Now we are focusing on better performance and usability. We think that TargetProcess is a quite feature-rich application that fulfills most needs in agile project management. It is time to stop and find answers to the questions: "Where do people get stuck with our software?", "What is complex and how it can be simplified?", "How to make TargetProcess enjoyable to use?", "How to make TargetProcess the most performant software in our niche?". The questions are hard to answer and address quickly, but we are looking for the answers.

Steven C. Seow wrote an excellent book about principles that should be taken into consideration for any "performant" application Designing and Engineering Time: The Psychology of Time Perception in Software. I read it and want to share some interesting observations.

Hick–Hyman Law describes the time it takes for a person to make a decision as a result of the possible choices he or she has. Simply speaking, less functions — simpler and faster choice. It leads to several conclusions what we should do as software developers:

  • Minimize options. Obviously, if you have 50 elements on the screen, it takes time to choose which action is required. If you have 20, the UI is faster to work with.
  • Keep it simple. Well, it is a general principle for all the facets of agile software development.
  • Short system messages (10 words max). People don't have time to read long messages. Delays kill usability.

Some concrete numbers from the book:

  • Response time of typical action in the application should be about 2 seconds.
  • If response time takes more than 5 seconds, it is required to show a progress indicator. User should know that system is working on the task.
  • If system response time is more than 7 seconds, people tend to leave web site or switch to another task. It breaks interaction flow.

Noticeable Performance Improvement

If you are going to improve performance, it should be faster by more than 20%. Otherwise most people will not see the difference (it was shown in some researches that performance difference is noticeable in a range between 10% and 18%). For example, if you are improving search function with 10 seconds response time, it is required to make response time at least 8 seconds (or less).

Flow

Flow is very important for good user experience.

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.

Our goal is to make the Flow possible. I think it is the hardest thing in software development.

Real software not only helps people to solve real problems. It enables The Flow.

When user opens an application and sees complex UI, it is frustrating for him. Application should match user experience and skills. Simple or Advantage modes, clean and simple UI (Hick–Hyman Law!), balanced options and functionality — this sounds familiar, but hard to develop.

Labels: , , ,

posted by Michael Dubakov @ 4:32 AM

May 6, 2009 / This is not a joke: Gantt charts in TargetProcess

1 comments

It's good to get questions from people who work with TargetProcess. Indeed, questions and feature requests are like a plancton for this product ocean. We thrive on them, and we take the power to move forward from our clients' feedbacks. Some of the questions are worth to be blogged on, to initiate a discussion and get the right direction.

So, one of these questions is about Gantt charts, whether we're going to implement them in TargetProcess or not. Notably, for the most part this question is asked just this way — are you going to implement Gantt charts? People forget to explain what are they looking for in Gantt charts and why do they need them whereas in reality it makes a huge difference if they want Gantt charts for dependencies on tasks level or if they want Gantt charts for Program-level planning, to get a "bird's eye view" on what's going on with all the projects, as they put it.

For those who want Gantt charts on tasks level, to manage dependencies and to nurture a gigantic critical path for the sake of nurturing it - the answer is always "no". There can be no Gantt charts for tasks and dependencies since agile is not about tasks dependency and critical path management — it's about flexibility and "temporary dependency", if you want to call it this way. The most you can get about dependency on User Stories and Tasks Level in TargetProcess is indication of related User Stories with a custom field. We're going to implement this in the next release.

User Story NameDepends On
As a user I want to LogoutAs a user I want to login
As an admin I want to delete usersAs an admin I want to view users list
As a user I want to purchase thingsAs an admin I want to add thing into the catalogue

I will not be going into much detail with the reasons for this "no", re-writing multiple articles on this topic, Google is always right at your fingertips :) But I'll just give you a link to a very comprehensive post.

The only way for Gantt charts to stay alive in TargetProcess is in high-level planning of Program-Projects, that's what you might call a "what's- going-on-in-the-forest" view. We already have these Gantt charts in plans. That's how they will look:

High level Gantt chart

Originally, TargetProcess has been more focused on managing just one project. But as we get feedback from people, we see the need to implement more elaborate features for managing multiple projects on Program-Project level — those Gantt charts provide a quick scan look to all the projects.

Follow our roadmap for the Gantt charts. Your feedback is really important to us, so we encourage you to register at our Help Desk Portal and support forum and vote for Program level Gantt charts here.

Labels: ,

posted by Olga Kouzina @ 4:04 AM

Apr 8, 2009 / Agile Certification? C'mon Folks!

6 comments

I wrote previously about agile certification. I don't like the idea. However, some new arguments arose recently.

For example. Peter Stevens wrote: "In a time when every office worker gets told 'A Microsoft Office certification is good for your career,' it is clear that certification is part of the game".

It is not the case for companies applied agile software development. For example, at TargetProcess we do not pay almost any attention to official certificates. They all sucks. I personally interviewed many people having several Microsoft Certificates, but many of them were bad developers. They were coders, and that is something we are fighting against. It appeared that certification has nothing in common with developers skills. We hired several people with no certificates at all, and we hired several with certificates. There is no any relations between good developer and certificates they have.

Agile implementation changes company culture. Without this shift agile adoption will fail in the long term.

I do believe that there are many Certified Scrum Masters that did not get the Scrum process right. People are different. Someone may attend the course and work hard to improve his knowledge. Someone may attend the course and take SCM title with honor, thinking that he knows everything to implement Scrum in his company.

On my opinion that is one of the reasons why Scrum adoption fails in companies.

How To Certify Meta Process?

Software development process is a complex thing, that should be adopted to each company, environment, etc. Some best practices may not work in some conditions. It means we can't include practices into certification test at all. What we can include is things that shape the process, things that focus on development process improvements, like retrospective meetings, communication empowerment, self-organization, emergency. But can you imagine how the questions sound like?

  • Have you something in place that enables process evaluation and improvements?
  • Do you have practices that power communication?
  • Do you have practices that enable self-organization?

Guess what answers can we get on such general questions: "Yes, our top managers meets every year and discuss development process improvements", "Yes, we have Outlook, it is great for communication!", "Yes, team located in one room, so it is easy to shout out and assign particular task". The result is obvious though.

What Type of Agile Certification May Work?

Agile certification may be developed in the future, but for the very strict set of conditions. For example, there may be quite good set of questions for the team under the following conditions:

  • Team size: 4-6
  • Project type: Typical web site
  • Project complexity: Average
  • Distributed Team: No
  • Region: Europe
  • Technology: Ruby

If someone creates questions based on the criteria above, that may work. All other attempts to certify teams using General tests will miserably fail in the long term.

Labels: ,

posted by Michael Dubakov @ 3:08 AM

Mar 23, 2009 / Simple Rules, Complex Systems and Software Development

3 comments

Many complex systems are based on simple rules. A set of several simple rules leads to complex, intelligent behavior. While a set of complex rules often leads to a dumb and primitive behavior. There are many examples.

Ants Colony

How ants search for food? They do not have cell phones, cars and mini-markets near the nest. They should have something simpler to communicate.

Here is how ants work:

  1. Travel randomly  in search for food.
  2. Take a piece of food and head straight back to the nest. On the way back to the nest lay down an odor trail.
  3. Notify nestmates of the discovered food encouraging them to leave the nest. These newly recruited ants will follow the odor trail directly to the food source. In their turn, each ant will reinforce the odor trail until the food is gone.

Sounds simple? Take a look at this very nice ants colony model. Drop some food and enjoy the action.

Birds Flocks

Birds flocks are beautiful. You may think that the movement gets orchestrated by one savvy bird. But this is not the case. A bird glock is guided by three simple principles (every decent bird knows them):

  1. Separation: steer to avoid stumbling upon local flockmates.
  2. Alignment: steer towards the average heading of local flockmates.
  3. Cohesion: steer to move towards the average position of local flockmates.

Simple? Yes, it is. Look at the picture on the right. It's just amazing!

Game of Life

Game of Life was invented in 1970 by John Conway. It is a cellular automaton and simulates the birth, death, etc., of organisms based on certain rules:

  1. Each cell with one or no neighbors dies, as if of loneliness.
  2. Each cell with four or more neighbors dies, as if of overpopulation.
  3. Each cell with two or three neighbors survives.
  4. Each empty cell with three neighbors becomes populated.

Simple rules. But these rules lead to fantastic diversity of the forms. Different types of the forms have been discovered e.g.  still objects, oscillators, gliders, spaceships, etc. It is impossible to predict the state of a system after several thousands steps. Cellular automaton has properties of a complex system such as emergency and butterfly effect. Small changes in the stable structure (for example, adding one more living cell) may cause death of the whole cells population.

Moreover, it is possible to build a computer based on Life! It is possible to implement logic based on stable structures and execute simple calculations. The Game of Life is a Turing machine! How can someone suggest that such a simple system based on four rules has so much power?

Take a break and have fun with Life game simulation.

Simple Rules and Software Development

Is there any relation between simple rules and software development? Sure, there is. Software development process should be simple. Process complexity leads to mechanistic and dumb behavior.

  1. Information exchange and collaboration vs. standard status reporting meetings.
  2. Learning vs. stagnation.
  3. Emergent behavior and creativity vs. Following rules, standards, instructions.

Agile methodologies are simple. Scrum is a very simple thing. It has just several rules, roles and artifacts. Well, it is a lot harder to really implement Scrum. It is hard because you need to break stereotypes and habits. Many people are resistant and don't want to try new things. However, Scrum works. It works because of its simplicity, it lives in accordance with complex systems.

Scrum stimulates learning, feedback, communication and cooperation. Emergency is possible in Scrum.

Here is one sample of unnecessary complexity — too many hierarchy levels:

A potential problem, unlikely in small and medium organisations, is deep organisational structures. According to Peters and Waterman (1982)18, both Toyota and Roman Catholic Church have only five layers of management in comparison to Ford's seventeen.

Do you by any chance happen to have a software development process description in a huge 100+ pages document? Are you still in business?

Labels: , ,

posted by Michael Dubakov @ 4:09 PM

Mar 19, 2009 / Zero Defects? Are You Kidding Me?

11 comments

Are you familiar with zero defects mentality? It looks very good from the first sight. Zero defects... Let me think... Well, cool! I like it! I’d like to have zero defects in my projects.

So, what is zero defects mentality? Here is the quote from Lean Software Development an Agile Toolkit book:

“One of the fastest ways to kill motivation is what is called in the US Army a zero defects mentality. A zero defects mentality is an atmosphere that tolerates absolutely no mistakes; perfection is required down to the smallest detail. The army considers a zero defects mentality to be a serious leadership problem, because it kills the initiative necessary for success on a battlefield” — Mary & Tom Poppendieck

Obviously, zero defects mentality is not something that HOUSE M.D. likes ;) Moreover, I think Dr. House hates zero defects mentality. It causes several unpleasant effects:

  • Not enough courage to refactor complex, messy, buggy, but important piece of code.
  • Can’t make important decision, instead make less risky, but wrong decision.
  • Do everything to avoid responsibility, that leads to coward and stupid behavior.

"Zero defects" may sound good. But in reality you still have errors after production. Even in predictable and (quite) easily testable industries (hardware, automobile, etc.) there are problems with 100,000 power adapters that should be replaced (or hard drive problems, or engine problems, I bet you can continue the list).

How can we expect zero defects in software development? It is harder to test, harder to define in details, harder to predict. Software development is a complex adaptive system, we can't predict all effects. Bugs in production is a normal thing, and by “normal” I mean we can't bring them to zero. We can (and should) minimize them using all possible ways, but The Last Bug is a mirage.

There are several obvious strategies that may help:

  • Test Driven Development. Nice side effect of TDD is a unit tests suite. You have tests for new code, and you have unit tests for old code. More tests — less bugs.
  • Continuous integration. Instant feedback helps to identify problems early and fix them early. It saves time (and money) and reduces bugs in production.
  • Automated regression functional tests suite. Unit tests are good, but you need something else. Functional tests emulates user behavior and find user interface errors, integration errors, etc. Needles to say you should have continuous integration in place to succeed with automated functional tests.
  • Root cause analysis. There are several ways to fix a bug. You may just hack the code and apply a patch (please, don’t do it at home!). You may think deeper and fix the bug nicely. Also you may look into the root of the problem and fix it. Yes, it may take time, but you will prevent future bugs from this domain.
  • High development skills. Ironically, high skills do not always reduce bugs rate in production. “Stars” may be strong in some areas (business layer), but may not polish things. It may lead to many small bugs, especially on UI.

Is it a good thing to have "Zero Defects" goal in the sprint? The answer is "Are you kidding me? Zero bugs? It's a miracle!"

Labels: ,

posted by Michael Dubakov @ 12:10 PM

Mar 9, 2009 / Agile Bug Management Anti-Patterns

10 comments

Agile development books often skip bug management practice. However, there are several dangerous misunderstandings (anti-patterns) that are quite common. It is better to recognize the problem early and fight to win. Here are three common bug management anti-patterns in a development process.

Bug fixing phase inside iteration

Symptom: You have several days at the end of  iteration fully dedicated to  bug fixing.

If you have a bug fixing phase inside an iteration, you have mini-waterfall in each iteration, which is not a very good idea (in agile we blame waterfall for good reason, don’t we?). Story should be tested as soon as it is completed.

Bug fixing iteration

Symptom: You run several iterations with almost no or little bug fixing and then one (or even two!) iterations fully dedicated to bug fixing.

Bug fixing iterations kill your iterative development. It is even worse than mini-waterfall. Such iterations increase your work in progress dramatically. You have nothing done during several iterations before bug fixing iteration. You have nothing to ship. Moreover, bug fixing iterations reduce motivation, people don't like to fix bugs for 2 weeks or for the whole month.

No “Zero open bugs” rule in user story’s Definition of Done

Symptom: You have open bugs in a completed iteration.

You may have decided that some bugs discovered during story development are unimportant and can be postponed to  future releases/iterations. This is a very dangerous practice that leads to bugs accumulation. Moreover, it may be a reason for Bug fixing iteration (see above). The best strategy is to have “Zero open bugs” rule in Definition of Done for user story.

Labels: , , ,

posted by Michael Dubakov @ 3:29 PM

Nov 12, 2008 / Agile Software Development and Complex Adaptive Systems: Intro

3 comments

There are quite many agile processes in the world already. We have Extreme Programming, Scrum, Crystal, DSDM, Feature Driven Development, Lean. Some of them are famous, some are maybe dying. The point is, we have plenty of agile processes. In general this is not too bad. We've got alternatives, they move agile forward and solve real problems. On the other hand, I feel the lack of information on the roots of agile processes. Most articles available are missing the point on my opinion.

Why iterative development works? Why agile manifesto is the truth? Why traditional project management techniques miserably fail on software development projects? Somehow many people feel the right direction. They have a background that guides their decisions. We feel that agile manifesto brings real value. We has proven this in practice after all! But I personally feel that there is something deep and cool behind most of agile practices. Something that will explain why this all works.

While reading Jeff's post about Scrum roots, I found a reference to Complex Adaptive Systems. I went digging into more details. I read a lot about CAS and related things and there were many "a-ha" moments. There are so many parallels between CAS and Software Development. It is pretty obvious that Software development is a Complex Adaptive System itself. It has almost all basic properties of CAS and it is interesting to read, for example, about adaptation in various CAS and think about its application to the software development and agile principles.

I believe that a deep understanding of Complex Adaptive Systems will shed some light to the real roots of agile development and will answer important questions. With this knowledge in hand it will be easier to see why this works and why that failed. It will be easier to make decisions and create a better software faster.

However, I am not sure how interesting this will be to the people :) In the next several posts I will write on why software development is CAS, describe important properties of CAS and apply them to software development (adaptation, feedback, self-organization, emergence, edge of chaos, non linearity, etc). Let's see how it goes, maybe we'll find something interesting ;)

Labels: , ,

posted by Michael Dubakov @ 12:55 PM

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: , , ,

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: , , , ,

posted by Michael Dubakov @ 3:25 AM

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:

  • We've made some progress and on Oct-21 someone added more work to the iteration. 
  • Next day someone added even more work, so we've got a clear indicator of the scope creep.
  • Then someone removed quite many effort from the iteration  
  • The current day is Oct-27 and we see that some effort already burned (green bar) and some effort added (red bar)
  • We see the forecast based on our progress and remaining effort (grey bars) and it seems the iteration may be completed on Nov-16
  • Ideal line shows that the iteration should be finished Oct-31 and we're two weeks behind (gosh!)

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: , ,

posted by Michael Dubakov @ 3:23 AM

Sep 25, 2008 / Agile Software Tool will not help you to understand Agile

0 comments

As you maybe know we at TargetProcess develop agile project management software. We have a free community edition that is becoming popular and have about 1300 downloads already. People who request the free edition or trial provide comments. Sometimes these comments really disappoint me. Especially if I see comment like "I hope this community release help me dive into scrum. Thanks."

What's wrong with it? Well, I don't know any software tool that may help to understand agile process better. If a company starts SCRUM implementation or any other agile process implementation we do not recommend to start with a tool. Hire agile coaches, read books, try simplest tools like whiteboards and sticky notes, visit conferences, try best practices, and learn! Do not invest into any software tool till you feel the need.

The team may be distributed, or large, or needs real-time progress reports desperately, or anything else. But the team should try to operate with simplest tools first. And focus on live communication. It is the only way to "feel" agile spirit. It is the only way to dive into agile.

Do not rely on a tool. It may help to resolve some problems. It may even help a lot if you have distributed team. But it may dictate or recommend some best practices, project structure, process structure and the way how you are developing software. That is something to avoid in the beginning of agile adoption. The team should invent own best practices, own project structure, own process. With this in hands the team may decide to use a tool to resolve real discovered problems.

Agile PM tool is not a silver bullet after all. Do not rely on it blindly. It should adopt to your development process, not vise versa.

Labels: , ,

posted by Michael Dubakov @ 4:32 AM

Sep 19, 2008 / Waterfall got you down with "multitasking"? It's time to take an "Agile" medicine!

1 comments

Everybody knows that multitasking is bad in general. Time is wasted due to context switching and more errors due to insufficient attention. There are many opinions and articles about multitasking problems and general advice is to eliminate it when possible. However, it is required to define what the task is in multitasking before making any conclusions. For example, is it possible to consider waterfall a multitasking process?

For simplicity purposes, let’s assume that our development process has 4 stages: specification, design, implementation, testing. We have a bunch of requirements that may be implemented in the project. In the design stage we focus on the system design only. We think about objects, patterns, communication, API, etc. Looks like quite a focused activity, doesn’t? However, at the same time we are designing many features. We are trying to consider them all and create a design that supports all of the features at once.

There are two facets to this problem:

Activity-based:
From this point of view we have a single focused task - system design.

Feature-based:
Here, we have many tasks (design feature 1, design feature 2, etc.).

What is a better view? I think it is required to focus on delivery. In the end our ultimate goal is to ship working software with a set of features. We do not ship system design, requirements documents or acceptance tests. We ship functionality (features). Feature that solves a real problem is the most important thing in software development. That is what we produce. We should focus on features (that solve real problems in a most efficient way). We should not focus on activities; they are just a part of development process. If you can release working bug-free software without testing stage - that is perfect. If you can release it without design stage - fantastic. Following common/defined/approved/considered-best process is not a rule of thumb. If you can release working, usable, high quality, efficient software without any formal process - that is fine. I am not trying to diminish the importance of processes in the software engineering, but too many people developing software using waterfall, loose focus on their ultimate goal – to ship a product that user wants!

It is better to consider feature as a task (in a multitasking term, it means that multitasking and “multi-feature” are interchangeable). Having this in hands we can say that waterfall is a kind of multitasking. It leads to many features in production cycle, thus eliminating focus. Development team tries to follow defined stages with the best possible output, but the goal is often blurred. People focus on specification, design, implementation, testing, but often they loose focus on features. Why? Well, two reasons: context switching and insufficient attention.

For example, in the design stage you have many features to design and can't prove all design concepts for all of them. During implementation stage you face many problems with wrong initial design decisions and have to change and adapt design quickly. That is natural, since design can be proved only during the implementation, there is no way to get it right the first time. However, such quick decisions may be uncontrolled and uncoordinated. They ruin the original fancy design. Insufficient attention? Yes, since it is impossible to design and prove ALL the features during the design stage.

The same is true for the testing phase where we have many features to test. We can't focus on one feature, we feel that there are many more features to test and most likely will not complete full testing of one feature. We feel that it is better to test all features briefly than test some features deeply. We briefly test feature A, then jump and briefly test feature B hoping to get back to it later and complete the testing. We have many features to test causing insufficient attention. Often under time pressure you can't get back to briefly tested features, and that leads to bugs in post-production period. Large testing stage blurs focus on features testing. It may sound strange, since it is the testing stage after all - but think about it once again.

Iterative development (especially using short iterations) solves these problems in the roots. You have few features in the production and may focus on them. It is easy to fully test several features. It is quite easy to design and prove the design right away (in waterfall you may have several months gap between feature design and implementation). You have a clear focus by not having to switch to other features outside of the iteration scope.

Iterative development is a vertical slicing. You implement "by Feature". Waterfall development is a horizontal slicing. You implement "by Activity". What do you prefer? ;)

Labels: , , , ,

posted by Michael Dubakov @ 3:59 AM

Sep 11, 2008 / Software Development Diseases and Agile Medicine

3 comments

It is really interesting to check some established diseases in software development and investigate how they can be resolved using agile processes. If agile development is so good, it should provide solutions to common problems. Here we go.

Student Syndrome

Many people will start to fully apply themselves to a task just at the last possible moment before a deadline.

Maybe the most famous disease in software development teams. You have 40 hrs task and thoughts like "Huh, one week! I am pretty sure I will complete this task in 2 days!" You are doing something fun like refactoring or research and start working on the task Wednesday's afternoon. Suddenly you encounter a serious problem. You spent all day hunting for resolution with no luck. In a weekly status meeting you say that task was not done and 80% ready, but there is completely unexpected nasty problem that popped up and broke the plans.

Looks familiar? Yes, it is. Agile development solves the problem with several simple practices:

  1. Daily Meetings. You have to say something on a daily meeting. If you committed to the task on Monday and spent all Monday researching something completely unrelated you will have bad feeling during Stand-Up. It pushes you to actually start working on task. Also serious problems will not be under the carpet for days, they will be revealed and expressed.
  2. Short Iterations. In short iterations every single task is important. If you have 1 week iteration you are feeling that deadline is close enough and you have no spare time. If you have 6 months project deadline in waterfall process you have an eternity. You can do wrong things for weeks till the reality hits you in the neck.
  3. Short Tasks. Two days is a good maximum for a single task. It is quite hard to convince yourself that you can start coding tomorrow if you have only two days to complete the task.

Parkinson's Law

Work expands so as to fill the time available for its completion.

Indeed it is a matter of perfection and laziness. Some people may complete the task earlier and have spare time for other things. Some people will complete the task earlier and polish the solution till it shines. Some people will digress from the task and complete it on time. All attitudes may be dangerous. The result is that a whole project delayed.

Agile approach has some medicine for this disease as well:

  1. Definition of Done. The task is done when it passes all assertions in DoD. The goal is to have clear, unambiguous definition. People should know when it is ready. The phrase "it will be done when it's done" should have clear meaning behind.
  2. Iteration Goals. Clear iteration goals help people to focus on getting things done.
  3. Short Tasks. Again short tasks may help here. In short task it harder (but still possible) to add long safety buffer.

Conway's Law

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Maybe it looks quite weird, but this law has great application in software development. If you have two modules that interact via API, you hardly create good API unless developers of the both modules communicate together. It leads to some conclusions:

  • Communication between developers is very important for good design.
  • Distributed teams may hurt software design in case of poor communication (and it is harder in distributed teams).
  • Software can't be produced in isolation. You can't have several people working on several modules with no or little interactions.

In agile development there is a clear statement that communication is very important. It does not have explicit practices for software design communication (well, except pair programming), but it doesn't take a rocket scientist to create and apply them. Company should adapt and change to have great communication flows.

Brooks' Law

Adding manpower to a late software project makes it later.

There are two simple reasons behind this law:

  1. It takes some time for the people added to a project to become productive.
  2. Communication overheads increase as the number of people increase.

From the first sight agile development can't to anything with these problems. However that is not true.

  1. Pair programming. Likely it is the most efficient way to familiarize new people with the project.
  2. Iterative Development. New iteration and new release is a new mini-project in fact. It is easier for people to start with something new. If you join the team in the middle of one year release you feel less comfortable.
  3. Small teams. Agile approach works best for small teams. When it scales, it does not bring much communication overhead. For example, a single scrum team works autonomously, while scrum master participates in scrum-of-scrum meetings. However it does not increase communication time in a single scrum team.

Feel free to continue the list of diseases ;)

Labels: ,

posted by Michael Dubakov @ 2:32 AM

Apr 15, 2008 / Should We Have Parallel Releases and Iterations in a Project?

7 comments

The story began few months ago when we restricted creation of overlapping releases in TargetProcess. What does it means? People lost a possibility to create several parallel releases. The answer is pretty simple if you have several teams working on the same large project. Definitely you may have parallel releases and in fact each team may have own release schedule which should be approved/synchronized with other teams, but it may have different end date. It is not a mandatory to have all releases from all teams in the same day X.

But what if you have one team and one project? The main concern is something like that: “We are working on version 1.5 now, but we need to releases some patches for version 1.0 and also some people from our team working on version 2”. Sounds like a natural situation. Indeed we have to release some patches with bug fixed as soon as possible since it affects current customers and they need resolutions right now. Indeed we are developing new version with defined set of functionality. And hey some our gurus started prototyping several killer features that are not will be a part of version 1.5, but may be released in version 2. All it may look reasonable. Isn’t it?

Well, the simple answer is no, it isn’t. Let’s dig into details. For example, we have a team with 6 developers (skip QA and other team members for simplicity). You have 1 month releases schedule. You have defined scope for release 1.5 and some features for release 2. You know that you should also release 2 or 3 patches during this month for version 1, but the scope of the patches is undefined at the moment. How will you plan the release(s)? “OK, Joe, you will work on patches when some important issues will be reported by customers. But till that time you may work on Feature X for release 1.5. Mark, Beth and Teddy will take all other features from release 1.5. Also we have some very important and complex features that planned for version 2. We should mitigate risks and prove the concepts right now. Tom and Jerry will work on that”. What we have in the end?

Joe belongs to both releases. Other people do not have multi-tasking. Everything looks good. In reality we may end up with some bad things:

  • Some issues assigned to release 1.0.x are hard to fix and Mark will help Joe to fix them.
  • Joe spent too much time on bug fixes and unable to complete Feature X on time. So it will be required to exclude the feature from release 1.5 (or call someone from release 2 to help Joe).
  • Beth’s feature appeared to be more complex than expected. Again two options (drop it or call for help).
  • Jerry did not finish his work for release 2, since he was helped Beth and Joe in release 1.5
  • Tom did all fine, but in the end it appeared that customer decided to drop the feature from the release 2 at all and replace it with another feature.

I agree that all above sounds pessimistic. But didn’t you have similar problems in the past?

Now we have 3 people with multi-tasking and all Tom’s work out of context (he did not add any value to the releases). Obviously, our plan failed. Why? We violated some core principles of agile development:

  • Make decisions as late as possible. In fact Tom and Jerry’s assignment to release 2 was a mistake, since the release 2 will happen next to release 1.5. Important addition: It is OK (and even recommended) to proof all possible concepts before project start or in release 1.
  • Reduce Work in Progress (WIP). The more WIP you have for given resources, the later you will release something. If we have 10 user stories and all of them will be in progress, we will have waterfall process in the end. We will have 90%-done problem and all related risks.
  • Avoid Multi-tasking. Something related to point 2, but with such plan we really increased multi-tasking. Depending of context it may be better to assign Joe full time to Release 1.0.x (if you are struggling with de-motivation problem, you may just rotate developers for patch releases for example).
  • Avoid 100% people loading. You may want to load all people 100%, but that’s a mistake. People should have some free/spare time. It is a proven fact that 100% load decreases productivity/throughput. So if you assign Joe to release 1.0.x and he will do nothing 1-2 days that is not a problem. He may do some minor refactoring or some minor bug fixes. But he will be available just in time when first issue request will be received.

Is this plan better?

Well, maybe. We eliminated all work from Release 2, which is good. Could we eliminate work from release 1.0.x? Probably, if fixes are not very important and may wait till release 1.5 availability. And often they can! Most likely you will have several fixes that MUST be released ASAP. It may take 2-3 days from one of the developer to handle them.

Turning back to TargetProcess ask me a question “Will you make it possible to have parallel releases in a single project?” I am answering “Yes, we will”. In reality things are more complex. You have pressure from top management who knows nothing about lean and agile and you gave up explaining the reason behind one release at a time and 100% people load problem. You have a large team inside one project and want to separate work with releases (why not?). You have maintenance releases and want to track them separately (why not?). Maybe there are more cases. Real life is complex and teams are learning doing agile.

Labels: , , ,

posted by Michael Dubakov @ 5:53 AM

Jan 9, 2008 / Should We Measure Individual Estimates Accuracy?

4 comments

Individual estimates accuracy is another metric requested by several TargetProcess users. First of all it may be useful if and only if:

  • Task estimated by one developer only (if whole team estimates tasks you can’t measure individual accuracy, only whole team accuracy).
  • You are using time tracking to track all spent time for all tasks

For example, Ted subscribed to Quick Search user story. He broke down this user story to tasks, estimated each task and got 50 hrs of effort for user story. Then he implemented the user story and spent 60 hrs. It means his estimate accuracy for this task is 50 / 60 = 0.83 or 83%. In the end of iteration we can calculate all Ted’s assignments and spent time and define estimate accuracy for next iteration, let’s say it is 0.7.

OK, but how we can use this metric? Well, if Ted subscribed to 60 hrs work it means he will spend 85 hours and for 2 weeks iteration it means at least 5 hrs overtime. Ted should take this information into consideration and remove some tasks from his ToDo. This works if Ted estimate accuracy remains the same, but is that always the case? In reality Ted’s accuracy may vary from 0.5 to 0.9 and exactly for next iteration it may be 0.9 and in this case Ted will be able to do all committed work.

As you see estimate accuracy coefficient should be used as a recommendation only, but if Ted insists on his commitment Project manager/Scrum master should agree and let Ted do the job. Again we have similar problem as with individual velocity when Scrum master may demotivate developers with numbers in hands.

I see value in individual estimates accuracy, but I see some danger as well. This metric should be used by developers, not by Project managers/Scrum masters.

I think we should care about team estimates and team velocity, not about individual estimates and individual velocity. Agile development is all about jelled teams.

Labels: , ,

posted by Michael Dubakov @ 4:36 AM

Jun 25, 2007 / Erroneous and Dangerous Agile Criticism

20 comments

Today 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.

Labels: ,

posted by Michael Dubakov @ 2:27 AM

Jan 31, 2006 / Why MS Project Sucks for Iterative Development? Part II

3 comments

Hammer and Warm Wax

See Part I

.

Let's take an average software project with full plan created up-front. It appeast that it is hard to support project plan in actual state using MS Project. It is hard to reflect real progress. But why? MS Project is great software, it should be easy. And it is easy in many cases, but not in software development. MS Project is useful when:

  1. Project is very small (a month or two). But in this case maybe it is not required. Use Excel, make simple features list with estimates and that is it.
  2. Project is very large and requires high-level plan. You may create very good project plan for Bridge building, Airplane or Space Shuttle construction. PERT is great in this case and project plan reflects phases, not tasks.

But most software projects have specifics:

  • Average project duration is several months
  • They change a lot and require fine-grained plans ("This feature will be implemented by two people. Joe will create GUI screen within 1d and Matt will program controller within 2d").
  • As a result, it is very hard to keep fine-grained plan in actual state for medium and large projects for WHOLE project life-cycle (the keyword is WHOLE of course).

No matter what tool you are trying to use. Most managers and executives improperly think that Waterfall requires such detailed plan somewhere in the beginning. Waterfall is not the best way for software development, but incorrectly understood and implemented it becomes a real pain in the neck.

You may say that MS Project is just a tool and all I wrote above do not directly depend on MS Project, but on methodology and process. I partially agree, but, once again, MS Project was not designed to support anything but Waterfall or its modifications. It is used for Waterfall and not so many people tried to use it for something else. MS Project + Waterfall = Hammer, but software development in most cases is not a nail, it is a warm wax. You can't make anything but a flat from wax using a hammer.

As you see, there are plenty more reasons to find a better way. Let's step back and look at another process.

Iterative Development

If we can't have fine-grained plan for whole medium/large software project, let's split it on chunks and create fine-grained plan for each chunk when it will be necessary. This idea is not new and called Iterative Development. Whole project split on iterations (exact iteration duration depends on many factors, but usually it varies from 1 week to 3 months) and iteration planned just before start.

This may sound astonishing for some executives. "So we don't know project end date??? We don't have a plan??? Our customers will not deal with our company! What the hell you are talking me?" How can anyone answer these questions? There are two ways to go.

On the first road there is no exact project end date and this road called Customer Satisfaction. You respect them, trust them and produce software they want. Feature by feature, iteration by iteration. Exact date of final release is not required since customer knows that you'll implement as many features as possible based on defined priorities. It is real trust and it is quite rare.

On another road there are many signs with a big red "Deadline" in the end. While everyone wants to be on Customer Satisfaction road, most of us are on Deadline road in fact. This is a real world and, while we changing it, we have to drive some projects on this road. Can we apply iterative development? Yes, but with some restrictions, since there is less trust between developer and customer. Customer expects a fancy project plan, so we will create one, but low-grained. MS Project is good for low-grained plans. The plan will contain project phases and major milestones and, of course, it will contain end date. If customer asks why there are no tasks, you answer that you don't like micro-management and fine-grained plan will be developed later. In fact, customer doesn't care about exact plan, it does care about delivery dates and you've already provided them. Then you may break down each release on iterations and follow first road.

Some off topic. The other trick is to leave project/release scope flexible and this is really hard to achieve. It is harder than make a sculpture from warm wax with a hammer. If customer insists that he should get these features till that date without any deviations - you are in trouble. All you may vary in this case are people and process. And often you can't vary people as well. So the process becomes a single life-saver for you and your team. While it is powerful life-saver, it may not help. Once again, do your best to leave scope or date flexible and focus on Business Value whenever it possible. If not, use iterative development anyway and try to release something useful as early as possible. Maybe customer will appreciate your effort, trust you and you slowly turn to Customer Satisfaction road.

"OK, we may use MS Project for low-grained plans. But what should we use for fine-grained plans?"

I can't point Best-of-the-Best solution, but some important things that your tool of choice should do:

  • Fine-grained plan for iteration should be visible and understandable for all developers without any restrictions
  • Person who performs a task should track time spent on the task. PM shouldn't ask everyone how many times he/she spent on this and that.
  • Plan should be easy-to-change (no dependencies, easy re-allocation)
  • Iteration status should be visible for all (and preferably tracked automatically)
  • Iterative planning should be supported by the tool

In short, the tool should be opposite to MS Project, it should be strong in those areas where MS Project becomes frustrating.

Stop! I Can Plan Iterations in MS Project!

Yes, go ahead and try. You'll quickly discover how it is useful for iterative development and how it is designed for iterative development.

I've planed iterations in MS Project for several projects and it somewhat worked, but this method lacks visibility. Developers don't see plan and don't see progress. You should update actual effort manually and assign tasks using Outlook.

How many features in MS Project you will use for Iterative Development? Gantt Chart, Resources and Tasks. That's it. Tasks will be independent, so critical path is useless and Gantt chart is not very helpful. Leveling… OK, sometimes it helps, but in most cases conflicts may be resolved very easily for one iteration. Reports? Useless in most cases, but you may need something for executives. It appears, that MS Project is too complex and don't bring enough value to justify its usage in iterative planning.

On the other hand, there are many features that you'd better have for iterative planning:

  • Product/Release backlog. The main issue. If you use MS Project, you will have to store backlog in Excel or somewhere else and copy/paste features when required.
  • Integrated time tracking. May be resolved programmatically and with help of MS Project Server, but this is an additional effort and MSP Server used not so often.
  • Work remaining tracking. This practice is very useful to know actual iteration state. Can be resolved the same way as previous item.
  • Iteration velocity concept. If you create an iteration in MS Project, Effort will be Iteration Velocity in fact. But you don't have clear velocity progress picture

So you really may plan iterations in MS Project, but it will be not so simple and natural. MS Project just will not help you much.

Labels: , , ,

posted by Michael Dubakov @ 1:41 PM

Subscribe to the RSS feed
Stay tuned by having the latest updates via RSS
Follow TargetProcess on Twitter
Get in touch with our team

TargetProcess is an agile project management tool. It is designed to solve distributed teams problems and support agile development processes.



Key Features

  • Full Agile Project Management Support (Scrum, XP, Custom)
  • Productivity Tools (Tp.Tray, ToDo list, dashboards, Inline editing)
  • Customizable Development Process
  • Subversion Integration
  • Integrated Bug Tracking, Help Desk, Time Tracking

Get TargetProcess for Free (5 users pack)

Previous Posts



    follow me on Twitter
    Blog Information Profile for firefalcon

    Archives