Edge of Chaos | Agile Development Blog

January 13/14 is the Old New Year holiday. Seems like today is the latest appropriate time to look back  and recall the most interesting blog posts by TargetProcess in 2009

Based on visitors count, the posts are ranked as follows (descending order):

1. Lean and Kanban Software Development Digest: In May 2009, this digest came along right on time as Kanban adoption started to grow. We’ve been sifting through the Lean/Kanban buzz and considering if Kanban might be a good tool for our development process, so this post has the most valuable findings we’ve made and shared with agile community.

2. Refactoring vs Rewrite: This post is a real train of thought of a Product Owner trying  to make a decision on how to proceed with product development — rewrite or refactor. Can well be used in textbooks for software product management

3. Mind Maps: Scrum, Extreme Programming, Lean: Another by-product of our research on agile development processes. The specific value of mind maps is that they help grasp complex things with visual representations.

4. Tale: Deadline and Technical Debt: Once upon a time…  Who could ever expect that the fundamental principles of product management can be outlined in a fairy tale ? There we go:  smart Arthur, the cunning king, quest for princess — the metaphorical expression of the danger of technical debt in software development.

5. 5 Wrong Reasons to Apply Kanban. For some reason (no pun intended), 5 wrong reasons ranked higher than 5 right reasons. Maybe it’s just human psychology — to go from “what’s wrong”  instead of  ”what’s right” …

6. How We Use Kanban Board. The Real Example:  Once we figured that Kanban process is just the right thing for us and put it in action, we shared this  experience with our blog readers.

7. 5 Right Reasons to Apply Kanban: There they are

8. Zero Defects? Are You Kidding Me? : Can this juicy frog be sure that it swallowed the very last bug? This post is a warning against the so-called “zero defects mentality” in software product management.

9. Simple Rules, Complex Systems and Software Development: Complex systems function at their best when guided by simple rules. Look at ants, birds, space rockets and … software development.

10. BDD and User Story Specification: Examples — This post includes some real user story specs in BDD for TargetProcess product. Enjoy and use.

These are the TOP 10 posts  in 2009 from TargetProcess agile blog (click here for more)

Happy OLD NEW YEAR!

Kanban is becoming a popular agile tool. Indeed it is very good for software projects of certain types. However, there is a danger of false reasons behind Kanban adoption.

#1. User Stories Diversity

“Our stories vary in size a lot from 1 point to 40 points. Large stories just do not fit into an iteration”

It is very easy to say you can’t split user stories, thus iterations should be abandoned. An easy solution is not the best one. There is something important behind the fact you can’t split stories. Most likely you don’t know how to split stories right. It is quite hard from the beginning and demands creativity.

Moreover, according to Queueing Theory, it is better to have small stories with roughly equal size. Small batches with equal size improve flow (and you have a better and more predictive cycle time). So in Kanban you still have to split stories to smaller stories and try to make them equal size.

#2. Failed Iterations

“We can’t complete most stories in a single iteration”

There may be many, many reasons behind. Mini-waterfall approach, velocity greed, large stories, manual testing, poor stories description, etc. You may even have a wrong iteration length. For example, in large projects 1 week iteration may be an overhead with a huge transaction cost. So 1 month iteration may be much better in this case.

You need to analyze true reasons, the roots of the problem.

#3. Failed Retrospective Meetings

“Retrospective meetings are waste, they do not help in process improvement and we want to remove them”

You just don’t do these meetings right. One popular failure is no Action Items after the meeting. Without action items a Retrospective Meeting is just a kind of informal chat that you may have over a glass of beer. You meet, chat about your problems, and get back on the same track next day. Rule #1 is to collect and write the list of Action Items that you will try to accomplish during the next Sprint [or any other time box].

One more  common pitfall is to skip action items execution. You may collect them, but not really try. You may even try them, but abandon too quickly. Almost all new rules or practices put you off the comfort zone. It takes time to learn them, use them and like them (or dislike), but it should be an expert opinion, not just a gut feeling.

If you expect that you will replace failed retrospective meetings with a nice and simple “stop the line” rule, you’ll fail, since it is even harder than scheduled regular retrospectives and demands even higher level of self-discipline.

#4. Shared People / Functional Departments

“We have a single pool of developers and share them between projects. We can’t form stable project teams”

Do you really think that Kanban will solve your social and organizational problems? C’mon! It helps to visualize flow and find bottlenecks, but if you don’t have a cross-functional team — you have hard times. It is proven in so many sources and researches that cross-functional teams perform better, produce better results and better software.

If you are experiencing difficulties planning sprints with shared pool of developers, try to fix the root of the problem first - switch to cross-functional teams and eliminate multi-tasking.

#5. Simplicity

“Kanban is so simple! No plans, no estimations, no iterations, no overhead”

Indeed Kanban looks simple. But it provides nothing interesting by itself. To ensure a successful Kanban adoption, you need to apply Lean principles first. This new buzzword may sound like a silver bullet, but obviously it  is not. Hard work, discipline, target on perfection and constant improvements - all that is required to apply any agile methodology.

Don’t get me wrong. I am not saying that Kanban is bad. We use it within TargetProcess and I personally believe it works way better than iterative development (for us).  I just want to make a point that you’d hardly resolve all your underlying problems as you switch to Kanban.

P.S. I usually don’t read posts like “10 reasons to …” Can’t believe I wrote such post myself!
P.P.S. Read next post 5 right reasons to apply Kanban.

• What is Cadence? Great post explaining cadence using nice pictures. “The purpose of a cadence is to establish a reliable and dependable capability which demonstrates a predictable capacity. Cadence gives some confidence in the upcoming work when we are triggering rather than scheduling work.”
• Series of amazing Danilo Sato posts about Velocity anti-patterns: Done is not done, Making up points, Used as a performance measure.
• Alan Shalloway has interesting and thought provoking post “Is Part of the Agile Community Acting Like the Waterfall Community of Old?” “The pattern is unfortunate - it seems that there are those who don’t like discussing some thing have taken one of two approaches. If they can intimidate people who are using Scrum Alliance certifications for their livelihood, they do so. If they can’t, they attack the integrity of those people they don’t like (e.g., David and myself and others I haven’t mentioned). “

• The roots of agile project management is a nice article. It summarizes trends that evolved into agile software development paradigm.”If users can’t foretell what they’ll want until they see it, if predicting and planning substantial IT projects is not possible, and if protecting projects against changes that arise during the development process is impractical, the ideas behind existing “waterfall” methods are clearly flawed, and an incremental, prototype-based methodology could offer substantial benefits.”
• Defining Kanban on my opinion is the best article that describe what Kanban really is. On author opinion, Kanban has just two properties: have a pull system, provides rapid and highly visible feedback. I support this vision.
• Extreme Programming Mind Map. Nice overview of Extreme Programming with a good mind map.

The concept of deadline has always been one of the sacred cows for any human activity.  Normally, with very few exceptions, what do people do with any project? They set a deadline and think that they will care about meeting this deadline somehow. You can see lots of examples for that in construction industry. Remember, China and the 2008 Olympics. They had a deadline for building Bird’s Nest arena in quite a short period of time. In this case, it was really necessary to meet the deadline since the Olympics was to start on August 8, 2008.

How about software development projects? Product development? With agile methodology?

I think there are 2 options here: agile team does have external pressure for deadline, and the team is free to choose when to release. The main criteria for release is quality as observed in this tweet.

When reading blog posts and articles on lean and kanban (this one for example), I noticed that people are very wary of calling things their names and avoid saying it out loud - DEADLINES ARE CRAP. What matters is the work flow, the quality, the limits of WIP and the Definition of Done. So, if a team has no external pressure, the recommendation is to avoid extra stress by imposing unnecessary deadlines.

There’s no rush for perfection, as they say. But how about external pressure? How about clients who bluntly say — I want this job done yesterday? Frankly, as I worked in outsourcing, I always felt an urge to say to such clients — if you want to have this done yesterday, you should have moved your a** yesterday and select a vendor who you trust yesterday. With custom on-demand projects, clients often fail to understand that meeting a deadline and completing a project on time is the responsibility of both customer and vendor, with customer even more responsible.

So, if you’re with an agile software shop and you have such clients, there are 3 options:

1. educate your clients on deadline concept as above and say bye to them
2. bend over backwards, have stress, and deliver something-not-sure-what on a client’s “yesterday” deadline
3. patiently explain the client that only a part of what they want can be done by their deadline and prioritize work.

The sad thing is that the majority of clients will go elsewhere hoping to “get the job done yesterday”. But if you really are competent, do good work, your reputation will start building up and at the end of it all you’ll get a bunch of devout customers - especially if you work in a local community.

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

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

Yes, it is.

[youtube=http://www.youtube.com/watch?v=1lqxORnQARw&hl=en&fs=1]

We’ve released TargetProcess v.2.11 with Navigation flow, Selenium and NUnit integration, Getting started area and sample project generation.

Solving problems! Most of us would agree that is the ultimate goal of any software. It is especially difficult to create a tool that resolves several large problems. For example, effective project management is a huge problem that may be split into several smaller ones such as: easy planning, effective tracking, quality assurance, etc. What makes it extremely difficult is companies’ diversity. There are a lot of businesses with unmatched variety of processes, goals, people, cultures, tools and environments.

OK, we at TargetProcess have a niche, by supporting companies on “agile” road. However, we still face too many differentiators that need to be satisfied.

Some people want Gantt charts and Start/End dates for their tasks. To such requests we have been consistently saying “No”. Others want better high level planning, improved time tracking, easier UI, – the list is endless. We can’t say “No” to all of them, since many of such requests are quite reasonable and most importantly - solve real-life problems. However, we can not add requests blindly into the Product. If we did, we would create a “bloatware scary monster” and people would start running from it.

What is the solution? The solution is to provide frameworks for solving problems. Sounds weird, but here are some examples to support this point.

Example 1.

Requests: “We badly need a report that includes all features, stories and bugs for current release”, “I want to have a quality report that shows count of passed/failed/not run test cases for each user story in current iteration”, etc.

You get the idea - people want and endless array of reports. One solution is to start implementing these reports as they coming — one by one. We feel the better yet solution is to simply allow people to build such reports without our help. Powerful reports engine resolves these types of concerns in a single hit. Moreover, people are creative and once familiar with the approach - will start to produce very useful reports that address all of their needs. The key is to make them feel in command and provide necessary tools!

Example 2.

Requests: “We want to group features by module! How come you don’t have modules in a project?”, “We have several teams in a project and want to plan and track them separately”, “Your software really sucks! I can’t even find all the bugs and user stories related to Safari easily!”, “I played a little more with your software and I can’t use it without relations between entities.”

Did you get the problem? It is not an easy guess. They all look like different problems. Straightforward solution may include:

• Module entity in a project.
• Multiple teams concept implementation, including changes in relations, reports, etc. (will complicate product a lot).
• Custom fields for several entities at once.
• Dependencies between entities.

Wow, it will take time to implement all of the above features. Scary part is that these requests are just a tip of an iceberg. After implementation we will more likely receive even more “related” requests. Is there any magic bullet that hits all the targets in one shot?

Yes, there is! OK, all the requests are about categorization and relations. Categorize by module, categorize by team, categorize by browser, see all related entities that have the same value in a defined category. And the real solution is to provide an easy and flexible categorization. The answer is… tags and bundles! Let’s see how all the problems above may be resolved with tags.

Common solutions for different problems. Tags and Bundles is a framework that will resolve almost all categorization problems. And be sure that people will find creative ways to solve other problems as well. If it is possible to plan with tags, I can’t even imagine what tags will be used for (in a good way).

We at TargetProcess are trying to provide frameworks rather than straight-solution-to-one-problem. The latter approach works exclusively for the stand alone problems that cannot be grouped with similar issues.

Generalization mindset is a must in Product development, but beware premature generalization.

It looks like a magic, but soon it will be possible to manage projects using TargetProcess on a very cool Microsoft Surface table. Releases and iterations planning using drag and drop with usual human hands and fingers (throw your mouse and seal up your touchpad), nice sorting and grouping, fantastic user interface and experience!

“Microsoft Surface brings real tactile feeling into software world. You may operate with entities using hands on a table, almost like with usual cards. You may take a bunch of user stories and throw them to release. You may drag the slider to move release date. You may give a flick on user story to delete it! It really sounds like a miracle. I think such experience is a huge step forward for whole software engineering industry.”, commented Michael Dubakov, founder of TargetProcess, Inc.

We are creating new appealing user interface with really handy functionality and unsurpassed usability. Stay tuned and find additional details here!