Scrum

Scrum vs. Kanban vs. Scrumban: Team Members, Meetings, and Roles

2013/05/21 by Dalia Lasaite in Agile, Kanban, Scrum, Scrumban | Leave a comment

We recently talked about the processes and the structure of agile methodologies, but at the center of the implementation of these methodologies is the team. Therefore, this time we review the differences of the three methodologies – Scrum, Kanban, and Scrumban – with respect to the team members, roles, and interactions.

Roles

In Scrum, there are several roles: Product Owner, Scrum Master, and the team itself.

Product owner is responsible for the product vision and priorities – and she is the person who decides which items or user stories are the most important to work on and complete in a sprint. The Scrum Master ensures that the Scrum process is going as agreed, removes any issues in the process and provides leadership with regards to the way it works. The team actually builds and implements the product.

Kanban and Scrumban do not have clearly defined roles for team members – so the roles may wary and it is up to the team whether any roles should be used at all.

Team members

Generally, Scrum is a methodology where the team members can be cross-functional. While there is no precise definition on what is cross-functional, the team as a whole should have the skills to complete the work within each iteration. As Scrum is time-limited methodology, it often happens that some team members need to work on several types of tasks in order to complete the work during the sprint – but as mentioned above, the methodology does not explicitly define what is cross-functional.

On the other hand, in Kanban the team members’ specialization or preference to tasks is preferred. Since the work is limited by work in progress, anyone with items in backlog can start working on another item as soon as they are finished with their own – which allows for specialization of the team members.

In Scrumban, the team can be either specialized or cross-functional.

Ownership

The key difference in ownership is that while Scrum is a team-oriented methodology and is owned by a team, Kanban and Scrumban support multiple team ownership. So, for example in Kanban, different stages of the process can be owned by several teams – such as development team, quality assurance team, and others.

Meetings

Several meetings are used in Scrum. They are sprint planning, daily scrum, and retrospective. The sprint planning meeting involves pulling items from the backlog into the sprint and prioritizing the user stories that will be carried out during the sprint.

The daily scrum or stand-up meeting includes a short daily meeting where each member of the team briefly shares what they are working on. The daily scrum typically lasts no more than 15 minutes.

The retrospective reviews the teams progress after each sprint, and discusses ways to improve the process.

In Kanban and Scrumban, meetings are optional. They can be avoided entirely, or agreed upon on a regular or on demand basis.

Short Kaizen events can be done from time to time in order to focus. Kaizen events are defined as short, breakthrough events where employees from several departments or teams examine a problem, propose solutions and implement changes. These events can be used in Kanban and Scrumban from time to time, in order to solve issues or improve the process of work.

Continuous improvement

The approach to continuous improvement prescribes how the team makes changes and improves their work process based on the issues they encounter.

Scrum achieves continuous improvement by using a sprint retrospective meeting after the sprint, and discussing the outstanding issues as well as improvements to the way to work.

In Kanban and Scrumban, continuous improvement is optional. However, as mentioned above, short Kaizen events can be used for this purpose as well.

 

The next time we will be reviewing a few miscellaneous differences between Scrum, Kanban, and Scrumban – including boards, rules, and who should use which methodology.

Read More

Scrum vs. Kanban vs. Scrumban: Planning, Estimation, and Performance Metrics

2013/05/02 by Dalia Lasaite in Agile, Kanban, Scrum, Scrumban | Leave a comment

In the previous blog post we reviewed the basic differences of Scrum, Kanban and Scrumban. In this blog post we dwell deeper and look into how the tasks are planned in each of the methodologies, as well as how is the performance measured in Scrum, Kanban and Scrumban.

Planning routines 

Planning routines define how the work is planned during the process and when the planning sessions take place.

In Scrum, the product backlog items are pulled into to each sprint. Planning is regular and occurs in the beginning of each sprint.

Kanban, on the other hand, does not prescribe a precise planning routine. Therefore, the teams can choose to plan when they run out of backlog items (demand planning) or when the code or version is released (release / iteration planning). Scrumban, similarly to Kanban, uses planning when the backlog items are completed – and then plans for the new items.

Estimation

Estimation is the process of determining the time required to finish each item.

In Scrum, the estimation of the time required for the items to be completed is typically done before the start of the sprint. Generally, the items have to be shorter than the time allocated for the time-boxed iteration. If they do not, they are usually split into smaller items.

In Kanban and Scrumban, estimation of the item duration is optional. After an item is complete, the team members simply pull the next item from the backlog and proceed with implementing it. Some teams still choose to carry out the estimation in order to have more predictability. Alternative approach to achieve predictability is to make sure that each of the items is of the same size, and therefore can be completed in the same amount of time.

New items in iteration

Agile methodologies also define how new items are added to the iteration.

In Scrum, it is forbidden to add new items during the sprint. Therefore, if there is a new item, it has to wait until the regular planning meeting in order to be included into the workflow. If the project requires dealing with incoming items (e.g. support), it is generally advised to use Kanban or waive this requirement in Scrum.

Kanban and Scrumban allow adding new items whenever there is enough capacity in the queue. Therefore, Kanban and Scrumban are very useful for functions with continuous flow of new items.

Performance metrics

The key performance metric in Scrum is the burndown chart. Burndown chart shows how much work within each iteration remains at each day or each hour of a sprint. A burndown chart example is provided below.

The blue line represents a typical burndown on an hourly basis, compared to the ideal burndown (the dotted line). The green line represents cumulative value that is added each hour. The key goal of the burndown diagram is to show whether the team is behind or ahead the schedule within each sprint.

In Kanban, the performance is measured via the cumulative flow diagrams and by estimating lead cycle time. Cumulative flow diagram shows the total items that are in progress, as well as the time it takes to complete them. Average lead cycle time estimation shows how much time, on average, does it take to complete one item. An example of the lead cycle time estimation is below. Similarly to Kanban, Scrumban also uses average lead time as its key metric.

It is important to note, however, that Scrum, Kanban, and Scrumban are just tools that are recommended and there is a variety of approaches of implementing the recommendations, depending on the team’s specifics. In the next blog post we will review the team requirements for Scrum, Kanban and Scrumban, including roles, meetings, ownership and continuous improvement.

Read More

Scrum vs. Kanban vs. Scrumban: Iterations, Work Routines, and Scope Limits

2013/04/22 by Dalia Lasaite in Agile, Kanban, Scrum, Scrumban | Leave a comment

As agile methodologies become more popular, there sometimes is confusion on what exactly they mean and how they differ. In this blog post we compare three methodologies and show how they differ across several dimensions.

While there are some other agile approaches as well, we compare here the most common ones – Scrum, Kanban, and Scrumban – as these are the ones that are used the most commonly.

Scrum vs Kanban vs Scrumban: Agile Task Board

 

ITERATIONS

Iterations are predefined timeframes, during which a portion of work or a task is done. In Scrum, the teams typically work with 1-4 week sprints, during which the tasks are done before a deadline.

Kanban, on the other hand, does not have predefined iterations. Instead, teams work continuously, using releases shorter than one week, or bigger iterations like goals.

Scrumban combines the two approaches into one. Continuous work is used along with short iterations for planning, and longer cycles are used for release. 

WORK ROUTINES

Work routines define how the tasks are distributed among the team members. The push principle implies that tasks are assigned to the team members in a centralized way. The pull principle means that the tasks are “pulled” or chosen by team members themselves.

Scrum, Kanban and Scrumban are all agile methodologies, which use pull principle – whereby the team members choose the tasks they would like to work on. In Scrum, the tasks are chosen early by the team members. In every sprint, the tasks are chosen – or bound – by the team members before the sprint starts.

Kanban and Scrumban both use late binding – whereby the tasks are chosen during the work process. Once the current task is finished, the team members are free to choose further tasks they would like to work on. This is called late binding of tasks to the team members.

SCOPE LIMITS

Scope limits define how the workload is limited in the agile methodologies.

In Scrum, the workload is limited with each sprint. The tasks cannot exceed the amount of work that can be done in one sprint. If the task cannot be completed within a sprint, it is typically split into smaller tasks, that can then fit within a sprint.

In Kanban and Scrumban, the work in progress limits define the scope of work. Therefore, if the maximum number of tasks in progress is three, the team members cannot work on more tasks than three at the same time.

In the next blog post we will cover planning routines, estimation, and performance metrics for each of these methodologies.

Read More

Busyflow Co-Founder & CEO: Our Development Process is “Chaotic Agile”

2013/02/05 by Dalia Lasaite in Agile, Extreme Programming, Lean, Scrum, Start-ups, Test-Driven Development | Leave a comment

BusyFlow integrates cloud applications into one dashboard, helping teams collaborate and work together more efficiently. The company works with numerous APIs, codes in Python and has just launched their Android app. We are talking with their CEO Jaro Satkevic on their development process – and how they adjusted it to make developers happier.

Tell us about yourself. What does your company do and what is your role?

I am the CEO and co-founder of BusyFlow. Busy Flow is app that integrates different productivity and collaboration tools, like Dropbox, Trello, BaseCamp, Google Drive and other tools into one workspace where people can see the changes, act on them and collaborate together. I am a co-founder and I manage the developer team.

Are you a developer yourself?

Yes, I am. But at the moment most of the time I am doing other activities in our start-up.

Can you tell us how big is your team? How many people and how is it organised?

At the moment we have four people. We also have two more people related to our company – a designer and an iOS developer – who help us when needed. So actually it is me and three other developers in our team.

Can you tell us about your development process? How does it typically work?

Read More

How Bentley Systems Uses Project-Based Approach to Stay Agile

2013/01/18 by Dalia Lasaite in Agile, Enterprise, Scrum | Leave a comment

Bentley Systems is the global leader dedicated to providing architects, engineers, geospatial professionals, constructors, and owner-operators with comprehensive software solutions for sustaining infrastructure. Founded in 1984, Bentley has more than 3,000 colleagues in 50 countries, more than $500 million in annual revenues, and since 2003 has invested more than $1 billion in research, development, and acquisitions. We are very happy to talk with Justas Belevičius, software development manager at Bentley based in Melbourne, Australia, about their development process.

Tell us about yourself. What does your company do and what is your role?

Bentley Systems is one of the leading software providers for the world’s infrastructure. Our comprehensive portfolio of software products and services consists of hundreds of globally recognized names, including MicroStation, ProjectWise and AssetWise as our flagship products and technology platforms.

I take a role of Software Development Manager in Structural Group department where I currently lead development of Bentley’s Integrated Structural Modeling (ISM) software platform. ISM allows to integrate, i.e. connect different stages of structural project workflow. Simply speaking, ISM can be perceived as an intelligent versioning control system for structural data, though it is only a part of its functionality.

Can you tell us about the development team? How many people do you have and how is it organized?

Sure. Bentley Systems is currently has more than 3,000 employees and over a thousand of them are directly working on research & development. Most of our products are actively developed and maintained for multiple years, however development itself is organized in small short-term chunks – projects. The end result of the project is typically a new version of the shared technology, product or a new product. Teams working on most projects are less than 20 people. The work in each project is further split into iterations and organized adhering to SCRUM principles to some extent.

Read More

Never Ending Fight: Physical Task Boards VS Kanban & Scrum Software

2013/01/16 by Dovile in Agile, Kanban, Scrum | Leave a comment

Many Agile, Scrum, and Kanban followers do not recommend using a tool. At least at the beginning – they say, meaning that there are enough changes when adopting new way of working and starting using a tool would make things even more difficult or even lead to a failure. Also they usually add that software is more complex and you have to work with it instead of doing real work. However, I would like to disagree. Conventional Scrum or Kanban boards may seem very simple at the first sight and not so easy to manage when you really try do make it work for your team.

Physical task boards

  • Scrum  and Kanban task boards bring visibility.
  • All the tasks are placed in corresponding columns, what makes an overview of the current situation – what is planned, what is the status of tasks that are being worked on, and what is already completed.
  • The configuration of the task board is very flexible and easy to adapt to any team.

These statements are really attractive,  so you get excited about how easy it can be to improve. You get some tape, markers, sticky notes and start with your Scrum or Kanban board. And here is where your illusions about flexible configuration and transparency of a physical board fade away.

Scrum board

Althoug a traditional Scrum board has only three columns – To do, Doing, Done – you may need to split DOING into more columns to show more specific stages a task goes through. Task cards contain quite a big amount of information – title, description, priority, estimation, assignment – so you need to make the columns big enough to contain several tasks at once. For this reason, you need quite a big white board. And this leads to the result – instead of bringing visibility into the process, a big Scrum board with many tasks cards becomes just a big colorful wall which is difficult to understand.

Of course, you may not face all these troubles on the first day or week. It is more likely that you will start with a simple task board and everything will work well at the beginning. But later on, you will face the need to improve the task board, or your team will grow. And then you‘ll see that a Scrum board is not the best solution.

Here is how your Scrum board will look. No matter how hard you try to keep the physical board neat and tidy, those hand filled task cards still remind a colourful decoration. This Scrum board surelly enlivens the team’s room, but I does it really perform its intended purpose?

Read More

Development at LinkedIn: Build Your Process In A Way Where You Can Change It Easily

2013/01/07 by Dalia Lasaite in Agile, Scrum | Leave a comment

LinkedIn is a company that needs no introduction – with over 187 million users in more than 200 countries, it is one of the most important internet companies on the planet. Today we are very lucky to speak with Jim Brikman, staff software engineer at LinkedIn, about their development process.

Can you tell us about yourself? What is your role at LinkedIn and what do you do?

Sure. I have been at LinkedIn for a bit over three years. I am a software engineer and have worked on a number of teams, including the monetization team and the platform team. My current job is on our Presentation Infrastructure team. We are developing the infrastructure and the technologies that we actually use to build the site – the rest of the company builds and runs their code on top of our code. I also run several other programs at LinkedIn – the monthly HackDays, our [in]cubator program, open source, and the engineering blog.

Sounds good. Can you tell us a bit about the development team at LinkedIn? How many engineers do you have and how is it organized?

Good question. The company has grown enormously since I have joined – I don’t know the exact number, but it’s probably between 500-700 people in technology. The exact organization varies often as technologies and requirements evolve, but at a high level, you can break it down into roughly 6 groups. The Applications & Mobile Applications teams work on the user-facing products, features, and APIs. The Systems and Infrastructure team defines and builds the processing, storage, caching, and distributed systems solutions that are used by the Apps teams to serve and scale the site. The Front-End Engineering team works on the client-side pieces, including JavaScript, CSS, and HTML. The Tools Team builds the internal tools and processes, including how we store code, the build system, automated deployment, monitoring, and so on. The Data Team works on how we make sense of our huge data sets, including search, data mining, and machine learning. Finally, the Test Team figures out how to make our code robust, bug-free, and performant.

Read More

Screach CTO: Do Not Be Afraid To Change Things

2012/12/26 by Dalia Lasaite in Lean, Scrum, Start-ups | Leave a comment

Screach is an award-winning Newcastle-based company that delivers interactive experiences between digital screens and mobile phones, such as a trivia quiz in a pub or an awesome mobile-controlled game on a digital billboard. We are speaking today with their CTO David Challener on how the team manages its development process.

Tell us about yourself. What does Screach do and what is your role?

Screach delivers interactive experiences with digital screens. The easiest example is the following: Imagine an interactive quiz running on a screen in a pub, and people using a mobile app to answer the questions in real time. We set up that interactivity between the mobile app that we call Screach, and the digital screen. We have done quizzes, crowd voting and interactive games, to name but a few. We did one experience for insurance firm SwiftCover in which a course was shown on a big screen, and passers-by were challenged to steer a car along it using their phones as a joypad.
We’ve also built a hardware product called ScreachTV, which allows venues like bars and restaurants to put targeted, relevant and engaging smartphone-compatible experiences such as quizzes, messages, offers and games on their TVs. They’re in around 100 UK venues already as well as some in New York, and that’s increasing all the time.

And you are the CTO of the company, right?

Yes. So anything technical basically goes through me and my team.

Read More

Ovelin CEO: Take Time To Plan Before Acting

2012/12/17 by Dalia Lasaite in Kanban, Scrum, Start-ups | Leave a comment

Helsinki-based startup Ovelin has developed two wildly successful guitar-learning games – becoming #1 music game in 34 countries with their games WildChords, GuitarBots, and guitar tuner app GuitarTuna. We are talking to their CEO Christoph Thür on how they organize their development process.

Tell us about yourself. What does your company do and what is your role?
I am the co-founder and CEO of Ovelin. We are making learning to play the guitar fun and motivating with computer games. You can play our games with a real guitar on your laptop, and you do not need any kind of special guitar or special equipment. The microphone on your device listens to what you play and then the game gives you real-time feedback if you do well or not – just like a guitar teacher would. The game is packaged in a fun way, so it is easy to approach, simple and step-by-step – and if you do well, you unlock harder levels.

How big is your development team? And how is it organized?
We are eight people on the development side. We have a visual artist, a 3D artist, an audio signal-processing expert, the lead programmer, and two additional programmers – one of which works on the game side and the other one – on the server side. We also have one person who is making the game content – the exercises, the tutorial material and the music. And we have a musician.

The team is based in Helsinki, except the audio signal-processing and the music guys, who are based in Tampere. They are coming here every week for one or two days, and then we have the whole team together.

Read More

Archify’s CTO: Do Not Overmanage Your Project

2012/12/10 by Dalia Lasaite in Agile, Lean, Scrum, Start-ups | Leave a comment

Today we are talking to Archify - the providers of an awesome personal archiving service – and their CTO Gerald Bäck. The company is based in Berlin, but their team is distributed across the whole Europe – and Gerald shares how they manage their development process.

Tell us about yourself. What does your company do?

I am Gerald, the CTO of Archify. Archify is a company that helps you find things again you have already seen. Let’s say you have read an article on a website, or saw a video somewhere – if you do not exactly remember where you have seen it, it is often very complicated to find it again. Archify can help you with that. We are recording and archiving every website you browse with a screenshot and the full text, and we are also archiving every update in your social stream, including your friends’ updates on Facebook and Twitter. Archify captures all that and makes it searchable for you.

Great. Can you tell us about your development team? How big is it and how is it organized?

Currently we are a team of four – and it is spread all over Europe. Max and me are the founders of the company – and we are based in Berlin. We both still work as developers, as we really enjoy developing. We also have another guy who does front end development and design – he is currently living in Portugal and will join us in Berlin next year. And we have one more developer in Ukraine. Not really a very centralized team.

Read More