Archives for January2013

Eylean showcase

Hello everyone.

Finally we have decided to make series of short demos of Eylean board in action, showing some basic features and our so focused user experience. As these are just few starter demos, do not worry, many more will come. All the suggestions and requests are welcome. All agile methodology users may benefit from these videos as they will find out key structure elements of the board.


User assignment

Flexible workspace

Task details

Subtasks and structure



Read More

6 Tips for Efficient Collaboration of Distributed Teams

Photo Credit: Giorgio Montersino via Compfight cc

When you ask companies about their biggest challenges, working with distributed teams is frequently among the top answers. Working in a distributed team often makes it difficult to communicate and collaborate efficiently. A number of unexpected challenges arise, including making sure that everyone in the team is involved, up-to-date on the work, motivated – and that the important details are not missed in communication nuances.

At the same time, more and more companies choose to organize their work remotely – either to lower their costs, offer their employees flexibility, or to access talented professionals who might be located elsewhere. Here are six ideas how to make sure that a distributed team works:

1. Know the coworkers in person

Communication and collaboration is much more effective between people who know each other in person. In the best case, a distributed team should be formed from people who have worked together in a collocated team previously. If this cannot be done, team members should at least have a possibility to meet others in person when they join the team. While sometimes costly, this investment is worthwhile. People are the most important part of the team, and if they do not feel united, any methodologies, tools and processes will not help.

Read More

How Bentley Systems Uses Project-Based Approach to Stay Agile

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

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

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