Archive

Posts Tagged ‘agile’

Agile Outsourcing: Get It or Forget It?

January 26th, 2010 21 comments

Bringing together agile philosophy and software development outsourcing has been one of the hottest topics over the last decade.  Lots of blog posts, discussions in social networks — people try to figure out for themselves if it’s at all possible to align agile methodology with the existing reality of outsourced projects.

How can vendors who practice agile gain new customers? How can customers as newly-converted adepts paste their vision of agile thinking on their existing outsourcing partners?

First of all, let’s look back into when and why actually did it all start with IT outsourcing. Manufacturing outsourcing existed since long ago, but IT offshoring only started at the end of 80′s – beginning of 90′s. Companies jumped at the opportunity to save bucks and use cheap labor not only for producing goods, but for producing software. So, the main point is that from the very beginning outsourcing has all been about saving money. No other notable motivation – just saving money and using cheaper labor.

homework

Next, along comes agile manifesto. People start seeing that the waterfall approach  they’ve been using with their outsourcing vendors is not that good after all.  Fixed price contracts do not guarantee real value (Scott Ambler writes very well on that in this article). Next, the more labor is outsourced to some country, the higher are the costs, so the main point for outsourcing which is cost savings makes no sense any more.

There’re other even deeper-lying consequences. On the one hand, the country which outsources – or businesses in this country not the country itself – they save bucks but lose in the long run as they do not grow their own engineering minds, let alone all the problems that you have working with remote teams – yes, we have all this telecom in place, but nothing ever will replace face-to-face communication. If you often go on business trips to the outsourced destination to talk to your team – again, it’s more costs.  On the other hand, outsourcing makes a dangerous long-term impact on the recipient economies as well.

But the point is not about how bad or good outsourcing is.  Vendors have written an array of blog posts on how to align agile and outsourcing – and that’s natural – they want to keep going, so they do everything to back up their point of view proving that agile goes well with outsourcing. This might work true in some cases.

The companies that outsource on the other hand – they have legacy outsourcing teams. They need to get going with them as well, to stand up to all the funds already invested in their outsourcing center/provider.

So with all this outsourcing in our hands – what do we do?

As an agile outsourcing vendor, you should be ready to invest lots of time and effort to educating your new customers on the value of agile and to building a solid relationship. This might be a very difficult task since some people just don’t want to get educated and prefer to stick to good old fixed price bids, logging and billing for gazillion of change requests, lack of communication and other “joys” of classical outsourced development.

As a company with established outsourcing facility, you’re better off. But perhaps you could be even better off if you started this relationship not with an overseas company, but with a guy next door at least.

Anyway,  you are where you are – so you would need to work with your outsourcing partner to practice the agile approach, since at the end of it all work with agile methodology brings real value, as opposed to counting short-term waterfall pennies and losing long-term gain.

Youth, Old Age, Cancer and Technical Debt

November 12th, 2009 No comments

Everything has its life-cycle. Even stars. Even The Universe. Everything.

era1-nowmap

It is quite sad for intelligent creatures, but it is just a fact of life. I want to draw some quite obvious parallels to reveal the real danger of Technical Debt for a software product.

Humans

Let’s take a human. When we are young, we are overflowed with energy. Do you know how a 7 year-old boy spends his day? I have a son, so I’ll tell you. He wakes up at 7 am (sometimes before 6 am!) and tries to play some quite silent games (it is too early to make much noise). He can restrain himself till about 8 am, then he starts to jump, does somersets,  some boxing etc… By 8.30 we have a real “tornado” in our house. It may take him an hour to exhaust and have a breakfast. Such periods of activity can be easily repeated 2-3 times a day. And he literally turns off around 9 pm – sleep is when he recharges his batteries.

An old man is quite the opposite. He saves every movement, everything is hard and slow. He makes many mistakes and health maybe getting worth. Learning new things is also getting harder at times.  Yes, wisdom and tremendous life experience is there,  but very often there is no energy to move forward.

Software products

Software products have exactly the same behavior. Young product is energetic. It has an excited development team behind. It moves forward quickly and feels warm sun on the top. It learns lightning fast and grows on new knowledge. Everything is smooth and shiny. Time to market is everything and tradeoffs are so common! Let’s fix it fast and mark with //TODO: refactor this comment. Let’s hack this framework here to release another cool new feature this week. Let’s re-invent the wheel and write some custom javascript code. Gosh! We don’t have time to learn this new cool javascript framework! These are quite common patterns for young and energetic products.

But what’s next? Years later progress stops. Product becomes old with all the bad and good side-effects. Suddenly it is much harder to add new features. Ages of development make the product more complex. Millions of technical debts rotten its body like cancer . There is no clear architecture anymore and there are so many patches that one small change can produce a totally unpredictable impact and bring along new bugs in unexpected areas. Yes, development team has wisdom. But often no courage and energy to revive the product.

Technical Debt Is a Cancer

How long does this cycle last? It really depends. We all visit doctors. Most of us want to live longer and healthier. Early cancer detection gives good chances to fight and win the disease. We should do exactly the same with software. Here are typical symptoms:

  • Velocity has dropped significantly  over the last several iterations/releases
  • A bug fix triggers one or several new bugs too often
  • Nobody knows ideas behind the original software architecture
  • Team spends more time fixing bugs than developing/improving features
  • Automatic tests are red 80% of the time (if it is 100% — the product is most likely in coma)

If you see at least 2 such symptoms, you’ve just discovered a product cancer — Technical Debt. Technical debt is a true killer when you have deadline (time to market). If you have the symptoms, you should fight the disease right now. You may think that it is OK to wait  several months, add some more “cool and highly requested” features and then get back to the real problems. It is a wrong decision, believe me. I used to make it and I used to fail with it. It bogs you down. You lose focus and make stupid mistakes. It leads to fear. And fear is a bad ally. You go from one extreme to another to  only increase entropy, nothing else.

If you miss the deadline, all the possible actions will not help. Cancer will win. And then you will have just two options: re-write the product completely from  scratch or start a new product.

If you see these symptoms, you should stop and think about the attitude of your development team. If you’ve survived over several years, priorities should be changed. Reset your development team and use chemotherapy.

  • Focus on quality. Fix the roots of the problems.
  • Teach the original architecture to all, pair program, communicate.
  • Introduce “No new code without tests” rule.
  • Fight fear. Let the knowledge spread. Knowledge eliminates fear.
  • Put the most experienced people on fundamental problems solving.

You have to fight the cancer to bring energy back, to bring courage back, to live and produce a great software product. Otherwise it will be as dead as Lotus Notes.

Tale: Deadline and Technical Debt

November 10th, 2009 18 comments

Once upon a time there lived a very brave and adventurous young man by the name Arthur. He lived in a large kingdom with knights and castles and an extremely cunning king who had a beautiful daughter – Caroline. She was so beautiful, that every morning birds would fly through the open window with fresh roses in their beaks. Birds would drop rose petals near her bed and fill the air with pleasant tweets, every five minutes exactly. Then they would fly away to never come back…they would simply die outside, because they couldn’t live without princess’ beauty anymore.

The king was greedy so he held annual competitions during which the contestants had to pay 10 sovereigns each to participate. The winner would marry Caroline, but missions were so hard, that there were no winners ever!

New competition was announced and brave Arthur decided to win the highest prize! He saw the beautiful princess only once before and fell desperately in love with her.

On a sunny day all the contestants gathered together on a central square. The king said: “Brave men! There will be 3 main missions… and a very easy 4th mission to the winner. Today I’ll tell you about the first mission only. You have to build a house in 10 days. It should have 2 rooms, doors, windows and a roof. That’s all you have to do!!”

sustainable-hobbit-house

Mission #1

Is it possible to build a house in 10 days? Arthur was disappointed. He had hoped to kill a dragon, catch a witch or do something else that a brave knight is supposed to do. But he was smart (and brave). He spent all the day doing nothing but thinking. Other contestants laughed at him: “Look at Arthur! He gave up miserably! Arthur, go home, you are such a loser!” But as you know, our Arthur was smart so he decided to build the simplest house possible. And he did it: the ground became a floor; house had only 2 tiny rooms and the light would enter through the 2 windows near the front doors; the roof was there to simply protect from rain and snow – no more no less! Most importantly, he finished it in 8 days! Many, many other brave men tried but failed. Some started to build a large and solid house and ran out of time. Others started building too quickly and their houses would collapse half way through. However, brave Arthur and a dozen other guys completed the first mission successfully.

“I am proud of you! – said the cunning king. “Now here is the second mission for you all. This time, you should build a basement that will be twice as large as the house itself. Also you should build a fireplace. You all have a total of 12 days to get the job done.”

Mission #2

And again Arthur spent the whole day thinking. “I don’t even have a floor in the house… How can I build a basement? The house will simply break down… If I spend time on the floor, I’ll have no time to do the rest.” Then he found a workaround. He decided to dig deeper than usual. “Deep basement should be safe enough and floor is not required in this case! Fireplace will take 2 days to create, and I can definitely make this basement in 9 days!”

Arthur worked like crazy and completed the mission in 11 days. He slept for the whole 12th day – the last day of the mission. At the end, only 5 other brave men have completed this stage of competition.

“You did a fantastic job!” – the king said. – “Now listen to the last mission. You should build an upper level in your house. An upper level may have only one room, but you have only 5 days to do it.”

Mission #3

All the contestants were quite excited. It looked like an easy task. But Arthur was sad. “If I build another level” – he thought – “my house will crash…” This time he started to work immediately. He brought several large logs into the basement and made props. It took him a total of 2 days. Arthur was not sure that it’d be enough, but he had no more time and decided to accept the risk. Luckily, he had a flat roof and therefore it turned out to be relatively easy to create another level right on top of it. Arthur was tired, but extremely happy. After all, he was the only one who made it through the last mission!

“My boy!” – King happily hugged Arthur. – “You did it! I can’t believe, but you did it! You are just one step away from the Caroline’s hand. Your last mission can’t be simpler – You should live in the house you built during the first 2 weeks. This is it. And then you will have my blessings and the hand of my beloved daughter, Caroline!”

“Wow, so easy!” – said Arthur. “Yes, it is” – answered the king with a smile on his face.

Mission #4

The next day brave Arthur was killed by the crashed ceiling. It was a windy and rainy day…

Categories: agile Tags: , , ,

BDD and User Story Specification: Examples

October 22nd, 2009 4 comments

I’ve started using BDD to create user stories specifications several months ago. It works great. Very good format. Developers understand it without problems, Testers can write acceptance tests quickly and it is easy to follow for Product Owner.

Here are some examples of real user stories specs in BDD for TargetProcess product:

As a Scrum Master I want to see Release BD Chart drawn by weeks

As a Scrum Master
I want to see Release BD Chart drawn by weeks
When Iterations practice is disabled
So that I can benefit from BD chart

Given any development process
When I turn off Iterations practice in Admin -> Process -> Edit
And navigate to Release BD chart
Then iteration velocity replaced by weekly velocity
And Chart end date is the same as Release end date
And BD chart drawn by weeks instead of iterations
And Chart Start Date is the same as Release Start Date

As a Scrum Master I want to see Lead/Cycle time progress

As a Scrum Master
I want to see Lead/Cycle time progress
So that I know whether we are improving our development process or not

Scenario #1
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Lead Time chart
And chart contains 1 line for stories

Scenario #2
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Cycle Time
And chart contains 1 line for stories

Scenario #3
Given Reports section in project and Bug Tracking practice is ENABLED
When I navigate to Lead and Cycle Time Report
Then I see Lead Time chart
And chart contains 2 lines (for stories and bugs)

Scenario #4
Given Reports section in project and Bug Tracking practice is ENABLED
When I navigate to Lead and Cycle Time Report
Then I see Cycle Time
And chart contains 2 lines (for stories and bugs)

Additional Info
X-axis – Months (display 12 last CALENDAR months)
Y-axis – Lead time or Cycle Time (in days)

To display value for given months, we take stories completed this month (determined by End Date).
For example, in June we’ve completed 5 stories, in July 10.
Then lead/cycle time will be calculated for June by sum(5 stories lead time)/5 and for July sum(10 stories lead time)/10.

Charts should have labels for each month.

Story line color: #507cb6
Bug line color: #cc060d
kanban_stats1

Categories: agile Tags: , ,

Our Development Process

October 15th, 2009 10 comments

Inspired by Kanban at Lonely Planet. I think it is a good idea to share software development processes from different companies. Maybe even it would be great to create a repository of the processes somewhere on a popular agile web site/blog.

Context

  • Product development (quite large web application)
  • Two development teams: Core (5 developers, 1 scrum master, 3 testers) and Integration (3 developers – one of them plays scrum master role, 1 tester)
  • Quite mature product: 4 years
  • Technology: C#, ASP.NET, ExtJS, NHibernate

Process

  • Development team has all the power to try new practices, keep working practices and remove bad practices. There’s a little push from scrum master side.
  • We do not use iterations.
  • We do use releases, but often it is just a set of all the features implemented last month.
  • We do not have iteration planning meeting, but discuss every user story JIT before implementation on a meeting with PO + Testers + Developers.
  • We do not estimate stories and bugs, just a very brief estimate like (“oh, this will be a large story, let’s split it”).
  • We split stories, but sometimes not as aggressively as required.
  • We release new builds every week (sometimes 2 builds per week). The goal is to release every day, but we do not have a good automated functional tests coverage so far.
  • Smoke testing of the build takes 3 hours (3 testers).
  • We have a limit of 3 user stories or bugs in progress.
  • We have retrospective meetings every 2 weeks.
  • We sometimes have technical user stories (for example, remove jQuery from application), but that is rare.
  • We use Kanban Board in TargetProcess heavily and have a large screen in development room.
  • We have a flat hierarchy in the company. There are only two layers and no boundaries between the layers. No formalism at all. Also we do not have positions like Senior Developers, Junior Developers, etc. All people are equal (however, there are informal leaders).
  • Average Cycle time for user story is 13 days and 5 days for bug.
  • We track spent/remaining time on tasks and stories.

Development practices

  • We develop each user story or bug in a separate branch. Master is always ready for release (after smoke testing). We use Git (switched from Subversion).
  • Pair programming on all user stories and complex bug fixes. Sometimes people work alone on smaller/simpler problems.
  • Developers switch pairs every day, even if user story is not completed yet. The goal is to a have fresh look, knowledge spreading and real collective code ownership.
  • Before story implementation, pairs discuss possible solutions. It is quite formal.
  • TDD. All the new code is covered by unit tests. Situation is worse on JavaScript side, we just started TDD adoption for UI.
  • We use Cruise Control and have quite many different setups. Smoke builds, release builds, etc. Functional tests run in parallel and it takes 1 hour to run them all.
  • Selenium. Automated functional tests are based on Selenium. We’ve created a framework in C# especially for our application to simplify tests creation. Tests coverage is not good so far, but we are working on it (there are 2 automation testers in our team).

ToDo

  • We want to add performance tests into automated builds.
  • We want to have 80% functional tests coverage to be able to release new builds every day
  • We are incorporating User Experience into development process. This is our main goal for the next year. It includes Customers UX Community creation, interactive prototypes for all user stories, usability testing.

See what changed 1.5 years later.

Driving Down the “User Experience” Road

October 7th, 2009 2 comments

maserati-granturismo-s-01

Overall the recent Agile 2009 Conf. in Chicago was a good event. Unfortunately, the first two days were not quite what I expected. Combination of just “OK” sessions and jet lag left me wondering whether the trip was worth it. However, the following two days were much better, but the very last, Jared Spool’s keynote, left no doubts that Agile 2009 was totally worth coming to! An absolute killer presentation on User Experience with an excellent steak on the side (yes, Americans know good steak) – what else could you ask for?  A lightning bolt, a hit, all of the above – I can hardly express how enlightened and inspired I felt walking out of the ballroom where the speech took place. And that’s when reality hit me, and I suddenly understood how bad we suck with our User Experience… I got depressed for about 2 days, but then I started to act.

I read several books about User Experience. I read countless articles, forum threads, blog posts on the same subject and finally started a process of searching for UX specialist to add to our development team (and we hired him already). I’ve dug through all the information about UX, UI, Design and thought about how we could integrate it into our development process.

In one month I came up with a vision. I created interesting presentation and shared my vision with the team and inspired them. They applauded (thank you, folks!). I believe Agile and UX is a great mix. Definitely it is not easy, but I think it is a right path to follow. We want to create the best agile PM software in the world, and it is just impossible without outstanding user experience.

We want to share all the new experience about the journey. I’ll post more about process changes, mindset changes, education and whole team involvement. Here is our first try, see how we are re-designing ToDo list in TargetProcess:

Categories: design, usability Tags: , , ,

5 Right Reasons to Apply Kanban

August 12th, 2009 12 comments

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 Board

Categories: agile, kanban, lean, scrum Tags: , , , ,

5 Wrong Reasons To Apply Kanban

August 10th, 2009 25 comments

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.

Bugs Source #1: Unclear User Stories

August 6th, 2009 11 comments

I think unclear specifications is #1 source of bugs. If you deliver something that was not intended, there will be many complaints from customers. In customer’s opinion almost all these complaints are bugs. Also, without instant communication it is very easy to miss important details and release an un-polished user story with a number of small glitches.

Agile development is very rapid. In many cases the path from idea to user story in progress is extremely short, it may be even 1 day. With this hard pressure on,  it is very easy to make errors in user story description. Product Owner may miss some important details and as a result the story will do something wrong, something that was not expected.

This is the first question you must ask… is it a bug, or is it a change? I’ve seen a lot of bugs that have come up that were “We asked you for x, never thinking about y, so could you please change the system so that y is covered?” It’s a business scenario, so there’s no reason to expect a developer or tester to anticipate/test it. I know where we’ve struggled is in injecting items into the product backlog, we tend to classify it as a bug and so we end up with a lot of bugs, but not a lot of change in the back log. That’s exactly what I think we’re supposed to be avoiding in Scrum or any other agile methodology. As we see change, we should be taking it on as a feature and prioritizing it accordingly. Only when it’s something broken should it be called a bug.— Jim Leonardo

The best solution to this problem is communication.

Clarification meeting

The important thing in software development is to put everyone on the same page. Developer, Tester and Product Owner should run a small meeting about user story, thus forming a mini-team. If a user story has several developers and several testers, all should participate.

The goals of the meeting are:

  • Ensure that everyone understands what should be implemented.
  • Brainstorm acceptance tests/test cases and create a check list.
  • Reveal and eliminate all discrepancies in story description/specification.

We have these meetings at TargetProcess and they are very efficient and helpful. Recently there have been some stories  with no meetings, and as a result the stories had more defects and a longer cycle time. Side effect of the meeting is that Product Owner receives less questions about functionality later, thus having less interruptions (which is good).

Stories should be ready before iteration start

It is a good idea to have all user stories described with good details before iteration start. Thus testers and developers will have time to review them and prepare questions to the iteration meeting. It may trigger a much better discussion and reveal some interesting problems that were unclear initially.

There is a danger to document more user stories than required, and it will be a form of a waste. Product Owner should maintain good balance here.

Agile Mind Maps: BDD, Continuous Integration, Design

July 21st, 2009 1 comment

It seems people do like mind maps. Previous post about Scrum and Extreme programming mind maps was very popular. So I decided to continue the topic and gather more mind maps for agile practices.

Behavior Driven Development (BDD)

BDD is a step forward and an evolution of TDD. This BDD mind map nicely describe the whole thing.

BDD Mind Map

BDD Mind Map

Continuous Integration

Continuous Integration is one of the most important software development practices. It give instant feedback and perfect traceability. Check Continuous Integration mind map for details.

Design

Simple design is one of the principle of agile software development. This mind map represents some design smells in quite interesting format. Agile modeling with Mind Map and UML post describes how can use mind maps to create better software design.

Automated Testing

Mind map that shows one approach for automated testing using Fitnesse and Selenium.

Planning

Simple mind map about planning activities in agile development.