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.
At the end of every development iteration we always do a retrospective and a root cause analysis meeting. In our retrospective we cover what went well, what did not go so well, and come up with action items for things to try in our next sprint. In our root cause analysis meetings we usually pick some problem that occurred, try to figure out why it happened, then understand how we could prevent this problem from happening again in the future. Our root cause analysis meetings are usually always on a negative topic. However, during our recent project we decided to change things up and do a root cause analysis of the following question:
Why did our last project go so well?
This may seem like a strange question to ask, but often in root cause analysis meetings we tend to focus only on the mistakes made during a project. When problems occur you need to identify the root causes of those problems to prevent them from happening again. While in a project that goes well it is just as important to recognize what we did right this time to ensure we understand “why”. What did we do different this time that worked? What were the crucial decisions made that kept the project on track? In our root cause analysis we found some key decisions, that in retrospect were important but at the time did not seem critical.
Failing fast when a decision starts to become problematic
For our project we thought we had a clear, straight forward design to work with from the beginning. However, after spending even just a day spiking some ideas our design immediately started to show cracks. Our design that on the surface looked simple, turned out to be far more complicated to implement than we had imagined. A large part of the reason for this problem was that our project was to make changes to an existing application about which no one on our project had any previous knowledge. We immediately had a team huddle, called a “Just In Time” design meeting and corrected our course. As a result, we lost a day, instead of a week or a month going down the wrong path.
Consulting experts early
When we started our project we knew of a few ways to accomplish our task, we had received suggestions that sounded fine, but we really were not sure if our approach was the best solution available. Fortunately we have some very experienced people in our company that have spent many years contracting and as a result have an incredible variety of experiences from which to draw upon. So we called a quick design meeting with one of these experts, showed them what we were thinking of doing and just picked their brain for ideas. It turned out our expert was able to come up with an approach to our problem that not only would allow us to complete the task within the time-line given to us by our business team, but at the same time would allow us to implement a cleaner solution.
Keeping code ownership high
We had no one person on the team that if they were sick for a day it would prevent a task from being completed. During our project we made sure every line of code was written with a pair (We always try to pair program every line of code) and switch pairs regularly. Because of this knowledge sharing we did not have any “Experts” on any one area of the application. We always had at least 2-3 members of the team who were knowledgeable enough on any given area of the application be able to bring another developer up to speed.
Break all stories into small tasks with a clear definition of “Done”
The stories we work on during a sprint always show the business value we are adding, but from a developers perspective there are usually multiple tasks required to complete each story. At the start of each sprint we held a task breakdown meeting for breaking each story down into a set of small tasks. Our team found that having a set of clearly defined tasks for each story was very important to keeping the project on track. With any story we receive from the business team their will be questions and as a result we found that doing this task breakdown meeting helped flush out many of those questions at the start of the sprint, as opposed to after development had already began, which in the past was usually what happened. It made it clear to our team lead and business analyst exactly what work was being done, who was doing it, what tasks had been completed, and what tasks had not yet been started. Also this gave our business analyst and team lead a better idea of when to expect demos since they could see how many tasks were remaining before a story would be completed.
Demo to business team often
We started our project doing a fairly poor job of demoing but this was corrected after one of our sprint retrospectives. Business analysts need to see the work being done and often will think of something that was missed, or see something that perhaps spawns another story. One of the easiest ways to ensure that what is being developed matches what the business team wants is to keep them in the loop and an excellent way to do that is through frequent demos.
Quick feedback from business team
During development there are always going to be cases in business logic spotted by developers that were missed during the initial planning phase. When a developer spots a missed case and brings it up to the business team, quick feedback from the business team can play a major role in keeping the project on schedule. In our last project this turn around time was often hours, if not shorter in most cases.
Keep the systems team involved from the start
The people who will be deploying the application and hosting it should be involved right from the start of the project. Your systems team has experienced many deployments and also know the pain of hosting a problematic application. Allowing the systems team, who will be responsible for the application after development has been completed, to be involved in key decisions can greatly improve the chances of a successful deployment and potentially reduce the cost of hosting the application.
Having your team do a positive root cause analysis can be very useful. It sometimes seems like after a problem in one sprint, we focus in the next sprint so much on improving in that one area that we sometimes slip in areas where we were previously doing well (for our team it was demos). On previous projects I have worked on, we definitely tried to follow each of these best practices outlined in our positive root cause analysis. However, since we moved to Agile almost two years ago, this was the first project where everything just “clicked”.
Two Sprints ago something happened for the first time since I have been a Team Lead – my team’s velocity was a big fat zero. As a team we are fairly experienced in Agile and Scrum and quite self-organizing, yet somehow our Scrum board was portraying us as a rookie crew. The first question that may come to your mind is, “did you guy’s have to deal with a lot of production bugs or injected stories?” Sadly the answer would be, no. The team obviously wanted to get to the bottom of this anomalous Sprint so performing a root cause analysis seemed like the right thing to do.
After working through a root cause analysis exercise as a team (this is actually something we do on a weekly basis) we had a pretty good idea of what had contributed to us delivering a big fat goose egg. There were no real surprises revealed, but it did help to get some stuff written down and in front of our faces. On a positive note, the team did agree that even though we didn’t burn up any stories, a lot of work actually did get done. So what went wrong?
- The was a lot of technical unknowns in the new project we were working on resulting in stories with fuzzy boundaries.
- The team was unsure when they were done a story, and as a result they dragged on longer than they should have.
- Our stories were obviously poorly broken down.
- We were not representing the work that was actually getting done properly on our Scrum board.
- The knowledge gained from earlier spikes may not have been leveraged to their full potential.
- We had gotten a little too comfortable in our Sprint planning process. Our previous projects (in the recent past) were usually well defined and understood. Because of this we found ourselves spending less time planning because we could get away with a just in time mentality. This didn’t work for our current project.
Naturally we want our root cause analysis exercises to result in some sort of action plan. With an understanding of what led to our questionable Sprint, the team was able to put some corrective measures into place for the start of the next Sprint.
- For each story/task on the Scrum board, represent hurdles and stalls visually. Even though we talk about them in daily stand-ups, seeing them on the board can help show severity if it goes on for a long period of time.
- During our kick-off meeting break down each story into small, bite-sized tasks and use these on the Scrum board. They should be small enough that we have no cards on the board that have a complexity value over 1 – the smallest size possible on our scale.
- Do not end the kick-off meeting until all task cards are completed, prioritized based on importance and dependencies, and a commitment has been agreed upon.
- If we find ourselves doing something that is not represented on the Scrum board,
- ask yourself if you should even be doing it.
- if you should be doing it, write up a new card and put it on the board to ensure that everything we do is tracked.
- Continue with one week Sprints.
So how did the team fare after putting their plan into action? They met their commitment. The kick-off meeting resulted in a Sprint plan that was straight-forward and well defined. It provided a clear-cut set of tasks that the team could easily base their commitment on. During the Sprint they were more mindful of the work at hand and made decisions as to whether it belonged in the iteration or not. As a whole we re-focused on areas that we had gotten too comfortable with and neglected.
It was very satisfying to see the team face this problem head-on. They calmly analyzed it, devised an action plan, and executed it. They could have easily panicked, but they didn’t. They proved that they were a mature team that could recognize a problem, and use their agility to correct it.
At Agile 2009 I attended Brandon Carlson’s talk entitled “Value or Velocity?“. Velocity is often thought of as a measure of speed or productivity, but if a team can deliver x story points’ worth of the wrong product, and another team can deliver the same number of story points’ worth of an amazing product that everyone wants, but the two teams are said to have been equally productive based solely on their Velocity numbers.
In other words, getting more done is meaningless unless you know you’re getting the right things done. To make sure you’re doing the right things, Brandon suggested assigning value points to epics.
The simplest method is Value Poker, kind of like Planning Poker. The Product Owner assigns a value to each epic relative to other epics in the sprint backlog, with the smallest amount of value being a “1”, just like the story that requires the smallest amount of effort is a “1” in Planning Poker.
Another, probably more accurate method is Attribute-Driven value assignment. In this case, all product owners and stakeholders meet and assign values to epics together. Each stakeholder will know the most about one or a small handful of attributes. Some possible attributes include: market differentiation, strategic alignment, usability, system stability, sales commitment. Draw up a chart with each attribute as a column, and each epic as a row. The stakeholders for each attribute assign a value of 0-3 in each row for how valuable the epic is for that attribute. Total up all the values for a row and then you have numbers you can sort on, and that can become your prioritized list,
To a stakeholder it is much more meaningful to hear “this month the team delivered 31 value points” as opposed to “this month the team delivered 31 story points”, because at the end of the day it’s delivered value that customers pay for, not complexity of stories.
By: Tefon Obchansky
So what does a couple do when they are getting married in less than two weeks, and there is a pile of things to get done for the wedding? Well, when the groom-to-be is me, the obvious answer is that they organize the work using Scrum. I had floated the idea to my fiance a little while ago, and she wanted nothing to do with it. In her mind she felt that a list on our whiteboard would be just fine.
When we found ourselves a mere two weeks from the big day, I once again asked, “are you ready to do Scrum yet?” She reluctantly agreed, tweeting her displeasure for the world to see and we got underway. We knew there was a pretty big list of things to do so we started off with a Blitz Planning session.
I grabbed a stack of sticky-notes and we started to blurt out tasks that needed to be completed if this wedding was going to fly. As the tasks were identified I jotted them down onto the sticky-notes. Once we felt that we had a fairly comprehensive list, we took a few minutes to give each story a complexity value. A value of 1 was fairly trivial such as “pick up the wedding rings from the goldsmith”, while a 5 was reserved for things such as, “write our wedding vows.” We stuck with the Fibonacci numbers to allow for uncertainty in the larger tasks.
Since we had approximately two weeks before the wedding it made sense for us to have two, one week Sprints. With a table covered in pink sticky-notes, we moved each of the stories into one of two piles representing each Sprint. Now we were able to do a more fine-grained planning of each Sprint.
We knew that the more complex stories had higher risk associated with them so we made sure to start those as early as we could. We did however remain mindful to not overload Sprint 1 with only the large stories. There were some stories that needed to be done on certain days, and some that had dependencies on other teams which required some clever shuffling.
It didn’t take very long before we had our Scrum board organized into two Sprints. We split the board into columns representing each day allowing us to put the story cards onto the day we intended to complete them. This gave us a really good visual representation of the work ahead. This layout is actually very similar to the Scrum board my team at Point2 uses. Having a visual representation of when stories are scheduled to start and expected to finish is a great tool for the team, as well as stakeholders to get a sense of how well the Sprint is going.
We’re about halfway into Sprint 1 and things are going as I was expecting. Stories are being burnt up on a daily basis, while some of the more complex ones are taking longer than we had initially estimated (sanding and re-staining the kitchen light fixture…..which needed to be done prior to our rehearsal dinner at our house). Some stories we had hoped to start on a certain day have not yet started, while some were completed early. We’ve also seen a couple of new stories injected into the Sprint requiring us to reshuffle the board.
Obviously the Scrum process at home can only be, “Scrum-like”, but as the Sprints progress I am seeing many of the same things that my Scrum team at Point2 experience from Sprint to Sprint. So maybe Scrum isn’t actually going to save my wedding since I don’t think it was ever in jeopardy, but I do think it was a great exercise to see how applying an Agile method in a completely non-technical area yielded many of the same results seen in the software development industry. If anything, applying Scrum to the wedding preparation was a useful tool in devising a plan, allowing us to visualize and execute that plan, and have a little fun along the way….geek-style.
Ahh, the ubiquitous Post-It® Note. My workspace is covered with lovely multi-coloured notes, or it was until I discovered Digital Notes. The unassuming Post-it has become a legend but I wanted to share it again, as told in The Knowledge-Creating Company by Nonaka, and Takeuchi.
“Art [Fry] sang in the church choir and noticed that the slips of paper he inserted to mark selected hymns would fall out. He decided to create a marker that would stick to the page but would peel off without damaging it. He made use of a peel-able adhesive that Spence Silver at the Central Research Lab had developed four years previously, and made himself some prototypes of the self-attaching sheets of paper.
Sensing a market beyond just hymnal markers, Fry got permission to use a pilot plant and started working nights to develop a process for coating Silver’s adhesive on paper. When he was told that the machine he designed could take six months to make and cost a small fortune, he single-handledly built a crude version in his own basement overnight and brought it to work the next morning. The machine worked. But the marketing people did some surveys with potential customers, who said they didn’t feel the need for paper with a weak adhesive. Fry said, “Even though I felt that there would be demand for the product, I didn’t know how to explain it in words. Even if I found the words to explain, no one would understand…” Instead, Fry distributed samples within 3M and asked people to try them out. The rest was history. Post-it Notes became a sensation thanks to Art Fry’s entrepreneurial dedication and dogged persistence.
(Nonaka I, Takeuchi H. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. 1995)
That entrepreneurial spirit has been part of 3M’s corporate culture almost since inception. As stated in the William L. McKnight Management Principles:
“As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative. This requires considerable tolerance. Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way.
“Mistakes will be made. But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs.
“Management that is destructively critical when mistakes are made kills initiative. And it’s essential that we have many people with initiative if we are to continue to grow.”
Chris touched on this when he blogged about Failing Should be Easy and even Why don’t people like my ideas?!. Art Fry was given the opportunity to fail. When people didn’t like his idea, he proceeded to find a way to prove that his idea truly was great.
I’m proud that we here at Point2 allow people to fail; in fact, using Test Driven Development we ensure that everyone fails at first.
We give people time to explore and experiment, and everyone has some time for professional development.
Incidentally, Ken Schwaber’s early paper, “SCRUM Development Process” references heavily the work of Takeuchi and Nonaka and their description of a rugby organization style.
By: Kevin Bitinsky
When Point2 adopted Scrum over a year ago we started with 30 day iterations. The process was new to us and it seemed like a reasonable starting point. As we ironed out our practices and got more experience we naturally started to make changes to improve how we did things.
After running through a few 30 day Sprints we soon realized that they were just too long. We were finding that at the end of the Sprint we were unable to remember what we did at its start. This became glaringly apparent during retrospectives. The decision was made to move to two week Sprints, and that is they way our six teams have been operating ever since.
My team had been throwing around the idea of shortening our Sprints even further over the last few months, but at our last Retrospective we decided to actually take the plunge. Even though we were being reasonably successful with two week iterations, we still felt that we could go faster. One week (5 day) iterations seemed like a good way to help take the team forward. Here’s how we think the change will affect the team.
- Even though two weeks was not long, it still left enough room for a large amount of stories to be part of the Sprint. This meant we had a broad focus. One week iterations would allow us to easily visualize the Sprint. Our focus would be much sharper
- One week Sprints would hopefully allow us to better accommodate change that comes in an Agile environment.
- With weekly retrospectives would come more organized discussion to fine tune our process even further (that’s not to say we would not continue to make mid-Sprint changes if need be).
The team plans to make the transition at the start of the next Sprint. We understand there may be a bit of extra overhead in regards to planning and estimation meetings, but feel that these will get considerably shorter, having less impact on the actual Sprint.
Without actually having tried it yet the team just has a “gut” feeling that this will make us go faster. Just think about it for a second. If you are in a 400 metre race, you will have to run at a slower pace in order to finish. Cut that race down to a 100 metres and you should be able go to all out. I look forward to seeing how this will impact the team and will do follow-up posts reporting on our progress.