Juan J. Perez

Facebook Developer Garage and Methodology

2008-05-06T05:19:00Z

I attended the Seattle Facebook Developer Garage tonight and kudos to the folks who organized the event! It was a fantastic event that was literally bursting at seams with people. There must have been over 200 people at the event from all over the Pacific Northwest. I have used facebook for some time and get how pervasive it has become, however, there was a large number of people coming up with very elegant/simple solutions to interesting problems. Maybe I’m late to the party here, but these social networking platforms are enabling real businesses that are services thousands to millions of users.

Onto the point of the post: At the event, there were a serious of developer and some business oriented talks (each talk was about 10-15 minutes). All was fun, the crowd was laughing and listening- doing what happens at most of these user group type talks. Then we got into a design oriented session that included the word “beautiful” in the title. Although the speaker had some great points, people did not react the way they had reacted to the other sessions – this was a talk based on subjective characteristics and a series of “steps” that we could follow to achieve these attributes.

I realized that we had crossed a type of boundary between things that could be proven and ideas/methods that seemed to be the speaker’s opinions. I think this is a common problem when people speak about best practices/methodologies. I have seen this reaction many times – I’ll even admit that I’ve seen it at talks that I’ve given before. I guess there’s no better way to learn something that to experience it for yourself. So what do I think this speaker could have done better when talking about his methods:

Prepare the audience for a session on “best practices.” Developers are really good at finding holes in things. It’s important for people to get in a mindset that these best practices are just one of potentially many means to the end.
Give examples. Supporting each of his principle with a number of examples. Some that clearly followed it and others that did not.
Understand important metrics. Identifying metrics allow people to track and optimize them. Not all metrics are created equal, but metrics are important in understanding the dynamics of the system/progress.
Identify stakeholders. Personas are just as important to the method/best practice as they are to the system that is being created.

In the spirit of a “best practices” blog post, I’ll be up front about my list of principles J. These are some principles that I’ve learned over my time working on software methods and it’s not intended to be an exhaustive list.

Jeff Beehler talks about the VSTS Project (planning and operations) on Channel 9

2008-03-21T21:33:00Z

Jeff Beehler was interviewed by Brian Keller on Channel 9 and talks about how VSTS runs their team from the highest level (Pillars), though Value Props, Features, all the way down through Tasks, which could even have sub-tasks. You'll notice that he spends a lot of time in both VSTS Reporting as well as navigating the Work Item system which is where these project management entities (Pillars, Value Props, Features, Tasks) are stored. Since Rosario has strongly typed links between work items, it's a very natural experience to dig around (both up and down) the links graph to learn about different aspects of the project.

This is a really interesting video from both a business and requirements perspective because it shows the continuum between the operations of the project at the Task level as it relates to the schedule (bottom levels) and the business value delivered to customers at the Pillars and Value Propositions (top levels). Remember, it’s not good enough to deliver quality software if you miss the target for the end-user (business) value and Jeff shows how by using TFS he can understand, not only the state, but also the dynamics of the project at both ends and everything in between.

The question that lots of people will have is “How can I get that level of visibility and project management in my team?” I think the answer has two parts: (1) What is the level of visibility you need for your project. The VSTS team is a relatively big team broken down to many sub-teams which delivers releases at a specific rate. The levers you need is a function of your team’s goals related to managing releases, quality, work breakdown, resources, etc… It may look similar to this or require more or less levers and visibility points (2) As Jeff mentioned, those reports were custom reports built by his team. I’ve yet to run into two teams that work the same way. Lots of teams say “We’re Agile” and even then there are always subtle differencse at best. That means that you’ll end up customizing reports, especially at the higher levels. At the lower level (Tasks) Jeff shows a cumulative work diagram that is very similar (if not the same, I didn’t ask Jeff if it is the same so I’ll say it’s similar) to the Remaining Work report found in MSF. Bottom line is you’ll have to have someone who knows the TFS database and warehouse build these reports for you.

Check out the Channel 9 Video at http://channel9.msdn.com/Showpost.aspx?postid=391362.

TeamSpec on Channel 9!

2008-03-10T04:44:00Z

A couple of weeks ago I had the opportunity to demo TeamSpec to Brian Keller and the Channel 9 camera! I want to thank Brian for the opportunity to show some of the software we've been building at Personify for the last 2+ years. One thing you'll notice about the video is that it was done in one take. There was something scary about the idea of one take, but it turned out to make the session more natural.

Check out the Channel 9 TeamSpec video at http://channel9.msdn.com/Showpost.aspx?postid=389257.

The folks at Channel 9 (as well as 8 and 10) are providing some really great value for the industry. I've been spending more time watching videos on all kinds of topics/areas.

Mix08 and SEPG 2008

2008-03-04T00:34:00Z

I will be attending both Mix08 in Las Vegas this week as well as SEPG 2008 in Tampa starting on March 17.

At Mix, I'll be roaming the sessions as well as the hands-on-labs rooms.

At SEPG, I will be at the Personify Design station of the Microsoft booth. If you are attending SEPG drop me a line or swing by the Microsoft booth. I will have some tasty demos of our recent release of TeamSpec!

Yes, March is going to be a crazy month :) You can either find me on LinkedIn or Facebook and send me a message...

TeamSpec in the community...

2008-02-28T06:20:00Z

It's very exciting to see the different creations that people in the TFS community are creating using TeamSpec. At the outset of TeamSpec, we set to solve the stale document problem. In the process, we ended up created an environment in Word that enables documents to stay synchronized at the item level.

Check out Willy-Peter's (VSTS MVP) post about his initial experience with TeamSpec at http://dotnet.org.za/willy/archive/2008/02/21/teamspec-v1-0-what-a-pleasure-on-tfs2008.aspx.

Let us know how you're using TeamSpec. Post it on your blog or send us mail and we'll post it for you.

Oh, and by the way: We're very close to finishing Rich Text support for those work item fields that are stored as the HTML format on TFS. Rob Schlender (one of rock-star devs) is truly making magic in making Rich Text support a reality. I'll make sure to get a video together once we get closer.

TeamLook for TFS 2008 launches!

2008-02-09T01:53:00Z

We're very excited (and happy) to announce the release of TeamLook for TFS 2008! In addition to support for TFS 2008, we’ve made some usability and performance improvements which also make TeamLook for TFS 2005 better. You’ll notice that we’ve now united the installer for all configurations making it much easier to install. You can download the new TeamLook bits at http://www.personifydesign.com/products/teamlook/download.aspx.

For those of you that haven’t had a chance to learn about some of the exciting improvements introduced to Team Foundation Server 2008, check out Brian Harry’s blog entry on the TFS 2008 feature list.

As always, send us mail with questions and comments. We love to hear about interesting uses of both TeamLook and TeamSpec! If you haven’t checked out TeamSpec, make sure to check out http://www.personifydesign.com/products/teamspec/discover.aspx.

Thank you for your continued support!

TeamSpec v1.0 (for TFS 2005 and TFS 2008) has launched and is available now!

2008-01-20T01:16:00Z

“What does the spec say it should do?” These words can come from anyone on the IT team! We’ve heard them from testers that are verifying functionality. We’ve heard them from managers asking to understand project progress or approving a future budget. We’ve heard it from developers that are about to implement functionality. We’ve heard it from end users that ask about why it works like it does today or hoping for how it will work in the future. The reason this is an interesting and honest question is because we all expect the intentions of the software to change as we learn more and solve parts of the problem. The problem is that most teams are moving so fast that we forget to update the spec when we make decisions and implement the functionality in the code or operating environment. Without a herculean effort by someone on the team, inevitably, the spec becomes stale. It doesn’t take too long before people stop asking the question because everyone knows that the spec just doesn’t know: it’s stale!

Wouldn’t it be nice if the spec knew about the changes in the project and was able to synchronize to the current plan? Wouldn’t it be nice if you could push content from your current spec documents into a centralized database that will manage the lifetime of those requirements as they change? Wouldn’t it be nice if we had document templates that could make it very simple to create new requirements in the project? Wouldn’t it be nice to change the contents of a document spec and update the centralized database directly from the document? Wouldn’t it be nice if we could throw away old specs if the formatting and layout of the document just didn’t make sense anymore and create a new spec with the most up-to-date content and new formatting? Wouldn’t it be amazing to be able to answer the “What does the spec say it should do?” question so many times that your colleagues and constituents one again believe that the spec does in fact describe how the system should work?

With Personify Design TeamSpec and Microsoft Team Foundation Server, you can!

To learn more about TeamSpec, watch the videos at http://www.personifydesign.com/products/teamspec/discover.aspx.

Download the TeamSpec trial at http://www.personifydesign.com/products/teamspec/download.aspx.

Thanks to everyone in the community that has provided feedback during the betas. We really appreciate your expertise and cannot wait to see the types of specs you create using TeamSpec! Send email to teamspec@personifydesign.com and tell us about how you’re using TeamSpec- we love to see your creations!

Terry Clancy to talk on Requirements and VSTS on Thursday, Jan 17th!

2008-01-16T19:00:00Z

Terry Clancy will be giving an online talk/webcast on Requirements and VSTS tomorrow! Apologies for the short notice, but there's still time to register.

Register at: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032362264&EventCategory=4&culture=en-US&CountryCode=US

Event Overview: Developing precise and accurate requirements is a crucial step in the success of a development project or a new business process. Microsoft Visual Studio Team System, along with Microsoft Visual Studio partner solutions, can help companies improve their requirements development process. A number of partner solutions provide the capability to define requirements and store them in Microsoft Visual Studio Team Foundation Server, integrating these requirements into the application development life cycle. In this webcast, we provide a detailed look at requirements solutions that integrate with Visual Studio and Visual Studio Team System.

Presenters: Terry Clancy, Business Development Manager, Microsoft Corporation

Videos: Managing Requirements using TeamSpec and TFS

2008-01-10T02:34:00Z

The journey into creating more videos that show TeamSpec is action is DONE! Well, for now :). Visit the new 'Discover TeamSpec' page at http://www.personifydesign.com/products/teamspec/discover.aspx to view the six videos that show how TeamSpec makes TFS work items a first class citizen inside Microsoft Word. The first five videos are quick (3-5 minute) where I show the core scenarios that we're enabling with TeamSpec. The sixth video is a (15 minute) feature walkthrough where I show all the parts that enable the scenarios shown in the other videos.

The videos are titled:

Using a document template and TeamSpec
Connect existing or new specs to TFS
Create specs from requirements in TFS
Manage changes in specs
Find specs from TFS work items
TeamSpec Feature Walkthrough

Please send us feedback and comments.

Oh, almost forgot - we'll be launching TeamSpec next week! Back to work... :)

TeamSpec Feature Walkthrough Video!

2008-01-05T01:51:00Z

First off, Happy New Year everyone! I hope you had a great holiday break and are ready for an exciting 2008!

We're in the final stages of stabilization for TeamSpec and I've started to put together some videos showing off the functionality. I started my journey into creating these videos in the "correct" way, which would result in a beautifully polished video, great timing, the right talking points, perfect scenarios, etc... About a few hours into it I realized that my goal wasn't necessarily to produce an award winning set of videos, but instead show how TeamSpec makes TFS Work Items a first class citizen inside Microsoft Word. With TeamSpec, gone are the days when a spec becomes stale and there's nothing you can do about it. Just synchronize the document with TFS. If you don't like the formatting you used for the User Stories section of your document, wipe it and use a customized TeamSpec Skin to recreate that section of the document with new formatting!

It's better to watch the video and see TeamSpec in action than to read me rave about it. Yes, we use/dogfood it at Personify and we love it! We can't wait to fix the remaining bugs and have you (the customers) start using it too. :) With that, please click on the link below to watch the TeamSpec Features Walkthrough video.

http://personifydesign.com/products/Videos/TeamSpec%20Feature%20Walkthrough/TeamSpec%20Feature%20Walkthrough.html

TechEd EMEA Keynote and Personify Design

2007-11-05T15:21:00Z

It's always great to see your work on stage! Today I had the pleasure of sitting in the audience at the TechEd EMEA keynote where Soma (Corporate VP Developer Division), Tony Goodhew (Senior Product Manager), and Dan Fernandez (Lead Product Manager) delivered a FANTASTIC keynote and set of demos. I wanted to congratulate the Personify team in Seattle for building some of the very exciting parts of the demo which received some significant applause. Specifically, the Silverlight based aisle shopping experience, the WPF based 3D product viewing control which showed the quince paste container inside the Microsoft Word custom task pane, and the WPF based interactive 3D in-store management application which allows the store manager to navigate the store in 3D and place products directly on the shelves.

Congratulations to Soma, Tony, Dan, and the rest of the folks at Microsoft for a great keynote and more importantly delivering a very compelling set of software tools!

Justifying Requirements in the Software Team

2007-10-27T01:26:00Z

I’ve received a few requests for help on justifications for Requirements efforts in teams. Often it’s someone trying to get resources from their management with hopes of understanding and evolving their software process. The ultimate challenge is identifying the right amount or balance of Requirements Management and Business Analysis will help the team. Given the caveat that I have never seen two teams that are the same, here goes…

Justification for Requirements Management to the business managers is sometimes a catch-22 situation. It’s an investment to visualize and breakdown project requirements while understanding the problems that stem in project requirements requires visibility into the software process. On the other hand, treating IT investments as a black box is a bad idea and can result in missed deadlines, delivering the wrong solution, and a low quality deliverable. The right amount of process in the software team is a function of how efficiency is managed and optimized. In other words, manage and measure those things with variability that can benefit from efficiencies.

Here are some general problems that are answered by involving business users via requirements and traceability. There are some pretty extensive studies that have been done on Requirements Management, Project Management, and Business Analysis which provide literally volumes of information.

Stakeholder vs. developer language differences

Developers and end-users/stakeholders live at different levels of abstractions and therefore communicate using different context and vocabulary. It’s important to capture the stakeholder requirements and map them to the development domain.

Change happens everywhere - in the business domain (just as well as the development domain)

When the business learns something about the business environment the Development team needs to assess the impact that change will have on the project. Without a set of up to date requirements which are mapped to development artifacts (design, architecture, tasks, bugs, etc…), it’s very difficult rank the change request relative to the existing state of the project and resources.

Stakeholder need to be part of the extended team

Validating requirements and their implications with stakeholders or end-users will not only foster a feeling of partnership with stakeholders, but also minimize complexity derived from scope creep. Stakeholder reviews need to enable stakeholders to understand status and implications of their decisions.

Delivery contracts for building trust

Building trust based on accountability and delivering what is promised can be accomplished using Requirement Specifications. Ultimately, if you can’t describe what is going to be delivered then there is a good chance it will never be delivered.

Quality Assurance (QA) needs to know what/how to verify intentions and goals

QA needs to understand all levels of intent (functional, non-functional, business, etc…) in a system in order to validate the system. In some cases it may make sense to involve QA in the planning process to ensure testability in the defined requirements.

Project Planning and Operations are separate

Planning should feed into Operations and vice versa. The iteration between the two disciplines requires a series of transformations which enable traceability from high level artifacts such as business goals to low level artifacts such as code.

Estimating size and complexity requires context

Deciding on the size, however measured, requires both a top-down structured divide-and-conquer style approach as well as a bottom-up verification that everything fits into the defined higher level context/requirements. Without this bi-directional checks and balances the code can implement more than you need or the solution can end up not solving the problem.

Scope management

Defining the part of the problem that will not be solved is just as or more important than defining the problem you will attempt to solve. Because they complement each other, defining the part of the problem you will not solve will help specify the other part.

The following are some resources I use when discussing Requirements Management and Business Analysis. If you have some favorites, I’d love to learn about them.

Wikipedia

http://en.wikipedia.org/wiki/Requirements_analysis#Problems -This enumerates a list of problems between developers and users/stakeholders
http://en.wikipedia.org/wiki/System_Requirements_Specification - System Requirements Specification and a list of deliverable types
http://en.wikipedia.org/wiki/Systems_development_life_cycle - SLC
http://en.wikipedia.org/wiki/Business_analyst - Business Analyst definition and breakdown

Software Engineering Institute

http://www.sei.cmu.edu/str/descriptions/reqtracing.html
http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html - The Requirements Development and Requirements Management section of the document

International Institute of Business Analysis

http://download.theiiba.org/files/BOKV1_6.pdf - Business Analysis Body of Knowledge

Mike Cohn – Mountain Goat Software

http://www.mountaingoatsoftware.com/article_view/27-advantages-of-user-stories-for-requirements - Advantages of User Stories for Requirements

TechEd Developers in Barcelona, Spain

2007-10-24T00:49:00Z

Drop me a line if you are heading to Barcelona for TechEd Developers on November 5th and you would like to meet up. I'm always up for meeting up with people and talking shop. (juanjperez -a-t- gmail dot com)

Cheers,
Juan

TFS and Requirements: Tasks, Bugs, and Everything Else

2007-10-23T22:09:00Z

During software engineering consulting engagements I spend quite a bit of time learning how each team works together to do what they do. Much like the beginnings of a software project, I go through an investigation phase where I literally ask questions such as, “When Sue does X and copies the files to Y who picks them up and does Z?” The goals of the investigation are: figure out how to measure the work that is happening, identify work that is on the “we really shouldn’t be doing that” list, and find gaps in the team’s workflow. Although the last two are very important and are high on the ‘bang-for-your-buck’ scale, the ability to measure work will result in the most mileage for your team since that's how you identify bottlenecks in your team. When you find a bottleneck, the question to answer is “how do you unblock the blocked or make the slow faster?” Since you’re working with people, there are often unpredictable personnel reasons why bottlenecks exists, if we eliminate the personnel reasons for bottlenecks, it comes down to (either slow or non-existent) decision making. These decisions, which are sometimes made by the software team, the operations folks, or the end user/customer, are based on previous decisions. This context can be considered the Requirements of the project since they have to be considered or enforced for the project to succeed. So the question is, “how and where do we store these decisions?” Although they can be stored in a simple spreadsheet, document, or database, significant value can be achieved if they are stored in a database where they can cross reference each other and other project artifacts (such as Source Code, Builds, Tests, etc…) With Microsoft Team Foundation Server Work Item Tracking you can do exactly that.

It’s important to break down the kind of information that is stored in TFS Work Items. I think of it as a stack of information classes, where at the bottom are ‘things that need to be done by people’ (aka Tasks and Bugs) and as you go up the stack it becomes ‘decisions that need to be considered or enforced by people who are doing the things’ (everything else). Since this article is not about bugs or defects, we’ll consider Bugs as equivalent to Tasks since they represent work that needs to or may get done. At the top of the stack are Business Requirements such as Vision, Mission, Scope, Business Goals, etc… As you go up the stack from Tasks to Business Goals, the scope increases and vice versa. For example, quality of service requirements are often relevant to components of a system (higher) or a set of features whereas functional requirements are usually specific to a feature that a user will experience while going through a scenario (lower).

At the end of the day, these work item types are defined by the kinds of work done and type of decisions that people make on a daily basis. Once you identify who does what on your team and track the dynamics of the relationships between work and decisions you will be able to identify bottlenecks and make appropriate changes to either your team or the process (the way the team works together) to improve quality and efficiency. Most importantly, you’ll finally have a view into the dynamics of the team which in the worst case can become the loathed black box.

TeamSpec CTP available

2007-09-27T15:56:00Z

Download the TeamSpec CTP Now!

Before we release a v1.0 of TeamSpec, we want to share the state of the product. We’re very close to making the v1.0 release and wanted to make one final pre-release update both to get more feedback as well as make some final improvements. If you downloaded our last release (Beta) you will notice that we’ve made significant progress towards the vision of making the document an environment where the Business Analyst and Project Manager (and extended team) can manage the planning and change process for software projects completely integrated with TFS.

TeamSpec can be seen as the natural evolution of a TFS work item form since you can create a document from a single work item or a group of work items. The exciting part is that you decide on the formatting/structure the work item fields while enjoying the benefits of Microsoft Word.

This release has improvements in the following areas:

1. Managing changes in documents

2. Online/Offline transition

3. Locating documents published to SharePoint through work item links

4. Associating content in documents to new work items using templates (bulk work item creation)

5. Performance

6. General usability

Check out the Discover TeamSpec section which has been redone for this release. It’s a great walk through on the new interface and feature set.

With this release, we have decided to build TeamSpec exclusively on Word 2007 since Word 2003 did not have core functionality required to make TeamSpec usable.

We look forward to hearing your feedback and thanks again for the support!