Canonical Voices

Posts tagged with 'project management'

Steph Wilson

Meet the newest member of the Design Team, project manager Davide Casa. He will be working with the Platform Team to keep us all in check and working towards our goals. I sat down with him to discuss his background, what he thinks makes a good project manager and what his first week was like at Canonical (spoiler alert – he survived it).


You can read Davide’s blog here, and reach out to him on Github and Twitter with @davidedc.

Tell us a bit about your background?

My background is in Computer Science (I did a 5 year degree). I also studied for an MBA in London.

Computer science is a passion of mine. I like to keep up to date with latest trends and play with programming languages. However, I never got paid for it, so it’s more like a hobby now to scratch an artistic itch. I often get asked in interviews: “why aren’t you a coder then?” The simple answer is that it just didn’t happen. I got my first job as a business analyst, which then developed into project management.

What do you think makes a good project manager?

I think the soft skills are incredibly relevant and crucial to the role. For example: gathering what the team’s previous experience of project management was, and what they expect from you, and how deeply and quickly you can change things.

Is project management perceived as a service or is there a practise of ‘thought leadership’?

In tech companies it varies. I’ve worked in Vodafone as a PM and you felt there was a possibility to practice a “thought leadership”, because it is such a huge company and things have to be dealt with in large cycles. Components and designs have to be agreed on in batches, because you can’t hand-wave your way through 100s of changes across a dozen mission-critical modules, it would be too risky. In some other companies less so. We’ll see how it works here.

Apart from calendars, Kanban boards and post-it notes  – what else can be used to help teams collaborate smoothly?

Indeed one of the core values of Agile is “the team”. I think people underestimate the importance of cohesiveness in a team, e.g. how easy it is for people to step forward and make mistakes without fear. A cohesive team is something that is very precious and I think that’s a regularly underestimated. You can easily buy tools and licenses, which are “easy solutions” in a way. The PM should also help to improve the cohesiveness of a team, for example creating processes that people can rely on in order to avoid attrition, and resolve things. Also to avoid treating everything like a special case to help deal with things “proportionally”.

What brings you to the Open Source world?

I like coding, and to be good coder, one must read good code. With open source the first thing you do is look around to see what others are doing and then you start to tinker with it. It has almost never been relevant for me to release software without source.

Have you got any side projects you’re currently working on?

I dabble in livecoding, which is an exotic niche of people that do live visuals and sounds with code (see our post on Qtday 2016). I am also part of the Toplap collective which works a lot on those lines too.

I also dabble in creating an exotic desktop system that runs on the web. It’s inspired by the Squeak environment, where everything is an object and is modifiable and inspectable directly within the live system. Everything is draggable, droppable and composable. For example, for a menu pops up you can change any button, both the labelling or the function it performs, or take apart any button and put it anywhere else on the desktop or in any open window. It all happens via “direct manipulation”. Imagine a paint application where at any time while working you can “open” any button from the toolbar and change what the actual painting operation does (John Maeda made such a paint app actually).

The very first desktop systems all worked that way. There was no concept of a big app or “compile and run again”. Something like a text editor app would just be a text box providing functions. The functions are then embodied in buttons and stuck around the textbox, and voila, then you have your very own flavour of text editor brought to life. Also in these live systems most operations are orthogonal: you can assume you can rotate images, right? Hence by the same token you can rotate anything on the screen. A whole window for example, or text. Two rotating lines and a few labels become a clock. The user can combine simple widgets together to make their own apps on the fly!

What was the most interesting thing you’ve learned in your first week here?

I learned a lot and I suspect that will never stop. The bread and butter here is strategy and design, which in other companies is only just a small area of work. Here it is the core of everything! So it’ll be interesting to see how this ‘strategy’ works. And how the big thinking starts with the visuals or UX in mind, and from that how it steers the whole platform. An exciting example of this can be seen in the Ubuntu Convergence story.

That’s the essence of open source I guess…

Indeed. And the fact that anti-features such as DRM, banners, bloatware, compulsory registrations and basic compilers that need 4GB of installation never live long in it. It’s our desktop after all, is it not?

Read more
Daniel Holbach

I’m very proud of what quite a number of teams achieved together last week. On Friday we announced the opening of the Ubuntu Touch software store. Just to quickly illustrate who was all responsible for this, here’s a list of the teams/projects involved:

  • Click itself – the format in which we ship apps.
  • Community team – helped with coordination of whole app story and project management.
  • Design team – putting together plans for how the experience should be.
  • *dations teams (Foundations, Phonedations), getting everything in the phone image, helping with the integration of the download service.
  • IS, setting up servers and help with deployment.
  • Online Services (Client) – writing the code for the whole app management experience on the client side.
  • Online Services (Server) – putting together the software store, review capabilities, etc.
  • SDK team – teaching QtCreator about Ubuntu apps and click packages.
  • Security team – defining and putting together our app confinement strategy.
  • Unity teams – integration of the app scope and other bits and pieces.
  • Lots of others (feedback, code review, encouragement, etc).

I’m sure I forgot to mention a team or two, but it’s at least worth trying to point out who all was responsible for this. The security confinement, the SDK and Unity have obviously been under heavy development for a longer time already, some plans existed before, but the vast majority of what you can see now was planned three months ago. So with this in mind, I feel everybody involved in this project deserves a big hug and some words of praise. This is a great achievement.

There are definitely a bunch of things still left to be done, but now we have:

  • a good app development experience,
  • a software store you can easily submit apps to,
  • a mobile OS where you can easily install apps.

Go (virtual) team! :-D

Screenshot stolen from Michael Hall (

This project was my first try at project managing and I thoroughly enjoyed it. Hundreds of emails, lots of meetings and discussions on IRC made the software store a reality. Everybody worked very hard to bring this to fruition and it was a fantastic feeling to be able to download some new apps on my Nexus 7 today.

As I said above: there is still quite a few things we’ve got to do, so the coming weeks are going to bring us a lot of great stuff: purchases, some automation of the app review, easy app updates, apps with compiled code and much much more. Stay tuned and keep publishing your great apps!

Big hugs to the extended team, you are all heroes and thanks for the great time with you!

Read more
Victor Palau

I had a CR-48 Chromebook for a while, which has recently fallen in disuse. While I have never being totally convinced about Chrome OS being a polished, well designed, interface that simplifies the “always connected” user journey that Google was envisioning, I liked the concept.

Now I am reading in ArsTechnica that Chrome OS is getting a brand new look, that is … basically.. well, not new. While I am sure there are many technical advantages of a fully hardware accelerated windows managers, my issue is with the [lack of] concept.

Google has spent much energy convincing users that they do not need to have local apps, that they can do everything in the cloud and that the portal to this experience is Chrome. Having an OS which the only application that could possibly run, and at full screen, was the browser was a controversial but bold move. More over, it really hit home the user experience they were targeting.

This new UI seems to be sending the opposite message. It seems to be saying: “OK, we were wrong.. but  maybe if we make Chrome OS look more like windows you will like it better?”. Is that really the message? Well if you give me an app launcher in a desktop, I am bound to ask for local apps. If you give me off-line sync for Google apps, I am bound to ask for local apps.

I fear Google is paving the road to [windows vista] hell with good window manager intentions. I am primary an Ubuntu user, and what I like about it is that every single release over the last few years has continue to build on a design concept. Every new release is closely wrap on a consistent user message. Take as an example the HUD introduced in 12.04: it is new and different, but somehow it feels like it always belonged in Unity.

I am bought into the Ubuntu user experience, and I am excited to see what a new release will bring. If I had bought into the Chrome OS experience, I think I will be asking for a refund.

Anyway, I am looking forward to the new Chrome OS UI being available for the CR-48. Maybe I will change my mind once I get my hands on it.

Read more
Victor Palau

I have commented several times on the 2-weekly cadence that we follow at the certification team, but I haven’t gone into much detail on our 6 monthly cycle. We have just completed the Natty cycle (normally release date + 2/3 weeks) and we are about to start our Oneiric one.

6 monthly cycles help to plan achieving longer goals that drive the user stories implemented by the team in each iteration/sprint. During Natty, we had a loose coupling between these two.  I regularly (once a month) reviewed the progress of the Natty backlog and made sure that nothing was falling through the cracks. Despite the good completion rate in Natty, it was more of a case of the user stories forming the Blueprints (6 monthly requirements) than the other way around.

For Oneiric, the certification team went into UDS-O with much better defined blueprints. This has not only resulted in better sessions, but also on well defined backlog. Clearly, there is no much point trying to tight down what we will be doing in 4/5 months, so user stories towards the end of the cycle are vague and fairly large.  User stories for the next 2 months are better understood and described.

We have been collecting velocity data for the last few months, so by asking the team to roughly size new stories and review the sizes for the “next_iteration+1″, I hope to be able to build a burn up/down chart over the next few weeks! I will keep you posted.

Read more