Yesterday, I was using Excel to fill out a list of names and e-mails. As I was happily (well not really, I was typing in a bunch of email addresses) going about my business, I accidentally came upon a feature of Excel I’ve never seen before (more about that in a bit). Now, I should come clean and say that I’m not an everyday user of Excel, and I am certainly not what I’d call a power user. I’ll bet there are a lot of people who know about this feature, but it was new to me.
The thing that made this stick out was that it just came out of nowhere while I was using the program. I’ve seen other pieces of software do that and only end up creating a jarring experience for the user; this was seamlessly done. Most importantly, it helped me get my task done faster, and to me, that’s what software is supposed to do. This is a place where the folks delivering Excel did something that made my job easier in a really nice and unexpected way. I need to challenge myself to do this for my users more often.
So what was the feature? Check it out. Keep in mind this is a reenactment (so I don’t share a bunch of IDT employee emails. You’re welcome). The actual list of e-mails I was adding was much longer, so the time it saved me was significant.
(P.S. If anyone from Microsoft reads this, if 2013 had the feature, I’d have definitely given you a smile yesterday!)
It really goes without saying, but I had a fantastic time at Iowa Code Camp on Saturday. It’s always a great reminder of the amazing folks who work in technology here in the Midwest. Code Camp is often the only chance I get to talk to some of these folks every year, so it’s always awesome to catch up.
I attended some great talks and had some really great conversations just sitting around the tables between talks. This is always such a great event.
So let me thank the people who came and listened to my talk. I really appreciate you being there and hope that I was able to give you even one piece of information you can take back to your work to make things better for your team. If so, then I feel my time was well spent.
I also want to thank all the people who volunteer their time to put the event together twice a year as well as the folks who come in from all over the place to share what they’ve learned. You are all truly an amazing bunch of folks.
If you couldn’t make it, look for the next one coming this fall in Des Moines. I’d love to see you there!
There are a lot of people who seem to think that agile project management means there aren’t any rules, and you simply do whatever you feel like to get software deployed. My best guess is that attitude comes from reading the agile manifesto and the twelve principles of agile without actually understanding what they’re saying.
It seems that people are over-focusing on phrases like “maximizing the amount of work not done” and “working software is the primary measure of progress.” By cherry picking phrases and taking them completely out of context, agile can be twisted into something dark and evil.
I’ve listened to people justify horrible software practices by saying that they’re “more agile” because it helps them deploy software more quickly. Never mind that what they’re delivering is riddled with bugs and not remotely what the users needed. “No, I couldn’t actually test the software. It had to be ready for the sprint review!”
When I hear things like that, I’m reminded of my favorite comic strip growing up: Calvin and Hobbes by Bill Watterson. From time to time Calvin and his best friend, and stuffed tiger, Hobbes would play a game of their own creation called Calvinball. In Calvinball there are two rules.
A) The rules are made up as you play, and new rules can be decreed at any time. 2) Calvinball cannot be played the same way twice. (There also seems to be a rule that you have to wear a mask, but that should just be obvious)
So from now on, when I hear people describing their agile implementations and explaining why testing is a waste of time, customer interaction is stupid because they know what the customers need better than the customers do themselves, or that iterations are for wussies, I’m going to refer to them as Calvinball agile implementations.
In this series of posts, I’ll be addressing the misconception that it’s not possible to plan releases using agile methodologies. In a previous post, I talked about the three sides of the “Iron Triangle” that can be adjusted when project milestones start slipping. In this post, I’ll talk about planning releases for a Scrum team where schedule (time) is flexible.
Why Flex Schedule?
The most common reason a team would want to flex schedule instead of scope is when they are running a parity project; a project that is replacing the functionality of an existing system. Ideally the team would still only replace portions of the system at a time and use this method to plan each release. However, this planning method works even if this is not possible and an entire system needs to be released at once.
As with flexing on scope, this kind of planning requires two things. First, that you have a well-groomed and prioritized product backlog. Second, it requires the team to have been sprinting long enough to have a fairly predictable velocity. Lacking these prerequisites will reduce the accuracy of this method of planning.
Best and Worst Case Scenarios
Another similarity to flexing on scope is that this planning method requires a team to determine their best and worst case velocities. Rather than restating how to do that, I’m just going to refer back to the post on flexing on scope.
Planning for fixed scope is very straightforward. Simply add up the effort for all the backlog items that need to be in the release. We then essentially build a burn down chart for the release, plotting the projected burn given the team’s average velocity. After we’ve determined what the average burn looks like, we also draw lines for the best and worst case velocities. Now we’ve got a range of time that can be reported for completion. In the example below, we would expect the release to be finished in 5 to 8 sprints or so.
Just like with flexing on scope, we would update this burn with current data after each sprint. This will cause the date range to narrow as we get closer to completion.
What About Scope Creep?
Interestingly, I often hear the term “fixed scope” when what is really meant is “minimum scope.” The scope is rarely actually fixed; there are often requirements that have been missed, and in parity projects, not implementing those requirements isn’t usually an option.
What’s the best way to account for requirements that have been added to the release? Ok, maybe best way is a bit optimistic, but here’s how I do it. Let’s say we’re working the release from the chart above and 75 points worth of scope gets added to the release during the second sprint. I prefer adding the new scope below the original x-axis. This visually differentiates schedule changes based on newly introduced scope from those based on varying velocity. It’s important for stakeholders to understand the consequences of changes in scope and not blame changing schedules on “developer laziness.”
After adding the scope to the graph, we now draw a new baseline to get the expected schedule. We can now clearly see that adding 75 points to the scope pushed our delivery dates out to somewhere between 5.5 and 9 sprints from our start date.
I hope you find these planning techniques helpful. Let me know if there are other situations you run into that make planning difficult.
In this series of posts, I’ll be addressing the misconception that it’s not possible to plan releases using agile methodologies. In a previous post, I talked about the three sides of the “Iron Triangle” that can be adjusted when project milestones start slipping. In this post, I’ll talk about planning releases for a Scrum team where scope is flexible.
Why Flex Scope?
A team might choose to be flexible on scope when they are making releases on a regular schedule, or if requirements need to be implemented by a hard date. In this situation, because the release date is set, if milestones are slipping, the product owner will need to make decisions on which features must be in the release and which can be postponed for a later release. Let’s talk about how the business can make plans around which features are likely to make it in a release and which won’t.
Planning in this way assumes two things. First, it assumes that you have a well-groomed and prioritized product backlog. Second, it assumes that the team has been sprinting long enough to have a fairly predictable velocity. If these prerequisites are not met, this method of planning will not be particularly accurate. This inaccuracy isn’t a symptom of trying to plan for an agile methodology, though. Planning without those prerequisites would be similar to trying to plan a waterfall project without having good requirements and without knowing your resource availability.
Best and Worst Case Scenarios
With this kind of planning, the team must first decide on a best and worst case velocity. This can usually be done informally because these values will be refined as sprints are completed.
Let’s imagine a team has an average velocity of 40 story points. After some discussion, the team decides that if a sprint goes horribly; if everything that can go wrong does, then they would likely get a velocity of about 25 points. Then the team talks about an amazing sprint. One where the Scrum gods smile upon them and absolutely everything goes right. They decide that if that were to happen, they might have a velocity of around 55 points.
The team then uses these numbers to determine a range of points they can complete by the release date. In this example, let’s assume the release is to happen after six sprints. The team calculates the number of points they should be able to complete for the best case and for the worst case.
Worst case points: 25 * 6 = 150
Best case points: 55 * 6 = 330
The team then draws lines on their backlog at those values. All the stories above the worst case line will definitely be ready by the release date; even if everything goes wrong in every sprint, the team will still complete those stories. All the stories below the best case line will definitely not be done by the release date; even if everything goes perfectly in every sprint, the team cannot get to these stories. The stories between the two lines are maybes; the team may or may not complete them depending on what happens during those sprints. At the beginning of the six sprints, the team can’t be more precise that this; they will continue to refine the estimate as they sprint, though.
After each sprint, the team will recalculate the best and worst case lines based on how many sprints are left. For example, after three sprints, with three sprints remaining, the worst case will be 75 points (25 * 3) and the best case will be 165 (55 * 3). The team then redraws the lines for the backlog items that have yet to be completed. As the release approaches, the number of stories the team knows they will complete will increase. Similarly, the number of stories the team knows they will not complete will also increase while the unknown section will shrink. This will allow the product owner to be more and more confident about what will and will not be in the release as the development progresses.
Planning With the Customer
As the scope estimates are refined, the product owner, working with the customer can determine if the stories are still prioritized correctly. Sometimes there are features the customer feels must be in the release, but after a handful of sprints it becomes apparent that they will likely not meet the cut. When this happens, the customer can start working with the product owner to re-prioritize as soon as this is discovered.
Take it to the Next Level…
Some people may feel uncomfortable with the team just deciding what their best and worst case velocities should be by using the old “wet finger in the wind” method. If this seems a little unscientific, it is possible to add some rigor if you have historical data on the team’s velocity. If this is the case, you can calculate the mean and standard deviation for the velocity over a period you feel comfortable with and use these values to come up with minimum and maximum velocities with given confidence levels.
By taking this data-driven approach, it is now possible to produce scope estimates that also include a general confidence level in that estimate based on historical data and typical variation in velocity.
Hopefully this has gotten you thinking about the kinds of information you can share with your project stakeholders for schedule-driven efforts. I’ll demonstrate a similar technique for scope-driven planning soon.
A common misconception about Scrum is that teams using it can’t do planning. In the next few posts, I’ll be demonstrating some techniques that can be used to plan releases for teams using Scrum.
In a previous post, I talked about the options project teams have when a project starts to fail. In it, I described the three sides of the “Iron Triangle” that can be adjusted when things start slipping. In this post, I’ll talk about choosing to flex the cost side of the triangle.
What does flexing cost mean?
Being willing to flex on cost can mean several things. It could be buying some additional tooling, buying new hardware, or setting up new environments. Those are all things that might help get a project back on task. However, when most people talk about being flexible on cost what they often mean is adding additional resources, and that is something that rarely helps get a failing software development project back on track.
Other folks have covered that topic much better than I can, so I won’t go into all the gritty details. A good place to start is the book “The Mythical Man Month” by Frederick P. Brooks Jr, but there is a wealth of information available on the internet dedicated to this topic.
Why do people do this? What are we hoping to improve by adding resources to a Scrum group? One word: velocity.
Why doesn’t this work?
Velocity is a tricky beast. At its simplest, velocity is a measure of how much work a Scrum team can complete during a single sprint. While the concept of velocity is simple, understanding how it is affected by changes to a team is anything but. In general, adding new people to a Scrum team tends to initially disrupt the ability of the team to get work done.
From a purely technical perspective, the usefulness of adding resources to tasks relies on that work being parallelizable. In other words, the work can be broken up into pieces that have no dependencies on each other and can be consolidated into a whole after the pieces are all complete. Unfortunately, most software development tasks don’t fall into this category, and adding additional resources only adds to confusion and communication problems.
Ignoring technical issues, the people and personality challenges caused by adding “new fish to the pond” can also prevent velocity from immediately improving. These kinds of factors are also very hard to mitigate and usually just need to run their course.
Can additional cost ever help?
While adding more resources to a Scrum team in the hopes to have an immediate positive impact on velocity doesn’t tend to work, there are ways to increase the team’s velocity in the long run.
Adding members can eventually increase a team’s velocity. If the need for more capacity is recognized early, adding new members to the group will increase the velocity after the group has had the time to reintegrate. How long that takes varies from group to group. These additions to the group would ideally be new permanent members of the team, not simply burst capacity brought in to push schedule to the left. There is also a “sweet spot” for team size. If the team grows past about nine people, it may be wise to split the group into more than one Scrum team.
If team members are not fully allocated to the Scrum team, increasing the existing team members’ allocation will absolutely allow them to get more done each Sprint. My preference would be for folks to be 100% dedicated to their Scrum team, but I also live in the real world and understand that that doesn’t always happen. If your Scrum team members aren’t 100%, making them full time is the best way to increase their capacity for work.
So how does this help with planning?
It doesn’t, much. Since it’s really not possible to know what effect adding team members will have on velocity, you can’t really plan accordingly. Bummer.
Given my druthers, on projects I’m working on, I’d much rather be flexible on schedule or scope than on cost. I’ll talk about those in future posts.