Software Engineering, Project Management, and Effectiveness
Scenarios are a practical way to organize and focus your product design, development and release. (We use scenario-driven engineering in patterns & practices)
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.
My Related Posts
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:
Surveys / Feedback
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.
Learning / Improvement
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.
How to be a leader in your field? Dragos shared a link to How to Be a Leader, which I found interesting. In the article, Philip E. Agre presents a six step recipe for becoming a leader in your field:
I think the takeaway was that to be a leader in the field, you help move the ball forward. In step 1, Philip gives an A-Z list of how to pick which ball to move forward.
Another part of the article caught my attention. Philip writes:
"To succeed in your career, you need more than the skills that you got in school -- you need to be the world expert in something. Knowledge is global, it's growing exponentially, and nobody can pack all of the necessary knowledge into their head. So everyone's going to specialize."
I think there's a lot to be said for focus and specialization. The trick is picking what to specialize in. Personally, I like to specialize in skills that compound over time versus flavor of the day.
It's obvious in retrospect, but I found a distinction between low-friction communication and high-friction communication. By low-friction, I mean *person A* doesn't have to work that hard for *person B* to get a point.
I find low friction scenarios are often cases where *person B* starts with the mind-set "how might that be true" and they help *person A* tease out, or make their point. The starting point is collaboration -- two people working to understand the message. I find high-friction scenarios are often cases where *person B* starts with the mind-set "let me tell you how you're wrong."
It's really easy among a bunch of engineers to rip ideas apart. The trick I found is to first ask, "how might that be true?" This gets over the potential hump that maybe while the delivery was off, there was merit in the message (or a concept needs help to be teased out) and it certainly builds more rapport than starting off as a devil's advocate.
How do you get past deadlocks in a meeting? You can apply the Six Thinking Hats. I've blogged about the Six Thinking Hats before, but to summarize, it's a way to get everybody thinking about the problem in a collaborative way.
The Keys to The Six Thinking HatsThe real key here is that rather than circular or deadlock debates, you focus the group on a particular viewpoint at a time. This is a similar to writing, then editing vs. editing while your write, or brainstorming, then critiquing vs. critiquing while you brainstorm. The big difference is that rather than just brainstorming and critiquing, you're looking at the issue from multiple, specific angles. On the people side of this technique, you're letting people wear a different "hat", in a safe, constructive way.
Applying the Six Thinking Hats The approach below is lightweight and low-overhead, but gets you 80% there without requiring everybody to know the details of the Six Thinking Hats.
Summary of Steps
Step 1. List the questions that represent the hatsList a set of questions on the whiteboard to represent the hats. You can do this either at the start of the meeting or when you hit a sticking spot.Here's the Six Thinking Hats:
Here's an example set of questions you can use to represent the hats:
The sequence of the questions can matter. For example, it wouldn't make sense to start thinking up solutions before you've focused on the problem.
Step 2. Walkthrough each question as a teamWalkthrough each question as a team. This is the key. Rather than debating each other, you're now collaborating. You'll be surprised when suddenly your team's "Devil's Advocate" is now showing off their ability to dream up wild solutions that just might work!
Step 3. Modify the approach.If it's not working, change the approach. For example, you might find that you started with the wrong "hat" or question. See if switching to another question or hat makes a difference. The key is to keep this lightweight but effective.
This isn't a heavy handed approach. Instead, it's a subtle shift in stratey from free-for all debate to focusing and coordinating your team's thinking power in a deliberate way. This lets everybody get heard as well as really bang on a problem from multiple angles in a teamwork soft of way.
Well, it's official ... Software security is in for a ride! -- Mark Curphey joins Microsoft. Mark already brings a ton to the table in terms of ideas, network, and results. At Micrsoft, he'll crank it up. Congrats Mark and I look forward to our future adventures!
Our Scenario Frames for Team Foundation Server are available on CodePlex. We have Scenario Frames for the following:
We use scenario frames for several things:
The real power of a scenario frame is that's it's a shared frame of reference. Personally, because I've seen so much benefit from scenario frames time and again, I couldn't imagine doing guidance or building a product without using scenario frames.
We released the final version of our patterns & practices Performance Testing Guidance for Web Applications. This guide provides an end-to-end approach for implementing performance testing. Whether you're new to performance testing or looking for ways to improve your current performance-testing approach, you will gain insights that you can tailor to your specific scenarios. The main purpose of the guide is to be a relatively stable backdrop to capture, consolidate and share a methodology for performance testing. Even though the topics addressed apply to other types of applications, we focused on explaining from a Web application perspective to maintain consistency and to be relevant to the majority of our anticipated readers.
Key Changes Since Beta 1
Why We Wrote the Guide
Features of the Guide
Contributors and Reviewers
Rico and I have long talked about performance threats. I finally created a view that shows how you can think of performance issues in terms of vulnerabilities, threats and countermeasures. See Performance Frame v2.
In this case, the vulnerabilities, threats and countermeasures are purely from a technical design standpoint. To rationalize performance against other quality attributes and against goals and constraints, you can use performance modeling and threat modeling. To put it another way, evaluate your design trade-offs against the acceptance criteria for your usage scenarios, considering your user, system, and business goals and constraints.
I did a few things to try and improve browsing and findability:
I was surprised by how many of my posts related to productivity. Then again, I focus heavily on productivity with my mentees. I think personal productivity is an important tool for turning their great ideas, hopes, and dreams into results. If it's not already their strength, I want to make sure it's a least not a liability.
On my Book Share blog, I changed themes, reorganized key features, and created a best of list. While it may sound simple here, I actually went through quite a bit of trial and error. I tested many, many user experience patterns and relied heavily on feedback from a trusted set of reviewers. Although I used a satisficing strategy, I did try to make browsing the content as efficient and effective as possible. I was surprised by how many subtle patterns and practices there are for blog layouts. Maybe more surprising was how many anti-patterns there are.
How do you cut to the chase? How do you clear the air of ambiguity and get to facts? Ask cutting questions.
My manager, Per , doesn't ask a lot of questions. He asks the right ones. Here's some examples:
As simple as it sounds, having five separate customers stand behind you is a start. I'm in the habbit of litmus checking my path early on to see who's on board or to find the resistance. As customers get on board, my confidence goes up. I've also seen this cutting question work well with startups. I've asked a few startups about their five customers. Some had great ideas, but no customers on board. The ones that had at least five are still around.
At the end of any meeting, Per never fails to ask "next steps?", and the meeting quickly shifts from talk to action.
"Is it working?" is a pretty cutting question. It's great because it forces you to step back and reflect on your results and consider a change in approach.
There's a lot to be said for well-crafted vision and mission statements. I've been researching and leaving a trail at The Bookshare.
In a Nutshell
How Do You Craft Them
A good vision statement is a one-liner statement you can repeat in the halls. Nobody has to memorize it. It's easy to say and it's easy to groc. The same goes for a mission statement. You might need to add another line or two to your mission statement to disambiguate, but if folks don't quickly get what you do from your mission statement -- it's not working.
How Do You Use Them
ExamplesI'm a fan of using reference examples (lots of them) to get a sense of what works and what doesn't. The Man on a Mission blog is dedicated to mission statements and has plenty of real-life examples to walk through.
On my teams we do a daily sync meeting. It's 10 minutes max. We go around the team with three questions:
We stay out of details (that's for offline and follow-up). It's a status meeting more on accomplishments and progress over reporting activities (lots of folks are doing lots of things, so it's crisper to focus on accomplishments.) The more distributed the team, the more important the meeting.
The best pattern that has worked over time is ...
Another way of thinking about this is ... "if this were the end of the week, what would you feel good about having completed?" "Each day, are we getting closer or further, or do we need to readjust priorities or expectations?" ... "What did we learn and what can we improve?"
Execution checklists are a simple, but effective technique for improving results. Rather than a to do list, it's a focused checklist of steps in sequence to execute a specific task. I use notepad to start. I write the steps. On each execution of the steps, by myself or a teammate, we improve the steps as we learn. We share our execution checklists in Groove or in a Wiki.
Key ScenariosThere's two main scenarios:
I encourage my teams to create execution checklists for any friction points or sticking spots we hit. For example, if there's a tough process with lots of movable parts, we capture the steps and tune them over time as we gain proficiency. As simple as this sounds it's very effective whether it's for a personal task, a team task, or any execution steps you want to improve.
One of my most valuable execution checklists is steps for rebuilding my box. While I could rebuild my box without it, I would fumble around a bit and probably forget some key things, and potentially get reminded the hard way.
The most recent execution checklist I made was for building the PDF for our Team Development with Visual Studio Team Foundation Server guide. There were a lot of manual steps and there was plenty of room for error. Each time I made a build, I baked the lessons learned into the execution checklist. By the time I got to the successful build, there was much less room for error simply by following the checklist.
Today we release the final version of our patterns & practices: Team Development with Visual Studio Team Foundation Server. It's our Microsoft playbook for Team Foundation Server. It shows you how to make the most of the Team Foundation Server. It's a compendium of proven practices, product team recommendations, and insights from the field.
Contents at a Glance
As a mentor at work, I like to checkpoint results. While I can do area-specific coaching, I tend to take a more holistic approach. For me, it's more rewarding to find ways to unleash somebody's full potential and improve their overall effectiveness at Microsoft. Aside from checking against specific goals, I use the following frame to gauge progress.
I've found this frame very effective for quickly finding areas that need work or to find sticking points. It's also very revealing in terms of how much dramatic change there can be. While situations or circumstances may not change much, I find that changes in strategies and approaches can have a profound impact. My take on this is that while you can't always control what's on your plate, you can control how you eat it.
I showed a colleague of mine one of my tricks for building slide decks faster. It's a divide and conquer approach I've been using a few years. I do what I call "one-sliders."
Whenever I build a deck, such as for milestone meetings, I create a set of single-slide decks. I name each slide appropriately (vision, scope, budget, ... etc.) I then compose the master deck from the slides.
Here's the benefits that might not be obvious:
The biggest impact though is that now I find myself frequently sharing concise one-sliders, and getting points across faster and simpler than blobby mails.