tag:blogger.com,1999:blog-1659324396286843782024-03-24T16:32:33.566-07:00Adoption of Agile Developmentwww.adoptionofagile.comTips, discussions, thoughts, and ramblings about my adoption of Agile software development practices.Grant H. Jounghttp://www.blogger.com/profile/02249862941585448340noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-165932439628684378.post-66327554612422874452011-04-23T23:15:00.000-07:002011-07-12T13:19:12.644-07:00The Best Thing You Can Do For Your TeamOne of the most important things I've learned over the course of my career is how important it is to ensure your teams have the information they need to succeed. In my opinion, effective team management is not about how well you direct your staff. It is much more about how effective you are in your ability to provide <b>all relevant information and support for your team to succeed themselves</b>.<br />
<br />
We're lucky that so many Agile techniques aid us with this approach. Story board walls, burn up charts, build monitors, retrospectives - all aim to arm your team with information they need to self-direct towards success. However, project leaders must also embrace this concept themselves to find <i>all</i> information needed as well as the best way to radiate it. Different projects may also have unique definitions of success that project leaders should be careful to examine.<br />
<br />
<span style="color: red;"><b><i>Good managers find a way to radiate all relevant information that your team needs to succeed.</i></b></span> The closer this information is to real-time, the better.<br />
<br />
Somehow, we've grown to expect that it is often management's job to fix problems. However, often the right thing to do is to simply let your team know about the problem so they can fix it themselves with management's full trust and support.<br />
<br />
I've seen good data and metrics go to waste in a report being generated solely for upper management and stakeholders, never to be seen by the team themselves. Here are several issues that could happen as a result of this approach:<br />
<ol><li>Management doesn't read or ignores the report<br />
</li>
<li>Management directs the team to start doing X, leaving the team in the dark on why they should be doing X<br />
</li>
<li>Management implements patch fixes, which don't fix the root cause<br />
</li>
<li>Management comes up with suboptimal solutions since they aren't the ones doing the work<br />
</li>
</ol><span style="color: red;"><b><i>Every member of your team is a professional.</i></b></span> As professionals, they should be given real-time information that allows them to see when they are failing. As professionals, they should be given real-time information when they are succeeding. As professionals, they should be given real-time information that allows them to self-direct themselves towards success.Grant H. Jounghttp://www.blogger.com/profile/02249862941585448340noreply@blogger.com6tag:blogger.com,1999:blog-165932439628684378.post-15040727056366800122010-03-16T21:34:00.000-07:002010-03-18T23:14:21.114-07:00Are Velocity Goals Really a Good Thing?So, some feedback from a colleague of mine (thanks DocOnDev!) got me thinking about whether or not establishing a velocity goal for your team is really a good thing. Seems like an honest enough goal for your team - you have a deadline and specific features to meet and you set an iterative velocity goal as such to meet said deadline and features to be delivered, being careful not to have the velocity goal exceed what your team can deliver.<br />
<br />
But, in setting that velocity goal up for your team, are you really communicating to your team (even if you don't mean to) that ALL you care about is getting to that velocity goal? Perhaps your team is then taking short cuts or avoiding large refactoring efforts so that they can complete stories as quickly as possible, compromising quality?<br />
<br />
Perhaps the answer to this question really lies within each member of the team you're working with. I know developers who would never compromise quality to meet a date, but then you have the opposite spectrum of developers who may hard code unit tests to always pass! DOH!<br />
<br />
I guess the lesson here is to make sure that it's clear to your team that even though we have a velocity goal set, it's important to never compromise the quality of the code base or our own personal integrity to meet said velocity goal.<br />
<br />
Perhaps it also depends on your specific project - maybe the most important thing for the organization you're working for IS the deadline and a velocity goal becomes an effective means of ensuring that the team meets that deadline.<br />
<br />
What's your take on having velocity goals for your team? Is this a good or bad thing?<br />
<br />
----<br />
<br />
See comments to this posting for additional thoughts on this issue!Grant H. Jounghttp://www.blogger.com/profile/02249862941585448340noreply@blogger.com24tag:blogger.com,1999:blog-165932439628684378.post-1397675008442707412009-10-20T22:20:00.000-07:002009-10-21T16:40:01.500-07:00More Effective Retrospectives With The W.Ack.Hm White BoardRegular re-occurring retrospectives DURING the course of the project is a key reason why Agile helps make projects successful. Why wait until the end of a project to learn what worked well and what could have been improved when you can adjust things during the course of the project? Project "post-mortems" held only at the END of a project should be a practice that dies along with its morbid name!<br />
<br />
But, no matter what approach I took for the retrospective, I ran into one nagging problem... people seemed to struggle to remember what happened during the last iteration. Or, if they did recall anything, it was usually much more of the negative rather than the positive. An effective retrospective should highlight and celebrate our successes as much as our failures - so it was of little help when people would only remember the failures!<br />
<br />
So - soon after starting up my latest project, I decided to try to tackle this critical problem. <b style="color: red;">How could I truly maximize the benefit that regular retrospective meetings can provide for a team if the team either couldn't remember key issues or were really more focused on getting back to work on their current stories?</b><br />
<br />
Enter the <b><span style="color: red;">W.Ack.Hm (pronounced "Whack'em!") White Board!</span></b><br />
<br />
I simply took a portable whiteboard and drew three columns with the following names:<br />
<br />
1. <b style="color: red;">W</b>ahoo!<br />
2. <b style="color: red;">Ack</b>!<br />
3. <b style="color: red;">Hm</b>m...<br />
<br />
But, instead of filling these columns in during the retrospectives, the board was simply left out near our story board wall for the team to enter items <b style="color: red;">IN REAL TIME</b>. There was no more need to open up those cob-web covered doors to the memories of our last iteration!<br />
<br />
If someone was having problems checking in their code since the source control server seemed to be lagging, they could simply go up to the W.Ack.Hm board and write that issue under the "Ack!" column! If someone found a way to resolve a design problem that was nagging them for the last few days, they could go up to the board and write that under the "Wahoo!" column - perhaps even showing it off to the team right then and there! If someone was reading up on a new technology that they thought could help us, they could write it in the "Hmm..." column.<br />
<br />
Grant - why didn't you just use more generic names like "Positives," "Negatives," and "Thoughts?" Well - first of all, you can't get a creative name for the board with those three words!! And, "Wahoo! Ack! Hmm..." are much more fun and active words - hopefully inviting you to write something down under those columns. <b style="color: red;">Making things fun is a subtle but very important difference in getting more participation from your team!</b><br />
<br />
Okay Grant - I get it! How did it work out?<br />
<br />
To my delight, after the first week implementing the W.Ack.Hm White Board, there were 6 items in the "Wahoo!" column, 10 items in the "Ack!" column and 3 items in the "Hmm..." column. By contrast, the last retrospective I ran with the team resulted in 1 positive and 5 negative items being listed - and no thoughts on what could be done to improve things. <b style="color: red;">By using the W.Ack.Hm white board, we had more than tripled the amount of items we discussed during our retrospective!!</b> How's that for maximizing value from your retrospective!!!<br />
<br />
Another benefit from this approach is that there was no longer a need for a long, drawn out period collecting feedback from the team since you already have most of the items to discuss already written down. I still allocate <i>some</i> time for the team to enter additional items to the board - but that phase has been trimmed down to be only a few minutes at most! We're now able to finish our retrospective meetings in 30 minutes flat - and they feel like a much more efficient use of our time since we are actively discussing the items on the board for almost the entire meeting.<br />
<br />
<b style="color: red;">As with any retrospective meeting, they key to making them work for you is to collect that information and create action items that are worked on as soon as your team has the ability to do so.</b> Thus, I ensure that the contents and discussions around the W.Ack.Hm board are collected and stored within a WIKI page that I've setup for our retrospectives. I also proceed to enter action items to resolve any issues into our issue tracking system where we can then proceed prioritize and deliver on those issues, adding direct value to the project.<br />
<br />
I can honestly say that some of the most critical risks to the project have been mitigated by items and discussions brought up during our retrospectives. To my surprise as well, we've also been able to implement most of our "Hmm..." suggestions as well! Results will vary based on your team and project schedule - but if you aren't actively working on issues resulting from your retrospectives, why even have them if they aren't going to provide any value?<br />
<br />
If you've gotten this far into reading the post, I can only hope that you are thinking about instituting this for your team as well... may it help your team out as much as it has helped ours!Grant H. Jounghttp://www.blogger.com/profile/02249862941585448340noreply@blogger.com8tag:blogger.com,1999:blog-165932439628684378.post-91679660898321576222009-08-02T13:55:00.000-07:002009-09-12T07:43:29.833-07:00When Agile Evangelism Goes WrongAfter having been an Agile convert from the more traditional waterfall methodologies, I found myself promoting Agile heavily with the company I was working for back around the year 2004. We had successfully implemented our own custom Agile process within our division and had seen great benefits from it. But, there were two other divisions within the company that were still following more traditional, waterfall processes. While I was not in a position to make changes at the other divisions, I knew that the other divisions didn't like the existing SDLC and morale across those divisions were at an all time low. Seemed like the perfect opportunity to move the entire organization to Agile!<br /><br />So, I thus began my quest to evangelize Agile as the next coolest thing to <a target=blank href="http://en.wikipedia.org/wiki/Recursion">recursion</a>. I was ready to promote Agile and convince people that it would help them and the overall business. "This should be easy!", I thought to myself. After all, I knew <span style="font-style: italic;">everyone </span>was looking for something better! I proceeded to document our Agile process we had setup within our division and began sharing the document with other product and software managers across divisions. I even distributed copies of it during a product and technology summit. I made it a point to keep talking to other managers about Agile and what it could bring for them. It wasn't long before I was labelled the "Agile Nut" around the office. While I didn't mind the label, what I came to realize is that my approach to instill a grass roots effort to transform the entire organization had failed miserably - instead of convincing my colleagues that Agile could really help the organization, it occurred to me that I may have turned them OFF to Agile instead.<br /><br />What went wrong? Why couldn't they see the light even when they were all looking for change? It occurred to me that I must have been so excited about Agile being a great way to help transform the organization that people began to see me as more of a crazy, cult-follower of Agile processes rather than someone "sane" that could help introduce the change at the broader level. Yes - I didn't have support from the C level managers nor the managers in the other divisions. While I was able to convince a few of them that Agile would indeed help the organization, it took lots of discussions and in the end, the idea of an Agile organization was abandoned.<br /><br />Did you catch the <span style="font-style:italic;">key </span> word I used that was the problem? I had to <span style="font-style: italic;"><span style="font-weight: bold;">convince</span></span> my colleagues that Agile would help them. When they were skeptical about the Agile processes I was talking about, I should have forwarded them book and web resources for them to learn about Agile <span style="font-weight:bold;">themselves</span> instead of trying teach them myself. It always seemed like a battle talking with my colleagues - constantly proving to them that Agile methodologies would work for them. If they weren't responsive to what Agile had to offer, I should have <span style="font-weight: bold; font-style: italic;">let it go</span> and ensured that there were resources available for them to learn about Agile themselves. With all the convincing I was doing, I had instead dug a hole for myself in my efforts to convert the organization. After all, any movement toward Agile would have just proved that I was "right" and my colleagues were "wrong" now.<br /><br /><span style="font-weight: bold; font-style: italic;">You shouldn't tell someone the same advice more than twice </span>- if they aren't receptive to your suggestions, then it's up to them to learn for themselves. Providing a framework for letting people learn from their own mistakes and giving them the opportunity to learn for themselves is part of what Agile processes is about - and I should have known better to let the management team at the organization realize for themselves what Agile could bring to the organization.<br /><br />The organization eventually DID decide to make BIG changes to their development strategy by centralizing their development teams across all divisions. With the newly consolidated development division now in place, the Agile strides we had made within our own division had begun to crumble.<br /><br />Not all was lost though - our division was eventually sold off to another company and I was able to revive our Agile processes for the most part. But, my experiences with the failed Agile transformation was perhaps one of the best lessons in my career in what I needed to do to help make future Agile transformations - or ANY broad organizational change - a success.Grant H. Jounghttp://www.blogger.com/profile/02249862941585448340noreply@blogger.com8tag:blogger.com,1999:blog-165932439628684378.post-16816710960039197002009-07-01T14:20:00.000-07:002009-09-12T08:31:08.407-07:00Efficiency - A Must Have Agile Metric As Important As VelocityWhen I first picked up Agile development, I absolutely got hooked on the simple yet powerful way it described how to track your team's progress on projects with REAL data. Before I implemented Agile, I can't remember how many times business stakeholders or execs have tried the Developer-Used-for-My-Benefit approach, only for it to bite the organization <span style="FONT-STYLE: italic">hard </span>in the nuts later. I call it the D-U-M-B approach for short.<br /><br />CEO: "How's the project coming along Pat?"<br />Pat the Developer: <puts down="" cola="" jolt="">"Uhhh - going well. I can crank this out in no time - easy!" <sips cola="" jolt="" day="" the="" for="" 3rd=""><br />CEO: "Excellent - I'm going to give you a huge bonus and tell sales and marketing to start pushing it."<br /><br />Uh-oh... I think we all know the end of this all too well-known scenario... :(<br /><br />Gathering actual <span style="FONT-STYLE: italic">hard</span> data while your project is running is the only practical way to measure the completion of your project - and Agile processes are all about collecting and charting this hard data, making it <span style="FONT-STYLE: italic">visible</span> to the entire organization so there is never any question where a project status is at!<br /><br />One of the core hard data metrics within Agile practices is the team's <span style="FONT-STYLE: italic">velocity </span>- the amount of work the team is able to complete in a given amount of time/iteration. Using the team's last velocity, the team can predict what their velocity will be for the next iteration. Charting the team's velocity for the project will allow you to make some smart data-based decisions as well by analyzing their velocity trends. For tips on providing your Agile team the best chance on achieving a high, stable velocity, read <a href="http://grantjoung.blogspot.com/2009/06/7-tips-on-achieving-high-stableteam.html" target="blank">this</a> later!<br /><br />However, even with all the great info velocity charts provide, I found myself wanting something more than just the velocity chart. If resource days are limited in an iteration due to holidays, vacations, or sick days, the team's velocity can drop significantly. It makes complete sense of course - fewer working days = reduced work completed for that iteration. But, how could I prove that the dip in velocity was just due to the limited number of resource days? How could I prove that the team worked just as hard as they would have if they were fully staffed for the entire iteration?<br /><br />Enter the <span style="FONT-STYLE: italic">efficiency</span> metric. <span style="FONT-WEIGHT: bold">The </span><span style="FONT-STYLE: italic; FONT-WEIGHT: bold">efficiency</span><span style="FONT-WEIGHT: bold"> metric </span><span style="FONT-WEIGHT: bold">allows you to determine how efficient the team was for each iteration, </span><span style="FONT-WEIGHT: bold">but in a way that it factors out the number of resource days that were available during that iteration.</span> Thus, even if there was an iteration when the entire team took a few days off, where the Velocity Chart would show an obvious dip in the amount of work accomplished, you can rely on the efficiency chart to show if they were just as efficient working that iteration from the previous ones. Below is an example Team Velocity and Efficiency chart based on data collected for the same iterations.<br /><br /></sips></puts><div style="TEXT-ALIGN: center"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcoKcAsilw4JbeTlV3nh7YnrwhIW4-3mTfK58ZFTzoxJj1gUiSv7oTl9-li2aC7tn2IoGFeRDyfnwSbp9VPekKP2kh1WebQGhYQAfkE19RmzDoA4kc3zaADZb2T5I4JYwWH6aTIBzYK1k/s1600-h/ExampleVelocityAndEfficiencyChart.GIF"><img style="WIDTH: 330px; HEIGHT: 400px; CURSOR: pointer" id="BLOGGER_PHOTO_ID_5355900312065594610" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcoKcAsilw4JbeTlV3nh7YnrwhIW4-3mTfK58ZFTzoxJj1gUiSv7oTl9-li2aC7tn2IoGFeRDyfnwSbp9VPekKP2kh1WebQGhYQAfkE19RmzDoA4kc3zaADZb2T5I4JYwWH6aTIBzYK1k/s400/ExampleVelocityAndEfficiencyChart.GIF" /></a></div><puts down="" cola="" jolt=""><sips cola="" jolt="" day="" the="" for="" 3rd=""><br />You can see that even though the team's velocity dropped signficantly during iteration 14 because half of the team was out due to the flu for a few days, the efficiency chart shows that the team remained consistent in its effort to get work completed - which tells you that during that iteration, a dip in velocity was entirely due to the lack of resources that were available that iteration.<br /><br /><span style="FONT-WEIGHT: bold">COOL BEANS GRANT - I GOT IT!!</span> So how do you calculate a team's efficiency?</sips></puts><br /><puts down="" cola="" jolt=""><sips cola="" jolt="" day="" the="" for="" 3rd=""><br /></sips><span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">E</span></span> = <span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">V</span>/<span style="FONT-WEIGHT: bold">R</span></span><puts down="" cola="" jolt=""></puts><puts down="" cola="" jolt=""><span style="FONT-STYLE: italic"><br /></span></puts><puts down="" cola="" jolt=""><br /></puts><span style="FONT-STYLE: italic; FONT-WEIGHT: bold">E</span>=Efficiency for the iteration<br /><puts down="" cola="" jolt=""><span style="FONT-STYLE: italic; FONT-WEIGHT: bold">V</span>=Velocity for the iteration<br /><span style="FONT-STYLE: italic; FONT-WEIGHT: bold">R</span>=Total number of person days worked on the team for the Iteration<br /><br />Hopefully, you're already tracking velocity (<span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">V</span></span>) for completed iterations. You'll also need to start tracking total actual person days (<span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">R</span></span>) worked for your completed iterations as well. For example, if you have a team of 5 and your iteration is 10 days, then the maximum possible <span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">R </span></span>value for your team would be 5 x 10 = 50 days. The actual <span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">R</span></span> value would thus be the maximum possible <span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">R</span></span> value for your team minus the number of absent days per team member during the iteration (e.g. 50 max - 1 sick day = 49). <span style="FONT-STYLE: italic; FONT-WEIGHT: bold">Tip</span>: Plug all of your numbers in a spreadsheet and setup formulas to do your calculations for you! <span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">E</span></span><span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">fficiency </span></span>is auto-calculated for me once I've entered <span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">velocity </span></span>and <span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">resource days</span></span> for the completed iteration into my spreadsheet. After you've got your efficiency calculated, producing your Efficiency Chart is as simple as producing your Velocity Chart - just chart it over each iteration!<br /><br />Below is an example spreadsheet showing calculation of Efficiency using Velocity and number of resource days.<br /><br /></puts></puts><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhr1adlkivykZNC2GmlR_0ASg3aEjjZjaXmf-pZ3pPqHV_GB6Icge7zRHJ2VKFLLiwUIfaRpB_JyTTmyEK-m-wIGCJCW637z_2WnoQoZBOkBnvN6upjK6GymPFJrIGaX2PpxzyijioMlnU/s1600-h/ExampleSpreadsheetCalculateEfficiency.GIF"><img style="WIDTH: 320px; HEIGHT: 255px; CURSOR: pointer" id="BLOGGER_PHOTO_ID_5355902506199712658" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhr1adlkivykZNC2GmlR_0ASg3aEjjZjaXmf-pZ3pPqHV_GB6Icge7zRHJ2VKFLLiwUIfaRpB_JyTTmyEK-m-wIGCJCW637z_2WnoQoZBOkBnvN6upjK6GymPFJrIGaX2PpxzyijioMlnU/s320/ExampleSpreadsheetCalculateEfficiency.GIF" /></a><br /><puts down="" cola="" jolt=""><puts down="" cola="" jolt=""><br />Now that you have your efficiency chart at hand, viewing it in combination with your velocity chart unveils much more information about your iterations than the velocity chart would have provided alone. See a dip in your velocity chart but efficiency was stable? Resource days must have been limited that iteration. Like velocity, the trend for the efficiency chart for teams heading in the right direction should be very similar to that of the velocity chart: new teams will likely have a few beginning iterations where efficiency may be erratic when they start settling into the project and learning to work together. But, eventually, you should see a peak and plateau, representing that the team's current maximum efficiency has been achieved. Note that efficiency ratings are not the same between different teams - so don't get all twisted up if one team seems to have a smaller efficiency than another! To me, a successful efficiency chart is not about how high it reaches, but about if it has reached a peak and consistent plateau.<br /><br />Having efficiency also allows you to obtain what I'm calling the <span style="FONT-STYLE: italic; FONT-WEIGHT: bold">benchmark velocity</span> for your next iteration. If you're using velocity charts right now, I'm sure you've been told that the best way to determine how much work the team can do in the next iteration is the velocity from the last iteration. I beg to differ!! With the efficiency metric of the last iteration in hand, simply multiply it with the <span style="FONT-STYLE: italic; FONT-WEIGHT: bold">expected </span>number of resource days for the next iteration, and you've got the <span style="FONT-STYLE: italic; FONT-WEIGHT: bold">benchmark velocity - the velocity your team would hit if they work just as efficiently as they did this past iteration.<br /></span><span style="FONT-STYLE: italic; FONT-WEIGHT: bold"><br /></span></puts><span style="FONT-STYLE: italic; FONT-WEIGHT: bold">v</span> = <span style="FONT-STYLE: italic; FONT-WEIGHT: bold">E</span>*<span style="FONT-STYLE: italic; FONT-WEIGHT: bold">r</span><br /><br /><span style="FONT-STYLE: italic; FONT-WEIGHT: bold">v</span> = benchmark velocity for next iteration<br /><span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">E</span></span> = efficiency from just completed iteration<br /><span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">r</span></span> = Total number of <span style="FONT-STYLE: italic">expected </span>resource days available for upcoming Iteration<br /><br />Below is a spreadsheet showing the simple formula to calculate the benchmark velocity.<br /><br /></puts><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEis_Mg1yULLGaD7y1yG-A1-jMXktdCwgglLRbVDCIEvUYPx61jblQeU4A0FxhfYloW78Oeclv4f-oJ9_5LZ9VeyC4DDDJwqUTVBVrg-O_zdrP_UtyDeIND8ZN_WlztOttRBc-S5zgeQa3Q/s1600-h/ExampleSpreadsheetCalculateBenchmarkVelocity.GIF"><img style="WIDTH: 320px; HEIGHT: 252px; CURSOR: pointer" id="BLOGGER_PHOTO_ID_5355903337490319442" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEis_Mg1yULLGaD7y1yG-A1-jMXktdCwgglLRbVDCIEvUYPx61jblQeU4A0FxhfYloW78Oeclv4f-oJ9_5LZ9VeyC4DDDJwqUTVBVrg-O_zdrP_UtyDeIND8ZN_WlztOttRBc-S5zgeQa3Q/s320/ExampleSpreadsheetCalculateBenchmarkVelocity.GIF" /></a><br /><puts down="" cola="" jolt=""><br /><puts down="" cola="" jolt="">Grant - why do you call <span style="FONT-STYLE: italic"><span style="FONT-WEIGHT: bold">v</span></span> the "benchmark" velocity instead of the<span style="FONT-STYLE: italic"> </span>"expected"<span style="FONT-STYLE: italic"> </span>velocity? After all, isn't that what it really is? When the team needs to decide what their upcoming velocity commitment should be, there are more things to consider than just the pure numbers from the previous iteration. For example, maybe your office is scheduled to move to another building next week. Even though everyone is still working those days, you shouldn't expect them to be just as efficient as they were last iteration!! Thus, you and the team should expect to have a lower velocity for the upcoming iteration than what the "benchmark" velocity is calculated to be... hence the term "benchmark" instead of "expected." Saves you the trouble in also explaining to project stakeholders, customers, and execs on why the "expected" velocity wasn't reached as well if you had called it that!<br /><br />Allowing your team to view the benchmark velocity and then talk through any outside factors that could impact the upcoming velocity for better or worse should allow the team to settle upon a velocity number that they can commit to. A fully self-organized, steady team should more often than not accept the calculated team benchmark velocity as their commitment. If your team is consistently committing to numbers that are drastically different from the calculated benchmark, it's a clear signal that they are still learning how to stabilize their development efforts for the project. Don't be surprised if the team decides to commit to a velocity that is higher than the benchmark as well!<br /></puts></puts><br /><puts down="" cola="" jolt=""><puts down="" cola="" jolt="">The efficiency metric is now a must have for <span style="FONT-STYLE: italic">all </span>of my Agile run projects - it's my hope that your team and organization will also benefit from using this metric as well!</puts></puts>Grant H. Jounghttp://www.blogger.com/profile/02249862941585448340noreply@blogger.com10tag:blogger.com,1999:blog-165932439628684378.post-9321768585981988822009-06-29T15:58:00.000-07:002010-01-29T12:08:38.683-08:008 Tips for New Agile Teams to Achieve a High, Stable Velocity<div style="font-family: times new roman; text-align: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcxQ2VKsBDc7ZKVwX2XL3QMelIkY249I8b6803rbwr05DuwqPNbqwEOOK917b8-qfR1VUqFdLlW2v7uZuE2i9J-_BHoKPPWIYyu5PhDZKGz3C_Wwxsdf4zBBMCS7-FXE0Dc1ZUecsuqwQ/s1600-h/ExampleVelocityChart.gif" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5352894890765658290" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcxQ2VKsBDc7ZKVwX2XL3QMelIkY249I8b6803rbwr05DuwqPNbqwEOOK917b8-qfR1VUqFdLlW2v7uZuE2i9J-_BHoKPPWIYyu5PhDZKGz3C_Wwxsdf4zBBMCS7-FXE0Dc1ZUecsuqwQ/s320/ExampleVelocityChart.gif" style="cursor: pointer; display: block; height: 193px; margin: 0px auto 10px; text-align: center; width: 320px;" /></a><br />
One of the most common Agile project management techniques to measure the continuing growth and success of your team is the beloved Velocity Chart, which simply shows the amount of work your team has completed after each of your iterations.<br />
If the team you are working with is new and knows nothing about Agile, you should expect an erratic first few iterations where velocity can greatly differ as your team learns the process and gets accustomed to working with each other. Over time, teams headed in the right direction will increase their velocity and hit a peak and plateau, a key milestone that unfortunately not enough Agile software development teams are getting to in my opinion. When the team has achieved this state, they have settled into a rhythm and maxed out on the amount of work they can accomplish. This is <span style="font-style: italic;">not </span>to say that there aren’t any steps that can improve the team’s velocity beyond this plateau, but this is a subject best suited for a future discussion.<br />
<br />
<br />
<div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8dYvD6NYkU7gQ0PfzBCmY8thHgoWyV8r93yt2RAkCks6NmvCPtWvlAOWAnl8YWa_VbXY_3-8zVWhPVUFDGhg0LrzUr7wi1QcjAA2H1c99iFR8UH2wXttp4jxinUL2sRiTX15eUrmDUzw/s1600-h/ExampleVelocityChartPeakPlateau.gif" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5352896230318128178" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8dYvD6NYkU7gQ0PfzBCmY8thHgoWyV8r93yt2RAkCks6NmvCPtWvlAOWAnl8YWa_VbXY_3-8zVWhPVUFDGhg0LrzUr7wi1QcjAA2H1c99iFR8UH2wXttp4jxinUL2sRiTX15eUrmDUzw/s320/ExampleVelocityChartPeakPlateau.gif" style="cursor: pointer; height: 193px; width: 320px;" /></a><br />
</div><br />
So what's the big deal in getting a team to reach their velocity peak and maintaining a plateau? Well, for one thing, team morale is often extremely high when teams have established this state; it signifies that they work well together and are able to get the work they need to complete at a sustainable pace. The business also benefits by having a team that is dependable and consistent in the amount of work they are able to deliver – a project manager’s <span style="font-style: italic;">wet </span>dream (yuck!). Seriously though - a highly and consistently performing team makes project forecasting and planning much more accurate and allows the business execs, stakeholders, and clients to know with much better confidence WHEN the team can complete a project with proper estimates in place. For example, if I had a choice between two teams to work with - one which was showing a consistent plateaued velocity and another that shows velocities above what the first team could do, but had erratic changes in team velocity, I would much rather work with the team that had reached a plateaud state. An erratic velocity iteration over iteration means that the team hasn't fully worked out their kinks and thus is a riskier team to work with.<i><o:p></o:p></i><br />
Below are some tips I've learend over the years practicing Agile software development on what you/your team can do to promote the evolution of an Agile team towards achieving their own velocity chart plateau!<br />
<br />
<b style="color: red;">1. ENSURE YOU HAVE ALL ROLES DEFINED TO MAKE THE PROJECT A SUCCESS AND ASSIGNED THOSE ROLES TO THE RIGHT TEAM MEMBERS</b><br />
In order for a team to be successful, they need to have all the appropriate roles and skills within the team to keep progress moving within the project without having to wait for resources outside of the team. In my opinion, a minimum self-organized team needs to have a project manager, a product manager, a developer, and a QA person. If possible, it’s always great to include the customer/client as well on the team – but I realize that may not always be possible!! Of course, each project may differ in the roles and team members that may be necessary to ensure your project remains successful. For example, if your project requires several new complex databases and servers to be spun up, it would probably be a good idea to have an IT staff member assigned an official project role as well.<br />
<br />
<b><span style="color: red;">2.</span><span style="color: red;"> </span><span style="color: red;">AVOID CHANGES TO YOUR TEAM’S PERSONNEL</span><br />
</b>One of the worst things you can do to prevent a team from reaching their plateau is to move personnel into and out of the team. That’s why it’s so critical to establish the right roles and team members at the onset of the project so that they can grow into the roles that have been defined. But ultimately, realize that any change in personnel means your team must re-learn how to work effectively with each other and often re-establish their own roles. If you’ve already got a team that has plateaued, do yourself a favor and make sure they STAY together as a team – it’s difficult to get a team to that state – so why would you willingly break that team up after the project is over? Have them tackle the next project together!<br />
<br />
<b><span style="color: red;">3.</span><span style="color: red;"> </span><span style="color: red;">MAINTAIN CONSISTENTCY FOR HOW YOUR TEAM ESTIMATES</span><br />
</b>How much work your team accomplishes each iteration is defined by the estimates/point values the team (and only that team!) gives to stories that they work on. If they suddenly change the way they estimate stories mid way through a project, it will completely throw off the validity of your velocity chart!! This is not to say that each team member should continue to strive to make their estimates and point values as accurate as possible – but just remind them that each of them should maintain consistency in the way they estimate from iteration to iteration.<br />
<br />
<b><span style="color: red;">4.</span><span style="color: red;"> </span><span style="color: red;">RETROSPECTIVES AFTER EACH ITERATION</span><br />
</b>It’s vital that your team always evaluate themselves after each iteration and talk about things that went well and things that didn’t. Doing this is an important step that allows your team to grow together; it also sends them a message that ultimately, they have direct responsibility over their own work and team environment and DO have an active say on how THEY can improve their day to day work. Re-enforce the message that improvements points are the entire team’s responsibility to resolve – there is no such thing as individual failures on Agile teams (usually!). This will help set the tone that finger pointing and name games are not to be tolerated on the team and that if one person has a problem, it’s the <span style="font-style: italic;">team’s </span>responsibility to correct that problem. Resolving issues and re-enforcing good behavior together as a team will promote self-organization and ultimately lead to improved velocity over time.<br />
<br />
<b><span style="color: red;">5.</span><span style="color: red;"> </span><span style="color: red;">WELCOME FIRST TIME FAILURES OR MISTAKES AS LEARNING OPPORTUNITIES</span><br />
</b>If you’ve got a new team, failures and mistakes are to be expected – it’s part of their learning process in finding a way to work better with each other. Sure, reading up on Agile processes and information like this one can help avoid costly rookie mistakes! But ultimately, mistakes are bound to happen even to the most senior of Agile teams. Instead of reprimanding the team or individual(s) that made those mistakes, establish a culture that virtually celebrates failures/mistakes as learning opportunities for the entire team. The second ANY team member doesn't feel comfortable talking about their own mistakes or failures only jeopardizes the team's growth potential.<br />
<br />
<b><span style="color: red;">6.</span><span style="color: red;"> </span><span style="color: red;">PROJECT TEAM COLOCATION</span><br />
</b>THERE IS NO SPOON... err... WALL!!! Have your ENTIRE team sit next to each other in an open , non-partitioned environment that allows them to interact with each other on a daily basis FACE TO FACE! Yes - I DO mean everyone - most importantly your customer-proxy!! This will actively promote the growth of this team and ensure that they learn how to work with each other on a day to day basis. Okay - maybe your developer is getting cranky and says they can't concentrate enough when they need to in such an open environment. Just establish some sort of signal that says they want time to themselves and shouldn’t be interrupted unless absolutely necessary. We used over-the-ear headphones (noise cancelling also helps) as a way to tell others to back off – I’m concentrating!! If we had non-urgent questions for that team member, we would just ask them later or send them an email and have them answer it on their own time. Alternatively, if your office has extra rooms, make one room a “quiet lab” where they can work in peace, doors closed, but ONLY when necessary.<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span style="font-weight: bold;"><span style="color: red;">7.</span><span style="color: red;"> </span><span style="color: red;">ESTABLISH A RHYTHM FOR EACH ITERATION</span></span><br />
</div>Make sure any re-occurring meetings that happen for your team happen on the same schedule based off each of your iterations. That way, your team can establish a rhythm with each iteration and can get accustomed to having “Retrospective Fridays” or “Monday Iteration Planning” meetings. Do your best to avoid having your team’s resources participate in any meeting outside of the already established, re-occurring meetings you have laid out for them so they can maximize the amount of time they work on the project and don’t get distracted with non-project related meetings.<br />
There are of course many other things that I've probably missed here - but hopefully these tips will at least give you some guidance or thoughts on areas that you may not have considered otherwise - at least consciously. :)<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span style="color: red;"><b>8. ELIMINATE EXTERNAL TEAM DEPENDENCIES</b></span><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">While not always possible, eliminating external team dependencies and EMPOWERING your team to control their own destiny will avoid situations where your team will be negatively impacted by factors outside of their control. It could be anything from ensuring that your team has access to development and QA environments running the project to more business focused dependencies like ensuring that there is an appropriate client/client-proxy that is readily available to make product/business decisions for your team. Look out for external dependencies during your retrospectives and move them INTO your team when possible!<br />
</div><br />
</div>Grant H. Jounghttp://www.blogger.com/profile/02249862941585448340noreply@blogger.com10