In that case you need to build in slack for learning into the system. You want everyone to have time for sharing, improving and learning continuously, and you want to be able to come home from work with energy to pursue your goals for personal skill development even further.

It’s great fun to be good at what you choose to spend your life doing.

Since the primary raw materials in software product development are skills and intellect, rapid learning is the prime goal and the capital for product development. Fail to invest in raw materials for your business, and you’ll soon run out of stock. Don’t allow for time to learn, rather, require it.

Running a system at 100% yields all sorts of problems.

Symptoms include

• You stop talking to each other. “Sorry, can’t help, have to go do this thing that is  really urgent”
• You start building technical debt. “If I just skip to write that test (it’s really hard to write), then I can save 2 hours today to get to the next thing I have to do.”
• Shallow bug-fixing. “Need to fix this bug real fast, in order to get the other 4 bugs done, too! No time for digging further” Root cause analysis and regression testing get skimped on.
• Useful, although sometimes inconclusive and somewhat directionless, discussions plainly stops happening.
• Stress activates your lizard brain, which numbs the rational being. You are in survival mode.
• Work gets less inspiring and fun, which slows things down. Inspiration is high-octane fuel.
• People get exhausted, and energy-level is low during, and after work hours. You need to “relax” on Facebook at work and in front of the TV at home, instead of doing inspirational learning.

(Picture from Wikimedia commons)

If you have trouble grasping the concept, picture a congested highway. If you remove a small percentage of the cars, you get a magnitude of improvement in throughput and speed. This is a fact.

Did you ever try to squeeze a washing machine 100% full? No clothes get cleaned. Remove 10 or 20% of the clothes, and you have a winner.

Don’t maximize utilization.
Build in time for learning, improving and sharing.

If you, as we have been, find yourself in this mess. There are several ways to get out of it.

1. Say no. If you never say no, you don’t have a strategy — say no to the least important stuff. Saying no is hard, scary and extremely useful.
2. If you work for a consultancy firm, give up. Incentives for maximizing utilization is too high in consultancy companies, as they get paid for “productive hours” only. Quit your job, and go to work in a product development company, or a skilled in-house team. Anything but most consultancy firms, they will cannibalize you.
3. Scale up capacity to meet demand. What can I say, we are hiring.

Quantified

This is no science, but if I would be forced to put some numbers on this, I’d say that:

• Build in approximately 20% learning/sharing time during normal work hours. Yes, that’s one whole day a week. We use it for our monday school, impulsive discussions, reading, friday meeting (our arena for general discussions on processes) and blogging, to mention some activities.
• If you want, you can probably “work” 60 hours a week or more without any danger of burning out, but only as long as that time is spent balanced and having fun, learning and improving/being productive — and only if personal situation allows for it without sacrificing time spent on other important values, like your kids.
• Don’t build overtime into your standard operating procedures. Required overtime doing “productive” work should be the rare exception, not the default.

Find a sustainable pace where you are balancing learning, improving, being productive and all of the time having fun. That’s an important ingredient in the recipe for success.

By the way, did I mention that we’re hiring or that we’re hiring?

It’s official: We’re not doing Scrum anymore.

I will take the time to elaborate on why, and I’ll reflect on what we’ve learned from our experiences.

Why are we not scrumming?

The shortlist:

1. Iterations were too long – It would sometimes feel like a waterfall in miniature. Reality for most development teams is that circumstances change constantly, and developing the capacity to adapt to these changes are more important than planning iterations carefully, which is just a form of guesswork.
2. Too much overhead – Sprint planning felt a bit forced. We had to decide what to do for days or weeks to come, and ended up with requirements churn. Beyond a certain point during planning, we went into congestion, and stopped caring about the details.
3. Our sprints are too diverse – Sprint goals ended up  so diverse sometimes that we ended up more often than not with the sprint goal of “Finish all tasks” which was a quite uninspiring goal. (We tried very hard to create good sprint goals)
4. Demos not often enough – We need to show off the feature we just made right now, not in 14 or 30 days at the demo. That is way to late for us. Demoing should be an integral part of each feature or improvement you make. You need to be close to, and intimate, with real users. If we had investors or any other formal committee of sponsors that needed to approve everything we did, we would see the use of such “demo roundups” at regular intervals.
5. Too long release cycles – The scrum process batches a lot of changes, improvements, bugfixes and new features into periodical releases. We are working on continuous deployment with a steady stream of product improvements, which allows for more predictable releases and better fail-tolerance.
6. “Scrum is just the easy parts of XP”  – It’s a quote from Kent Beck, although he does not like to be quoted on that one. This is why most are doing Scrum in combination with XP of course. I think you in many cases are better off with XP without Scrum, but that’s another story. We’re not doing XP in its purest form, either. Even though XP has much stricter coding practices, XP also has its limitations. The lean startup movement (which Kent Beck himself seems to be quite interested in) complements the weaker parts of XP — the customer feedback part, especially in the initial phases of product development.

You might see a pattern here: We’re still doing most, or all, scrum practices, just more often and in smaller chunks. This brings us closer to Lean.

What did we learn from it?

You should have a Product Backlog, and it should be a very simple sortable list. The emphasis should be on keeping it short, however. A long list of features becomes an administrative overhead. We found ourselves sifting through much of the same tasks from sprint planning to sprint planning. Too much got captured in the sprint backlog. We are still using product backlogs actively.

You should hold sprint planning meetings. The problem with the scrum-format of it is that it has more emphasis on creating a plan up front (i.e. the waterfall comparison), than it has on the planning itself. If planning is a monthly activity (or bi-weekly, or whatever your sprint length is in scrum), you end up reading your plan more than you spend time planning. We find that planning is at its best a continuous, on demand, activity. Do more of it, often, but in smaller chunks, and keep less of it lying around. I will have to agree with the Dwight on this one : Plans are nothing; planning is everything.

Daily scrums solves a non-existing problem – I’m sure that it is not hard to find team that would benefit from daily scrums. If you are such a team, chances are you are not communicating enough. We find that by hanging out on the project IRC-channel doing continuous micro-coordination and sharing information, and by hooking up on Skype to discuss challenges and problems on-screen as they arise we have nothing left to coordinate or discuss on the daily scrums. Everyone is in the loop on what is happening.

Retrospects are pure beauty. Again, the problem with scrum for us is not that it is has bad practices (it has the best of practices, actually). The problem is that it is performed to seldom to have the desired effect. Retrospect is not an activity, it is a mindset, and has to permeate everything you do, and should be done on a continuous basis. Ask these questions about every little project, task and experiment you run. What went well? What could be better? What will I focus on improving? It’s key to learning, and learning is essential.

Under what circumstances would we consider scrum?

If we ever find ourselves in a multi-team environment with quite large teams (5-10 per team), with sponsors that needed formal updates and demos, we would be sure to consider both scrums and scrum of scrums.

So, was all our Scrumming just a waste of time?

No way. It was a learning experience.

Never forget this: There is no silver bullet. You should try different stuff, be critical and analytical in the process, ask why to just about everything, and you will learn a lot. Shed each practice that fails to materialize into concrete value for your development process. In the end, no process formalities will save you, your diverse experience will.

What will we do differently?

We will continue to draw inspiration from Scrum, Lean, XP, Lean Startup, Customer Development, Continuous Deployment, etc. But instead of changing ourselves to fit the process (as was much the case with our scrum-efforts), we will look at the core of their ideas, extract their essence and see how they could apply to our existing and intuitive way of doing things;

If being a keen student of processes and development theory has taught us only one thing, it is that we should trust our gut feeling, our sense of what is purposeful and what is common sense, and that most of our current practices are worth keeping, and improving.

I advise you to try to improve the quality of how your team already, and intuitively go about doing the work. Do not change the way you work entirely in an attempt to magically achieve quality and speed. This way you can better preserve what you already got figured out, and at the same time be improving continuously.

In plain words, what are we doing now?

We still do a lot of the scrum practices. We just do them more often, and in smaller chunks. You might even say continuously, to some extent. We have learned to cherish planning over plans, and a retrospective mindset over bi-weekly formal retrospects. We write less plans, we take less notes. Communication flows more freely instead of formally in batches.

We get more done, and with increased quality, and we also have Scrum to thank for it, but definitely not only Scrum.

One of our biggest ongoing project nowadays is our establishment of Continuous Deployment practices, and all the discipline that goes with such a strategy. (It requires some coordination when you have servers deployed all over Europe, as we do) You will need to optimize the entire value stream to achieve this. We’ll keep you posted on how it evolves, and the benefits our customers and we reap from it.

• Plan it
• Code it
• Test it
• Commit it
• Deploy it

Nothing out of the ordinary, it seems. The seemingly new thing about continuous deployment is that we remove all the waiting in between each of these steps. That is, we don’t batch changes before to testing them. You test immediately what you just coded. You commit it. Not to a branch due for merging in a week. No, directly to trunk. And you even deploy it at once to production. Done. Clear your mind of it, enjoy, relax, spend some time doing something proactive.

Develop, test, commit, deploy. One feature, bug-fix or improvement at a time. That is the mantra for continuous deployment.

Some developers, and perhaps particularly managers, will find the idea crazy at first. Release immediately? Omigod. But frequently this sensation of safety in postponing something, is not rooted in any real benefits, and there seems to be no rational answer to the question of: why wait? Did your code ever get better during the night? Some will even argue that big feature releases is a marketing invention, invented to squeeze more money out of customers frustrated with the bugs in the current version. This practice of batching changes in releases in turn got embraced by the industry as the professional way of conducting business. I could easily add this to my list of major problems with the software industry.

Wouldn’t it be nice to deliver a bug-fix the same day it was reported? The same hour, even? It might just be possible if you are continuously deploying product improvements like this, kaizen-style.

Where does this idea come from?

The idea of continuous deployment comes from the lean school of thought. In the mindset of lean kanban pull systems — where you are constantly looking to remove waste and minimize your batch-sizes — grouping a lot of big software changes together in big batches and big releases makes no sense.

Even Flickr is doing continuous deployment these days.

The whole idea is to respond to customer “pull”. The customer needs something now. The clock starts ticking. Is the feature more useful if you wait a bit before you start coding it? No. Then start now. Is the feature better if you wait with testing after coding it? No. Then test now. Wait until tomorrow to integrate into version system? Is that better? No. Then integrate. Does thing get better if we wait to deploy that new feature? No. Then deploy it. Stop your clock. The shorter the time, the better for the customer. And better for quality, it seems. And the better for you, the coder. Unreleased code is stressful. Released, working code, is stress free. The code works. It’s proven.

After a few iterations, our fear level was actually lower than how we used to feel after a staged release. Because we were committing less code per release, we could correlate issues to a release with certainty. (From Case Study: Continuous deployment makes releases non-events)

Bugs that are not discoverable in testing are easier to find and fix if you released only one feature, than if you batched a months worth of changes together in one big bang release. Or so the lean school of thought states. I agree. You would have written the code hours ago, and probably say ‘a-ha!’ the second you hear about it. 20 minutes later, a bug-fix is released. Why wait?

A few resources on lean from Amazon:

• Software Development: An Agile Toolkit
• Implementing Lean Software Development: From Concept to Cash
• Lean Thinking: Banish Waste and Create Wealth in Your Corporation
• The Toyota Way

What does it take?

Not surprisingly, continuous deployment requires a high level of team discipline. No goofing off and no more fixing everything mañana in testing. Practices such as 5 Why root cause analysis, extensive testing and automation will be required. But it will all lead you to better quality and higher iteration speed. Speed and quality, it is all related.

Eric Ries writes on O’Reilly Radar about “Continuous Deployment in 5 easy steps“. Eric Ries has gotten a lot of traction with his Lean Startup movement lately. And you can follow his thoughts and reports on personal experience on continuous deployment on his blog http://www.startuplessonslearned.com/

Look ahead

Will we pursue this issue of continuous deployment any further? In the name of delivering a high quality experience to our customers and users now, when they still need it: yes we will.

If you will join us in this, please follow this blog on RSS or follow the company or the author on twitter. If you digg it, then digg it.

a) Ease of Use

The software solution walks you gently through the process of solving your problems as intended. No distractions, no unnecessary decisions to make, no confusions, always heading towards the goal. In short : A great user experience.

b) Quality of Craft

Quality of Craft means that the software solution is easy to maintain, it’s easy to modify so that it’s always accurate in solving the ever changing problems it’s going after (and by that I don’t just mean in configuration, but easy to change the code of), it’s easy to move about (i.e. from server to server), it performs great, it responds immediately when interacted with and it scales, or can be modified to scale, in order to handle the traffic it will attract.

Photo by toffiloff

Isn’t that an intuitive definition?
The definition is common sense in software product development.
Perhaps a “Software Product 101” should start out with such a definition.

Thus, we should assume that everyone get’s this nailed down from the start, or through a little experience, no?

I’m sorry to report that surprisingly few players in the industry is able to see this.
And even fewer is able to execute it.

It’s always either or, never both. The tendency is quite prominent.

It seems as start-ups create great solution accuracy and a good user experience using customer oriented development methods, and in general a lean start-up methodology. Growth, however, turns them in the direction of stability and the need for predictability. Sadly this usually leads to a loss of the qualities in a) in favor of a few of the more stabilizing qualities in b).

As much as I agree that as a start-up turns into an enterprise, the need for operations stability and predictable performance increase. I do not, however, believe that this is achieved best by sacrificing the ability to adapt and to keep the software usable and accurate.

I believe that while sacrificing qualities in a) might seem to be the easiest path, it is not the only path, not to mention that it in no way is the right path.

I am part of a small, growing, start-up company, and we’re focusing our resources at keeping on the right path, maintaining the agility of a start-up, and the stability and predictability of an enterprise. It is possible — this path exists.

It’s hard to find. But we’ll find it, or die trying.

Related posts

• A post about buildings (and software quality).

Disadvantages of Pair Programming

Don’t four hands produce more code than two?

If you are a carpenter, you can hit more nails with four hands than with two. If you are a brick-layer you can lay more bricks with four hands than with two. If you are a developer you can write more production code with four hands than with two. Or wait. This is based on the assumption that the bottleneck in software development is a mechanical one ; the speed of which you can type on the keyboard. My 10 years as a developer and 5 years as a program manager tells me otherwise. The bottlenecks in somewhat innovative projects (non-repetitive) rarely or never include typing speed. Bottlenecks do include hesitation (doubting your own solution), introducing bugs and having to go back to fix it, suboptimal design that deserves a refactoring, lack of needed knowledge for the task, loss of focus and so on.

A small disclaimer before I go on : We have not been experimenting with Pair Programming for more than a few months, and my above observations are based on observing teams develop from a managerial point of view and from reflecting upon my own coding habits as a team member.

Benefits of Pair Programming

Amplify learning

The speed of learning in pair programming is overwhelming. Once you enter a topic one party has more experience in, you are in for a ride. I have never experienced learning at such a pace as when this occurs.

Prevent bugs

Bugs are cheapest when they are prevented  from being introduced with measures that does not put restraints on your risk-taking and innovation. Pairing keeps you innovating, and will still help you spot errors more frequently. You will be more critical of your own code, and you will have someone constantly looking for possible improvements in your code, such as stopping a bug in the making, or having an idea for an even better test.

Continuous improvement

Pair programming is a dialogue between two people trying to simultaneously program, and understand how to program better.

Articulating ideas

Pair programming forces you to put words to your thoughts. This will through constant practice improve your skills in articulating your ideas.

Share frustrations

The responsibility on one single programmer can be huge at times. It is relieving to carry the load together. A teams strength and robustness is greater than the sum of strengths.

Avoid hesitation

When exhausted for ideas or new angles, it can lead to hesitation to implement what you suspect is a sub-optimal solution. The union of ideas and angles between the two developers makes this a rarer incident, and the resulting discussions will usually help remove the knots causing hesitation.

Distributed resources

From a managers point of view, a migration of people between project modules, and even between projects, becomes vastly easier. This is a dream come true. Nobody is the sole “owner” of code anymore, and developers can move more freely between code sections and projects, simplifying the complex task of resource scheduling. Starting out on unfamiliar code means that you should be pair programming with someone with a lot of domain knowledge in the start.

How to do pair programming

Pair programming is two people using one keyboard to write code. Here are some important best-practices to go along with that description.

1. Choose a suitable partner for pair programming the given task during the daily scrum.
2. Sit side by side with only one keyboard and one mouse. Both should have a good view of the monitor.
3. It must be easy to slide the keyboard from person to person. Switch roles from typer to observer every so often.
4. Discuss and have a good time.

So, these are my reflections on the subject so far. I will be sure to update you (RSS) on any changes of opiniton as we continue to improve our development practices.

The Software Management Manifesto *)

You have the right to an overall plan. The team should tell you what they could accomplish in the next year or two, and tell you how much that would cost.

You have the right to see progress. From the very beginning of the project, the team should be producing functionality that you care about. The functionality should be in the form of a running system, proven to work by passing repeatable tests that you specify.

You have the right to change your mind. As software development proceeds, you should be able to substitute new functionality for old. You should be able to change the relative priorities of the features of the system, dictating what should be done first and what should be done later.

You have the right to be informed of schedule changes. Since some things will turn out to be easier than expected and some things harder, the schedule is going to change. You have the right be informed of such changes as soon as the programmers know about them. You have the right to exercise your business judgment by choosing among options for reducing scope so as to restore the original date. You have the right to cancel further development at any time and be left with a useful, working system that reflects your investment up to that date.

*) From Software Management Manifesto

Does your process ensure your customers these rights?

One of the more useful activities of Scrum involves a bit of self-reflection — namely the retrospect. Admit that what you did yesterday could be done better today, and you are on the way to continuous improvement — a goal in and of itself.

Scrum tells you to ask “What could be improved for the next sprint?” at each retrospect. It is usually hard to think of good answers to this question. In this post I make an effort to compile a list of the most usual suspects, and I also suggest some remedies we have seen to work.

If you are anything like us, your usual suspects would be:

Presented in no particular order, these are suggestions for improvement that we have discovered.

1. Complex and / or undocumented code

Did you stumble upon any code that were hard to understand and even the comments did not help you out? If you did, you know how time consuming and frustrating this is fixing such code. It is a giant waste of time — and you have to spend a lot of time understanding the whole picture in order to refactor it to simpler, documented code. Andidote : Refactor mercilessly. Stop writing legacy code.

2. Untested code

Did you ever struggle to track down a bug in code, only to find that it could have easily have been pinpointed in milliseconds if a test had existed? Did you ever fear improving a piece of code because you did not trust the tests to cover enough to tell you if you broke anything? This and similar kinds of project mistrust is a real killer for productivity. Antidote : Stop writing legacy code. If you have to use legacy code, write tests for the code you are about to use, first.

3. 90% done

Did you ever start coding on some functionality, only to find that it depends on something that is almost finished, but not quite? Obviously you’ll have to finish the 90% done item. And it takes a lot of time, you have to dig into it (losing the context of the current functionality you are working on) in order to complete it properly. Antidote : Schedule work one user-story at a time,  and bring all code to 100% completion — i.e make it pass all unit-tests and acceptance tests (customer tests) — before proceeding to the next feature.

4. “Iterating quality in”

Thinking of iterations in form of “write incomplete code now” and the next iteration (whenever that is) “I’ll make it right(er)”, will bring you into all sorts of trouble. This kind of mentality leads to both 1, 2 and 3 above. Antidote : Add more discipline to your iterations. All iterations should end in all commited code being 100% done. Iterations are lovely and necessary, and you will improve existing code during each of them, but you should do your best the first time, as well.

5. You tested what?!

Did you just receive feedback on stuff you did a month / two months / three months ago? Delaying acceptance-testing (customer testing) until a developer has forgotten all about the code is very waterfallish. Antidote : Keep cycle time from checked in code until testing, deploying and feedback as low as possible (hours or days, not weeks or months).

6. Setting architectural goals, instead of functional goals

Setting out to “Create world-saving fancy-schmancy plug-in-environment” instead of “Allow programmer to paste text-data through a plugin-api” (much smaller and better defined) will usually lead us into creating a lot of code that will not be used any time soon. Also, it is much harder to measure “done” in “Create fancy plugin-environment” and the goal in itself is likely to bee too big for one sprint. It leads us into the “90% done”-problem. Antidote : Deliver value continuously and in increments by splitting the problem into smaller user stories, each with a value for the customer. The user stories will be much smaller, allowing feedback and quality into the process.

7. Big-bang integrations

Branching for a while is not a problem when you keep your branch synchronized to trunk all the time. Merging to trunk becomes a breeze. The problem is created for the other guy(s) that have another active branch (god forbid). When you merge to trunk, they are (when synchronizing) smacked in the face with your last week of changes. Antidote : Branch only when you must in order to keep commiting daily changesets which would otherwise make the trunk unstable. Merge to trunk as soon as you have a state of passing all tests. Aim for worst-case scenarios of day(s) between merging to trunk, not weeks.

8. The future is strangling the present

If you are spending a lot of time in requirements (user-stories) the future is killing the present. You are probably going into details too early.  Antidote : Add just-in-time discipline to your process.

9. New functionality, but no users

Have you ever launched a new functionality that no-one were delighted to have immediately? This is a waste of time, and best-case scenario someone will start using it in 3 months and lead you into what resembles #5 above. Antidote : Your planning process is broken, involve real users in planning, make sure you are not planning to far ahead.

The “Standish Group Report – Chaos” (1995) points out a key difference between bridge building projects and software development projects (a difference besides the 3000 years of experience in building bridges). The key difference is that when a bridge falls down, it is investigated and a report is written on the cause of the failure. This is not so in the computer industry, where failures are covered up, ignored, and/or rationalized. As a result, we keep making the same mistakes over and over again.

Consequently, do not judge anyone by their mistakes, but by their ability to recover and learn from them. Ultimately this will determine your success.

Seeking to continuously improve materializes in admitting that the last time you did it, you did not do it as well as you could be doing it today. Finding out why, is the key. Today you can be better than yesterday, tomorrow you can be better than today, and so on. This is true if you are willing to take a honest and sincere look at your mistakes.

What could you have been doing better in your previous projects?
Do you recognize any of our usual suspects?

Stay tuned with RSS.

If we are to do just-in-time user stories, we better know what is next, so we are not wasting any time on detailing stories way ahead. In this post we will look into how we will know what is next in line.

If you have only one, or just a few, users, you can certainly gather them all in a room and ask them to arrange the product backlog in the order that would suit them best, considering each story’s estimate. A lot of products, however, have a lot of users, and we might want to listen to more of them than we can easily coordinate in a single room.

Outline of Procedure

1. Prepare by writing coarse user-stories.
2. Survey users about how much they would like a feature, and how much they would have missed it if it were not there.
3. Do a simple cost vs. benefit analysis based on the answers.

1. Prepare

Write coarse user stories. Refer to my last post on the subject. Ensure that all items in the product backlog are coarsely defined user stories, or groups (themes) of similar user stories. Do not go into details, as this will only complicate the process of prioritizing them, and thus hurt our overall goal of planning project properly. Add estimates on a best guess basis. We usually use the Fibonacci sequence from 1 through 21 on ideal developer days.

Mandatory user stories (that is, user stories the product cannot do without) are put on top. Do not waste time scientifically managing mandatory stuff.

2. Survey Users

If you want a cookbook approach to prioritizing, view this presentation by Mike Cohn. I will only present the main principles right here.

Do a user survey. Ask open questions — and ask them both ways.
On a scale of 0-9 …

• .. how much would you like to have this feature?
• .. how much would you miss this feature, if it were not in such an application?

Asking the question both ways will teach us more about the real impact of the user story. If a user is 5 on both, it will have a larger impact to leave it out, than a story with 7 on how much the user would like to have the feature, and 0 (zero) on the how much a user would miss the feature. In relative terms the difference is bigger. Use this information to prioritize between stories.

3. Use Estimates and Surveys to Prioritize (Cost / Benefit analysis)

Finally, this benefit analysis is used together with the estimates (i.e. costs) on each user story to do final priority between each user story, or user story “themes”. Feel free to “go mathematical” on the final approaches. I suggest using “Relative Weighting” as explained by Mike Cohn in slide 25 (page 15) at this pdf.

When To Do This?

Grooming the Product Backlog should be an ongoing activity. The clue is to carefully introduce new items into the Product Backlog, and make sure you are not just throwing ideas in there as a mental dumping ground. Ensuring such grooming, and holding mid-sprint surveys and user discussion panels, are some of the measures we are attempting at Aptoma these days.

Importance

This is important in order to

1. Always work on the most important stories, thus delivering as much business value as possible to the stakeholders in each iteration.
2. Facilitate “Just-in-Time User Stories“. By breaking up and adding details to the stories on top of the product backlog, we are now only discussing details where necessary — just-in-time.

Get going.

Questions you might ponder may include

• What is the difference between Scrum and XP?
• Why are some using Scrum and some XP, and why are some using both?
• What does XP have that Scrum is missing?
• And, to add to the confusion, what is Lean?
• Is Lean agile? Are all agile? What the hey?

Shortest possible explanation

They are all agile, and cover most of the same principles.

A little longer explanation

Scrum is more managerially focused, XP has more technical practices incorporated into it. You need the technical practices to make Scrum work properly, and thus many tend to use both even though they overlap significantly.

Lean seems to be the “next thing”, and it is probably because the Poppendiecks has been more wholistic in their approach to agile than has Scrum or XP. In my opinion their principles and practices covers better all the aspects of true agile software development.

What do we do at Aptoma?

We call it Scrum even though we cover the technical practices of XP as well. However, we will never admit to doing Extreme Programming due to its silly, silly name. (“Extreme” wouuu). There is absolutely nothing extreme or remarkable about agile. It’s just down to earth Common Sense Results Focused Tight Development)  I’ll rather admit to being a Scrum based or Lean software development organization any day.

Lean = The XP + Scrum combination, better explained and without the silly naming.

Even more information

I’m not going to go more into it, but you can read more at Martin Fowler’s blog (one of the agile manifesto signatories). His post on Scrum made me realize that more people should be introduced to the relation between the agile processes, and thus I wrote this post.

Don’t get hung up on whether you want to use Scrum, XP or Lean, but be sure to develop both good managerial and technical practices based on Agile principles. We been studying all these processes, and we seem to have implemented something, and learned a lot from all of them — none of which seems to conflict with each other.

Some links

• *) Agile manifesto – Agile is a set of software development methodologies (such as XP and Scrum) that put emphasis on having a process with frequent inspection and adaptation in a process where change late in the development process is cheap and expected. This is in opposition to the “old” way of doing (or naïvely believing you could do) deterministic scope and planning in details up front.
• Lean Software Development — the process with recumbent bikes on the book-covers
• Extreme Programming — the meaningful process with the silly name.
• Scrum – our own introduction (bliki format) and Mike Cohn’s mountaingoat resources.

Good luck.

PS. Next week we’ll talk about prioritizing your product backlog, which is a follow up from the recent post on user stories. Hang on to the RSS to be notified upon its release.

In our summary post of Scrum, we refer to the Product Backlog as “a list of functional and non-functional requirements sorted by importance“. This post aims to improve and add to this definition. We have decided to go with user stories in the Product Backlog.

A user story is a short description of a functionality which is of value to the user or the customer (Product Owner).

Summary

1. Start out with a product backlog with coarse descriptions. Think of stories in it as short topics for discussion with the customer. (I.e “A user can launch a rocket with one click of the mouse”).
2. As the story advances in priority, it might be broken into even smaller stories – thus in effect increasing granularity.
3. As a story is up for implementation, it is discussed in detail with the customer. The customer is helped with writing acceptance tests to clarify all details and to obtain a definition of “done” to the story.
4. Keep the customer available for further details during the sprint planning and the sprint.

This is how to best work with user-stories, adding details just as they are needed — relying heavily on face-to-face discussions. Some more details follow.

Coarse User Stories as Discussion Topics

Start out by writing super short user stories in the Product Backlog. They might even be too big for any realistic release planning purposes at this stage, but provides a very good overview of the system. Let us imagine that we are planning the project “RMS”, or “Rocket Management System”. Let us start out planning the project together with the customer with coarsely defined stories like this one

- A user can launch a rocket with one click

Seeing a coarsely defined story like this, you probably know how tempting it is to start talking about how this could be achieved through hooking up the button with an XML-push to the rocket-launching system and stuff like that. Don’t think of these things right now. Let us put in a few more stories.

- A user can launch a rocket with one click

- A user can abort a rocket launch.

- An administrator can issue a ‘rocket list of the day’.

- An administrator can plan a series of automated strategic missile-attacks up front for the weekend when he is out fishing.

(And for good measure, being a rocket system and all, let’s add the following: )

- A user must log in to the system.

- A user must re-verify when launching a rocket.

Break a story into smaller stories

It is normal for a story that has reached high priority in the product backlog to be broken into more stories as focus on its details increase. By smaller we refer to how big their estimates will be. This in effect adds to the level of detail. The story “A user can launch a rocket with one click” might be broken into the following stories as we start thinking more detailed on it.

- A user can select a rocket impact destination.

- A user can launch a rocket with one click

- A user can change rocket impact destination mid-flight.

- A user can detonate a rocket mid-flight.

- A user can set the rocket on pause.

…

This means that the stories that are closer to implementation will normally be smaller than the ones that are further into the future. This is just as it should be. Using this technique we have a coarsely defined Product Backlog, which serves as a good a specification as the most beautifully crafted requirements document that you can imagine. Why is this so?

Face-to-face

By deferring details on each story until the last responsible moment, keeping them on the level of topics for discussion, we are forcing developers and customers together for face-to-face discussions. Certainly no developer would be so foolish as to start developing a “Rocket Management System” with the current level of detail we have in our Product Backlog.

Bringing them together we are all set up for transferring tacit knowledge about requirements and system expectations in moderate sized portions; we will only discuss the stories which are due for implementation. Tacit knowledge, as we know, does not transfer through requirements documents.

The importance of face-to-face discussions cannot be stressed enough.It is all too tempting to think that a fat requirements document is the safe and professional path, but a good old sit-down with face-to-face discussions are transferring information that a requirements document could never dream of conveying.

Developers use details from this session to create any documentation they need for remembering the details. Details are very welcome at this stage, as we are just about to make use of them.

Acceptance tests (customer tests)

It is important that details in the requirements are testable. This way we know when the implementation of a story is done. At this stage we write acceptance tests together with the customer. The top priority story  “A user can launch a rocket with one click”, needs the following tests, according to the customer:

- A user can launch a rocket with one click

1. Test that not one in 10 new inexperienced users mistakenly launch the wrong rocket or launch the right rocket at the wrong destination.
2. Test that the rocket is fired within 10 seconds of clicking the button.
3. Test that even after clicking “launch” but before the rocket has launched, the user can hook off other options (such as “Land softly” or “Go twice as fast as usual”).
4. Test that on nuclear scale rockets, a confirm dialogue must appear. “Really destroy all humans?”.

Writing these acceptance tests together with the customer allows developer to ask questions that might strengthen tests, and remove ambiguity in test-formulations.

Root out assumptions

Having discussed the story details with the customer, the development team goes off on sprint planning to lay out how to proceed with this information. Using the story text, the added details and acceptance tests, the team can define how to get to done. The customer should be available to answer questions that will arise during development, thus rooting out the need for the developer team to make any unnecessary assumptions during the implementation.

Summary, once more, even shorter

1. Start with coarse stories.
2. Break into smaller stories as we get closer to implementing them.
3. Discuss all thinkable details with customer upon committing to implementing a story. Add acceptance tests.
4. Focus on the communication! Keep up the talk with the customer during the implementation.

Notes

1. Recommended reading : User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series) by Mike Cohn (Paperback – Mar 11, 2004)
2. 1h:14m long talk held at Agile2008 by Mike Cohn about Prioritizing the Product Backlog, a talk in which he very much enters the subject of user stories. He introduces and elaborates on how user stories can be packeted into “themes” and how future stories start out as big “epics” as he calls them.