Archive
Software Developer and Evolution Conference 2010
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.
Agile 2010 Session Roundup
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.
Agile 2010 here we come!
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.
Prairie Dev Con 2010
Today was the first official day of the Prairie Dev Con 2010 conference, starting out with an opening welcome message with a nice breakfast spread. David, Nyik San, Brian, and myself arrived the day before at around 6pm so we’d be in time for the social mixer put on by the Regina developer community before hand. It was reasonably well attended and I met quite a few people and made some great contacts. It actually has turned out to be pretty nice being at a smaller conference because it’s making it very easy to build relationships with the other people attending.
This morning I started out by attending an Intro to Agile session which was fairly good. I was interested to see what somebody else’s take on agile was going to be. It was an overview of processes and how to do scrum etc so it didn’t overlap too much with my presentation which I was happy to see.
Next up was my presentation “Intro to Agile Development Practices”. It was quite well attended and went very well. The audience was very engaged and asked a fairly good number of questions. Apparently I like to talk more when I have an audience than I do to the white board. My presentation only took 45 minutes when I was practicing it but at the conference I went almost the full 75 minutes!
The notes for my session can be found here.
After being in sessions until 5:30 this afternoon I attended a supper put on for all the presenters of the conference at “The Diplomat” steak house and got to know a few more of the other presenters a little better. There’s a very good amount of diversity between the speakers, some coming from Guelph, Virginia, and Utah.
So far the conference has been great and I really hope it gets put on again next year. The one thing the conference is really lacking is some non-microsoft content. There are a lot of attendees who would love to sit in on some Python or Ruby sessions, and everybody who i’ve mentioned Scala too immediately says how much they wish there was a session on it. Hopefully next year we’ll be able to get some more P2ers presenting at the conference and help round out the technology diversity in the sessions.
Tomorrow I kick off my morning first thing by presenting my session on Iterative Development which i’m really looking forward to because there are no other presentations covering that content. Many agile presentations touch on the concept, but none talk about it in any detail.
Iterative Development – An Introduction
Iterative development is a pretty basic concept. You just develop iteratively… Hmm pretty sure i read once that you shouldn’t use the word you’re defining in the definition. Lets try again.
Iterative development is the practice of developing software in small defined chunks of time. This is in contrast with the old-school method of starting a project and working on it over the course of months or years in one long chunk, or iteration.
Lets just dig in to the meat of why it’s important. Imagine you wanted to get a house built. You line up a contractor who has experience building houses. You tell him you want a 1200sq ft house with lots of windows and a double garage. He asks you what layout you want, where should the windows be, do you want a deck, what colors for the interior and exterior etc. You answer him by saying “I don’t know, I hired you because you’re good at building houses, so you just make sure it’s 1200sq ft and has lots of windows”. Can you see where this is going?
Six months later he calls you and says the house is done. You walk in and while the house is impressive, it’s not how you had envisioned it, and with the amount you are paying him, you want it to look how you want. Unfortunately now that all the work is already done, it will cost a LOT more to make changes.
Software is the same way, if somebody comes and says to you “I want a system that does X” but they don’t have any details as to how it should look or work, it would be foolhardy to believe that they are going to just be happy with whatever you deliver to them.
Iterative development helps with this by allowing you to break up the project in to small iterations, the smaller the better, ideally 1 or 2 weeks. This way you can show what you have accomplished during each iteration to the customer and see what they think, and get their feedback on what they would like changed. Even if they customer had no idea what they wanted ahead of time, you can bet that they will after they see what you have built. The sooner you get that feedback from them, the cheaper it will be to ensure the project turns out how they want.
One of the other big advantages of dividing work up in to short iterations is that it’s a lot easier to estimate what you can get done in 2 weeks than in 2 months. Once you have the project divided up in those iterations it also becomes a lot easier to see if you’re falling behind or not as well.
That should give you a basic idea of some of the advantage iterative development provides. I’ll go in to more detail in future posts of some of the other advantages.
by: Chris Dagenais
Presenting at the Prairie Developer Conference June 2nd and 3rd
The Prairie Developer Conference is the first of it’s kind in Saskatchewan, a 2 day event covering a wide range of topics including things such as cloud technologies, agile development practices, database performance tuning, etc.
I submitted three proposals for sessions to the conference and two of them were accepted!
- Agile Development Practices, brief introduction and how they help your business
- Iterative Development, How it works, Why it works, Who it helps.
I’m very excited to get the chance to present on these topics to a reasonably large group of people from around my own area, as well as raising the profile of Point2 in Regina.
By: Chris D
How to Avoid Auto Deployments Behaving Badly
A couple of posts relating to development/ops gaps, and access control reminded me how very far we have come with our environments over the past few years.
Environment management in general comes with its own set of complications, but what I am interested in knowing is how other Systems/Operations departments are handling auto deployments. Several of the points in the articles above are moot for us and have been for some time. Access to production systems is heavily limited to our Systems Administrators and many of our products are deployed with scripts triggered by team city builds. Code or configuration files are not deployed manually to our end to end test environment, and when they are, generally an auto-deployment script needs to be touched to alter the outcome rather than a human touching a file. Don’t get me wrong, there are still blunders that occur from one environment to another “oh I forgot that we needed to add that file so I didn’t add it to the production release… oops”. However, my main concern is what to do when an auto deployment script behaves badly.
First, let us discuss what auto deployment is to our teams. When code is ready to release to a test or production environment, an auto deployment script will be executed to place the code on the correct server(s). In the case where code is going to production, a Systems Administrator is assigned a ticket to take a few preparation steps, then run the script to deploy the code. Depending on the environment and product, one or all of the following things could happen during an auto-deployment run:
- Disable/enable monitors
- Disable/enable nodes in a cluster
- Run database scripts
- Svn checkout or switch a directory or file
- Copy files from one location to another
- Start/stop services
- Start/stop web containers
The first time I ran an auto-deployment release, I felt naked. I was so used to knowing every piece of what was actually required for a product to become live that pressing a button felt completely foreign. I worried that something would be missed, and I just wouldn’t know. So what should you do in a case like this? How do you mitigate the risk of the system being compromised? You’re running a script that you know little about other than you just typed several passwords into a config file on a secure server and it’s using your permissions to execute. However, because you have done this manually before, you know what the behavior and outcome of the script should be, so verify it.
The first few times we were vigilant. Check to make sure the node is out, review all the database scripts prior to release, check log files during and after the release, etc. Over time though, we started to become more comfortable with the release runs, and this is when the problems started to arise.
Auto-deployment scripts in recent months have been known to produce any one of the following symptoms:
- Didn’t run the database scripts, or ran the incorrect database scripts
- Didn’t remove the node from the cluster or didn’t put it back in
- Deployed the wrong the version
- Deployed the wrong application
- Failed because of a spelling mistake
- Showed “all green” in our monitoring system, but still caused a serious underlying problem
All these problems are compound, they are the responsibility of both the development and systems teams to realize and mitigate. The real root of the solution is to treat the auto-deployment script as exactly what it is: code. What do you do with code? You test it, you unit test it, and you make sure that it throws exceptions and failures when it doesn’t do what it is supposed to do. Most of the above problems could easily be avoided if the script was intelligent enough to know when it has made a mistake.
So, this is my list of remedies for saving an operations team from feeling naked when learning to run auto deployment scripts.
- Get involved, have the script demoed to you and understand what it does before you run it. Ensure that every time it changes, you receive a new demo.
- Don’t be naive, yes, maybe one day this script will run without someone watching over it, but before that happens, sys admins and developers should work out the kinks.
- Review database scripts with a developer before the script is executed then check to ensure that one of the intended operations occurred.
- Any time a problem is encountered post-release that is found to be the fault of the script, have the script altered to create a FAILURE state if it ever happens again. Additionally, review the script for other possible failures and have those adjusted too.
- Check log files, review the script output and review the logs of your application containers.
- Ask developers to check log files too, you will not always catch an error.
- Consider having the script pause at critical stages (i.e. between nodes, etc) so that things can be inspected before they go too far.
- Improve your monitoring systems. Create monitoring situations for the errors that get caused by the releases.
One day, after you have executed a script 10 times and it has not made a mistake, you will trust it. The important thing to remember is that the scripts will continue to evolve, so stay involved and help test every change. After all, as Systems Administrators or Operations staff, it is your job to ensure that the system is operational and take responsibility or alert the appropriate team when it is not.
Melanie Cey
Systems Administration Team Lead
Movember
Ah what can I say about Movember, it’s definitely the hairiest time of the year around here at Point2. For those of you who have never heard of it, Movember is the renaming of November to signify the thousands of men all over the world who are growing mustaches for the fight against prostate cancer. Most people at Point2 learned about it last year when our now CTO asked us to join him in growing mustaches to raise money for this cause. Soon after that many of the normally clean shaven men of Point2 were proudly displaying hair where there was no hair before. Again this year we have decided to put the razor away and focus on growing the baddest mustaches our faces will allow.
The development team that I am currently on has four brave men willing to put forth their best mo for a good cause. Mustaches can be very powerful tools, helping to fight against prostate cancer, and even helping our team reach new heights of greatness. During our retrospective last week it was found that our mustaches had a large role in helping us achieve our velocity. We did so well that we decided to hold a Root Cause Analysis to find out how our teams Velocity was so much higher than the previous week. In that meeting our mustaches were cited as an extra member of the team helping complete many tasks, they also helped to bring morale higher than usual. I believe that I was not the only one who came to the conclusion that it was in fact the ‘Mo’ that not only helped us achieve our velocity goal but also to surpass it.
However growing a sweet mustache is not all glory, for most people it takes time filled with ups and downs. Some people may look you at in disgust however you may find that the longer your mustache grows the more attractive you become. Most men usually go through the 5 stages of ‘Mo’.
The 5 Stages of ‘Mo’:
1. Denial – Thinking this year I’m not going to look like a porn star from the 70′s
2. Anger – Grow faster and thicker!!
3. Bargaining – I’ll grow twice the mustache next year if you just let me shave this thing off
4. Depression – Oh, my wife won’t kiss me, and everyone looks at me like I’m insane
5. Acceptance – Well we’ve come this far it’s finally looking like something, and I think that hot blond just gave me the eyes.
Now that the month is over and the mustaches have moved on, things feel different, almost less masculine. However Our Point2 team did raise almost $3000 this year for Prostate Cancer, and I know that everyone who participated feels stronger from the experience. We now know that growing a good friend only takes a month. Well mustaches and Movember go together like bacon and eggs, but all good things must come to an end.
Click here to donate to our team
By: Dean Gaudet
The Agile Game
Dr. Stuart Brown, founder of the National Institute of Play, believes that the act of play is essential to human development and intelligence. After watching one of his TED talks, Play is more than fun, I was inspired to look into games an agile team can play during a regular sprint. After all, it seems pretty straight forward that human development and intelligence are valuable aspects of a software developer’s career. So I hit up Google for what it could tell me about agile games, and found a bunch of balloon toting, crazy string wielding fun games I could play with my development team. I envisioned my team’s reaction to the introduction of these wild games:
1. Get a bunch of awkward looks.
2. Make a fool of myself to help lead the way
3. Get a few giggles playing the game
4. Try to come up with a different crazy game the following sprint
To me this seemed like a lot of effort for a little flash-in-the-pan fun. I decided I wanted to focus more on games we could play that would infuse themselves into our work stream — Heck, let’s just make our work a game! First let’s discuss what makes a game fun. Games are scenarios where you have a goal to reach while operating within established rules, boundaries and limitations. What makes the game fun is having the freedom to choose different paths toward the goal, being able to use your skills to achieve smaller goals along the way, and to reap the rewards for achieving the goal.
We already have plenty of rules, boundaries and limitations in our workplaces, but let’s talk more specifically to agile software development. I am talking about story breakdown, story estimating, spiking, definition of done for a story, coding standards, pair programming, TDD, stakeholder satisfaction, etc. Once the rulebook is well understood by your team you must give them time to play the game. YOUR ATTENTION PLEASE: the players need uninterrupted blocks of time where they get to play by the rules and innovate a solution. Don’t be afraid, these blocks are measured in hours, not days. Do what you need to do to provide the players with at least 75% of their day as uninterrupted game time (the more the better). If you need meetings with them make sure you consider the following:
1. Do you NEED the meeting?
2. Does everyone need to attend?
3. Can the meeting occur at the edge of a break (start/end of day, right before/after lunch)?
As a Team Lead your job is part referee and part coach. Encourage healthy demonstrations of play and discourage improper play. Help remove problems which affect their ability to play, and celebrate their victories while helping them learn from their defeats.
And finally, a word to the wise – break down your stories into small enough pieces that they can be achieved in no more than 2 work days. Having those frequent moments of accomplishment makes every game more enjoyable.
Main Course: Hot Ideas
Many interesting women I know are incredible geeks, and many interesting geeks I know are incredible women! But then, I may be biased, cuz I’m a girl, and yes, I’m a geek too!
The truth shall set you free!
What solidified the fact that I am, indeed, a geek was my first invitation to a Saskatoon Girl Geek Dinner. That was it! I had no choice but to acknowledge my long-denied nerddom. I missed SGGD’s first meetup, but I have attended every Saskatoon Girl Geek Dinner since.
Last Tuesday, Saskatoon’s Girl Geek Dinners held its 4th event since its local inception in early summer, 2008. The dinner was held at Zu’s stylin’ new digs on Pacific Avenue. They were awesome hosts!
Organized by Melanie Cey, Brittany Melnyk and Devon McGeary, the GGD agenda included dinner, a presentation, a workshop, and an impromptu tour of Zu’s new facility.
The turnout was great! Not surprisingly, the ratio of women to men was a complete reversal of what we see in the workplace. Instead of 30:1 men to women, the ratio was 1:30+ men to women.
“I love my team, but…”
After dinner and socializing, Melanie got the program started by explaining the Girl Geek Dinner concept to attendees. You can read about GGD here. Essentially, Melanie acknowledged that working in a still male-dominated field of study offers few or no female role models within the workplace. Let’s face it: sometimes men and women exist on different planes and as a result life can be frustrating. But we don’t want to give up, fellas… we love what we do! and we want to keep doing it for as long as it makes us happy.
Cue Ginger!
Ginger Koolick spoke to the group on becoming a consultant. While outlining logistical processes of becoming self-employed, Ginger’s story had a notably female voice, and included not just business sense, but personal philosophy for leading a fulfilling life. It was interesting to hear that despite the sudden nature of her decision to go into business for herself, Ginger actually assembled a comprehensive business plan. I hope in the future she returns to the group to present retrospectives on her initial plan.
Flexing our Agile muscles…
Devon McGeary ended the presentation layer of our event with a hands-on exercise called “Blitz Planning”, an exercise which many of us at Point2 (if not all of us) have participated in to some degree within the past few months. In a nutshell, the session emphasized a quick and collaborative approach to building a project’s stories and tasks, illustrating and revealing sequences, dependencies, moving parts, and necessary expertise. (I know I’m omitting objectives, so if the idea sounds interesting, you should read up on it starting here.)
Refactory!
Just before the evening ended, Zu gals gave us tours of their newly renovated space on Pacific Avenue. It is a beautiful old building, and the decor is fresh and groovy. And truly, who wouldn’t love a fireplace in their lunchroom!!!
Next up?
The story has yet to be written… GGDs are cooperatives which focus on science and technology, and of course, women working in those fields. The Saskatoon chapter is new and growing, and certainly, there are many women (and men) who have much to offer the Saskatoon Girl Geek Dinner community. Maybe you are one of them??
By: Karen Martens
Share on Facebook
Recent Discussions