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
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.
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.
Since this was the first time a big software conference had been hosted in Saskatchewan, the organizer, who works primarily with Microsoft technologies, used many of his contacts from within that community to put together a good list of speakers. Now that the conference has been run once and had a good attendance, the hope is for next years conference that we can attract speakers on a more wide range of technologies such as as Python, Django, Scala, and document style databases such as MongoDB.
Since Point2 has been doing a lot of interesting work with new technologies, I hope for next year we will be able to put on a number of talks to offer a more well rounded list of topics for next year.
Overall, I was really impressed with PRDC10 and I am looking forward to seeing it happen again next year!
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.
Mark Hollman and I are heading on an adventure in the city of sin. What is this adventure you may be asking yourself, well it is the 2010 Better Software Conference and Agile Development Practices Conference in Las Vegas, Nevada June 6 – 11th. The conference is hosted by Software Quality Engineering, a consultancy firm that “offers education, publications, and real-world expertise to help you advance your software practices”. Our mission is to absorb as much information while in Vegas and make sure it doesn’t stay there.
I am very excited for a two day workshop that is new to this conference in 2010. I will be attending the Business Analyst Workshop on Monday/Tuesday. This workshop focuses on knowledge and skills that make a business analyst successful. The sessions are going to be highly interactive and provide me with practical takeaways I can use as soon as I am home in Saskatoon. I also will be attending a session on “Testing with Real Users—User Interaction and Beyond” by Seth Eliot and other sessions related to business analyst work. I hope to absorb all the information I possibly can and turn it into further blog posts and presentations for my coworkers at Point2.
Mark is excited for all of the sessions he will be attending and hopes that he can bring back tools and techniques that will help Point2 improve our process’s and collaborations between teams and departments.
Hopefully at the end of a tiring, but fun filled week of learning, networking and riding New York New York Roller Coaster, Mark and I can get some sleep. If you’re going to be attending the conference, or think there is something we should see or do while in Vegas – leave a comment!
“There’s just no quiet in Vegas” ~ Barry Manilow
By: Devon McGeary
It is safe to say that software development teams work best in the confines of each iteration. All the stories are laid out, estimated, and committed to based on conversations, designs, whiteboard diagrams, and a clear understanding of what is needed to be done. The business team works best in terms of looking at technical projects as a whole as they try to prioritize and decide what work needs to be done to drive business. And this is where the dilemma lies. The business team is looking for a general idea of how long a project will take to complete, but the development team is uncomfortable in providing one until they have all of the stories in front of them. The catch-22 is that stories aren’t written until a project has been given the green light.
The development team’s reluctance in providing high level estimates typically stems from:
- A fear that the estimate they provide will be mistaken as a commitment when it comes time to actually develop the feature/product.
- Not having the chance to fully explore assumptions and risks adds a sense of uneasiness since the estimate is usually heavily based on these assumptions (mainly technical assumptions – business questions should be answered).
- High level estimation meetings can be difficult to facilitate, and can quickly become frustrating for everyone involved. It is very easy to lose track of the goal of the meeting.
At Point2 it is usually the Team Lead/ScrumMaster and a Business Analyst who facilitate these meetings. It is up to them to ensure that the pain-points are alleviated. If the team has a genuine feeling that the high level estimate they provide will be construed as an actual final commitment then there is probably reason for it. Perhaps this was what happened historically and the team is having a hard time getting past that, or maybe it is continuing to happen. If this is the case, as a Team Lead/ScrumMaster it is your responsibility to manage this disconnect. If the nature of the high level estimate is being misunderstood by your customer or business team it is your job to fix it.
If there is a lot of questions arising during estimation that cannot be answered in a reasonable amount of time, there’s no way around it – assumptions will need to be made. The key is to make note of these assumptions and document them as risks in your final estimation. This will be key in helping the business prioritize the project. If there is a lot of high risk items the decision to start straight away may be best. On the other hand maybe the risks just outweigh what we hope to gain, and the project is scrapped. The point is to provide enough information for the business to make an educated decision. It is interesting to note that a lot of these technical assumptions are due to technical debt. Minimizing technical debt makes high level estimation much simpler, but I will leave that topic for another post.
When we first started providing high level estimates I had little knowledge as to where to even start. Being a former developer I too suffered from many of the above points. The bare minimum is to get the team to break down the tech project into logical, more manageable pieces. Briefly discuss these logical components to ensure that everyone has a shared understanding. It’s at this point that assumptions are likely going to be identified.
Once you’re ready to estimate that specific items try what I’ve been calling the Goldilocks technique. Throw out a number like “2 weeks” and ask if it is too much time, not enough time, or just right. Modify your number and repeat as needed. It is a good idea to sometimes provide more than one estimate based on the presumption that certain risks may come to fruition.
If your team has the understanding that the estimate they are providing is an educated/best guess that is going to provide the business with the knowledge needed to steer the company in the correct direction, the more willing they will be to engage the process. These are decisions that need to be made, and I’m sure everyone is more comfortable if it is the development team providing these estimates as opposed to the executive team who doesn’t have the expertise required. In a perfect world we would know exactly how long every project would take, but this isn’t a perfect world so all we can do it work with what we have. At the end of the day we are all working towards the same goal, and as long as the development team and the business team understand the purpose as well as the limitations of the estimates, the more likely those goals will be achieved.
When we’re building software, we often have a desire to deliver something that will blow people away. It makes sense right? Why would we want to deliver something that isn’t impressive, doesn’t work all that well, doesn’t look really pretty etc.
Well, it just so happens that there’s a good reason you’d want to do that, because it still delivers value, even in it’s often simple and unrefined form.
Consider this scenario, a client comes to you and asks you to build them a chair for their office. They want it to roll around, comfortable, adjustable height, nice arm rests etc, and they want it as quickly as possible because they don’t have a chair at all now.
Using the typical mentality of not delivering anything until you think it will blow people away, you go away and over the course of a month you build a fabulous office chair. You showed some pictures of it along the way to the client and they were pleased with the design, however they really wished they could have been sitting down at their desk while they looked at your designs…
The concept of fidelity is simply to deliver the simplest thing that provides value as soon as possible, and the move on to refine it. Using the chair example, the client wants a fancy chair, but the client also currently has NO chair, so obviously just having anything to sit on provides SOME value. Thinking in this way, the lowest fidelity solution that will deliver some value to the client might look something like this:
The client will obviously not be satisfied with a milk crate as the final product but it isn’t the final product, it’s the first iteration of the final solution. You would tell the client something along the lines of “here’s what we came up with in the first day, turn this upside down and it will allow you to sit at your desk, we’ll be back in a few days with an improved version for you. A couple days later you return with:
You tell the client that it’s a little more comfortable than the last delivery, and looks better as well. You will further refine the chair and be back in another week. After a week you come back in with:
The client takes a look at what you’ve delivered, sits in it, the padded chair is comfortable, it looks stylish, and they tell you this is my chair, this is what i want, don’t make any more changes.
So, what are the main differences here? The client ended up with an end product they were happy with in both cases right? The second method had a couple key benefits though. First of all, the client had results in hand and was able to use them (start sitting down) the next day, instead of having to wait for a month. Also because the team was delivering improvements regularly the client had many opportunities to suggest how they would like things changed. Finally, the client has the opportunity to stop the development of the product early for any reason and still be left with a usable product! So whether it turns out that the client is happy with less than they originally asked like in my example, or if the client just ran out of money and had to stop early, they are always left with something usable.
You could make the argument that this is just iterative development, and technically you are correct, however it’s important to remember the fidelity aspect which is that each iteration should provide a usable product that provides value. Consider another way to iteratively deliver a chair to the customer. In the first iteration you deliver fully refined wheels, in the second you deliver the adjustable chair post, in the third you deliver nice leather wrapped arm wrests, in the fourth a nice padded leather seat, in the fifth a nice leather chair back, and in the sixth you put it all together. That’s iterative right? You produced and delivered a piece of the product in each iteration and showed it to the client. The problem is that you weren’t delivering any value with each iteration. The customer doesn’t realize any value until the last iteration when you put it all together, which means if the project had to be stopped early, the client is left with nothing useful. Even worse, the customer can’t see how everything is going to work together until you put it all together for them, so they don’t have much ability to give feedback on your work.
Always deliver in iterations that provide value to the client, so they are left with something useful that provides value no matter how deep in to the project you are.
by: Chris Dagenais
Recently there was some major shuffling of the development teams at Point2 which resulted in me leading a team of seven developers. Of those seven only two were on my previous team. Even though all of the teams were developing software using Scrum, each of them had specific processes and practices. One of my challenges as the Team Lead was finding a way to effectively bring all of these people together who were used to their team running a certain way.
The easiest thing I could have done was to just decide how things were going to run and inform the team. This would have also been the worst thing I could have done. Teams are supposed to self-organize and they are going to have an easier time doing this if they are working in a way that they feel comfortable.
So what did we do to expedite the fusion of the team members into a new group?
- Get the team into a room to hammer out ideas regarding how iterations were going to run such as Sprint length, required meetings, etc.
- Encourage all team members to talk about why certain things worked well on their previous team. We want to make sure that the best processes and practices are being discussed. It’s easy for people to be less opinionated in a new group.
- Manage the expectations of the team and the customer/business. The team and business people were likely used to work getting done at a certain pace. Getting a new team to mesh is difficult and takes time. Make sure everybody understands this to prevent the team from getting frustrated, and the business from wondering why things have slowed down.
- Even though we do hold Retrospectives and Root Cause Analyses at the end of every Sprint, it is in the early stages of the new team that these are critical. These are the times where problems with the processes and practices will most likely be raised and discussed.
- As a Team Lead or ScrumMaster you have probably seen what works well and what does not. Find that balance in guiding your team in the decision making process without pushing them down a path for purely personal reasons. There may be times that they want to try something that you have seen fail previously. Under certain circumstances it may be best to let them try it. If it works, great! But if it does not it can also act as a good learning experience.
The new team has been together for about three weeks and has been running quite well. Our Sprints have been a little bit unpredictable and sporatic as we are working on a mash-up of stories from previous teams. Despite that our velocity was still most impressive for a new team.
I think the majority of the success has to do with the Agile maturity amongst our developers, but I also think that the team working in a way that they have fashioned is also playing a factor. It may seem like an obvious statement to say your team should decide how things are run, but it is also easy to get stuck in one’s ways, and just do what you’re used to.
At Point2, we have recently embraced using the concept of a “Walking Skeleton” as the first development work we do when starting a new project/module/bundle. This approach allows us make sure all of the overhead of a new project is accounted for and functioning properly before our project becomes too complex to allow for. We create the walking skeleton as part of our first sprint which ensures we have some deliverable by the end of our first iteration. By the time our walking skeleton is complete we have worked all of the kinks out of our CI, deployment, and testing strategies which are very straight forward still at this point.
Unfortunately, when my team recently started its current project, we dropped the ball when it came to finishing the walking skeleton end-to-end before starting on more complex tasks. It didn’t occur to as at the time that this was a bad thing because we were still making visible progress. In retrospect though, we acknowledged the difficulties and extra tasks we had created for ourselves by neglecting to help the skeleton take its first steps.
One issue we encountered was not being able to easily demonstrate new functionality to the product owners for sign-off. Because we had no certain way of running data through our application end-to-end (not even “Hello World”), we ended up fudging steps in the process just to see the desired results. This didn’t allow the business to try out the features without first having knowledge of the internal mechanics of the product. It also made it difficult, if not impossible, to properly functionally test the system in a true black-box fashion.
Another speed bump we ran into was the extra refactoring we found ourselves doing because the interfaces between components in our system were still evolving. We had not pushed data through each moving part so this meant that the way the parts fit together had not been clearly considered and defined. As the pieces came together we realized different interfaces were more appropriate and with interface refactoring comes unit test refactoring. Now I normally encourage a healthy dose of refactoring to every piece of code but not when I just finished the code for the task earlier that morning. Had we actually pushed something all the way through the pipe, we might have realized earlier that our initial architecture was not appropriate and, in fact, didn’t even make sense.
The causes we came up with were interesting but not surprising. We decided the main reason we forgot about finishing the walking skeleton was we were just too excited to get started on the new project, using new technology.
We came up with two action items to address the issues we came up with:
- Simply remember to plan for a walking skeleton next project.
- Blog about our experience to help others avoid the same problems.
By: Jesse Webb