When inflexible and wasteful processes are making your organization inefficient, it’s time to introduce agile methodologies. Scrum vs. Kanban then becomes an essential question: Which one is better suited for my own situation?

Scrum – A Fundamental Shift

Scrum is a well defined process framework for structuring your organization. Introducing Scrum is quite a change for a team not used to agile methodologies: They have to start working in iterations, build cross-functional teams, appoint a product owner and a scrum master, as well as introducing regular meetings for iteration planning, daily status updates and sprint reviews. The benefits are well understood: Less superfluous specifications and less hand overs due to cross-functional teams, more flexibility in roadmap planning due to short sprints, etc. Switching your organization to use Scrum is a fundamental shift which will shake-up old habbits and transform them into more effective ones.

Scrum Leverages Commitment As Change Agent

The initial introduction of Scrum is not an end in itself of course. Working with Scrum you want to change habits inside your team: Take more responsibility, raise code quality, increase speed. As your teams commit to sprint goals, they are intrinsically motiviated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as change agent. It’s amazing to see how much teams demand from themselves – often way more you as a manager ever dared ask for.

Kanban – Incremental Improvements

Kanban is way less structured than Scrum. It’s no process framework at all, but a model for introducing change through incremental improvements. You can apply Kanban principles to any process you are already running (even to Scrum . In Kanban, you organize your work on a Kanban Board. There you have states which every work item passes through from left to right. You start left with the Backlog, and push your work items along through the in progress, testing, ready for release, and released columns. And you may have various swim lanes – horizontal “pipelines” for different types of work. The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. Nothing else needs to be changed to get started with Kanban.

Kanban Leverages Work In Progress (WIP) Limits as Change Agent

For every column (state) on your Kanban board you should define a “Work In Progress”-Limit (WIP Limit). The WIP limit tells you how much work items are allowed to stay in a certain state. If the state is “full”, no new work can enter that state. The whole team has to help clear the filled up state first. That way your team will find out about bottlenecks in the progress simply by looking at the Kanban Board and is challenged to change the way they work to avoid such bottlenecks in the future. In that way, the WIP limit acts as change agent in Kanban.

Scrum vs. Kanban

Looking at both agile methodologies it should be more clear what to introduce when: If your organization is really stuck and needs a fundamental shift towards a more efficient process, Scrum seems to be more appropiate. If you already have working processes, which you want to improve over time without shaking up the whole system, Kanban should be your tool of choice.

Other posts:

• Scrum What? New Community Edited Q&A Site About Agile, Lean, Kanban and Scurm A lot of people I meet are interested in agile software development. Either they’ve heard about it or they participate in projects which use Scrum,...
• Scrum alone won’t cut it Scrum is a great framework for organizing projects. It defines exact roles and procedures to structure your work environment. You gain a lot of visibility...
• Kanban WIP Limits – The Fine Art of Focus If you want to get things done, focus is the key. Single piece flow (focusing on only one task at a time) might be too...

Every organization has to deal with a mix of ongoing and project oriented work. But, even if you structure your teams into departments to optimize ongoing work, they keep trying to self organize into project focused teams.

Matrix Management vs Project Organization

There are the regular tasks and chores, and there are the bigger undertakings which try to bring the organization as a whole forward. To balance both, you have two ways to structure your organization: Structure by department and have cross-departmental project teams or structure by project. Structuring by department is often called Matrix Management whereas structuring by project is often referred to as “project-oriented organization”.

Departments Focus On Specialization

The advantage of splitting teams into departments is that even though they might work in different projects they still can share their experiences and exchange ideas and learnings in their specific field. That way everyone can improve his specialization e.g. in product management. A disadvantage of that structure is that your project teams are distributed over various departments. This makes it harder for everyone to focus on the project goals as top most priority.

Project-oriented Organizations Foster Cross-Functional-Work

If your main way of structuring your organization is by project you group all specialists around those bigger undertakings. Everyone required for project success sits and works together and everyone can focus on the project goal. The disadvantage of this structure is that all people with the same specialization like product management hardly get to exchange experiences and learnings. There is a need for cross-project exchange, which you need to enforce to make it happen.

Teams Gravitate To Project-oriented Organizations

So, which organizational form is better? Of course, it depends ™. But, more often than not, people given a choice prefer working in cross-functional project teams. Even loosing the advantages of working with collegues of the same trade, they seem to gain more profit out of working together in a project. Co-location and constant informal information flow within the project team gives a team a great boost in productivity and reduces stress and friction between team members.

Other posts:

• Successful Teams Are Small And Dedicated Photo by Randy Son Of Robert From the dawn of time, humans have always worked together as a team to overcome hardship and danger, and...
• Agile Methodologies: Scrum vs. Kanban When inflexible and wasteful processes are making your organization inefficient, it’s time to introduce agile methodologies. Scrum vs. Kanban then becomes an essential question: Which...
• Waterfall, SCRUM and Lean Software Development simulation as teaching platform Currently, I’m preparing for teaching my next course on Agile Methodology. Again and again, I wonder what is the single most important thing my students...

Scrum is a great framework for organizing projects. It defines exact roles and procedures to structure your work environment. You gain a lot of visibility and you empower your teams. All that is great. But in software development or operations it’s not sufficient. You need an underlying set of values and practices which drive quality and speed.

Scrum is optimized for projects, not recurring work

In every company there are regular tasks like out of band user requests, really urgent bug fixes, the weekly report generation and distribution, etc. Scrum doesn’t really tell you how to deal with those types of issues. They don’t fit into iterations and can’t be put on a backlog. They make it hard for a team to commit to a sprint goal.

Kanban for recurring work

Kanban is all about optimizing flow. Especially recurring issues should be optimized to flow as fast as possible through your organization to minimize impact on project work. That’s where Kanban shines. One option is to organize big feature packages as projects using Scrum and have one or two teams dedicated to ongoing operations using Kanban.

Clean Code

Another important ingredient for a successful software business is to focus on Clean Code. Keeping your software maintainable is one of the most easily sacrificed but also most important factors for keeping speed and quality up.

By combining various agile practices like Scrum, Kanban, and good old Extreme Programming Ideas you can optimize your software process. Focusing on only one of them implies the risk of missing to address critical areas in your organization.

Other posts:

• Agile Methodologies: Scrum vs. Kanban When inflexible and wasteful processes are making your organization inefficient, it’s time to introduce agile methodologies. Scrum vs. Kanban then becomes an essential question: Which...
• Scrum What? New Community Edited Q&A Site About Agile, Lean, Kanban and Scurm A lot of people I meet are interested in agile software development. Either they’ve heard about it or they participate in projects which use Scrum,...
• Waterfall, SCRUM and Lean Software Development simulation as teaching platform Currently, I’m preparing for teaching my next course on Agile Methodology. Again and again, I wonder what is the single most important thing my students...

It’s hard to find the right structure for any organization. A lot of existing management wisdom comes from a time when you had to organize a physical work force. However, with today’s “knowledge workers” those structures don’t work as nicely anymore.

Everyone needs to prioritize

Every developer or devops has to prioritize the current work – nearly constantly. Do I work on a new feature next? Shall I answer those emails first? My box needs an upgrade – is now the right time for it? You hardly find a pointy haired boss standing behind you dictating your every step (hopefully ). Because of this, it’s extremely important to ensure that everyone shares the same goals and has all information needed to decide what’s most important right now. If only an archaic elite circle of managers know the whys and whats of a project and just delegate tasks, bad decisions by the executing team are inevitable.

Empowerment leads to better results, faster

Giving your team the responsibility for the success of their work is the next logical step. By letting the team know all the surrounding conditions and letting them add to the task list produces the best picture of work to be done you can get. I see it way too often that mostly the technical people in a team know exactly what needs to be done but do not feel to have the power to voice their concerns. Of course, those concerns like “we need to rethink this module as it will not scale as it is now” have to be taken into the prioritization of the backlog. If you ignore them for too long, you’ll see two bad effects:

1. You run into serious technical issues
2. You stress out your best and most dedicated people

Both effects can and should be avoided by choosing a fitting organizational structure: Empowerment of your best people.

Other posts:

• Launch Dates – The Good, The Bad, And The Ugly Setting a launch date for your new web site is common practice. Even though nobody knows what exactly the site might look like and even...
• A Luxury Problem: How Emerging Iterations Eat Team Commitment For Breakfast We’ve managed our complete development with Pivotal Tracker for over a month now, and never looked back. All in all, our administrative overhead simply vanished...
• Open Communication Stops De-Motivating your Team Instead of motivating our teams, we should simply stop de-motivating them. Everyone you work with is highly motivated by default. But, bad information policies, countermanding...

If you have a lot of big user stories, your velocity will jump up and down wildly. This makes it extremely difficult to tell when a user story will be done. Breaking down your huge user stories into smaller ones will help you smooth the flow and give you a clearer picture.

User Stories Start Big

Often you have an idea for a new feature. There is a vague picture in your mind how it could look and work. You put it on the backlog to be able to estimate and prioritize it. Teams new to agile often make the mistake to keep it that way. They assign it a huge amount of story points and start hacking away.

Big User Stories Are Abstract

The problem with this approach is that you skip an important design step in your process. A rough feature idea needs further break down to find out how exactly it should look like. By doing that you will replace the big, abstract story with a lot of smaller, more concrete ones. If your feature idea was “mobile support” you might start breaking it down into stories like “show my location”, “show nearby friends”, etc. These stories will replace the “mobile support” story. Now, it might be possible to estimate those stories. Usually the sum of story points for the descendent stories is bigger than the very vague estimate for the original user story.

Big User Stories Block Your Flow

Another issue of keeping user stories too big is that they will block your flow. If you use one week long iterations a big story might span multiple iterations. That means you deliver 0 story points for a couple of weeks and then suddenly you earn all 40 or so points for that one huge story. Unfortunately even after quite some weeks you have no idea which velocity you could deliver ongoing. Dividing the 40 story points by number of iterations will not cut it.

Only if you use small enough stories, which you can complete within one iteration, will you get a reasonable value for your velocity iteration after iteration. Only then you’ll be able to tell when stories could be finished in the future.

Other posts:

• How To Estimate User Stories When Using PivotalTracker For a team new to agile software development, estimating user stories is not easy. The team is used to estimate tasks in hours and days,...
• Estimation of User Stories With Story Points as Abstract Size Measure Photo by HeavyWeightGeek Estimation of Development Time is Hard After discussing which issues we tried to solve by introducing agile practices to manage a remote...
• Kanban vs. Iterative Development Agile methodology builds on the concept of iterations – time boxes – in which you create a piece of working software. Each iteration starts with...

For a team new to agile software development, estimating user stories is not easy. The team is used to estimate tasks in hours and days, and know they’re never right anyways. So why bother? In agile, estimating user stories relative to each other using story points can give you a fact based idea about what will be done by when. But how can you do it?

Assign 1 Story Point For Fixing Typos

Usually, you start with the smallest story from the backlog. But how many story points it shall get? We are using PivotalTracker with a fibonacci scale for story points. In PivotalTracker the scale is 0, 1, 2, 3, 5, 8. For us, the smallest imaginable thing to change in our software is fixing a typo. This is what we would assign a 1. Now, we’ve got a reference point for our smallest user story from the backlog.

Assign 3 or 5 Story Points For Concrete Features

If we start from scratch, stories tend to be quite big. If you can tell exactly what needs to be done, you could give it a 3. If describing the story gets cloudy, but you still have a quite good idea what to do, give it a 5.

Assign 8 Story Points For “Epics”

If the story is completely abstract by now, give it 8 story points. 8 story points means: “This story is too big to really estimate it. It needs further investigation. Then we can break it down into a series of smaller stories”.

And What About 0 Story Points?

In PivotalTracker, chores (things which need to be done but do not create value for the user), have a simplified status flow. There is no “Accept” or “Reject” for them. If you’ve got to do bigger things which need testing, we use features as story type and assign them 0 story points. That way, the chores do not add to our velocity (exactly the way it should be: Clean up work should reduce your velocity, as you deliver less value for your users).

Estimation of user stories is always dependent on the team and the stuff to be done. The above guidelines have worked out for us in a couple of different scenarios. But your mileage will vary. What is your experience with estimating story points? Please tell us in the comments!

Other posts:

• Size Matters – Why You Should Prefer Small User Stories If you have a lot of big user stories, your velocity will jump up and down wildly. This makes it extremely difficult to tell when...
• Estimation of User Stories With Story Points as Abstract Size Measure Photo by HeavyWeightGeek Estimation of Development Time is Hard After discussing which issues we tried to solve by introducing agile practices to manage a remote...
• User Stories – Making Sure Your Customers Get The First-class Seats Photo by Clinton Steeds In my last post about Introducing Agile Practices to Manage a Remote Development Team I described the issues we faced with...

A lot of people I meet are interested in agile software development. Either they’ve heard about it or they participate in projects which use Scrum, Kanban, or Extreme Programming. They wonder whether it makes sense to do pair programming, which Kanban tools to use, how to get started with test driven development or how to deal with bugs in Scrum.

There are tons of great blogs out there discussing agile software development. But I wasn’t able to find any agile focused Q&A site like the programmers’ stackoverflow or sysadmins’ serverfault.

After some pondering, I decided to set one up. Now scrum what? is launched. All questions and answers are provided by the community and the contents are creative commons licensed. Scrum what? has already attracted some very experienced agile experts to answer your questions.

It would be great to see your contributions to this community effort. Ask any question about agile, kanban, lean, scrum, or XP over at www.scrumwhat.com or, even better, pitch in and answer one. There’s even an RSS feed to follow. Everyone profits and together we can make software development fun again!

Please tell your friends about it. Use the retweet button or any of the social sharing buttons below to help spread the word.

Other posts:

• Agile Methodologies: Scrum vs. Kanban When inflexible and wasteful processes are making your organization inefficient, it’s time to introduce agile methodologies. Scrum vs. Kanban then becomes an essential question: Which...
• Scrum alone won’t cut it Scrum is a great framework for organizing projects. It defines exact roles and procedures to structure your work environment. You gain a lot of visibility...
• Behavior Driven Ops, Kanban vs. Scrum and a new upcoming Monitoring and Trending Tool Testing Dash Metrics with Cucumber (Bradley Taylor) – A short article showing off a Cucumber feature for monitoring with Nagios. Kanban vs. Scrum (Henrik Kniberg)...

It’s amazing to see again and again how teams complicate their lives without any necessity. They dream up features “urgently” required by their imaginary customers and then start a death march to launch them at an arbitrary, self-invented date. Why is it so hard to simplify things and get going? Let’s have a look at possible reasons and ways to fight them.

Excitement

If you start something new, everything seems possible and you nearly burst by all the energy which that excitement gives you. You start collecting your great new ideas like gems and you’re convinced that every single one is a “killer feature”. Soon your feature list has 50 prio one entries, which you need to do all at once! Otherwise, your product can’t be launched – you think. Of course, nothing could be further from the truth. As long as you’re not designing a space rocket, you can always add something later. And, if you use an agile development approach, it will even be fast and continuous.

Fear

Even worse than excitement (which is not a bad thing in itself, of course) is fear. If you fear failure or you fear that you cannot change something later, you’re really doomed. Fear switches off a big part of your brain capturing your thoughts in a small, dark corner where no other ideas are allowed to reach in. If someone suggests a simpler way of doing things, you panic and fight that idea with all your might. Obviously, fear is not the best guiding principle when building something.

Establish a rhythm

The best way I found to fight fear in a project is to get going. Sort your priorities into a backlog, take the top most stuff and just do it! After a week or two you’ll see the first results. This is good in two ways: It will remedy your fear that you’ll not be able to get something done and it will give you a way of actually putting facts on the table. Instead of guessing for months you can start using what you build. That will give you confidence and new ideas. Use Scrum or Kanban or whatever agile practices you see fit to get there.

If in doubt, leave it out

If you build less, you have two big advantages: You get it done faster and you have less to maintain later. These two advantages cannot be overrated. As you know, most of the efforts spent in software development go into maintenance. The time spent fixing what you’ve made is lost for doing new stuff. So if you don’t build something in the first place, you don’t have to spend tons of effort to maintain it later. And, your users will love you because they too have less to learn and less bugs to live with.

Other posts:

• 6 Bad Ways of Conveying Urgent Tasks (And How to Fight Them) Sometimes, due to the high urgency of issues, the owners of tasks are not patient enough to use your standardized way of filing a ticket...
• Agile Tool Vendors: Please don’t try to manage complexity – simplify my life! We’ve been using Mingle for over one year now and it serves us quite well. During the course of the year, we used it to...
• Four Short Links: 30 April 2009 Why do programmers code, priorities, how to assess a programmers competency and continuos integration cage fight – some food for thought… Programmers Don’t Like to...

I’ve been in the process of introducing agile over at NetDoktor for over a year. I really like the sound of “in the process of introducing agile”. It’s kinda like the permanent Gmail Beta (or Flickr Alpha). It means there will never really be a “final” agile process here and that’s a great thing! Why? Because the whole point of agile is adapting. “Adapt or die” is about the most basic business tenet I can imagine.

Click here to read the full post!

Other posts:

• New Job at NetDoktor On Monday, I started my new job as CTO of NetDoktor.de GmbH. Its the #1 health portal over here in Germany (ala WebMD or Revolution...
• Agile Links From The Archives One finding from our survey was that a lot of you want to read more about agile basics. As most of you haven’t followed Agile...
• The 5 Goals Of Agile And DevOps If you’re stuck with someone in an elevator and have only a few seconds to explain why introducing agile Methodolgies and DevOps is a good...

Writing software that doesn’t suck is hard – even for the pros. The problem doesn’t lie in solving a hard problem, but in creating a solution which is easy to understand, robust, and easy to change.
A lot of problems in teams and organizations stem from bad code. Bad code ruins the motivation of your team, slows you down to a crawl and drags you down, deeper and deeper into the fire fighting vicious cycle.

Why do we write bad code?

Let’s try to understand a few reasons why we continue to write bad code, even though nobody wants to do it.

In my experience, a lot of developers always feel under pressure to deliver faster. Of course, there is constant pressure to finish a product faster. And of course, everybody should work towards the goal of getting features out to the customers asap. The issue is that too many software developers cut corners when trying to speed up. They don’t write automated tests, they don’t refactor their code after finishing an initial draft of working software, and they claim they’re done even though only the most basic flows are working (and they never took the time to thoroughly test border cases).
We all know where this leads to: Dropping half assed features into QA creates a myriad of bugs and a lot of hassle fixing the left overs of the rush. Not having any automated tests makes you play russian roulette every time you touch your code, and adding and patching a draft version of the code makes it worse with every bug fixed.
Everyone feels it: Your code is going down the drain.

How can we break that vicious cycle?

If you’re stuck with a shit load of crappy code you have to stop the downward spiral. The recipe is simple, but, while it will get you into the right direction, and it will lead you a path of evolutinary code and culture improvements, it’s not a quick fix nor a silver bullet. However, it’s your only chance. There are just three steps:

Stop. Reflect. Adjust.

Stop

First of all, you’ve got to realize you can’t go on like this. You’ve got to stop the line. This sounds very counter intuitive given the fact that you’re late already. But, only by stopping can start improving.

Reflect

Get everyone into one room. Ask them for noteworthy events within the last week. What did they experience? What got in their way? Make it clear this is not a blaming game, just a fact-finding mission. If you’ve collected enough, give everyone five points to distribute among the issues: Let them put as many of their five points on any issue they think should be addressed first. With this exercise, you get a shared understanding of the trouble spots and a first assessment of what’s worst. This is your input for the next step.

Adapt

Take the one issue which got the majority of the rating points in the reflection meeting. Make its resolution top priority for the coming week. This will signal to your team that you take their problems seriously, and you won’t continue repeating the same mistake. Address their concerns and show them how to get better – one step at a time.

Repeat

Repeat the reflect and adapt steps every week. Make sure, you address the worst issue every week. Interestingly enough, in the first weeks most issues won’t be considered to be in the area of the team’s influence. As the team lead, you have to make sure to get them resolved. Over time, however, the team will become more self confident and tackle more and more issues on their own. Now you’ve created an upward spiral where you get better and faster every week.

Have you ever experienced similar situations? How did you deal with them? Let us know in the comments below!

Other posts:

• Stop Being Busy. Get Productive! photo credit: striatic You are busy. Your task list is growing so fast that if you wanted to print it out you’d have to use...
• Dump your issue tracking system – get agile! It’s a sad reality. Most IT departments are drowning in a sea of unresolved trouble tickets. Every staff member does her best to keep afloat...
• The Importance Of Having Seamless Ticket Flow I don’t know about you, but I want to organize my day’s work as it suits me. Sure, there are the inescapable meetings, which block...