Build Stuff

What pictures do we have in our minds when we think about effective software development? Code quality, continuous integration, automated testing or what have you. While I’m a big fan of all of them I would challenge the concept that these are the only, or the most important, areas which software developers or quality engineers should focus on.
Building software is a collective effort of people working in different roles and this should always be a starting point to a discussion about effectiveness. The missing piece may be craftsmanship but it may also be poor communication or handful of dull chores that few would fancy doing. How can we tell? What should we use as guidance? And, at the end of the day, how to build software effectively?
It all starts with learning what makes a team effective as the notion of effectiveness we have is usually flawed. Understanding how the work gets done end-to-end is often a missing piece as well and even an effective team doesn’t stand a chance against dysfunctional process.
The session will discuss the traits of effective teams as well as show how to use elements of Kanban to improve efficiency of software development teams. Surprisingly enough it has pretty little to do with engineering issues.

Can you maintain agile engineering practices with a distributed team?Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. In order to promote agile engineering practices, he uses remote pair programming to connect with teams halfway across the world.In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach.After seeing this talk, the audience should be able to remotely pair with members of their distributed team. They will also get a lot of tips on how to use pair programming effectively in both local and remote settings.

Building a software system is in fact a learning process. Unfortunately we don’t know much about learning even if we’ve been doing it for all our lives. A different approach on discovery of domain complexity could help our teams to understand, frame and master the problem and solution space, enhancing collaboration with the domain experts and the stakeholders and bringing some fun.

This implies breaking some rules and assumptions, doing something unconventional, and occasionally feeling stupid. Are you ready for it?

What kind of development model or process do you use, when everyone dislikes processes? More so, how do you do that when the team is very distributed, working from offices or homes at dozens of places around the world? How do you let people just do thework, instead of worrying about reports, meetings or hierarchies?
I don't know the answer, but I do know what has (and has not) worked at Unity Technologies, all the way from 3 to 100+ developers. We don't have a name for our process, but it is fairly chaotic, random and always changing; with a goal of "as little rules as possible". Hence, Lightweight Chaos could be a name.