Software Engineering, Project Management, and Effectiveness
You can now find our patterns & practices Performance Testing Guidance for Web Applications on MSDN in HTML. It's the same guidance we hosted on CodePlex. CodePlex was our channel for agile release of the guidance. Once we baked the guidance, we ported it to MSDN.
Contents at a GlanceHere's the
Chapters
DownloadYou can download the patterns & practices Performance Testing Guidance for Web Applications from CodePlex.
Guidance Explorer ScenarioIf you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex. Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit. You can then save your view or an item to Word or HTML
Today we posted our Performance Testing Videos to CodePlex. They're a companion set for our patterns & practices Performance Testing Guidance for Web Applications.
Video IndexHere's a list of the videos:
Additional Resources
You can now find our patterns & practices Team Development with Visual Studio Team Foundation Server guide on MSDN in HTML. It's the same guidance we hosted on CodePlex. CodePlex was our channel for agile release. Once we baked the guidance, we ported to MSDN. For some customers, MSDN is a trusted source, so being on MSDN is important. Additionally, MSDN provides some additional hooks and channels.
Contents At a GlanceHere's the guide at a glance
Guidelines
Practices at a Glance
Questions and Answers
How Tos
DownloadYou can download the Team Development with Visual Studio Team Foundation Server Guide from CodePlex.
Guidance Explorer ScenarioIf you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex. Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit. You can then save your view or an item to Word or HTML.
I happened to glance at the MSFT stock. I took a snapshot because I thought it was make believe. Either way, it made me smile.
In my experience, talent and passion are the keys to effective teams. It's not better defined roles. In PM Tip#14: Great teams have members that defy roles, Brad Abrams writes that the best teams defy traditional roles and responsibilities, and I agree.
Role-FocusWhen role issues show up, it's usually a sign there's other problems. Here's common problems:
Carving out roles to help orient the team is one thing (who's on first, who's on second ... etc.) Carving out roles to act as contracts is another. I'd rather work on teams where the focus is on collaboration and results over contract negotiation.
Results-FocusHere's a few keys that help with a results focus:
At the end of the day, I push for results-focused teams over role-focused teams, but it's probably because I'm a fan of getting results.
Time boxing is a way to chunk up time and get results. If you continously miss windows of opportunity or spend all of your time in one area of your life at the expense of others, time boxing can be one of your best tools. A time box is simply a limited set of time to accomplish a result. Think of it as how much work can you get done in a given block of time. I use it to organize my day, drive project results, make incremental progress on problems and spend time on the right buckets in my life.
Why Use Time BoxingUsing time as a constraint and forcing function for results is extremely effective:
Summary of StepsHere's some prescriptive guidance for creating and using time boxes effectively:
Step 1. Identify candidate areas for time boxing.Identify candidates for time boxing. This could be anything from work projects to personal projects. Personally, I've found it the most effective to start with something small, such as starting a new exercise program. I've also found it effective to use it to tackle my worst time bandits (any area where I lose a bunch of time, with either little ROI or at the expense of another area.)
Step 2. Identify your objectives.In this step, ask yourself what you need to accomplish with time boxing. Examples include:
Step 3. Identify the appropriate time box.In this step, figure out what a right-sized time box would be. For example, you might have a project due in three weeks. Within that three week time box, you might decide that if you allocate 2 hours a day, you'll produce effective results.
The right-sized time box largely depends on what you determined in Step 1. You might need to grow or shrink your time box depending on whether you're trying to build momentum, show results or just make progress on a problem. Step 4. Execute results within your time box.Execute within your timebox and stop when you run out of time. This can be tough at first because you might be on a roll. This can be really tough if you are used to doing things until they are done. What you're learning at this step is how to stay completely focused, how to treat time as a limited resource, and how to tune your results. You're also learning how to make time boxes effective for you.
Start with your time box as a baseline so you can evaluate your results. The worst mistake is to give yourself an hour for results, spend two hours, and then say what a great job you did in your one hour timebox. Instead, do the hour, then figure out whether you need longer time boxes or if your approach needs to change. Step 5. Evaluate and adapt.If it's not working, change your approach. Using time boxing is one of the most effective ways to experiment with different techniques to find the most efficient.
Examples of Effective TimeboxingHere's some examples of putting timeboxes into practice:
My Related Posts
I find chunking my notes from lectures and training helps me turn insights into action. I chunk my notes into three categories:
Why It's EffectiveIt's simple, but effective. It's effective because rather than just a list of notes, it's distilled actions and reference points.
Putting It Into ActionHere's what I do
The result is a crisp set of actions, a crisp set of insights, and then a full reference list of notes. Taking a few quick passes through my notes, reminds me of key things and helps the information sink in deeper. Deliberately turning notes into insights and actions also helps retention. Think of it as challenging yourself to use what you learn.
Here's a quick step through of using WCF in Visual Studio 2005. In this case I used a local machine, running Windows 2003, for the service and the client.
There's lot of possible paths, and this is just one path through. I focused on "Hello World" to run through the basic mechanics, but chose a path to touch enough things that might be interesting to explore another day.
ScenarioUse Visual Studio 2005 to do a dry run of creating a WCF service hosted in IIS and calling it from a console application on your local development workstation. (Note that you don't need to host WCF in IIS; for example, you could use a surrogate console application.)
PreparationIn my case, I needed the .NET 3.0 components and the WCF extensions for Visual Studio:1. .NET 3.0 Runtime Components2. WCF and WPF extensions for Visual studio
Summary of Steps
Step 1. Create the test serviceIn this step, we'll create a WCF service that uses HTTP bindings, for backward compatibility (non-.NET 3.0 clients)
Step 2. Add a Hello World MethodIn Service.cs, you'll add your Hello World method:
Compile and debug any errors.Step 3. Test your WCF service
There's two issues you might hit here:
Step 4. Enable meta-data for your WCF Service.
Step 5. Create the test client.In this step, we'll create a quick console app to call the WCF service:
Step 6. Add a Web Services reference to your WCF Service.In this step, we'll add a Web Services reference.
Step 7. Add the namespace to your
Step 8. Call your WCF serviceIn your test client, call your WCF service: static void Main(string[] args) { MyService service = new MyService(); string foo; foo = service.HelloWorld(); Console.WriteLine(foo); }When you compile and run your console application, you should see the following:Hello WorldPress any key to continue . . .
Hopefully this step through helps you quickly see some of the bits and pieces you can play with.
Scenarios are a practical way to organize and focus your product design, development and release. (We use scenario-driven engineering in patterns & practices)
Key Benefits
Chunking Up a Project Using ScenariosIf you think of your product as helping a user accomplish a goal, it helps cut through the fog. You can think of your product in terms of a list of user goals, business goals and technical goals. What's the minimum set of tasks your user needs to perform with your product? That's your baseline release. What's the incremental value from there? That's how you start to shape your versions and releases.
User Experience, Business and Technical PerspectivesUsing scenarios is a good forcing function to bring together the user experience, business, and technical perspectives. For the sake of example, let's say your scenario is "User views the product catalog." From the user experience perspective, you're thinking in terms of "show me a relevant list" and "don't make me wait," From a business perspective, you're thinking in terms of "support a given number of orders per hour" and "lower the total cost of ownership." From a technical standpoint, you're thinking in terms of "requests per second," "minimize resource utilization," ... etc. Well, no wonder getting software right is tough! Luckily, scenarios help you bring together and rationalize the perspectives against a common frame of reference.
Constraints Make More Sense In ContextConstraints are boundaries to operate within, or what the solution must or must not do. In software, I see a lot of generic constraints passed down as policies. When policy meets scenario, you now have a way to evaluate the effectiveness of that constraint. You can also measure whether that scenario is actually meeting the constraint. You can perform scenario-based testing against a set of scenarios with specific constraints.
Walking the ScenariosHave you ever been sold on a great set of features, only to fall flat when you try to actually do something useful? Obviously, that's the extreme case, but it happens to me. It happens less now because whenever I go to buy something, I walk my usage scenarios. Doing a dry run against a scenario is very revealing. This approach works great on the engineering side too. It's one thing to have generic technical requirements for security or performance. It's another to evaluate a scenario and make appropriate and relevant trade-offs from a user, business and technical perspective. Suddenly, generic technical requirements no longer seem as helpful, do they? They still have their place, but when you're engineering your job is to make the right trade-offs.
Scenarios and SolutionsGiven part of my job is to improve customer effectiveness on our platform, I regularly use scenarios as a backdrop for evaluation. As I've gotten more effective, I noticed shifting from features and components to scenarios and solutions is the key.
More Information
It was a nice surprise to see that our Guidance Explorer is among the top downloads on CodePlex.
Do you have to be great at everything? If this stops you from doing things you want to try, then it's a limiting belief. Scott Berkun spells this out in Why You Should Be Bad at Something.
Keys to Growing Your SkillsHere's a set of practices and mind-sets that I've found to be effective for getting in the game, or getting back in the game, or learning a new game versus just watching from the side-lines.
There's a lot more I could say, but I think this is bite-sized working set to chew on for now.
I did a quick round-up of some key patterns & practices team links and figured I'd share:
MSDN
Team Blogs
CodePlex Projects
Community Contribution
Surveys / Feedback
Resources
Whether you're a new hire or taking on a new job, here's some principles, patterns and practices to be more effective. They're lessons learned from the school of hard knocks and they represent some of the proven practices that have worked for others and have stood the test of time. This is a limited, but prioritized list (I gave myself a 20 minute window.) I'll drill into areas in upcoming weeks, depending on where there's interest.
Personal Productivity
Results
Communication
Intellectual Horsepower
Learning / Improvement
Networking
A few readers asked me to show some screens of my approach in Outlook. (I haven't used images in my blog before, so this is a good post to give it a shot.)
My Outlook FoldersHere's what I see when in my Outlook folders.
Notice how I cluster my scannable action folders (Outcomes, To Dos and Daily Status) and my reference folders (Notes, Quick Stuff and Thoughts.) The reference folders are my Collection Pools. The folders are physically stored in my local Outlook.PST folder I named "Admin." I then dragged the folders up to "Favorite Folders" since I use them daily.
Scannable OutcomesI use Posts in Outlook for my Scannable Outcomes. This is what I see when I click my Outcomes folder:
Each post represents a key project. In each post, I list the outcomes and actions (like a mini queue.) I can scan each post very quickly using the Outlook preview pane.
My To DosI use Posts in Outlook. Here's a shot of leveraging the pre-view pane for my To Dos. This is what I see when I click my To Dos folder.
Keys to Results
How do you store your notes and reference information in a way that’s low overhead and easy to find? The key is to created a limited set of places to look that you trust. I use a small set of what I call Collection Pools. I think of them as pools because they’re effectively pools of reference information I draw from.
Collection PoolsI currently use the following pools:
I create a folder in Outlook for each pool and I create posts in the folders. It’s flat by design. I could just as easily use a folder on my hard drive with text files, but I like the preview pane in Outlook and sometimes the rich text helps.
Using the PoolsHere's how I use the pools:
ResultsI actually started with my Notes and Quick Stuff folder a few years back. I thought it would be a temporary solution while I explored options. It turned out to be the most efficient approach of all the various ways I tried. I always knew where to put things and I always knew where to look and it was always open. I added the Thoughts folder in February this year. It too turned out to be the most efficient approach I have for a scannable set of ideas and insights and I like the ability to scroll through time.
While there’s a lot of fancier things I could do, simple text notes chunked up in a few folders is a pretty efficient system. I think the lesson here is that for a practice to stick over time, it has to be simple enough and effective enough. Otherwise, it fails the test of time.
How do you convince a team of venture capitalists to bet on you? There's a lot of ninja techniques but here I'll share the fundamentals.
Vision and ScopeWe use Vision Scope milestones in patterns and practices to sell management on how we'll change the world. Knowing the vision and scope for a project is actually pretty key. The vision will motivate you and your team in the darkest of times. It gets you back on your horse when you get knocked off. The scope is important because it's where you'll usually have to manage the most expectations of what you will and won't do.
Thinking in Terms of Venture CapitalistsWhen I do a vision scope, I think of the management team as the venture capitalists (a tip from a friend.) This helps me get in the right mindset. I have to convince them that I have the right problem, the right solution, the right customers, the right impact, the right team, the right cost and the right time-frame. Hmmmm ... I guess there's a lot to get right. A template helps. The right slide template helps because it forces you to answer some important questions.
Template for Vision ScopeHere's the template I used from my last vision scope meeting:
It's implicitly organized by problem, solution, deliverables and execution. While the slides are important, I found that the real success in vision scope isn't the particular slides. It's buy in to the vision, rapport in the meeting, and trust in the team to do the job.
What works for you?
Using speed as a competitive advantage is less about finding ways to do things quicker. It's more about eliminating speedbumps. In It's Not the Big That Eat the Small...It's the Fast That Eat the Slow: How to Use Speed as a Competitive Tool in Business, Jason Jennings and Laurence Haughton write:
"Instead of looking for magical answers as to what companies do to be fast, we began asking, "What do fast companies do to eliminate speed bumps that slow everyone else down?" ... truly fast companies that have demonstrated the ability to maintain momentum aren't naturally faster than their slower-moving rivals. But they are smarter. Smart enough to recognize that the speed bumps that slow everyone else down must be ruthlessly eliminated... Each has made speed -- fast thinking, fast decisions, fast to market, and sustaining momentum -- one of their unique competitive advantages."
Friction is death by a 1000 paper cuts. I'm a fan of reducing friction, while building speed and momentum. I'm always asking, what speedbumps can I eliminate in my day? ... my job? ... my org? ... my company? ... my industry? ... my life? These simple questions shape a lot of what I do. If I'm not part of the solution, I'm part of the problem.
How do you figure out what your organization is really about? It's one thing to know it intutitively. It's another to be able to share it or have meaningful dialogue. Here's the tests I use lately to know what a team or org is really about:
Tests for Organizational Clarity
If you know these, it tells you a lot.
Why This Cuts to the ChaseHere's a quick rundown on how you can use this:
There's obviously a lot more you can know about an org or team, but I'm finding these are keys to cut to the chase.