May 31, 2009 / Lean and Kanban Software Development Digest

4 comments

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

• Kanban for Software Engineering . Detailed presentation about Lean and Kanban. Focuses on many problems and solutions in a software development process.
• Kanban: A Process Tool . Another good presentation that emphasizes the simplest rule in kanban: Limit the number of things in work to a fixed number. Maybe a good start indeed.
• Practical Experiences and Tools Applied to a Kanban Sustaining Engineering System . Fantastic presentation about Lean/Kanban implementation with real examples by Alisson Vale.
• Kanban vs. Scrum. Rich and lengthy presentation that compares Scrum and Kanban. A very good visualization (which is a key in Kanban :). Shows why Kanban fits better for multiple development teams working on the same project. I tend to share this opinion as well.
• A Kanban System for Sustaining Engineering on Software Systems . Very interesting presentation of Lean implementation at Corbis. As I know, it is one of the first successful attempts to run Kanban in a software shop. Must read.

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: agile, digest, kanban, lean, links digest

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.

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: agile, performance, ui, usability

posted by Michael Dubakov @ 4:32 AM

May 22, 2009 / Friday's Digest #13 [Kanban, ASP.NET MVC, Ajax]

0 comments

• Goals for using Kanban David Anderson put a nice list of Kanban usage goals. "Goal 1. Improved performance through process improvements introduced with minimal resistance"
• How we do MVC and Our “Opinions” on the ASP.NET MVC . Very good posts about ASP.NET MVC challenges, tricks and solutions. Must read if you are starting serious project based on ASP.NET MVC.
• Tim Sporcic blog. I like this blog a lot. Tim has a talent to express his thoughts and most posts are very interesting and helpful. If you are using ExtJs, ajax and mvc pattern — just add the feed to your feed reader.
• jQuery vs. MooTools. Extensive comparison of two popular JavaScript frameworks. If you evaluating choices, don't miss this reading.

Labels: ajax, asp.net, digest, kanban, mvc

posted by Michael Dubakov @ 1:32 AM

May 9, 2009 / Friday's Digest #12 [Design, Business, Kanban]

0 comments

• In Defense of Eye Candy. Nice article. It discusses why aesthetics is important in a design: "when we talk about how emotions influence interactions, it’s closer to the truth to say things that are enjoyable will be easy to use and efficient." And another fantastic quote "how we 'think' cannot be separated from how we 'feel'".
• Discovery-driven Growth: The Only Plan Is to Learn as You Go. Quite lengthy, but interesting interview about business development in a current economy. Discovery-driven growth is a way to go.
• Kanban and Time-boxes. Does Kanban compatible with iterations and time-boxes?
• Wanted/Needed: UX Design for Collaboration 2.0. Designing collaboration software has some specifics. Can we create a framework that help with it?

Labels: design, digest, kanban

posted by Michael Dubakov @ 11:34 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 Name	Depends On
As a user I want to Logout	As a user I want to login
As an admin I want to delete users	As an admin I want to view users list
As a user I want to purchase things	As 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:

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: agile, gantt chart

posted by Olga Kouzina @ 4:04 AM

May 1, 2009 / Friday's Digest #11 [Kanban, GTD, Economy]

0 comments

• Why Small Companies Will Win in This Economy. "Small is the new big. Sustainable is the new growth. Trust is the new competitive advantage."
• So, Now You're an Agilist... What's Next? Interesting presentation from Jurgen Appelo with attempt to bring complexity science into agile software development. And interesting debates thread between Jurgen, me and Glen Alleman.
• Feature Crews: kanban systems for software engineering in the large. We are using branch-by-story at TargetProcess and something similar to feature crew. I think the idea is very good.
• Getting Things Done Mind Map Diagram. GTD is quite interesting technique, I am trying it right now (and liking it so far). This mind map is really good quick intro to GTD.
• Things — task management software. Great GTD software for Mac users. Very clear concept with perfect implementation.

Labels: digest, economy, gtd, kanban

posted by Michael Dubakov @ 3:28 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: agile, process

posted by Michael Dubakov @ 3:08 AM

Apr 1, 2009 / TargetProcess Announced v.2.14 Release With Full Waterfall Support

0 comments

I am really glad that finally we released v.2.14. Check the press release: TargetProcess Announced v.2.14 Release With Full Waterfall Support.

Labels: agile tool, waterfall

posted by Michael Dubakov @ 4:30 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?

• Part 1. Agile Software Development and Complex Adaptive Systems: Intro
• Part 2. Software Development is Complex Adaptive System. No Doubt
• Part 3. Edge of Chaos and Hyper Productive Software Development Teams
• Part 4. Simple Rules, Complex Systems and Software Development

Labels: agile, complex adaptive systems, scrum

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: agile, bug management

posted by Michael Dubakov @ 12:10 PM

Mar 13, 2009 / Friday's Digest #10 [Scrumban, Pair Programming]

0 comments

• Why Can't Error Messages Be Fun? Indeed, Chrome does it right.
• Scheduling in Scrumban. "We eliminate iteration planning and instead implement a system of continuous rolling-wave planning." I think rolling-wave planning provides great benefits to Product Owner. Backlog becomes more flexible and adaptable.
• Successfully Adopting Pair Programming. Nice article, describing real pitfalls of pair programming adoption. Beware "Spellchecking Pair" :)
• Sell Your By-products. What by-product you have to sell?

Labels: digest, links digest

posted by Michael Dubakov @ 7:39 AM

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: agile, bug management, process, qa

posted by Michael Dubakov @ 3:29 PM

Feb 24, 2009 / Friday's Digest #9 [Pair Programming, Design, CI]

0 comments

• I Love Pair-Programming. Fantastic real-life experience of pair programming. It is hard to advertise it more.
• 21 ways to hate pair programming. Nice list of mistakes people often make when doing pair programming.
• Fantastic sign up form. Creative way to provide sign up form. Not sure about usability (on my opinion not much difference from usual form), but it is eye-catching and "tangible".
• Continuous Deployment is about deploying code changes to production as rapidly as possible. "Every commit should be instantly deployed to production". Is it possible? IMVU proved it is. Nice goal we should strive for. Extreme case of Continuous Integration is Continuous Deployment.

Labels: digest

posted by Michael Dubakov @ 6:28 AM

Feb 17, 2009 / Organizing Support in Agile Product Development Company

1 comments

In 2007 we released TargetProcess v.2.5 with Help Desk on board. It was a quite powerful help desk with email integration and Help Desk Portal application. It opened new ways to provide support. We merged all support sources into one place: Help Desk. Customers send emails and they are converted to requests, sometimes customers post requests directly via Help Desk Portal. Also we have a support forum, but currently it is disconnected from Help Desk and should be monitored separately. So we had almost all the requests in one place, it looked like a good start.

Unfortunately it did not work as expected. We missed requests, we missed some communication threads and overall support quality was unstable. There were several reasons for that:

• When someone adds a comment to request, we did not receive notification. If a comment was added on Friday's evening there was a good chance to miss it.
• Sometimes we closed request thinking that the problem was resolved, but it was not. Customer would get back with comments and receive no feedback.
• There was no single person in charge of all incoming requests.
• Bugs created from requests live in backlog for quite long (several bugs have been living in the backlog for about 2 years, well, they have Small and Normal severity, but still too long).

Over the last two months we focused on support process improvement. We discovered the roots of our support problems and formalized the support process in just several simple rules.

1. Single Queue Manager. Queue Manager is responsible for all the incoming Issues and Questions. She handles requests Queue. It is a very important job and a good queue handling is a key to the great support.
• There should be no requests with reaction > 24 hrs.
• All simple requests are to be processed first (if the request can be answered right away we just answer it to shorten reaction time).
• Complex issues get prioritized and sended to QA team (QA team decides who will reproduce the issue):
• QA is responsible for the issue and communicates with customer directly.
• A bug is created from the issue and then assigned to Support Release. Support Developer takes bugs from this release and works on them.
• Product Owner is responsible for bugs prioritization in the Support Release.
• Scrum Master is responsible for new builds releases with bug fixes.
• Follow-up. If there's no reaction from customer during 2 days, we should send a follow-up.
• Clearance. Each week all issues and ideas with last comment from our side and no reaction from customer during 7 days are closed by Queue Manager (customer does not want to help and we're unable to reproduce it, so the request is closed).
2. Support Developer. One developer is allocated to support full-time each day (developers rotate during the week).
1. He provides technical help to Queue Manager and resolves complex issues.
2. He fixes bugs created from requests.
3. All ideas are handled by Product Owner.

This process has been working over the last month and I should say it works fine. Reaction times improved significantly and no requests are missed. Maybe this simple process will help other product development companies. In fact there is quite a few articles and discussions around support organization. Hope this one will be helpful and you will make less mistakes than we did.

One thing to add. Requests Queue Manager is a highly responsible job. This position demand extraordinary responsibility and the person should REALLY CARE about customers. That is the key.

Labels: help desk, support

posted by Michael Dubakov @ 6:57 AM

Feb 6, 2009 / Friday's Digest #8 [Scrum, Lean, Economy]

0 comments

• Martin Fowler emphasizes that technical practices are very important in Scrum process and team can’t succeed without them. The same thing is true for Lean.
• If you don’t know how pull systems work, here is a good article that describes that in details. Moreover, it shows how to create various pull systems from a single workflow by applying various limits.
• "Do You Austrians Have a Better Idea?" Creative recommendations for President Obama. Recommendation #5 - "Eliminate the DEA and the SEC. Since the SEC failed to catch Madoff, despite nine years of warnings, I think its $950 million annual budget is obviously a waste of money."

Labels: digest

posted by Michael Dubakov @ 10:26 AM

Feb 4, 2009 / Support in Agile Product Development Company: Email Client

2 comments

We are working hard to improve our support. Sometimes it is very good, sometimes not. We are receiving about 20-40 requests each day via emails and Help Desk Portal, also we have several chats and phone calls. I want to share our experience and problems we are facing with, maybe it will help other companies to provide good support faster.

Manage Support using Email Client

Initially, as may other companies, we just use email client to handle incoming issues and requests. It worked fine for 2 years. There was a single inbox for all support requests and there was a single person who handled it. You may flag important requests and track them. For example, if important issue submitted, you may ask for additional info, submit a bug into TargetProcess and notify customer about new build when the bug is fixed. Usual questions are even simpler, you just answer them and forget till customer asks for more info.

However, support management via email client has several important problems and constraints.

1. It is really hard to track many requests with it. The good thing is that you have requests queue and may handle new requests nicely, but what about old requests that are not resolved so far? For example, bug created from request and it is still not fixed due to various reasons. Also we may ask for some additional information, but customer did not replied. It is likely that we want to re-ask again, but it is quite easy to forget that.

2. The other problem is when you have several people working on requests. It is not clear what request already answered and what request still waiting for the answer. 37signals uses gmail client for that and it seems it works fine for them. However it is not true for usual email clients like outlook.

3. Third, if you have several channels (live chat, phone, email) it is hard to manage them. For example, you have discussed the problem in the live chat and now want to create a bug. You add a bug, but forget to notify customer about new build when it is ready, since there is no such email in support inbox at all.

As you see, email client does not scale. It can be used if you have low volume of requests, but at some point you need something more efficient.

Labels: support

posted by Michael Dubakov @ 4:56 AM

Jan 17, 2009 / Friday's Digest #7 [UI, Design]

0 comments

• Distinguishing decorative from meaningful elements in UI design. Ryan from 37signals shows how small decorative elements may influence usability.
• 10 Useful Techniques To Improve Your User Interface Designs. I am not a big fan of articles like "99 advices to web design", however this article is really useful. I especially like number 3 "Using contrast to manage focus", number 8 "Custom input focus" and 9 "Hover controls". We are going to use hover controls in v.3.0 design.
• Konigi.com is a great resource for UI developers. Many very useful links and examples.
• 2008 - The Year In Pictures. Nice photos. Nice atmosphere. Taste the last year as a good wine...

Labels: design, digest, ui, usability

posted by Michael Dubakov @ 8:16 AM

Jan 9, 2009 / Observation: Add/Edit Forms and View Pages in Web Applications

4 comments

99% of web applications have add forms. Most of them have edit forms as well. It is really hard to imagine how you can add/store something without a form. OK, there are some ways like: import something from CSV file or another format, create something from incoming email/SMS/etc., capture image and create something from this image

Still if you need to add something quickly, in most cases you will use a web form. Obviously, if you need to edit something you will use web form as well. Is it the best solution? Can we get rid of edit forms? I bet we can.

Most applications has View page. It represents information in a more readable and usable format than a form. And to change one property you:

• Click Edit link and wait for new page to load.
• Change the property.
• Find and click Save button.
• Wait for previous View page to load.

That's quite time consuming process. I think the better way will be:

• Double click property you want to change.
• Type new value.
• Push Enter to save the new value using AJAX.

This way has several advantages. First, you don't need to create edit forms (ok, but you need to implement inline edit). Second, you provide much better user experience. Third, you get rid of Edit links everywhere, which is good (less complexity and less links is always good). That is something we are going to try in TargetProcess v.3.0.

Labels: design, usability

posted by Michael Dubakov @ 11:00 AM

Dec 30, 2008 / Friday's Digest #6 [Scrum, Crisis, Web 2.0]

0 comments

• Is there an alternative to Scrum of Scrums? Will Read proposes Mesh network as a Scrum of Scrums replacement. Looks interesting as an information exchange flows in an organization.
• After The Crisis: A Parody of 15 Corporate Logos. Apple logo is very funny :)
• Jeff Atwood thinks that web application should not follow desktop application design. "A web app that apes the conventions of a desktop application is attempting to cross the uncanny valley of user interface design. This is a bad idea for all the same reasons; the tiny flaws and imperfections of the simulation will be grossly magnified for users."
• Herb Sutter found two fallacies in Jeff's post and think that this is a natural evolution. "Today, everyone writing rich Web 2.0 applications is doing their own thing, borrowing as best they can from Macs and Windows and others — but the results are all over the map, and will continue to be until there actually is such a thing as a UI standard for rich-GUI web applications."

I tend to agree with Herb. I don't feel bad when using web based app that looks familiar. And I definitely agree that in the future we will have several common frameworks for rich UI applications development with quite similar paradigms and interface concepts.

Labels: digest, fun, scrum

posted by Michael Dubakov @ 2:15 AM

Dec 22, 2008 / Observation: Lists in Web Applications

6 comments

I'm working on new lists in v.3.0 already and wondering how 37signals managed to create several web applications with no traditional lists. OK, there is one list that shows time records in Basecamp, but as far as I know there are no other such lists. All the other lists are very simple and well formatted. All 37signal's applications look simple, with fresh air and the first expression is very good.

Typical list in Basecamp:

The only traditional list I found in Basecamp:

Now I wonder why that happened. Maybe data volume in Basecamp is low? Maybe they are just super-smart folks (well, no doubt here)? Also I wonder whether it is possible to get rid of traditional lists in TargetProcess. Is it possible at all when people want to prioritize 300 user stories in the backlog (yes, we have such requests from customers!). Is it possible to get rid of usual lists when you receive dozens of support requests daily?

Labels: design, lists, usability, v3

posted by Michael Dubakov @ 6:09 AM