Why it is bad to have a single point of failure in a product and what to do about it.

Every day we solve problems. Some people solve many problems, some few. Most likely in your project there is a person, who solves most of the problems. Sometimes it’s a Business Analyst, sometimes it’s a Designer, most often it’s a Product Owner. He knows the market, the domain, the customers, the competitors, the features. He knows how things should work and pushes his solutions hard. Usually the team can’t resist and just accepts this situation. Is it good? Can we find better ways? Well, we’ll have to have quite a lengthy journey to find out.

Setting the Stage

Imagine, you have a new feature in the backlog. At this point we have several potential scenarios with a different level of harm:

1. Leave everything up to the developer.
2. Discuss this user story just before the implementation, come up with a solution and do no specs. Make all the decisions on the fly.
3. Discuss this user story just before the implementation, come up with a solution and do the specs.
4. Assign user story to a Product Owner, let him come up with a solution and have him do the specs.
5. Have UX phase, brainstorm a solution and create the specs just on time, before the development starts.

You can see that some of the scenarios are good, some are bad, and a few of them are just horrible.

To create a perfect solution, we should answer the three simple questions: When? Who? How? Well, the most important question is Why? We’ll assume it’s already been answered.

When?

Each story has its own life-cycle. It is born, it lives and then dies. There are three important moments in the life of a feature:

1. Someone has a good idea, and a feature is created in the  backlog.
2. Development starts.
3. User story is released to production.

When is it a good time to have the complete solution? Obviously, not right after the story is created, as things change, and it may happen that this user story is no longer required. It may just be deleted from the backlog in the future. Somewhere in the middle when we have more data? Maybe, but still not perfect. The perfect match is when we have the solution right before the development is about to start.

In this case the solution is fresh and shiny. Everyone in charge does remember why things should work exactly the way described in the specs. It is certain that the user story will actually be implemented, so the solution and the time spent on it will not be thrown away.

If a feature looks very simple, the UX phase can start about one week before the implementation. If a feature is complex, several months may be a good timeframe.

Who?

Many teams rely on the Product Owner, Business Analyst, etc. and expect solutions and specs from them. A team doesn’t care about the solution, but does care about completeness of the specification. Sometimes this works, in most cases — not.

Some teams rely on communication and do not create specs at all. They brainstorm a solution on the fly and then jump to coding. Sometimes this works, in most cases… well, you got it.

Some clever teams rely on the group of people that consists of developers, testers, designers and product owners who brainstorm the solution, find the best one, iterate and delegate writing specs to the product owner. And these teams rock.

Why the first two cases are bad?

The Hero

Yes, Product Owner is responsible for the product. Yes, he knows a lot. Yes, he can solve problems. And, yes, you expect too much of him. It is quite unusual to expect the best solution from a single person. It is always better to have a small group of people with various skills, various background, various focuses to find a great solution.

Product Owner can brainstorm everything alone and write all the specifications. He can haul the product alone. As a result, he would be a single point of failure… while there are many other buses in the streets.

The communication would be one-way, without much collaboration, and in such environment Product Owner would tend to ignore the opinions of other team members, since they do not participate in problem solving. If you don’t participate, why the freaking hell should I care about your opinion?

Knowledge sharing would be zero. Product Owner is a domain expert, he knows a lot. But the team gets zilch from his experience. There are no discussions, no collaboration, no two-way communication flows.

I used to be such a person. It was not good for the company.

Product Owner’s Rule #1: Don’t do everything alone

The Rush

Got a real problem? Get together, brainstorm it quickly, get shit done and kick it out of the door. Sounds good? Hell, no. The good thing is that you don’t waste time and rush straight ahead. The bad thing is that the solution would be great rarely, good sometimes, and in most cases just average.

In the rush mode you tend to cut corners, take the first acceptable solution and go for it. There are situations when it is good. In any emergency case this is a viable strategy, but in the long run it will not work. Rush mode is very dangerous. You may be even proud of it and call it “agile”, but it is not.

— OK, the quick add feature. Who’s got any ideas?
— Well, let’s just put up the Add Task link . You click it and see the input field with the Name label and Save button. You add one task and see the input field again, so you can add many tasks quickly.
— Great! Let’s do that right away.

Maybe this is somewhat stretched, but in reality I saw very similar situations (and did very similar things myself!).

Product Owner’s Rule #2: No rush

The Team

I bet you expect a viable solution now. Here is the algorithm:

1. Brainstorm every feature in a small group of 4-7 people. Invite developers, invite testers, invite designers, invite product specialists. Invite everyone who has diverse skills and can contribute to a discussion.
2. Think. Talk. Draw sketches. Learn some techniques like Design Studio. Do use them. Draw sketches.
3. Build trust. Support honesty. Ban sarcasm. People should trust one another, or you will have a bunch of gamblers instead of a team. Don’t be afraid to criticize bad ideas. The people who can’t stand some reasonable criticism should leave.
4. Repeat. Several times for each feature. Mix people. Invite new people.
5. Eventually, several teams will emerge, the teams that can solve problems without you.
6. Find people that can lead features and be responsible for the solutions. Let them lead UX sessions and play the Feature Owner role.
7. Create beautiful specifications (this is where I really suck).

It took me 7 years to come up with this solution. It works.

Product Owner’s Rule #3: Spread the knowledge, use diversity, delegate

How?

The “how” question is very broad. How to form teams? How to find solutions? How to evaluate them? How to document solutions? I’m going to just scratch the surface here.

Creative processes are hard to structure and hard to estimate. In general you don’t know when you’ll have a great solution. It may take several days or several years.

Each Feature Team has its own UX phase. Some people like to think alone, have decent preparations and then share ideas. Some people like to brainstorm things ad-hoc. Some like to sketch a lot. Some like to create paper prototypes. In general, it does not matter which practices and tools people use. The must have rules are:

1. Diversity. Team should consist of diverse people.
2. Iterations. First solution is not always the best. Neither second, nor third.
3. Feedback. Team should share potential solutions with other people and with customers if possible (and listen to their feedback).

There are many practices and tools you can try. I’ll just list some of them here:

• Design Studio. In a nutshell, you have a group of people. These people can split into teams or work alone. They have limited time to sketch the solution and then present the solution to everyone. Solutions are criticized. Then you iterate based on the feedback and sketch again. We’ve been using this approach with good results. Yes, it is time consuming. However, time is not important when you want to spread the knowledge. So use Design Studio in the early stages of people involvement into the solution phase.
• Sketches. The ultimate tool to brainstorm, explain, evaluate and present ideas. The main advice I can give is: hide your “OMG I can’t draw!” fear and sketch a lot. You will get better eventually. Sketch + speech is so powerful, so fast, so cool. You can iterate really quickly, try a dozen approaches and skip bad solutions.
• Critique. Do it. Express your opinion openly and politely. Don’t hesitate to upset someone. You solve problems here. Bad solutions should be thrown away. If you’re afraid to say something critical about your boss’ solution — it’s a bad sign. Fuck the common brainstorming rule about ideas and critique separation. This is only needed if you don’t trust each other. Trust gives you freedom of speech. Use it appropriately.
• Diversity. It really works. There are many proofs and observations on how diverse teams outperform experts and solid “think-alike” teams. Try it.
• Paper prototypes. Not as fast as sketches, but still good. With paper prototypes you can evaluate flows and find bottlenecks. It’s easy to grab them and ask some teammates to try something. You can even shoot a video and share it with people.
• Dynamic Prototypes. HTML+Javascript works best for such prototypes in most cases IMHO. However, there are many other tools that do provide decent solutions. We’ve had a somewhat mixed experience with live prototypes. In some cases they did work, and we got valuable feedback; in most cases we spent too much time on them and feedback was not so useful. Prototypes work great to prove some limited ideas about a solution, but they don’t work as full-blown usability tests.
• Usability Tests. We do them on a real application now. About 10 tests give a ton of feedback.

Product Owner’s Rule #4: Learn and try new things

The output of the UX phase is quite simple: feature specification. How to create beautiful specifications? We’ll talk about that in the next article with an intriguing title “Visual Specifications”.

What is Scrum?

Scrum is a software development methodology that helps teams build better software faster.

Why is Scrum popular?

In fact there are several reasons. Let me list all of them:

• Scrum looks very simple. Indeed, the methodology is very lightweight with just 3 roles, some basic reports and rules. So you may have a feeling that you know how to apply Scrum after reading a single book. This feeling is definitely false, but still it looks simple and people like simplicity.
• Scrum works. Yes, it does. In many cases it works better than the traditional processes.
• Scrum is commercial. There are many trainers around, there is Scrum Alliance that runs many courses and does everything to make Scrum popular. The first agile methodology most people know is Scrum. Technically, Scrum is very similar to Extreme Programming, but historically it happens that XP is not so popular, while Scrum is.

How long has Scrum been gaining popularity?

10 years ago some people heard about XP, but only a few heard about Scrum. So I think it started spreading over the world about 6-7 years ago. Now it is the most popular agile process.

What are some of the drawbacks of the conventional software development processes?

There are many. To me the worst thing in waterfall is extremely slow feedback. Fast feedback is vital for project success, but with waterfall you have very long feedback cycles (sometimes years). With such long cycles everything may change. Business may change, requirements may change, etc. It is hard to cancel such a project, since it is often “90% done”. Business has close to zero visibility about the real progress.

It is extremely hard to provide meaningful estimates. So most projects are seriously late and over budget.

How can a company benefit from doing Scrum?

Scrum gives:

• Fast feedback. With short iterations you can show working software much earlier and receive a valuable feedback.
• Transparency. Again, short iterations provide good transparency.
• Good financial control. Business can cancel or stop a project after any sprint (in theory, in practice it is not that easy).
• Better quality. Most practices in agile processes help development teams to fix the root problems and create a better software.
• Faster time to market. Agile teams often have better morale and motivation to create something great. It definitely affects how they work and how they ship.

Before a company chooses to even do Scrum, what questions should they ask themselves?

Scrum fails if there is no support from C-level people. Business should understand really well what Scrum is all about. Good questions to ask are “Who will play the Product Owner role? Do we have such people?” “Can we really delegate all the technical decisions to the team?” “Are we ready to trust developers?”

Scrum adoption requires a shift in mindset. And this is not a simple switch. It may take years to change company culture. Scrum does not work in complicated structures filled with political games and stupid rules.

Do companies really need a tool to help them do Scrum?

Not always. If you have a co-located team, I recommend to start with the simplest tools like whiteboard, sticky notes, etc. In this case you can focus on the process itself. Simplest tools encourage communication and creativity. So if you can live without an agile tool, do that.

However, remote teams and large teams can’t rely on whiteboards. They need something unified to store all the data, plan sprints and track progress. In such cases, a  web- based tool is a must.

When a company is in the process of selecting a Scrum tool to help them meet their needs, what kinds of things should they look for in a tool?

The tool should be adoptable. Too often agile tools are very restrictive (you should have just this project structure, with such and such entities, etc). A good agile tool should adapt to various projects and needs. It should not force you to change development process.

It should be easy to use. People don’t like to spend their time on tools, they want to spend time doing the real work.

It should be integrated to replace any current tools for bug tracking, time tracking, etc. It is better to have one good tool than several good tools in this case.

Will Scrum be gaining popularity in the months/years to come?

I think Scrum will continue to spread. Quite many companies stick to the old software development methodologies. This is changing and changing quickly. Agile processes are on the rise and Scrum is not an exception. I believe in the next 10 years we will witness the total agile adoption.

Many interesting posts and discussions about Scrum and Kanban published last weeks. Someone even called this a war :) I don’t think it is a war, but some posts indeed may drive such feeling.

• Ken Schwaber bashed Kanban. “I was told that Kanban is frequently used when an organization cannot readily adopt Scrum. Many of Scrum most difficult aspects are then sidestepped. Managers are still in charge of telling people what to do. People can be interrupted at any time. People are still work in functional silos, preserving the jobs of functional managers. People are not allowed to work in containers, sharing skills and knowledge to bring complexity into solutions – instead they are worked on a pull (more sophisticated than push) production line.”
• Karl Scotland discusses Scrum and Kanban difference as Intentional vs. Implementational approaches. Interesting perspective in fact. Karl thinks that Kanban can be used with Scrum to reveal even more problems in development process.
• David J. Anderson posted the most rational article about Scrum and Kanban difference. I like it a lot. Some phrases are true gems: “Kanban is not a project management or software development lifecycle method. It is an approach to change management – a framework for catalyzing change in an organization.” and “Kanban uses a WIP limit as a change agent and Scrum uses commitments. This is a fundamental difference in approach.” David also posted some reflections later with interesting thoughts about anarchy and science.
• A year ago Tobias Mayer didn’t believe that it is possible to use Kanban at all. “I fundamentally disbelieve that there is any such thing as a “value stream” when you are working in a complex environment, in a creative process, building new products or generating new ideas.”

I think Ken is wrong. His arguments against Lean and Kanban quite ridiculous. Sure there is no intention to treat software development as a factory and apply lean manufacturing principles blindly. Of course there are people who will try (or already tried) that and fail. But vast majority of lean community in software development do understand the difference and working on concrete practices. Lean philosophy is great, but tools and practices can’t be taken from manufacturing directly.

Pull system is more complex than Push? C’mon!

David has wise arguments and perfect position. I think Kanban will be more popular than Scrum in long-term perspective, but it will take time. Visualization is a key thing to manage complexity, and software development is a complex system.

Yesterday Google alerted me about a review of TargetProcess  by Boris Gloger. I started reading this review and I couldn’t believe my eyes. How could Boris Gloger, such a respected Scrum trainer, overlook some important features of an agile tool he’s reviewing?

Writing reviews  is a very responsible task. It only seems that web can tolerate all. There’s no censorship, no security checks on whether the info in a review can be trusted or not. Reviews are about knowing all the facts. Only when you make sure that you know all of the subject matter, then you can write a review.  I’d never stand up as a guru and claim – my people, I’m your guru, I know all about this tool –  and then – ooops.. – I’ve got some essential flaws in my knowledge of this tool.

Now, let’s see what Boris Gloger overlooked. Comments on Boris’ page do not work(!!!), unfortunately.

Target Process is a tool created by Target Process Inc. to manage agile process. They can support Scrum, Extreme Programming, Lean and others. The tool have a good set of features and some nice ideas to speed up the addition of data for your project. They also provide a Eclipse and Visual Studio add-in so each developer can see their to-do list right on the IDE. If you like to try it for yourself there’s a 30 day free trial available.

Ehm.  TargetProcess comes for free not only as a 30 days trial. It’s free for small agile teams up to 5 people. It’s our humble donation to the growing agile community. Boris, it’s a fully functional free copy with free updates and subscriptions for agile teams of 5.

The “Features” works like an Epic or Theme for your stories and if don’t care for that it can be totally skipped. If you’d like to use it’s possible to determine an estimation and priority for the features but it really doesn’t make much sense to me.

The Features DO work like Epic or Theme and you can rename Features to Epics or Themes or any other name of your choice. The names are completely customizable and it’s up to you which name to choose.

I’d prefer to see something simpler like tags for the stories.

What??? We’ve got tags for user stories and for all the other entities! We’ve got bundles of tags. Tags board. Tags are powerful tools for categorization and filtering, so if I were a certified Scrum Trainer I would have quadruple checked before making such a blunt statement about no tags in any agile tool.

We talk about estimating feature so, of course we can estimate stories also. That’s the first problem i think the tool have, it’s only possible to estimate using time units, ideal or not. That’s no mentions to story points at all, this miss, pushes Target Process to field of time tracking tools, which is not a good thing.

Wrong, wrong, wrong. You missed the point with story points. They’re there, and you can choose between ideal time units and story points. This bold statement of no user story points in TargetProcess pushes you, Boris, to field of shallow reviewers that do not take enough time to study the agile tool they’re reviewing, and then spread this distorted knowledge to their students on Scrum trainings.

Target Process is supposed to work with different agile models, so they use the term iteration instead of sprint.

Foul and a miss. As I already mentioned, one can customize terms and rename the term “iteration” to “sprint” or whatever. TargetProcess is supposed to work with different agile models, so we’ve made our terms and processes completely customizable.

On the Taskboard there’s an awkward choice, there’s only two columns available Open and Done, where’s the WIP ? It’s on another tab Kanban Board, I really don’t understand why they went that way, but it’s no good at all.

Ugh. I really don’t understand how Boris could have overlooked such essential part of TargetProcess as customizable states and processes flow.  Two columns Open and Done on the task board are available for dummies. For advanced reviewers, all the states they want are available. Users can introduce as many states as they need to their development process, and they can give any names to those states. Kanban Board states are customizable as well. It’s no good at all that our honorable reviewer missed this..!

It’s hard to say what I think about Target Process, they had good ideas, like the shortcut flows, but really bad ones like the Kanban Board. Overall the tool is ok but not very intuitive, could be more polished on the user experience, and of course the common problem of too much focus on time tracking hurts a lot.

Boris, I promise you will not be that hurt as you take a closer look at TargetProcess. You seem to have some special inkling with too much focus on time tracking, that’s why you see it where there’s no special focus on it. Time tracking in TargetProcess is just in the right amount, no less, no more. IMHO, it’s rather less of it, than more.  As for user experience – draw the curtain… look in here :)

I read Agile development grows UP article written by Mark Lines. It has quite a strange taste… Is it an attempt to advertise new methodology? I hope it is, otherwise Mark is completely missing the point and agile development trends.

I want to review the article. Just can’t resist, sorry.

Many of us don’t have the benefit of co-location, where the entire team works in close proximity (ideally in the same room), with the user representative present at all times to answer questions

Sure we all know that a co-located team is better. It is not a surprise that consultants advise to co-locate team members. If you need to win the race, it is better to drive BMW M3 than Ford Focus. There are so many discussions around distributed agile this year. There are so many ideas and experience reports on how to implement agile remotely. Agile works in remote teams.

Pair programming i.e. 2 programmers sharing 1 keyboard is an expenditure most management will not endorse

It’s a very strange argument. Many managers will not support continuous integration, iterative development and BDD. It does not mean that these practices are bad. Context is everything. In some companies and on some projects pair programming will increase productivity. While on other projects there will be no benefits or even degradation. How many agile coaches insist on pair programming and say “You are not agile without PP”? Not many. It is wrong to spread this argument to the whole agile community.

Delivering a system without moderately detailed requirements (beyond User Stories) is not acceptable for testing, writing training materials, and production support purposes.

C’mon! User stories can be VERY detailed. For example, you may use BDD-style user stories format and write many cases that will describe functionality in some format, that can be directly converted to unit tests! It is an incredible thing, to be honest.

Fixing architecture as you go (i.e. refactoring) without some initial architectural design is not appropriate for large-scale enterprise systems

Most people in agile community believe that it is required to spend some time on architecture. Again, it is so context dependent. If you create a simple application, one day may be enough to nail down all important decisions. If you create a complex system, it may take several months. Common sense is a critical factor here. There is always a danger to over-architect things and working software is the best proof of concept.

Also something called “emergent architecture” is being developed. I like the idea and maybe it is a right direction.

Most projects are not completely independent and cannot be built in isolation. Dependencies and integrations with other systems are required and require some co-ordination.

Agile adoption is spreading rapidly and indeed there are no common/standard approaches to solve this problem. But I believe it will be resolved during agile enterprise adoption (and we already stepping into this phase).

Organizations usually have some governance practices in place (such as PMOs, ISO, CMMI) that necessitate a level of bureaucracy and documentation

Does it all mean that PMO, ISO and CMMI are good and we should give up and follow the rules? Agile community tries to fight bureaucracy and I personally love that. Documented process means NOTHING for success of software development project. In 90% of cases it holds you in the spider’s net and blocks creativity. There is NO software development without creativity. Wake up, Mark.

We live with these standards, but we should fight them.

Deploying software to users every 1 or 2 weeks is usually not practical in most organizations. Just migrating software through development, test, system test, user acceptance, production environments is a major undertaking. Having many projects trying to do this in parallel on a weekly basis simply isn’t feasible.

This argument is so common… and “not practical in most organizations” is a truly masterpiece. Any statistic data? Did Mark try to deploy anything outside the enterprise-scale Java mastodon applications world? Many SaaS services do painless weekly updates. Some services do painless updates on a Daily basis! It is unbelievable, but I like that. Customers like that!

Mark promotes OpenUP methodology (based on Unified Process). Only advantages in the post, no disadvantages or context at all. Folks, I think it is a so long-awaited silver bullet! Finally it is there! Let’s bury Scrum. Let’s bury XP. Let’s burn Kanban and all the other processes that spark agile movement. God bless the OpenUP silver bullet. Amen.

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! :)

In previous post I mentioned 5 wrong reasons to apply Kanban. Tobias Mayer asked to blog about 5 right reasons :) Obviously there should be right reasons, otherwise Kanban adoption would fail everywhere. So there they go:

#1. Ability to release anytime

In Scrum or XP you can’t release in the middle of an iteration. In Kanban you may release anytime. When user story is ready, you may release it. Definitely it is a challenge to setup development process this way. It is required to have “branch-by-feature” source control policy, merge often, integrate and test often. But it gives you an ability to release often. That is something worth to fight for.

As a PO I like this ability very much. An important user story implemented? OK, let’s release it tomorrow in v.2.15.2. Our customers may benefit from this release as soon as possible. Lead time is faster — customers are happier.

One thing to mention — you need to have a good automated test suite, otherwise it will be problematic to make small releases with a good quality.

#2. Ability to change priorities on the fly

In Scrum you can’t add stories on the fly into sprint (usually). At least it is not an easy process and development team often resists to replacing a story from Sprint backlog. The story has been discussed, estimated etc. A new story may be discussed in a hurry, some details will be missed and as a result significant re-work will be required. So in general iteration or sprint should be frozen.

In Kanban if you have an urgent request to implement or a really important user story, you can just put it on top of the queue. It will be taken as soon as a free slot is available. It is simply a Product Owner’s dream :)

#3. No need in iterations

Why you need iterations? Initially iterations help to reveal real problems in the development process quickly. Further on they establish a project rhythm and rituals. However at some point in project I think you no longer need them.

My vision is that you need to iterate first, then flow. Our backlog is fuzzy now, plans change often. We learn how to do agile in general and iterations are not helpful there anymore. Without iterations there is no need in iteration planning and iteration demo meetings. They are waste. Instead we have more smaller just-in-time meetings with people in a feature-team before starting the development for each user story.  It works perfect.

Some people are missing the rhythm, but I think it is more to habit. Kanban establishes more complex rhythm and it may take time for development team to recognize it. Still stable rhythm may be the only reason to keep iterations in the late phase of product development, in my opinion.

#4. No need in estimates

Why you need estimates? In iterative development you need them to predict how many stories you may take in the next iteration. You may even predict a release date based on estimated backlog and iteration velocity. The other reason is that PO wants to know how big the user story is. If it is big enough, PO  may consider moving it to the next release. If it is small, PO may decide to put it into the next iteration.

Obviously, iterative development is hardly possible without estimates. But if you drop iterations, it is not a problem anymore. Can Product Owner live without estimates? Well, yes. In our company we don’t estimate user stories. Why not? Because I as a PO don’t need them and we don’t use iterations. All I may ask is a very rough estimate like  normal, large, very large.

In our situation (I stress that, in our situation), estimates are waste. We don’t spend time on estimates. We have a prioritized backlog and just take the most important user story and implement it. It may not work in some conditions, but we have quite a mature product and hundreds requests from customers. There is no clean field development, so normally we don’t have any defined release date. We release when it is ready (I understand that many companies can’t do that, but we have this favor).

#5. Perfect flow visualization

Kanban Board provides a very clear view on current work in progress. It visualizes flow and enables fast planning and tracking. It is really a great tool, we love it.

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.

Mind maps are cool. They provide a very good overview of quite complex structures and things. You may quickly scan the mind map and find interesting relations. Also it helps to create/maintain good picture of the process/structure in your head.

Agile development processes are good candidates for mind maps.

Scrum

This mind map represents Scrum checklist (PDF). Looks neat and focuses on right things like Definition of Done, correct roles definition,etc. In short it is a mind map of best practices in Scrum.

More formal mind map (PDF) of Scrum process. Plenty of details and good nodes separation. And finally a small and funny Scrum mind map.

Extreme Programming

Two very similar mind maps of Extreme Programming, but with different details.

Lean

Small Lean mind map. Interestingly, I did not find any Kanban mind map. Seems like it is time to create one :)

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 flock 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