Free Software developers can be very critical: Every single line of code gets scrutinized, every design is reviewed by several often opinionated people. Even the way communities are supposed to work sometimes gets restricted. Sometimes a simple Thank You can make all the difference for any contributor or committer.
FSFE proposed a really nice campaign: Celebrate the “I love Free Software” - Day on February 14th. In the hope that some of the readers of this blog actively develop or contribute to free software projects - this is a thank you for you! It’s your contributions that make all the difference - be it code, documentation, help for users or code reviews.
As I keep searching for those URLs over and over again linking them here. When running into JVM heap issues (an out of memory exception is a pretty sure sign, so can be the program getting slower and slower over time) there’s a few things you can do for analysis:
Start with telling the effected JVM process to output some statistics on heap layout as well as thread state by sending it a SIGQUIT (if you want to use the number instead - it’s 3 - avoid typing 9 instead ).
More detailed insight is available via jConsole - remote setup can be a bit tricky but is well doable and worth the effort as it gives much more detail on what is running and how memory consumption really looks like.
For an detailed analysis take a heap dump with either jmap, jConsole or by starting the process with the JVM option -XX:+HeapDumpOnOutOfMemoryError. Look at it either with jhat or the IBM heap analyzer. Also netbeans offers nice support for searching for memory leaks.
c-base - 8p.m. on a Monday evening - the room is packed (and pretty cloudy as well): Time for Dorkbot, a short series of talks on “People doing strange things with electricity” hosted by Frank Rieger.
First talk up on stage was Gismo on Raumfahrtagentur - a Berlin maker-space located in Wedding. Originating from the presenter’s interest in electrical bikes a group of ten people interested in hardware hacking got together. Projects include but are not limited to 3D printing, 3D scanning, textile hacking, a collaborative podcast. Essentially the idea is to provide room and infrastructure to be used collaboratively by a group of members. From an organisational point of view the group is incorporated as a GmbH - however none of the projects is mainly targeted to commercialization: It’s main target group are hobbyists, researchers and open hardware/software people. If interested: Each Monday evening there is a “Sunday of the Kosmonauts” where externals are invited to come visit.
Second talk was on the project Drinkenlights (Klackerlaken) - a way for children to learn the basics of electronics without any soldering (hardware available for three Euros max). Experiences made with giving the ingredients for creating these toys to children of varying ages were interesting: From kids of about five years playing around up to ten/eleven year olds that when in school seemingly had to re-learn being creative without being given much direction or instruction on the task at hand.
In the third talk Martin Kaltenbrunner introduced his Tworse Key - a nice symbiosis of old technology (a morse key) and new media (Twitter). Essentially built on top of an Arduino Ethernet board it made it possible to turn morse messages into Tweets. Martin also gave a brief overview of related art projects and briefly touched upon the changes that open source and open hardware bring to art: There are projects that open all design and source code to the public to benefit from a wider distribution channel (without having to actually produce anything), working on designs in a collaborative way and get improvements back to the original project. All of these form a stark contrast to the existing idea of having one single author whose contribution is to build a physical object that is then presented in exhibitions - providing both, new possibilities and new challenges to artists.
In the last presentation Milosch introduced his new project ETIB whose goal it is to bring hardware hacking geeks together with textile geeks to work on integrating circuits into clothes.
If you are interested in hacking spaces in general and what is happening in that direction in Berlin, mark this Friday in your calendar: c-base will be hosting a Hackerspace meetup - so if you want to know how hackerspaces work or want to create one yourself, this event might be interesting to you.
After quite some time off I went to the Scrumtisch Berlin. The event was incredibly well visited - roughly 50 people filled the upper floor at Cafe Hundertwasser. Today’s event was organised such that participants first collected discussion topics, prioritised them together and then discussed the top three items in a timebox of 15 minutes each.
Topics collected were:
Best tricks to make teams self organised (20 votes)
What is QA doing fulltime in a team (13 votes)
Ops and planning in a team (15 votes)
PO disappears and takes backlog and vision with him - what now? (7 votes)
Working with non-Software teams (17 votes)
Pimp up my retrospective (12 votes)
Multiple teams on one projects and vice versa (4 votes)
IBM doing Scrum/ massive Scrum (9 votes)
Feature knowledge vs market knowledge - what is more important in a PO if you have to choose due to people constraints (9 votes)
How to convince a team to do more (3 votes)
Why is agile good (10 votes)
Compared to previous meetings quite some topics repeat. About half of the attendees were there for the first time - so it seems there is a common set of questions people usually run into when rolling out Scrum.
Self organising teams
Seems like this is one of the most common questions run into when rolling out Scrum - how to really get to self organising teams. The question can be answered from two positions: What are the pre-requisites it takes to enable teams to become self organising? How to actually transform teams that are used to a command and control structure and are reluctant to transform?
The discussion, mainly led by Andrea Provaglio, CSM trainer focussed mainly on the first part of the question. Even when limiting discussion that way, the answer will still depend heavily on the organisation structure, number of management levels, team sizes.
Marion made the topic a bit more concrete: Given the flexible vacation planning approach of Netflix, her question was whether that sort of loose approach could work in a typical German company (after all we have 30 instead of <20 vacation days, we have fixed holidays, she as a C?O of course wants to avoid customers being left alone when the whole team is on vacation.) Andrea re-phrased agility a bit here. His proposal was to not allow people to take their time off just anytime but to give them the freedom to figure out when to take time off. He identified five principles for leadership:
Clearly setting a goal (in that case: Everyone needs to have a vacation plan at a given date.)
Provide the team with all resources, information and with the environment they need to accomplish their task.
Define constraints (”there must be at least one guy in the office on any given working day”)
Check back regularly
Make yourself available to answer any questions
The discussion on teams reluctant to adopt self organisation was separated out and deferred. His point was mainly about enabling and encouraging self organisation. Enforcing self organisation however is not possible.
Scrum in non-Software teams
Though phrased very broadly the topic quickly turned into a “how to do Scrum for hardware” discussion. Main problem here is that the further down you go the longer design generally takes. Even just routing lines on one decently sized circuit board can take several weeks. Mainly three possible ways out of the problem emerged from the discussion:
Loosening the definition of done - “potentially shipable” may not mean sellable or even really shipable. I don’t think one should go down that slippery path. Only by actually shipping can I get the feedback I need to improve my design. So instead of loosening the definition of done we should instead start thinking about ways to get faster feedback, reduce risk and introduce shorter iterations.
Another way is to look for ways to reduce iteration length, even though we might not get down to software release cycles, and align releases such that integration can happen earlier.
The third way out could be to realize that maybe Scrum does not quite fit that way of working and use a different process instead that still provides the transparency and fast feedback that is needed (think Kanban).
Overall the most important result of the discussion was that within 15min discussion the issues cannot be solved. After all the solution will depend on what exactly you are working on, who your suppliers are and what your team looks like. Most important is to recognize that there is a problem and to work on removing that impediment - most important is to identify issues and to improve your process.
Operations and planning in Scrum
The last question discussed involved operations and Scrum planning: Given a team that does software development but is interrupted frequently with production issues - how should they work in a Scrum environment.
There are multiple facets to that problem: When it comes to deciding whether to deal with something immediately or not it makes sense to weigh size of the issue against amount of work it takes to resolve it. “Getting things done” states that the minimum size of an issue to deal with instantly is 2min of work. Issue with that is that the assumption of GTD was that issues flow into and inbox that is dealt is when there is time. In production environments however these issues usually trickle in instantly interrupting developers over and over again incurring a huge cost due to task switching.
One way out might be to have an event queue and assign developers (on a rotating basis) to deal with the issues and leave time for others to work in a focused way. Make sure to rotate frequently instead of by sprint - otherwise you run into the problem of making the team unstable thus delivering no stable amount of business value each sprint.
Another obvious way is to account for frequent interruptions and include a buffer for those in your plan. The most important benefit of that approach is to make the cost of this working mode clearly visible to management - leaving the decision how to deal with it up to them.
Other simple fixes include introducing some level of indirection between the actual developer and the customer raising the issue, documenting solutions as well as incoming issues for better visibility, introducing a single point of contact capable of prioritising.
Coming back to vanilla Scrum however there is one interesting observation to be made: The main contract with iterations is for developers to be able to work in a focused way. Instead of having their tasks switched each day they are promised a fixed period of time to solve a given set of stories. In the end a sprint is a compromise between what management may need (change their mind on what is important frequently) and what developers need (working on a set of defined tasks not interrupted by re-priorisation). If the assumption of focus does not longer hold true, Scrum might be the wrong model. If what needs to be done changes daily, Kanban again might be the better option. Still making sure that the cost of task switching is visible is vitally important.
To sum up a very interesting Scrumtisch - in particular as agile methods really seem to become more and more common also in Berlin. Speaking of challenges: As user groups grow sometimes their character changes as well, in particular when built around participation and discussion. It will be interesting to watch Scrumtisch deal with that growth. Maybe at some point splitting the audience and having separate breakout sessions might make sense. Admittedly I’d also love to know more on the background of the audience: How many are actually using Scrum in the trenches vs. teaching Scrum as coaches? How long have they been using Scrum? In what kind of organisation? Maybe a topic for next time.
Judging from the way some people become overly careful when discussing agile in general and Scrum in particular in my presence I seem to slowly have built up a reputation for being a strong proponent of these methods. Given the large number of flaky implementations as well as misunderstandings it seems to have become fashionable to blame Scrum for all badness and dismiss it altogether - up to the point where developers are proud to finally having abandoned Scrum completely - so that now they
can work in iterations,
accept new tasks only for upcoming but not for the current iteration,
develop in a test-driven way,
have daily sync meetings,
mark tasks done only when they are delivered to and accepted by the customer,
have regular “how to improve our work” meetings,
estimate tasks in story points and only plan for as much work per iteration as was done in the past iteration
… my personal take on that: Add in regular releases and you end up with a pretty decent scrum/agile implementation, no matter what your preferred name for it may be. Just for clarification: Though very often I write about what I call Scrum, I don’t use that particular method just because it is the latest fashion. It simply is a tool that has served me well on multiple occasions and given me working guidelines when I had no idea at all what software development in a professional setting should look like.
So where does all that friction with anything Scrum, agile, lean or whatever you call it come from? Recently I came across a blog post that jillesvangurp.com nicely identified some grave issues with current Scrum adoption. Unfortunately the blog post only lists the failures without going into a deeper analysis of the actual defects causing those failures.
First of all, lets assume as working hypothesis that Scrum in itself does not solve any issues in your organisation but is a great tool to uncover deficiencies. The natural conclusion should be to use it as a tool to discover problems, but search for solutions for these problems elsewhere.
With that hypothesis, lets discern the the issues discussed in the post above and assign them to one of three defect categories.
Category one: Issues with the team
Problem: You have a team of all-junior developers, or of all-mediocre developers.
Goal: Turn them into a high performing team.
Solution: Imagine you were not using Scrum at all, what would be the ideal solution? Well the obvious route probably is to re-adjust the team, add several seniors so that you end up with the right mix of people that have experience and share a vision - juniors than can learn and adapt what works from them.
Comparing that to our hypothesis: Scrum is all for short delivery cycles. You will uncover teams that perform badly much faster than in methods with longer iteration periods. So it should be reasonably simple to figure out teams that have a dysfunctional configuration. Changing that configuration however no longer is dictated by Scrum.
Category two: Bugs introduced during Scrum roll-out
The failures discussed in the blog post include people following Scrum mechanically: Only because your developers are moving post-it notes from left to right does not mean they are doing anything agile. It’s perfectly possible to do waterfall in Scrum. Whether that helps solve any of your issues is a different matter.
Instead of mechanically going through the process what is more important is to understand the reasons and goals of each of the pieces that form Scrum. To make a rather far fetched comparison:
When introducing Scrum without a deep understanding of why each piece is done, what you end up with is people following that process without understanding the meaning of each step. They end up mimicking behaviour without knowing the real world: To some extend seeing only the shadows of good development patterns without understanding the real items producing these shadows.
As a general rule: Understand why there is a retrospective meeting, remember why you need estimations, think about why there are daily stand-ups (instead of weekly meetings, instead of daily sit-togethers, instead of hourly stand-ups). Figure out why there is a product owner, what the role of a scrum master does. Pro-Tip: As soon as you really have understood Scrum, you don’t need a checklist of all meetings to hold for a successful iteration - they will just fit in naturally. If they don’t, you are probably missing an important piece of the puzzle - rather than rely on a pre-fabricated checklist, go bug your trainer or coach with questions to better understand the purpose of all the different bits and pieces.
One very grave bug on roll-out is the general believe that Scrum is equal to a little bit of fairy dust you spread over your teams and all problems will automatically be solved afterwards. It is not - it’s not a silver bullet, it’s not fairy dust, it’s no magic - such things exist in fairy tales but have been seen nowhere in the real world. According to our working hypothesis above however Scrum does something really magical: By shortening delivery cycles it introduces short feedback loops which make it very easy to uncover problems in your organisation way faster than people are able to cover them up and hide them. Finding a solution on the other hand is still up to you.
The last roll-out issue mentioned is that of crappy certification - current certification programs are designed such that the naive organisation may believe that after two days of training their employers will magically turn into super heroes. Guess what - as with any certification training is just the very first step. Actual understanding comes with experience. Compare that to learning to drive: Only because you managed to get a drivers license does not turn you into a formula one winner. Instead that requires a whole lot of training. Same applies for any Scrum Master or Product Owner.
Category three: Organisation specifics
All other issues with Scrum mentioned in the blog post are either specific to the broken structures in the organisation under investigation or due to general Scrum mis-conceptions. Leaving these aside here.
To sum up: Scrum to me is nothing but a term to summarize good, proven development practices. I don’t care how you name them - however having any one name that is well defined makes it way easier to communicate. Scrum is not silver bullet - it does not solve all the issues your organisation may have. However it is a very effective debugger uncovering the issues employees and managers are trying to cover up. If you know all those issues very precisely already or you are certain that you don’t have any, chances are you don’t need Scrum.
Yesterday Thilo invited me to attend an “Electronics 101″ workshop including an introduction to soldering that was scheduled to start at 7p.m. this evening at the offices of IN-Berlin e.V.. As part of my studies back in university I do have a little bit of background in Electronics, but never before had tried any serious soldering (apart from fixing one of our audio cables) so I thought, why not.
The workshop turned out to be a lot of fun: The organisers Mitch Altman and Jimmie Rodgers had brought several pre-packaged kits for people to work on. Quite a few of them based on Arduino so after putting them together you can actually continue having fun with writing little programs. After giving a brief but very well done, easy to understand introduction to digital electronics Mitch showed attendees how to use a soldering iron (make sure to check out his comic “soldering is easy” if you want to know more) and got everyone started. Both Jimmie and Mitch did a great job answering any upcoming questions, fixing issues and generally helping out with any problems. Even those that never used a soldering iron before quickly got up to speed and in the end went home with that nice experience of having built something that you cannot only program but can touch and hold in your hands.
I got myself a LoL shield (still to be done), and a Diavolino. Still missing is the FTDI TTL-232R cable for getting the device hooked up to our laptops and be able to re-program it (though most likely that will be easier to find than a >1G Ohm resistor Thilo is looking for to be able to calibrate his Geiger counter).
Results of my first session are below:
The board
First pins attached
Last pins attached
Also thanks to Sven Guckes organising and announcing this workshop on short notice. And thanks to Thilo for talking me into that.
Two: Everything around us can be represented and understood through numbers.
Three: If you graph the numbers of any system, patterns emerge. Therefore, there are patterns everywhere in nature.
The above is a quote from today’s “Hackers in movies” talk at 28c3 - which amongst others also showed a brief snippet of the movie Pi. For several years I stayed well away from that one famous Hackers’ conference in Berlin that takes place annually between Christmas and New Year. 23C3 was the last congress I attended until today. Though there were several fantastic talks and mean presentation quality was pretty good the standard deviation of talk quality was just too high for my taste. In addition due to limited room sizes with 4 tracks there were quite a few space issues.
In recent years much of that has changed: The maximum number of tickets is strictly enforced, there is an additional lounge area in a large tent next to the entrance, for the sake of having larger rooms the number of tracks was reduced to three. Streaming works for the most part making it possible for those who did not get one of the 3000 full conference tickets to follow the program from their preferred hacker space. In addition fem does an amazing job of recording, mastering, encoding and pushing videos online: Hacker Jeopardy - a show that wasn’t over until early Thursday morning (about 3a.m.?) - was up on Youtube at least on Thursday at 7a.m if not earlier.
Several nice geeks got me talked into joining the crowd briefly this evening for a the last three talks in “Saal 1″ depicted above: You cannot be in Berlin during 28c3 and not see the so-called “fnord Jahresrückblick” by Fefe and Frank Rieger, creators of the Alternativlos podcast.
Overall it is amazing to watch BCC being invaded by a large group of hackers. It’s fun to see quite a few of them on Alexanderplatz, watch people have fun with a TV B Gone in front of large electronics stores. It’s great to get to watch highly technical but also several political talks 4 days in a row from 11 a.m. until at least 2p.m. the following day that are being given by people who are very passionate about what they do and the projects they spend their time on.
If you are into tinkering, hacking, trying out sorting algorithms and generally having fun with technology make sure you check out the 28c3 Youtube channel. If you want to learn more on Hacker culture, mark the days between Christmas and New Year next year and attend 29c3 - don’t worry if you do not speak German - the majority of talks is in English, most of the ones that aren’t are being translated on the fly by volunteers. If you are good at translations, feel free to volunteer yourself for that task. Speaking of volunteering: My respect to all angels (helping hands), heralds (those introducing speakers), noc (network operating center), poc (phone operating center), the organisation team and anyone who helps keep make that event as enjoyable to attendees as it is.
Update: Thank you to the geeks who after staying in our apartment for #28c3 helped get it back to a clean state - actually cleaner than it was before. You rock!
Once in a while I get questions like Where to start learning more on machine learning. Other than the official sources I think there is quite good coverage also in the Mahout community: Since it was founded several presentations have been given that give an overview of Apache Mahout, introduce special features or even go into more details on particular implementations. Below is an attempt to create a collection of talks given so far without any claim to contain links to all videos or lectures. Feel free to add your favourite in the comments section. In addition I linked to some online courses with further material to get you started.
When looking for books of course check out Mahout in Action. Also Taming Text and the data mining book that comes with weka are good starting points for practitioners.
Mid November Apache hosts its famous yearly conference - this time in Vancouver/Canada. They kindly accepted my presentations on Apache Mahout for intelligent data analysis (mostly focused on introducing the project to new comers and showing what happened within the project in the past year - if you have any wish concerning topics you would like to see covered in particular, please let me know) as well as a more committer focused one on Talking people into creating patches (with the goal of highlighting some of the issues new-comers to free software projects that want to contribute run into and initiating a discussion on what helps to convince them to keep up the momentum and over come and obstacles).
Looking forward to seeing you in Vancouver for Apache Con NA.
Unnecessary? Cowering down here in sludge and pollution, conjuring names on screens, learning nothing: that is unnecessary. Give me smallest finger on man's hand. I'll produce information. Computer unnecessary.
).
Mid November Apache hosts its famous yearly conference - this time in Vancouver/Canada. They kindly accepted my presentations on