Saturday, December 27, 2008
Tuesday, December 09, 2008
First I change few of the labels for the standard fields from the Conchango template:
Business Priority is changed to Business Value since the word "priority" has a certain connotation of order. I also implement a SuggestedValues rule with values ranging from 100 to 1000 with increments of 100 (100, 200, 300, etc.).
Estimated Effort (days/story points) is changed to just Story Points since I really encourage teams to not use days or hours when estimating the Product Backlog. I add a SuggestedValues rule to this field with the Agile standard of the Finbonacci sequence variation (1,2,3,5,8,12,20,40,100). Some clients use the planning poker cards from Crisp, but I do not include 0, 1/2, ?, or the Coffee Break card.
I also change the description on the Conditions of Acceptance section to include "or How To Demo Steps" since I really like using this technique over just a bulleted list of acceptance criteria.
I also add two new fields:
Return On Investment which is a read only field calculated by dividing the Business Value by the Story Points. We use this as additional perspective when ordering the Product Backlog. The value is updated by a web service created using Howard van Rooijen's project template for TFS event subscription end points.
Product Backlog Type which is used many different ways depending on your Agile tool or general philosophy. My version has three allowed values:
- User Story which is exactly what it sounds like. All these entries must fit the user story format.
- Technical Requirement which is for any behind the scenes work like refactoring, building supporting components with no UI, etc. This helps identify which items require functional tests to be created (meaning a User Story) or those that just need to be regression tested with the current suite of tests.
- Epic which is used for placeholder entries. Some people like to use TFS Areas for this but I prefer to put it at the Product Backlog level. It allows stakeholders to throw pie in the sky ideas on the backlog. Our rules specify that an Epic is not estimated, is always last in delivery order, and can never be added to a Sprint until it is broken up into acceptable User Stories with a Story Point value that can be done in half a Sprint.
I also add some new work flow steps:
Ready For Test is something the Conchango template puts at the Sprint Backlog level and I prefer to have this measured at the Product Backlog level. There is some contention on this even on the Conchango forums. My thought is that a task like "Create class to hold search criteria." cannot be tested but its corresponding User Story ("Search Online Catalog") can be.
Failed Test and Passed Test are two optional steps I sometimes put in to follow Ready For Test. This depends on how integrated the testers are with the development team. If they are very integrated and the team is good with simply communicating failed and passed tests verbally or via email then these can be left off. I have had less integrated QA teams that were also not co-located with the team and we found these steps necessary to keep up with test results.
And finally I organize the form a bit to keep it symmetrical and grouped a bit more clearly.
These changes are not necessarily a good fit for every team and I really try to understand the level at which each client can adopt the Scrum processes before we run head first into customization. I have found these changes to bring value to the process for the majority of time.
Monday, December 08, 2008
Here is my Quick Launch bar in all its shortcut glory:
That's it. Soak it all in. Bask in its gleaming aura of one click access goodness.
You got your Open Destop, Internet Explorer, FireFox, Outlook, Shortcut to my work web mail (no POP3 access you big jerks), and OneNote (ah...OneNote).
So I do not put a lot of links on my Quick Launch. And I do not put that many on my Desktop either. Why you ask?
Is it because of my Zen like knowledge of shortcut keys? No. I don't even think my ALT button is working.
Is it because of some Toolbar and Desktop Feng Shui philosophy? No. I tried that and the incense just gunked up my keyboard (Maybe that is why the ALT button is broken).
Is it because I simply do not actually do that much work? Maybe. Some co-workers might think that. :)
Mainly it is because I do not have that much installed on my local hard drive. I normally use VPC images that actually contain the bulk of the applications and tools I use. And for what I do have installed locally, I just keep the shortcuts off the Desktop and Quick Launch because I like a clean interface. I do not mind a few clicks to find things in my Start menu. My Start menu is organized in a very set pattern that I have used ever since there was a Start menu and I have just gotten used to it.
Sunday, December 07, 2008
With 4 children at home (all girls 11 yrs. To 6 months) and a 17 year old son, I don't seem to get as much free time to be active in the local development community like I used to. After working all day, dinner with the family, and the logistics of homework/housework/etc., when I do finally sit down in front of the computer (usually around 11:30 PM) it is very tempting to turn it off and just go to bed. But when I hesitate to sit down and write a blog post, investigate a new technology, or participate in a local community event, the people listed below are the ones I think about to inspire me to stay involved. This list below reflects people I interact with regularly either in person or online that serve as an example for involvement in the developer community. I think it only right that I pay them a little homage:
Brian Prince - Brian is the Microsoft Architect Evangelist for my region and is always willing to help out with our local community events. He is also very helpful to me personally whenever I ping him for assistance. I have seen him take personal interest in more junior members of our local community and encourage them to become involved when sometimes these people are left out.
Elijah manor - Elijah a prolific blogger and tweeter. I know he is very involved in his family and church and where he finds the time to do this I have no idea. Almost every day I follow a link from one of his tweets and discover something knew.
Michael Neel - Mike is the .NET User Group leader in Knoxville and I have worked with him at several local and regional events. He is very passionate about the community and it seems he is always driving somewhere (usually a great distance and on his own dime) to participate in community events. He is the one who got me started on filling up my iPod with developer podcasts to listen to while I am in the car (that's an hour of knowledge every day).
Evan Hoff - Evan is always traveling to go to a developer conference or referring a new technology book to me. He seems to know just about everyone in the Agile/ALT.NET community. I guess it helps that he is single and has the time to be so deeply involved but I remember when I was younger and single I did not have the dedication for that level or effort.
Corey Haines - I met Corey at devLink 2008 and found his outlook very refreshing. He is very passionate about being the best developer he can be in any language. He recent endeavor to travel the region pair programming with people all over to learn more is something I would never have the guts to do.
There are more people and I apologize to those I did not mention.
Saturday, December 06, 2008
When you open the Sprint Task Board you are prompted to choose a project then choose a Sprint. The Sprint you choose is actually an item in the hierarchical list of Iterations. I have always just selected my specific Sprint, but if you choose a Release you will then see all of the Product Backlog items under that release. So if you have previously performed your Release Planning and assigned Product Backlog items to their projected releases then they should show up. The image below is a view of a sample Product Backlog viewed in Excel. Notice that all but one item is assigned to the Release 1 Iteration.
When you open the Task Board application and choose Release 1 for this project you will see all of the items that were associated to Release 1 (or a Sprint in that Release). Anything not assigned to that Release will not be shown.
Most of the time we have used Excel during Sprint Planning meetings since we tend to be adding quite a lot of items and using the query view in Team Explorer was tedious. Using the Task Board app is less tedious than Team Explorer but still not as easy as Excel. So you can still use Excel to rapidly enter Sprint Backlog items and then publish them back to TFS, but since you cannot link items in Excel they will not be connected to any Product Backlog items. You can then open the Task Board app and open the Orphaned Work Item section to drag and drop these Sprint Backlog items to their corresponding Product Backlog item.
So while this option does not provide a good option for Release Planning, it is one possible solution for Sprint Planning. Using the Task Board app can give the team a more tactile feeling during the process. Seeing item represented on the screen gives you more of an idea for the scope of a Sprint/Release.
I still like the interface provided by VersionOne for Release Planning. Not only does it provide an easy to use drag and drop interface, it provides feedback on capacity as you go (see a demo here).
So thanks again to Jeff for prompting me to take another look at the functionality in the Conchango Task Board application. Now if they could just rip off the features in VersionOne I could get down to only two applications!
Monday, December 01, 2008
- Iteration Planning/Backlog Maintenance (-1): This is probably my most disappointing set of features. I never found the work item queries view in Team Explorer or Excel a decent interface for organizing the Product Backlog and Release/Sprint Planning. Products like RallyDev and VersionOne (which both have connectors to TFS) had easy to use, drag and drop user interfaces that made these features more tactile. Stephanie Saad shows the new Agile planning templates in this Channel 9 video. All that was really added were some Excel sections for capacity and release number crunching that we had implemented ourselves in Excel about a year ago. Microsoft may be simply relying on ISVs like Rally and VersionOne to fill in this space but I hate to buy another product (on top of VSTS/TFS's substantial cost) to get this functionality.
- Unit Testing/TDD Support (+1): While I am not a TDD zealot I do believe in test early and test often when it comes to unit testing. For those who really wanted to write their tests first in true TDD fashion it was a little kludgy to get a unit test class written without any of the references of target classes already defined. There are some new options while creating your unit tests to automatically create your target classes and namespaces as you go. Karen Lui demonstrates this in this Channel 9 video. These features are definitely going to make writing unit tests first easier.
- QA/Functional Testing (+1): This functionality I have not gotten to play around with as much so I have really only gotten an idea of how it works from this video. The new testing application, Camano, is a stand alone application that QA/functional testers can use to execute manual test and record them for automation afterwards. There are also the other cool features for recording video while testing and saving metadata about the path the tester took to get to the bug. All this info can be bundled up in a bug report that can be sent and tracked through TFS.
- Self Documenting Code (+1): Since there is less concentration on documenting architecture and design information up front in most Agile processes, techniques for making your code/application self documenting are highly recommended. But even these practices never gave you those great UML diagrams that really showed the "big picture" of how the solution as a whole was built. But now with some of the "bottom up" design features (demonstrated here), you can generate not only the standard class diagrams, but sequence diagrams also. The Architecture Explorer is also a very cool way to browse the basic structure of any .NET solution.
- Code Quality [Adherence to Architecture/Design] (+1): Enforcing code quality in a self managing Agile team is sometimes a difficult task. Pair programming and good code reviews are good ways to ensure the developers are following the basic architecture/design of the solution. The Layer Diagram (same video as above at the 30 minute mark) is a great way to layout the basic boundaries of your application that can actually enforce that the underlying code does not cross boundaries.
So far the Release/Sprint Planning and Backlog management is the only area I found wanting. Otherwise I am very eager to start using 2010!
Sunday, November 23, 2008
Wednesday, November 19, 2008
Wednesday, November 12, 2008
Topic: Breaking Serve on Dev/Test Ping Pong in Visual Studio 2010
This has probably never happened to you, but picture this scenario: a tester finds a bug, writes it up, and sends it to the appropriate developer. The developer can’t reproduce the bug and sends it back. The tester digs around a bit more to find better repro steps. The developer insists it’s a configurable error of the tester. Back and forth we go. In VSTS 2010, this process is streamlined by automatically gathering critical information about the project and code and making that data available when, where, and to whom it is needed. During this talk, Mark Mydland (Principal Group Manager of VSTS Test) will demonstrate these cool new features and dive into technical topics on the new architect tools, some amazing research work for concurrency and for bounds checking, 3-tier execution, and data recording (aka “Tivo for debugging”).
Speaker: Mark Mydland
Mark Mydland is the Principal Group Manager for the Visual Studio Team Edition for Software Testers product at Microsoft. In the past 12 years, Mark has worked as a developer and consultant across a wide variety of applications and industries. Mark first joined Microsoft in 2001 working as a member of the Natural Interactive Services Division (NISD). During his time in that group, Mark was the development manager for a team focused on analytics for assessing the efficacy of natural language interpreters with a particular emphasis on driving authoring simplification and relevance quality for user assistance. Based on this work, Mark filed numerous patents and coauthored a paper for the SIGIR journal. In 2004, Mark left Microsoft to work as a Director of Development at Getty Images where he led a change in process from a traditional waterfall methodology to a scrum-based agile approach which brought the release frequency from 12-18 months down to 1 month. Since Getty made extensive use of VSTS, it seemed a natural fit for Mark to join VSTS on his return to Microsoft in 2006. Mark received his B.S. from West Point in 1991. He has also held positions with USWeb/marchFirst and Andersen Consulting/Accenture.
We would like to thank Compuware for sponsoring the event.
Monday, November 10, 2008
Tuesday, November 04, 2008
To run the exercise you need 20 pennies, 6 stopwatches, and 10 people. Sit 5 people around a table. Assign 4 of them as workers for department 1 thru 4. The last person sitting at the table is the customer. The other five people will stand behind one of the people seated at the table. The people standing behind the workers are the department managers. The person standing behind the customer is the company president. All of the people standing have stopwatches as well as the customer. Place the 20 pennies heads up in front of department 1.
Running the Exercise (First and Second Pass)
You will run the exercise 6 times. The first pass starts with the worker in department 1 turning over each penny in front of them with one hand from heads to tails. As soon as the worker starts, the manager for department 1 starts his stopwatch as do the customer and the president.
When all the pennies have been turned over to tails, worker 1 will slide over all 20 pennies to the worker in department 2 next to them. When the first penny is moved to worker 2, manager 2 will start their stopwatch. When the last penny is moved from worker 1 to worker 2, manager 2 will stop their stopwatch. This process will be repeated for worker 2, worker 3, and worker 4.
When the first penny is moved to the customer from worker 4, the customer will stop their stopwatch. When the last penny is moved to the customer from worker 4, the president will stop their stopwatch.
Record the results of the first pass in a table like the one below:
This chart shows each departments productivity, the time to market (the first penny to the customer), and project completion (the last penny to the customer).
Perform the second pass exactly as you did the first pass. Make sure before you start all the participants with stopwatches reset them. Record the second pass results on your chart.
Running the Exercise (Third thru Sixth Pass)
On the third pass each worker will pass 10 pennies at a time to the next in line. So once worker 1 has turned over 10 pennies, they will pass them to worker 2 who can then start turning over their pennies while worker 1 turns over their remaining 10. It will not be more important that the customer stop when the first batch of 10 pennies arrives and the president stops when the last batch arrives. Record your results in your chart.
The fourth pass the batch size is decreased to 5 and the fifth/sixth pass the batch size will be 1 penny. Record both passes results.
At the end of the exercise review the results with the team and you will see some very interesting trends. The chart above is the results from our exercise at the Scrum training.
- When the team repeats the process with the same batch size they generally increase individual and overall productivity.
- As the batch size decreases each department’s individual productivity decreases.
- As the batch size decreases, the time to market is faster.
- As the batch size decreases, the time to complete the entire project decreases.
I found that paradox that the smaller the batch size (or iteration), the worse each department’s individual productivity. As we discussed this we talked about how this illustrated how in Scrum each iteration encompasses all the activities of the SDLC making each individual effort a bit less productive. The other interesting point was how the overall productivity of the “company” was increased. We as a company were quicker to market and completed faster. It really brought home the point of small iterations of work to the entire class.
I have described the exercise to several clients that I am helping adopt Scrum and Team Foundation Server and they have all suggested that it should be something I have each client’s team perform to help them grasp the benefits of the iterative style of development in Scrum.
Wednesday, October 29, 2008
For my first post on the training I wanted to describe how the course itself was run. One of the interesting approaches was that the training was run like a Scrum project. Each day Jeff populated our Sprint Task Board with subjects we would cover that day. Each hour he would move the cards on the board and update a burn down chart. All of the exercises were time boxed and he kept things going with Tibetan meditation bells to end a session.
The course manual had quite a bit of content and we did not make it all the way through the book. Jeff skipped around quite a bit and his slide deck had updated content that was not in the book but was provided to us afterwards. A good bit of content came from Henrik Kniberg's Scrum and XP from the Trenches book which I reviewed in my last blog post.
Jeff had many anecdotes of adopting Scrum from his many years of experience that made the ideas behind it a bit more real. There was a lot less rhetoric than I had anticipated and he backed up all the ideas with hard numbers from a multitude of studies. These numbers are great fodder for conversations with management when trying to convince them to adopt Scrum.
There were also some very cool activities that really illustrated the contrasts between traditional practices and those prescribed with Scrum. There are many paradoxes in Scrum (and Agile/lean processes) that produce results that are contradictory of what most people would think. I plan to post more info on some of these activities soon.
All in all it was a great class where I not only had a good bit of what I have been doing for that past couple of years validated but learned many new things as well. I would strongly suggest that if your company plans to implement Scrum that everyone involved in software development attend a training course of this type. Jeff recounted studies that have shown Scrum teams starting without a Scrum Coach or the right training normally only see about a 35% benefit initially where teams that are trained and coached well see a 400% increase in productivity.
Thanks to Jeff and Joe for a great course!
Friday, October 17, 2008
Wednesday, October 15, 2008
They released the beta 3 version of their WPF Sprint Task Board application a few weeks ago which now supports the Scrum template 1.2 for TFS 2005 as well as 2.x on TFS 2008. It is going to be release by the end of this month and the pricing will be $90 per license for 10 copies or under. You can get discounts for larger volumes.
I want to thank the user group leaders (Sujata, Jim, Charlie, & Steve) for having me down.
Sunday, September 14, 2008
So is up front requirements gathering and design really dead?
I have never been a agile purist and I think that for my clients some hybrid is more prudent. In the past I have been on Scrum teams that designed on the fly and kept the YAGNI mantra. Sometimes this resulted in some patchwork architectures and some disjointed business themes in the application. While I do think it is a great idea to embrace change, a basic vision for both your business case and architecture/design of any software solution are needed to keep the smaller iterations on at least some common path. This vision should be able to change as well, but there are some fundamental things that most probably will ring true for the solution. Determining that line is a black art. Too little and you risk being all over the place in your deliverables. Too much and you start becoming too rigid and have lost the benefits of an agile approach.
So how do you know how much up front work to do?
If I had a textbook answer I would give it to you. And it would most likely be wrong. Every case is different. Each client's situation and environment is different. As a company's business evolves the line might have to move also. But I do think that forming a basic business case as the initial vision and some high level architecture and design is almost always warranted. Even Ken Schwaber, one of the originators of Scrum, advises to start as soon as you have enough backlog items to start a sprint. You do not need grand functional specifications and loads of UML diagrams. As is often quoted "The plan is useless, but the planning is essential." When determining if you need to detail a specific business case ask yourself how essential is it to our core business? Higher value requirements always get the most attention. As far as architecture/design, defining the basic components and their interactions at a high level should be enough to ensure your deliverables follow a cohesive path. When determining how extensible a given component should be, concentrate of the most probable changes rather than inventing all sorts of possible future scenarios.
So how can you gather requirements and perform up front design while still being agile?
If you are going to start a sprint with just enough product backlogs items then some of those product backlog items should be forming high level business cases and prototypes so that subsequent sprints will have the benefit of an uniform vision on both fronts. I also believe that you do need some level of documentation for these outside of just the backlogs. A wiki is a great place for them since by its very nature embraces change (and the good ones can provide history for those people who just cannot get over the idea of this type of change). To take that idea to the next step, Team Foundation server allows you to add links to web pages on backlog items so that you can tie the documentation to the user functionality and development tasks. If you want to go low-tech use flip charts and save all the paper. Post it on the walls of the room where the team is literally surrounded by the business and architectural vision.
Even if you are well into an agile project, you can always have the stakeholders redefine the vision if you feel you are straying too far because of only thinking about the next sprint. Change is inevitable, but your company's core business fundamentally changing in not very probable. And good design should elegantly accept change also. I do not think up front gathering of requirements or design is dead. I just think that in agile environments it has evolved and shed its more useless features.
Tuesday, September 09, 2008
- Do key members of management buy-in to the agile concept? They do not need to understand it in its entirety, but they need to be open to the new (and sometimes radical) ideas it brings.
- Do the other departments show interest in the agile concept? I have seen the most push back from QA and BA departments when adopting Scrum. Some of them see it as the developers wanting to "take over" some of their territory. It is sometimes a hard task to convince them this is is not taking over anything but sharing the effort across all departments as part of a cross functional team.
- Does the nature of your business mandate processes that are counter to Scrum's? Many agile purists claim there is not such thing, but there are simply some businesses that would have a difficult time adopting Scrum because their way of doing business demands an approach in direct conflict with some of its ideals. Strict deadlines that cannot move, regulations that require comprehensive documentation, or a level of precision that requires a large amount of up front requirements gathering and system design are not impossible in Scrum, but might cause you to adapt it to the point of loosing the true benefits of the process.
- Do you have a team of disciplined developers? This is something I talked about in another blog post. Scrum (and agile in general) is misconstrued as allowing developers to do whatever they feel like. In fact it is the exact opposite. Many developers have struggled coming from very structured shops that gave them a process to hide in and basically told them what to do. Scrum requires a developer to be cross functional and the processes themselves are meant to expose inefficiencies.
- Does your infrastructure allow for cross functional teams? The best way to work in a Scrum team is to have them physically located together. I have worked in both situations where everyone was in the same room or a short distance away to having half the team in two other states. If you cannot be together physically, you will need some mechanisms to bridge the gap and allow easy collaboration between team members. Everyone knows I am a big TFS fan and I personally would not manage a diversely located team without it. Readily available conference calls, Live Meetings (WebEx or whatever), and instant messaging are a must for every member of the team. This does not just mean developers. BAs, QA resources, IT staff, and the users/stakeholders should all be as easy to collaborate with as the developer sitting next to me.
These are by far not all the questions to ask yourself, but they are some big ones that get the conversation started. I have heard agile experts even advise adopting agile practices without management knowing and slowly work up to involving them. In my experience that is a huge mistake. Moving to Scrum or any other agile methodology should be something the entire company works together on to make a clear and unanimous choice. There are definitely companies out there that are not yeat ready to adopt a process like Scrum and may never be able to. Scrum like any other software development process is not a silver bullet and is not meant for everyone.
Coming up next for the Comfortably Scrum series: Product Backlog Items.
Wednesday, August 27, 2008
- Ted Neward bought me a beer right off the bat. Then lost all his poker chips to me. Awesome. I also hear is a pretty smart guy!
- Brian Prince is a great DE and is always dedicated to growing the community as well as its individuals. Plus he was at devLink on his birthday.
- Kevin Kline is a SQL genius. Plus he came to devLink on his wedding day!
- Bill Vaughn is also a SQL genius, plus someone told me he wrote a book or two. But he is terrible at bluffing in Texas Hold 'em.
- Cory Haines has some edgy ideas but who can argue with those manly mutton chops! Plus he plays a mean harmonica.
- Rob Foster is always fun to be around and if I am going to slink past hotel security at midnight, he is my wing man.
- Steve Andrews graced my TFS talk and made me nervous. He did not throw anything or laugh out loud so I thank him for that.
- Tim Rayburn and I came up with the one true method call to end all method calls. He could also become a poker tournament announcer if he ever quits his day job.
- Jennifer Marsman's passion and excitement for developing is so contagious that the World Health Organization ranks her right below the Asian bird flu. She is also the bastard daughter of Dutch royalty. God save the Queen!
- Drew Robbins also did a great job with the event and the pre-conference poker tourney. Oh wait, that was Jeff Blakenburg. He is a great guy too!
- I did not get to spend much time with Leon Gersing but he tends to break out into spontaneous dance routines fairly often which is bonus for any event.
- Sirena Benefield was a new attendee from ITT tech who won everyone over the second she showed up. She codes, she plays Diablo II (old skool!), rocks on Guitar Hero, and was genuinely excited to be a part of all the activities. We will hear more from her in the near future.
There were so many more people, but I cannot come up with clever (or not so clever) lines for all of them. Thanks to everyone who participated in every capacity and I hope to see you again soon!
Tuesday, August 26, 2008
- John Kellar is the backbone of devLink. His attention to detail makes sure the event runs as smooth as possible and his involvement in the developer community ensures a great line up of speakers every year.
- Leanna Baker does a fantastic job with the logistics of the conference which are considerable. Where most of us work in the industry and gain a little notoriety from being a part of it, Leanna is not a developer and just simply wants the conference to be the best it can be. Her husband John Baker was a big part of keeping things running smoothly although he is a donut thief.
- Rachel Twyford has been a dedicated part of all three devLinks while being very pregnant for two of them. She was constantly on the move and when I saw her doing stretches at the final keynote I swore she was having the baby!
- Alan Stevens brought a very cool, new vibe this year with his excellent Open Spaces. Plus he throws a heck of an after party.
- Keith Elder was always on hand to help out and is a great M.C. Plus he does a great Frank Sinatra impression.
- Randy Walker was constantly lending a hand and was usually one of the first volunteers onsite and one of the last to leave.
- We had a great group of volunteers who really did a terrific job of helping run the conference: Jason Clark (who I am glad did not pass out in the sun), Bryan Meyer, Cliff Jacobson, and Evan Hoff. These guys were either constantly moving or stuck in one place (and sometimes outside) for long periods of time.
Without these people devLink would never be the greatest regional conference in the known universe.
THANKS TO EVERYONE!
I am starting a new series of blog postings entitled "Comfortably Scrum" as a way to spend a little more time on a specific topic and do it justice. I eventually plan to accompany each blog post with a companion video.
I am currently working on the first post on gauging if your company is ready to adopt an agile process like Scrum.
More to come!
Monday, August 25, 2008
Monday, August 18, 2008
This week is the third devLink Technical Conference here in Tennessee. After helping John Kellar start this in 2006, I took a break in 2007 to have a baby, but I am back as Vice Chairman again this year. For 2007 we are located at Middle Tennessee State University (MTSU) in Murfreesboro, TN. We thought the change in venue and the extra distance from Nashville may cause some roll off in attendance, but we have been sold out for a month. There are some great speakers coming this year and I am excited about the addition of Open Spaces which are being run by .NET Jesus himself, Alan Stevens. I took time off from presenting the last few months after my 5th child was born, but last week presented for the local AITP chapter and I am doing my Scrum and TFS presentation on the last day of devLink. Hope to see everyone there!
Wednesday, July 16, 2008
Question: Where is the functional requirements documentation?
Answer: There is none. They are in the Product Backlog as User Stories.
Question: Where is the architectural and design documentation?
Answer: There is none. It is in the code itself.
Question: When do I get status reports?
Answer: Never. Every day we have a Daily Scrum and update our tasks in the Sprint Backlog.
While I am not a true agilist, I do believe that relying on static documentation and periodic status reports to keep track of a project is what I call “managing from afar for plausible deniability.” Being a part of a Scrum Team means accepting a large level of responsibility. Product Owners cannot simply stroll in occasionally and rely on one-off status reports to gauge how well a project is going. Everyone is involved and it is not an opt-in process. No one on a Scrum should ever be able to use the excuse “I did not know…”
This does not only affect the Product Owner. The most resistance I have gotten in the past is from Quality Assurance. Typically they are used to detailed specifications to create detailed test cases that they execute after the development process is over. In a Scrum Team, the QA testers are peer members just as much as the developers. I’ve had the complaint before that all QA was given at the start of a Sprint to create their test cases were User Stories and Conditions of Acceptance. My response is “You’re right, but that’s all I have to go on too and I have to write the code!” The best way to get QA on board in my experience so far has been to have them at every Daily Scrum and in any design or requirements gathering sessions the developers have. This means getting your testers out of their section of the office and in the thick of the development team. They can use the User Story as a starting point and then flesh out their test cases along with the developers as the functionality is created. They can perform dry runs on code that is nearing completion so that at the end of the Sprint the goal would be that all code has been QA tested at least once.
Developers are not immune to this ailment either. Some junior or less disciplined developers may become vapor locked when they have to start coding without a detailed specification. You cannot go code in the corner and be fed requirements and Jolt cola through a slot in the door. You should not turn to the Scrum Master when you have finished a task and ask “What next?” The excuse “That’s what it said in the spec” is no longer valid. Team members must rely on constant collaboration to make sure the developed solution meets the user’s needs as well as the team’s technical standards.
I must admit the teams I have been on have experienced these problems and we still struggle against old habits. We try to make good use of the Sprint Retrospective to adjust each iteration to make the process better. Our Scrum Team has met every date, encountered very few QA or production defects, and has made our stakeholders consistently happy. We have done this through constant collaboration across all members and by evolving our process. There have been very few late nights and no death marches. And I have to say that the experience had made my statement of not really being an agilist less true each time I say it.
Monday, July 07, 2008
Sunday, June 29, 2008
The Team Foundation Server API provides an easy object model for iterating through a work item’s history. Each WorkItem has a Revisions collection that holds individual snap shots of the work item each time it was updated. The Revisions in the collection are in order or earliest to latest, but there is also a Rev property for each one that is the sequential order. Each Revision has a collection of Fields for each field, both the common system fields and any fields added from a custom process template. When you access an individual Field in the Revision you can see what the original value was (OriginalValue) versus what the value was changed to in the revision (Value). If the field was not changed the values are the same.
Since this is the very first time the work item was saved the OriginalValue property on all fields is null. The ChangedDate is the date we saved this particular revision and the RevisedDate is displayed as the maximum value of the DateTime type since this particular revision has not been revised yet. If we edit the work item on June 3rd the Revisions would look like this:
The RevisedDate for Revision 1 is set to the ChangedDate for Revision 2. The fields for Revision 2 now have their OriginalValues populated with the appropriate values from Revision 1.
So based on the examples above, if we want to know the last time a specific field was updated you would look for the “System.ChangedDate” field’s Value for the latest Revision where that field’s OriginalValue and Value properties are not equal. Here is a LINQ query that would accomplish this for the “Work Remaining” field (this field is an extended field that comes with the Conchango Agile Process Template).
One thing to remember when using the Work Item object model is its effect on performance. Not all fields are loaded initially so depending on how you access the WorkItemStore you may incur additional round trips to the server. This MSDN article does a good job of explaining how this works and what your options are to increase performance.
Monday, June 16, 2008
Working on this has helped me get deeper into the Team Foundation Server API and I will post soon about some interesting discoveries in the work item history objects.
Thursday, June 05, 2008
Monday, April 28, 2008
One thing that I have learned is that a development team that wishes to get the most out of adopting Scrum must be a very disciplined team. It is sometime a misconception that agile methodologies are basically "the inmates running the asylum", but agile (and Scrum in my experience) requires a more mature and self-reliant team than waterfall. Scrum team are "self organizing" and are given almost total freedom to get their job done during each Sprint. They are left to determine what needs to be done, who works on what task, the approach for each item, etc. often with little to no outside influence.
This is quite a big responsibility and I have seen many people (and I include myself) struggle with it. Less mature developers may dive into a technical task and be oblivious to how their task relates to the project as a whole. Often they do not take advantage of the Daily Scrum meetings to get a good sense of how the team is progressing towards the current Sprint goal. These developers will often under estimate tasks and their deliverables will tend to be less on target.
Scrum Masters can fall into old habits also. As a Scrum Master I tended to want to "lead" the team rather than facilitate the team leading itself. Sometimes this was "muscle memory", but often I had to provide a more hands on approach when my team would start to drift away from the goals of a Sprint. I had to make a concentrated effort to let go and allow my team to run itself. I also am guilty of getting off track in the sacred Daily Scrum meetings. My team takes great joy in using my own phrase "Don't tell me about the pregnancy, show me the baby." when I do this.
I think that most every developer really knows what must be done to create a solid software solution, but what we struggle with is the discipline to execute in our daily activities. It is often easy at the beginning and then gets decidedly harder as the pressure increases. I personally struggle with this and am trying to make a real effort to make myself adhere to the principals that I believe make me a better developer.
Just this last Sprint I found myself continuing on a task that we had time boxed to a few days. At the end of the time period I was very close to wrapping it up and decided to extend the time period. Each time I got "close to finishing" another issue arose and I extended the time period again. I did finish the task and the result will greatly benefit the team, but other tasks were sacrificed. I also had to admit to myself that if another member of the team had done something similar, as the Scrum Master I would have probably called them out on it. It was another lesson it how to be more disciplined in my approach.
My hope is that each day I gain a little more experience and a little more practical approach to how I adopt (and sometimes DON'T adopt) agile/Scrum philosophies. That way the next day I become a more disciplined developer.
Wednesday, April 16, 2008
Our first issue was the fact that our applications were built using Visual Studio Team System 2008 targeting both the 3.0 and 3.5 versions of the framework, but our Team Foundation Server was still 2005. There were several posts about creating custom tasks or using Powershell, but the simplest resolution was to simply use the FileUpdate task in the MSBuild script to modify the solution file. This was not actually in a blog post, but in the comments to this one. I would add to this approach that you change it back somewhere after the CoreCompile target fires. I opened the solution on the TFS server itself a few times to troubleshoot some other errors and without changing the file you get the conversion wizard when you try to open the modified solution file.
This worked for our 3.0 projects for our WCF services, but our web application needed the 3.5 version of the compiler due to our use of C# 3.0 syntax such as automatic properties and object initializers. Again there were several posts with various resolutions (some involving create another build server with a modified MSBuild.exe) but most were not acceptable to the client. We eventually called the DEVENV for VSTS2008 directly from the command line to build the web application solution. This worked better than I expected and even itemized build errors in the build log just as if it were part of the core compile. Calling the DEVENV was outlined in several blog posts also, but a fair amount of these had incorrect or incomplete syntax. Finally we found this post that provided the correct syntax and a very clear explanation of why it works. This resolution also helped us overcome the glaring omission of MSBuild support for setup projects.
So after many, many failed builds we finished our build scripts today that compile all of our solutions, build the setup projects, copy the MSI files to a network share, and then use PSEXEC to install the application on our development server. We have a separate batch of build scripts for the different branches in the code so within a few minutes I can deploy any branch of the code to our development server (or local machine) for testing. Even with a few days to figure it out the overhead of doing that manually will save us much more time in the long run.
Wednesday, April 09, 2008
Saturday, March 29, 2008
Saturday, March 22, 2008
- Scrum for Team System - One of the best TFS Project Templates for Scrum around. Created by Conchango in association with Ken Schwabber.
- Control Chaos - A good website for all things Scrum. Lots of whitepapers, books, and other resources.
- Scrum Alliance - Another good website for Scrum with a more community feel.
- Agile Management Blog - Aimed more at project manager types (or Scrum Masters), but has some good practical blog entries from David Anderson. This link is to his post about TFS and Agile processes.
- eScrum - Another TFS Project Template for Scrum.
- "Integrating Agile Development in the Real World" by Peter Schuh - Good introduction to several agile methodologies (including Scrum).
- "Agile Project Management with Scrum" by Ken Schwabber - The de facto book on Scrum by one of its creators.
- "The Enterprise and Scrum" by Ken Schwabber - The companion for the book above that takes the Scrum ideas and applies the to large, enterprise level projects.
- "User Stories Applied: For Agile Software Development" by Mike Cohn - Good introduction to using User Stories to gather and document requirements.
Team Foundation Server Resources/Tools
- MSDN TFS Site - The official Microsoft site for Team Foundation Server.
- TFS 2005 Power Tools - Tools for editing work item and process templates, check in policies, extended command line tools, build tasks. etc.
- TFS 2008 Power Tools - Mostly the same tools for 2005 ported to 2008.
- CodePlex - Tons of community created tools and guides for TFS including a migration tool, Subversion source control bridge, and more.
- Personify Design - Creators of TeamLook which adds TFS extensions into Outlook and TeamSpec which is similar to Rational's RequisitePro tool for maintaining links from Word documents to work items in TFS.
- TFS API MSDN Sample - Great sample project showing how to interact with the TFS API.
Team Foundation Server Blogs
- Buck Hodges - Lots of good information on TFS, third party tools, etc.
- Brian Harry - Some overlap with Buck Hodges' blog, but he also includes lots of statistics on their own implementation of TFS internally.
- Naren Datha - Several blog posts on TFS customization.
Team Foundation Server Books
- "Professional Team Foundation Server" from WROX - Good starter book that covers a wide range of topics.
- "Team Development with Visual Studio Team Foundation Server" by Microsoft - General guide for implementing. Lots of good practical examples. You can download it for free from CodePlex.
Tuesday, March 04, 2008
- Use of Iterations for designating Sprints: Previously you entered a sprint number into Product Backlog Items (PBI) and Sprint Backlog Items (SBI) to designate what sprint they corresponded to. There was no real validation and it was a tenuous link at best. Now the TFS Iterations are used and it provides a more solid approach.
- User Stories in Product Backlog Items: The PBI template now supports the User Story motif with a specific field for the user story text and another for the acceptance criteria. Not that you could not have done this before, it is now just built in.
- Much Improved Project Portal: The project portal is much cleaner than the previous version and I love the built in Wiki. It would be nice to have the ability to add a link directly to Wiki items, but you can do this with Hyperlink links if you really want to.
- Bug Work Item: We created our own "Bug" work item in the previous version. Having a built in item for this makes reporting much easier out of the box.
I have also enjoyed several of the improvements to TFS 2008 including:
- Easier Build Type Creation: A new wizard makes creating a build type much easier. Things you used to have to man handle the XML build script to accomplish are now simple options in the creation wizard.
- Queued Builds: I hated getting the pop up telling me another build was already in progress and having to sit and wait for it to finish.
- Out of the box Continuous Integration (CI) support: What used to be several steps that included touching event subscriptions, filters, and web services is now a few options on the build creation wizard.
- Links in Web Access: There has never been a very good way to see the link relationships between work items, but now the views in the Web Access portal show a nice little plus icon so that you can drill down to related items. Very nice.
Saturday, March 01, 2008
Thinking about it later, I thought of how people have kept up what they call an "Idea Backlog" of things they think up but cannot immediately put the time into them to see them to fruition. I thought using TFS, Sharepoint, or some similar technology so that a company could create an Idea Backlog much like a Product Backlog to facilitate the submission, discussion, and initiation of project ideas.
My thought was that ANYONE would be able to post an item to this Idea Backlog from the highest member of management to the most junior developer. These backlog items would have a little bit of structure to make sure initial submissions were at least minimally fleshed out, but then people would post comments in response to the submitted idea.
So Employee A submits an idea that equipping the engineers that regularly inspect Company XYZ's Widgets in the field with a Tablet PC application would increase data accuracy and decrease time spent per inspection. Other employees would post comments, questions, etc. to help flesh out the idea such as: "What about a Tablet PC application would provide better accuracy and less entry time than a laptop or handheld?", "Does anyone know a formula for calculating the average cost per minute for an inspection currently and the average inspection time?"
Now the discussion is open and available to everyone instead of siloed to management. Input from any source could provide great value and address areas of the idea that may have not been covered if it had been decided by only a few select people.
Most companies want a bit more structured analysis when deciding to move forward with a project and they usually have some basic criteria and metrics they apply to a business case to judge how valuable it would be to an organization. For instance, the pencil pushers usually want to know what the Return On Investment (ROI) or Total Cost of Ownership (TCO) would be. On previous projects I have seen companies spend a good bit of time trying to calculate this up front and just like trying to capture all the requirements up front and predict strict timelines: it is rarely very accurate. But it is something to be addressed, so each Idea Backlog item can have an ROI (or TCO, etc.) metric applied to it by any employee. It could be as simple as a 1 to 5 rating: 1 being little ROI and 5 being substantial. Risks Analysis is another big thing I have seen companies dedicating effort to and this could be yet another metric to apply to an item in the Idea Backlog. There could be many more metrics, both standard ones for all ideas and then custom ones that are more specific to a particular idea.
These metrics would follow a convention of the lowest rating being the least valuable and the highest rating being the most valuable to the company. A report could easily show what the employees of the company think about the value of the items in the backlog. Items could then be sorted by the metrics and you start to get a prioritized list of ideas much like a Product Backlog. A go decision for a project is still most likely going to be up to a select few, but now the evaluation of the idea is much more open and collaborative. When the go decision is made, postings and comments to the Idea Backlog item would also most likely give birth to Product Backlog items to get the project started in its first Sprint.
I'd be interested to hear comments on this idea as I myself start to think more about it. As a big proponent of Team Foundation Server, I am going to try and implement something like what I have described above as a collection of custom work items and links. I will post more as I start to work on this.