Looks like this October i’ll be making my way east out to Winnipeg where I have the opportunity to present two sessions at the Software Developer and Evolution Conference. I’m very excited as not only will this be my second conference of the year that i’m presenting at, it’s also going to be my first time in Winnipeg. If you know of any fun family things to check out in Winnipeg please leave a comment!
My first session is about self organizing teams, participating on and leading. There’s a lot of things to think about when it comes to creating and fostering self organizing teams. I plan to talk about some of them from the perspective of a manager and leader, as well as a team member on the team. I’m also coming up with a good exercise that I hope will be fun and help illustrate my points.
The second session will be on iterative development. I did this session at the Prairie Developer Conference in Regina, and i’ve used the feedback I received from the attendees there to refine the presentation to hopefully be even better, and i’m also incorporating an exercise in to this one as well.
I’ll probably be making more posts on those two topics in the coming weeks, so check back for more.
If you won the lottery, the person is exactly what you were looking for, has all the right skills, fits in with the rest of the team, and is paid fairly according to their skills. Now go log in to your online banking app and check if you’re a millionaire……….No? I didn’t think so, because as it happens, most of us have never won the lottery
Some of our technical staff are doing a fair amount of Python coding and also are preparing for the Linux Certification (LPIC-1) exam.
One of the first topics we have been studying is the Linux bash command line, command history and command editing.
Guess what, you may be surprised that modern Python interpreters use the GNU readline library… in plain English: you should be able to practice the skills you’ve gained during your Linux study sessions whenever you work with your Python interpreter, i.e.:
* Line editing
* History substitution
This requires you to:
1) Add line to your bash start up script ~/.bashrc (or your ~/.bash_profile):
(changing /home/user to your home directory, e.g. /home/mtarruella)
2) create the file: .pystartup (see below) in your home directory
Python will execute the contents of a file identified by the PYTHONSTARTUP
environment variable when you start an interactive interpreter.
How do you use it ?
i) use the Emacs key bindings you learnt for bash
e.g. CTRL-A moves the cursor to the beginning of the line.
However, if you are more inclined to the Vim key bindings
you will need to configure readline placing the command:
set editing-mode vi
in the file ~/.inputrc
ii) Retrieve commands from your history by using CTRL-P (Previous command) and
CTRL-N (Next command) or the useful ‘reversy’: CTRL-R (search command backwards).
iii) Start using command completion as if you were in the Linux bash command line e.g. start typing imp and press <Tab> you should then see:
The whole word “import” should be auto-completed.
More detailed information on the topic: Python interactive
Happy Linux! and now Happy Python too!
Note that this is valid for *nix and Mac’s too.
By: Marcos Tarruella
An example of .pystartup file:
# Add auto-completion and a stored history file of commands to your Python
# interactive interpreter. Requires Python 2.0+, readline. Autocomplete is
# bound to the Esc key by default (you can change it - see readline docs).
# Store the file in ~/.pystartup, and set an environment variable to point
# to it: "export PYTHONSTARTUP=/home/user/.pystartup" in bash.
# Note that PYTHONSTARTUP does *not* expand "~", so you have to put in the
# full path to your home directory.
historyPath = os.path.expanduser("~/.pyhistory")
del os, atexit, readline, rlcompleter, save_history, historyPath
So far my experience at Agile 2010 in Orlando has been great. Great location, great conference center, great people, and great information. It’s been a very busy and exhausting week so far, although i’m sad to think that i’ll be flying out around this time tomorrow and it’s all coming to an end.
My first session monday morning was titled “The Incentives Trap”. It was a session exploring what motivates people, primarily focusing on intrinsic vs extrinsic motivators with some exercises to prove out how the different types of motivators affect the work ethic and productivity of teams. I was on the “square” team which was divided in to developers and testers. My role on the team was a tester. I got paid $1 for testing a story and $1 for finding a bug. The developers got $1 for developing a story and $2 for fixing a bug. Only the project manager got paid for delivering value. Can you see who got screwed over in this scenario? Lets just say the project manager probably didn’t eat that night. It turns out that generally the team which is allowed to self organize, and is working for a charity for “NO PAY” is the most productive team that delivers the most value. Why? Because they are passionate about what they are working for, they are working for a charity because they believe in the cause and want to make a difference. That’s why it’s important for your development teams to understand and believe in the work they’re doing, it’s the only way for them to be intrinsically motivated to be productive.
This is lining up to be a long post, since that was only the first session I attended, and i’ve attended 2 – 5 per day….
My next session was titled “Beyond Scope, Schedule, and Cost: Optimizing Value”. It was a reasonably good session in which I primarily just came back with some interesting statistics and a couple of ideas.
- doubling the number of people working on a project typically quadruples the number of defects.
- 65% of features do not deliver their expected/planned value
- what is a more successful project?
- estimated to get 5 value points done in a week and achieved 5.
- estimated to get 8 points done in a week and got 6
Tuesday morning was the keynote by “Dave Thomas”. It was a lot of what you would expect to hear at an agile conference keynote. There were a couple of things that surprised me though, like when he exclaimed “you know we’ve made it now because the tool vendors are here, but let me tell you, if you can’t do it with paper cards, no tool will help you”. I don’t disagree with him, but the tool vendors are the major sponsors of the conference, so I found it a little ironic that he was denouncing their usefulness to all of the conference attendees.
In the afternoon I got to see a session by Johanna Rothman which I was quite excited about as i’ve been reading her blog for quite some time now. Her session was titled “Agile Managers: The Essence of Leadership”. The purpose was to talk about what role managers and leaders play in an agile organization, as many managers often feel lost. There weren’t really any surprises here for me as we’ve got it fairly well figured out at Point2 (we can definitely improve on execution of it as a management team, but we have our place figured out at least). The session was a nice indication for me of how well we’re doing, and it was great to see that Johanna is just as good of a speaker as she is a writer on her blog.
Wednesday started out with quite likely my favorite session of the conference so far “Scrum Metrics for Hyperproductive Teams: How they fly like Fighter Aircraft”. It was given by Jeff Sutherland and Scott Downey, Scott had the title of head agile coach at MySpace and now holds the same title at Napster which I thought was pretty cool. They had a lot of good information which I couldn’t possible discuss in it’s entirety in one paragraph, so i’ll just stick to a couple of points that stuck out for me which we’ll need to try. The first is we need a “keystone” story, probably estimated at 3 points, which because the reference point for all estimation done by the team for the rest of eternity. Why do we need this? Because as the team gets better they will naturally migrate their estimates along with their increased productivity which makes it hard to track improvements over time. It also makes it hard to have consistent estimates across sprints when you don’t have a never moving reference point to estimate against. Another thing I want to try focusing on is getting as many people as possible working on getting the top priority store from in progress to done. We typically have a pair sign up and work on a story until it’s complete. If 3 pairs can all work on the same story to get it done faster, we should do that. A sprint that ends with the top half of the stories finished is better than a sprint that ends with all of the stories 75% done. The other big area that I want to try some changes is in the team standup meetings. For now i’ll just say that the scrum masters are doing do much of the driving at the meetings. Their role in the standup should essentially end with making sure everybody on the team has shown up. More about that when I get back
I had another great session on Wednesday morning called “Coaching Agile Teams: Using Silent Work Techniques to Get to Astonishing Results”. It was a very interactive session with a lot of activities. I learned a number of techniques in this session on how to get a greater quantity of ideas out of brainstorming sessions about projects/products, as well as some ways to get much more innovative ideas. Jesse and I are planning to run at least 2 workshops once we’re back based on the exercises I learned in this session. I think it’s going to be very valuable for having the entire team feeling more involved in providing ideas that can help shape our roadmap and product decisions. Jesse and I are both really excited about it.
In the afternoon I went to a couple sessions that didn’t produce too much worth writing about with one notable quote “There’s a big difference between half-assed and half done” referring to people’s natural tendency to prefer delivering something half done with a high level of detail over delivering something finished to a lower level of detail.
Today, thursday, is a bit slower. It’s the last day of real sessions so everybody is starting to look burnt out (everybody at the conference including presenters). I went to a session about Design Complexity this morning that was quite interesting. I had a short debate with the speaker about building what you need instead of what you think you need, as she was advocating spending effort up front designing your implementation to be extensible in the way you think it will need to be extended at the time. We agreed that if you know it’s going to be extended immediately after this isn’t necessarily bad to do, but we disagreed on if you only “think” it will be extended in that way, but had no plans to do so.
I later went to a session titled “Confessions of a Flow Junky” focused on helping create an environment where people can get in their “flow” to become really productive. The speaker asked how many people have tried pairing and astonishingly half the room raised their hand, the speaker was pretty impressed. Then he asked how many do it regularly, and only about half a dozen people put up their hand. When he asked who know how pairing helps flow, I was the only person in the room with my hand up, so he asked how. I told him “you feel obligated to the person beside you not to screw around” which had the desired result of everybody laughing, and the presenter agreeing, saying it’s one of the littlest known benefits of pairing. I enjoyed the session, in particular because after the previous comment I had made, people were asking me questions at the end of the session about how we do things at Point2 and how I thought they could make improvements to what they do.
Networking at the conference so far has been great. I’ve met a lot of cool people from all over the world. I’ve met a few people from Ireland, a guy from Finland, a couple from France, many from the US of course, and a surprising number of Canadians. I actually happened to run in to a girl that I went to school with at Kelsey in Saskatoon that I haven’t seen since we graduated in 2000! What are the odds? I also happened to run in to one of the presenters that I met at PrairieDevCon in Regina this year and it sounds like I might get an opportunity to present at a conference in Winnipeg this October so i’m looking forward to finding out more about that.
I wanted to post some pictures but uploading them over the hotel wireless hasn’t been working so that will have to wait for later.
“Walk and Code” was the title of a short talk that caught my attention on the Agile 2010 conference ‘menu’. Doug Bradbury (from eight light) presented his experiences of precisely coding whilst he was walking on a treadmill.
It may sound quite nuts to you, but I think it’s such a great idea that I am going to give it a go.
His motivation came from the work done by Dr. Levine creating active computer workstations.
Dr Levine’s has studied how to change the spontaneous physical activity or, NEAT (Non-exercise Activity Thermogenesis) in our sedentary world. We’ve been ignoring the capacity of expending calories by doing all the activities of daily living, e.g. walking.
So start walking and coding, and extend your chances to live longer.
“People are built to walk.” – Dr. Levine from Mayo Clinic
Video from Dr. Levine treadmill-desk
This year i’m extremely happy to be one of the 4 lucky people selected to attend the Agile 2010 conference. I’ll be attending along with David Ford, Jesse Redl, and Marcos Tarruella.
This conference is an all you can eat buffet of Agile information, whether you’re a developer, qa specialist, manager, team lead, scrum master, executive, or alien, there is something there for you. Did I mention that it’s also being held in Orlando Florida at the Disney Dolphin Resort?
There were so many sessions during each time slot that I had a hard time deciding which ones i’m planning to attend. I eventually managed to boil it down though and hopefully I made good choices!
Some of the sessions i’m the most excited about are:
- Improving Decision Making in Your Agile Team by Meghann Drury and Ken Power
- Making feedback work in your teams by Sumeet Moghe
- Leading a Self Organizing Team by Mike Cohn
There are many others i’m attending that should be very valuable as well. I can’t wait to get there and meet as many people as possible.
About a week ago I started having problems running tests in IntelliJ 9.0.1. I didn’t have many plugins installed, in fact, I only had one installed, the Scala plugin from JetBrains. After an update to the plugin and IntelliJ (to 9.0.2) whenever I would run tests the project failed to make, generating 100+ errors and 16 warnings. I contacted our helpdesk team, who installed 9.0.3 Ultimate Edition and still encountered the same errors. After a few hours trying to find the problem myself, I sought help from JetBrains.
As it turns out, I’m not the only person to experience this problem, and according to JetBrains the fix will require a patch for IntelliJ or the plugin itself; however during my correspondence with JetBrains, I found a fix myself.
First, go to http://www.scala-lang.org/downloads and download the latest version of Scala. Extract it, it doesn’t matter where you extract it to, because all you need is to have it somewhere on your computer.
In IntelliJ, click the Project Structure icon and select Facets under Project Settings. Click the “+” to expand the Scala Facet, and click to select Scala (importer). Check the box labeled “Use Scala compiler libraries from specified jars” and update the fields to resemble mine in the screenshot below.
By Chris Powell
Just about a year ago I attended the Agile 2009 conference in Chicago where I had the opportunity to take part in a half-day workshop with Christopher Avery. It was here that I was first exposed to his Responsibility Process which inspired me to write the post Operating from Above the Line shortly after. I was hoping to run a similar workshop at Point2 to demonstrate Avery’s idea, but I couldn’t garner enough interest from a large enough group to make it worthwhile.
Fast forward a year and coincidentally enough Avery’s Responsibility Process came up as a topic during a staff engagement workshop championed by our Director of Human Resources. As it turned out some of the Responsibility Process posters also started showing up on walls throughout the office, but without context people didn’t know what to think of them.
Following the staff engagement discussion I was approached to run a workshop that would help to demonstrate the Responsibility Process to our Sales, MLS, and Syndication teams. I was very excited to do this and planned to fashion it after Avery’s effective Agile 2009 workshop. It’s easy to get the gist of the Responsibility Process by reading about it, but the true benefit is seeing it in action.
The idea is to get people to work on a difficult task as a group that will likely result in failure, and keep track of behaviour during the exercise. For this particular workshop we had ten people so I split them up into two groups of four. The remaining two were to be my observers.
- The Builders’ Job: build a ten story, free standing structure using only a deck of cards and a small amount of fun tack in fifteen minutes.
- The Observers’ Job: listen to the builders and take notes of any phrases that sounded negative.
Anyone who has tried to build a house of cards probably knows that reaching ten stories is nearly impossible. One group managed to get to seven, while the other group’s unorthodox design proved to be….well, good in theory. But as you guessed the point of the exercise was not to actually build a structurally sound building, but to surface behaviour that fit into the different states of mind on the journey to responsibility.
- Lay Blame
Here are some examples of the phrases that were recorded by our observers.
- I already know who’s fault this is.
- We don’t have the right materials
- Someone else do it. I’m too scared to go on.
- We don’t have enough time.
After writing each of the phrases recorded by the observers on a whiteboard I started to explain each of the states of mind of the Responsibility Process. Once everyone had a basic understanding we grouped each phrase into its appropriate state. Some were easy to categorize while others were more difficult which in turn spawned some excellent debate. What I found to be the most beneficial was real life examples brought forward by some as to when they may have been in one of these states recently.
We left the workshop understanding the premise behind Avery’s Responsibility Process, but were aware that this was only the first step. As individuals it is up up to us to make the effort in identifying our states of mind when we encounter conflict, and do what we can to move as quickly as possible to the next level. Now having ten people at Point2 aware of the Responsibility Process, we could lean on each other for support when learning to identify what state we were operating in. And as a company having as many people operating from above the line seems like the responsible thing to do.