Lately I’ve been coaching a team with the talented Jordan Baker and Rob Jackiewicz of Scryent, the driving force behind Plone in the Toronto area. When they left for the just finished Plone Conference 2009, I wished I was going with them, not so much because of Plone (though I did watch some of the talks online – 4.0 looks awesome thanks to Dexterity and Deco) but because of the amazing community that surrounds the product.
Time to tally up the total thus far me thought, and to some surprise discovered most of my coaching work this year has Plone connections: Web Collective, training at Plone Symposium East, Good Steward who attended the training, and now Scryent.
That 1% is now over $500, with two months left in the year. Looking forward to leaving a cheque in the Foundation’s Christmas stocking.
If you are looking for a financial way to give back, come join me in this manifesto.
The future of Plone looks bright because there are caring, talented, committed people behind it. Hope to see some of you again, maybe at the next North American Symposium.
How can I continue to stay connected and to give back to a community that has given me so much?
I’ve been wrestling with that question for a while. My connection to Plone the product is becoming less and less. I don’t use Plone in my work any more, now that my focus is on training and coaching Scrum, an Agile software development framework.
Meanwhile, my ties to Plone the community remain. I’ve been fortunate to work for companies that do build Plone solutions: Jazkarta, ifPeople and currently Web Collective, and am exploring options with a few others. Each company is doing amazing work, progressive in spirit and deed. That higher purpose thinking pervades the community, and is another tie that binds me.
So I find myself in this awkward situation – how to contribute and remain connected without immersing myself in the technology that binds everyone else together?
Then, my last day at the Plone Symposium, an idea came to me – donate 1% of all Plone-related earnings to the Plone Foundation. Yeah, I like that. Any time I work with an organization offering Plone-related services, the 1% pledge applies. And just for fun, let’s make it retroactive to the start of this year, So far, then, that donation totals over US $125, maybe enough for printing some new Plone schwag from the great minds at SixFeetUp.
I don’t know where my Plone-enabled journey will go from here. After 6 years, I hope we’ll dance for a few more. We’ve got more world changing to do.
I consider Mike Cohn one of the best on the topic of Agile estimation. His 90 min presentation on how to estimate is well worth your time. I took his one day course and all of the material in the presentation appears to come from that course.
Mike is truly inspired to find the best ways to estimate. He once forced each of his teams to pick a different method of estimating, too see which would win out a la Estimating Survivor.
Learn why relative estimating is better than absolute, how too much information can lead to poorer estimates and get good at (planning) poker plus a whole lot more.
So you’ve gone over requirements, and have an idea of what needs to be done, then the client/project manager pops the question developers dread:
How long will it take?
Then, depending on your situation, you might:
Give a number based on gut feel
Look at historical numbers for something of a similar size
Call a psychic hot line
Break down the job into smaller tasks and try to estimate those
No matter what your approach is, estimating is just plain hard. Is there hope?
Estimate in two parts – part one: relative sizing
It turns out that we humans are pretty good at relative estimates. We can compare two or more items and agree quickly on the size of one compared to the other. Take these dogs, for instance. How much larger is the labrador on the far left compared to the poodle on the far right, assuming by large we mean height? If we gave the poodle a relative size of 2 compared to most dogs, we might say the lab is a 5. We can then give a relative number to each dog without too much effort.
Now if I were to ask you for the specific height of each dog, we’d have a much harder time both estimating and agreeing on the final number. We’re not so good at actual estimates. Estimating helps us plan, but we don’t want to spend so much time on it that the cost outweighs the benefit.
Now imagine if each of those dogs was a small feature of a system your team plans to build. We’d then have a list of features each with their relative size, and a total size for all features. That gets us the first part of estimating, that is, how much work there is to do, but we still don’t know how long it will take to do the work.
Part two: how much can we get done in a specific amount of time?
For reference sake, let’s call our unit of measure ‘points’. We can determine how long a project will take by dividing the total points by an estimated velocity. Velocity is the rate at which the team completes work. For instance, one team might be able to complete 40 points of work on average over 2 weeks. If total points is 200, then the team will need 10 weeks to complete everything planned:
200 points / 40 points every two weeks = 5 * 2 weeks = 10 weeks
So how do we determine this velocity?
There are several ways to do this, but a simple way to get started is to take a random or representative set of stories (what features are called in Agile), break them down into tasks, and then estimate those tasks in hours.
Let’s say a team that has 100 hours in a 2 week sprint. They take a sampling of stories and come up with the following estimates:
Story A (13 points): 20 hours, 20 hours total
Story B (8 points): 15 hours, 35 hours total
Story C (5 points): 10 hours, 45 hours total
Story D (13 points): 20 hours, 65 hours total
Story E (8 points): 15 hours, 80 hours total
At this point, the team feels they can’t take on any more stories for the sprint. They leave a 20% buffer for the unexpected.
The total points planned for the sprint is 47 (13+8+5+13+8).
The team will need a little over 4 sprints to finish, so let’s call it 5: 200 points / 47 = 4.3, or 5 sprints.
We can also determine worst case / base case scenarios, based on how far along we are into the project, using what is called the Cone of Uncertainty principle. Mike Cohn talks about how to apply this in his book.
Bonus: now we can calculate project cost easily
We can also calculate the cost of the project by totaling up hours for each two week time box, or sprint as it’s typically called in Agile. If the team spends 100 hours every 2 weeks at an hourly rate of $100, then each sprint costs $10k and the project cost is expected to be $50k:
I’ve tried to illustrate some simple techniques to create better estimates. Break the task into two parts, first calculating the size of work and then the speed at which work can get done. There is a lot more to estimating that I haven’t covered here. If you’d like to learn more, I’m hoping to offer a one day Agile course at the upcoming Plone Symposium East. If you can’t make it, please post your comment / question below.
The catch is I need 10 people to sign up to make the trip and effort to prepare cost-justifiable. You see, I would be going mainly to the Symposium offer this course. Agile is technology agnostic, so while I am an active supporter of Plone, I don’t need to brush up on my buildout skills or learn the ins and outs of deploying Plone at a university (though I’m sure Calvin and Michael will give insightful and entertaining talks). I want to offer something back to the Plone community, and Agile is what I know best. Reconnecting with Plone peeps over beers comes a close second. 🙂
My passions lie in helping others, and I get my satisfaction in helping individuals enjoy their work more, teams becoming more productive and clients pleased with the result. I get to support teams as they embrace more fully Scrum’s five core values: commitment, focus, openness, respect and courage.
Is it Worth the Cost?
At US $250, this is the most expensive training option on the menu, but compared to other Agile training offerings, this is a bargain rate. No, you won’t be a super high performing team after one day of training, but you’ll leave understanding a flexible framework you can use to:
Know at each step how the project is progressing (amazing, but true) and use simple charts to communicate progress to the team and client
Get far better at estimates
Adjust the plan with minimal effort, even late in the project when your client wants to make 50 “minor” changes before launch
Lower the overhead of managing projects
Keep developers happy by coding more, sitting in killer meetings less
Lessen the impact of context thrashing, that is doing too many projects / tasks at the same time
Get an agreed upon definition of done to avoid subjective back-and-forth wrangling
and the list goes on…
Plus don’t forget you get to play with Legos for half the day. What could be better?
Scrum is for teams, so to make it easier for companies to send more than one person, I’m offering a 10% discount for each sign up, including the first one. That’s a $25 savings per person. I haven’t figured out how to do that within the event registration system, but I’ll get it to you one way or another. To qualify, you do have to work for the same organization.
Decide By April 30 and Get a Bonus
I need a few more sign ups by the end of this month before committing to buying plane tickets. Will you join me the Symposium? Anyone who signs up by the end of the month can join me for dinner after wards where we’ll dive more in depth on the issues / topics that matter to you.
Special Offer: One-on-One
Want even more help? You can either try and corner me at a pub for free (though quality of responses may be diminished) or join me for a one on one hour session to answer any questions you might have, talk through whatever issues/challenges you are facing. Make your list and get your own personal Agile coach. Email me if interested.
Games are a fun, interactive, effective way to teach. A dose of competition mixed with social interaction keeps people engaged. You learn by doing and reflecting on the experience. Powerpoint, your time is over.
Until recently, I hadn’t had the opportunity to use learning games, since most of my work as an Agile coach is done remotely. In February I tried out the Resort Brochure with The Blog Studio and Thmvmnt with positive results, and then in early March I spent a few days with the Web Collective, all small purpose-driven organizations looking to become more Agile.
Build the backlog. Teams estimate the size of items, and the product owner may re-prioritize based on those estimates, just like in a real project. Some games have pre-determined backlogs, with all items sized and prioritized for you. Seems a little too command-and-control to me, which Scrum isn’t supposed to be.
Multi-team collaboration. Teams work together, not against each other to reach their goal.
Metrics applied to planning process. If you are going to bother estimating, make it useful. Teams estimate the size of their work, compare planned vs. observed velocity (how much they get done each sprint) and see the effect of observed velocity on their release plan.
How it works
This was my first time trying the Lego exercise. The product owner (me) explains to the team the vision for the project, to get everyone inspired and focused. In this case, the team has been hired to build a new city.
The team then estimates the items in the backlog, which includes things like one story buildings, a church, a tow truck and a crane. We used Steve Bochman’s team estimation technique to quickly size up stories. Team estimation turned out to be quicker than planning poker, which is what I had always used in projects. Team estimation and planning poker focus on comparing the relative size of features / stories, which is far easier to do and more accurate than trying to guess the absolute time to build each item. The next day the Air Charity team at Web Collective estimated over 50 stories, averaging between 2-3 minutes per story! Amazing speed given this was their first Agile project.
Once the items are estimated, the teams have guess how much they can get done in one 5 minute sprint, and that is used to determine their initial velocity. We’ll then count up the number of points at the end of each sprint to adjust that number. In the diagram above, the team estimated 18 points per sprint before starting the work. Each section of stories is a sprint.
Watch the passion, focus and determination for yourselves.
What went well
Teams learned the importance of getting enough information from the Product Owner (client) to deliver what the client wanted. Some Lego creations were rejected because they didn’t pass expected scenarios, like being able to open the door on a building without the wall coming apart. The quick feedback cycles of sprints enabled them to fail fast and get back on track.
Everyone had fun learning about Scrum. They went through most of the Scrum process, from release planning to working in 4 sprints, including a demo / review at the end of each one.
What could have been better
Forgot to update burn down chart at the end of each sprint, and with that, the review of the teams’ overall progress in comparison to the release plan.
Need more Lego. One tow truck hobbled on 3 wheels.
With 8 people, team estimation stalled at times. Need to learn more techniques to keep flow moving. Hank Roark (@hroark on Twitter) pointed me to James Grenning’s Companion games for planning poker.
What I will do differently next time
Use a timer that everyone can see
Tweak the estimation process to make it go faster
Keep a check list of items to do during every sprint
I’ll now introduce to you your new contact for getting your blog on Planet Plone, a guy whose voice is destined for radio (or a Plone podcast?), John DeRosa!
John is Director of Web Development for Fisher Communications, where he’s working on new technology initiatives, and doing some Phone theming and customization in an open-source environment. He’s a coder at heart, and enjoys Python quite a bit. Before Fisher, he worked in a number of start-ups, the most successful of which was Singingfish. He lives in Seattle. You can find more details about him on his blog or on LinkedIn.
John looks forward to connecting with Plone people and helping out in this simple but important job.
Planet Plone is the blogging voice of the Plone community. Not following Planet Plone? Add the feed to your favourite feed reader. Want your Plone blog posts on Planet? Submit your name, blog url and feed url to the Plone.org issue tracker. I’m sure John will take good care of you.
Plone has been good to you. You’re earning a living thanks to the efforts of many, and perhaps your sanity has been saved on a few occasions by the kind folks in the #plone chat room. You’ve been thinking for a while about some way to help out, but can’t take on anything too big, and your Plone coding fu is in its infancy.
Well, have I got the perfect job for you!
Become the Planet Plone zoo keeper
Planet Plone is the blogging voice of the Plone community. There are now 115+ blogs registered with Planet Plone. People share all kinds of tips, ideas, rants and news on upcoming events through the Planet. A big thanks to Wichert and others who have done most of the leg work to make Planet Plone what it is today.
Not following Planet Plone? Add the feed to your favourite newsreader.
The Planet needs someone to process requests for blogs to be added or changes made to existing ones.
Maintaining Planet Plone is super simple. Each month, there are at most 2-3 requests to add or change a blog. Trac is used to manage blog submissions. You receive an email notification whenever a ticket is submitted.
All changes are made in one config file. Each entry looks like this:
name = Gerry J Kirk
link = http://www.gerrykirk.net
The first line is the content feed, the second is the name of the author, and lastly a link to the author’s web site.
If you are still with me, then congratulations, you are qualified.
But wait, there’s more
For the more technically inclined (that’s not me), you can if you wish maintain the software that runs Planet Plone. Right now, Alex Clark (aclark on IRC) and Lennart Regebro (regebro on IRC) leap to action whenever there are small fires to put out.
How do I sign up?
Those interested can contact me directly. I’m the current zoo keeper, looking to move into other Plone jobs, marketing in particular. It’s been a fun ride, but now its time to move on to something more substantial.
Feed address to Plone community-related content. If you also blog about other topics not related to the Plone community, then please provide a filtered feed, like all posts with a Plone tag or category.
Select Planet Plone from the Component list
I have some ideas on how to improve the process, we’ll see what is possible. Stay tuned!