Software Engineering, Project Management, and Effectiveness
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.
My Related Posts
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.
Keys to Results
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.
While I've been quiet on my blog, we've been busy behind the scenes. Here's a rundown on key things:
I'll have more to say soon.
Inspections are among my favorite tools for improving security. I like them because they’re so effective and efficient. Here’s why:
Bottom line -- you can identify, catalog and share security criteria faster than new security issues come along.
Security FrameOur Security Frame is simply a set of categories we use to “frame” out, organize, and chunk up security threats, attacks, vulnerabilities and countermeasures, as well as principles, practices and patterns. The categories make it easy to distill and share the information in a repeatable way.
Security Design InspectionsPerforming a Security Design Inspection involves evaluating your application’s architecture and design in relation to its target deployment environment from a security perspective. You can use the Security Frame to help guide your analysis. For example, you can walk the categories (authentication, authorization, … etc.) for the application. You can also use the categories to do a layer-by-layer analysis. Design inspections are a great place to checkpoint your core strategies, as well as identify what sort of end-to-end tests you need to verify your approach.
Here's the approach in a nutshell:
For more information, see our patterns & practices Security Design Inspection Index.
Security Code InspectionsThis is truly a place where inspections shine. While static analysis will catch a lot of the low hanging fruit, manual inspection will find a lot of the important security issues that are context dependent. Because it’s a manual exercise, it’s important to set objectives, and to prioritize based on what you’re looking for. Whether you do your inspections in pairs or in groups or individually, checklists in the form of criteria or inspection questions are helpful.
For more information on Security Code Inspections, see our patterns & practices Security Code Inspection Index. For examples of “Inspection Questions”, see Security Question List: Managed Code (.NET Framework 2.0) and Security Question List: ASP.NET 2.0.” (Security Question List: ASP.NET 2.0).
Security Deployment InspectionsDeployment Inspections are particularly effective for security because this is where the rubber meets the road. In a deployment inspection, you walk the various knobs and switches that impact the security profile of your solution. This is where you check things such as accounts, shares, protocols, … etc.
The following server security categories are key when performing a security deployment inspection:
For more information, see our patterns & practices Security Deployment Inspection Index.
In this post, I'll focus on design, code, and deployment inspections for performance. Inspections are a white-box technique to proactively check against specific criteria. You can integrate inspections at key stages in your life cycle, such as design, implementation and deployment.
Keys to Effective Inspections
Performance FrameThe Performance Frame is a set of categories that helps you organize and focus on performance issues. You can use the frame to organize principles, practices, patterns and anti-patterns. The categories are also effective for organizing sets of questions to use during inspections. By using the categories in the frame, you can chunk up your inspections. The frame is also good for finding low-hanging fruit.
Performance Design InspectionsPerformance design inspections focus on the key engineering decisions and strategies. Basically, these are the decisions that have cascading impact and that you don't want to make up on the fly. For example, your candidate strategies for caching per user and application-wide data, paging records, and exception management would be good to inspect. Effective performance design inspections include analyzing the deployment and infrastructure, walking the performance frame, and doing a layer-by-layer analysis. Question-driven inspections are good because they help surface key risks and they encourage curiosity.
While there are underlying principles and patterns that you can consider, you need to temper your choices with prototypes, tests and feedback. Performance decisions are usually trade-offs with other quality attributes, such as security, extensibility, or maintainability. Performance Modeling helps you make trade-off decisions by focusing on scenarios, goals and constraints.
For more information, see Architecture and Design Review of a .NET Application for Performance and Scalability and Performance Modeling.
Performance Code InspectionsPerformance code inspections focus on evaluating coding techniques and design choices. The goal is to identify potential performance and scalability issues before the code is in production. The key to effective performance code inspections is to use a profiler to localize and find the hot spots. The anti-pattern is blindly trying to optimize the code. Again, a question-driven technique used in conjunction with measuring is key.
For more information, see Performance Code Inspection.
Performance Deployment InspectionsPerformance deployment inspections focus on tuning the configuration for your deployment scenario. To do this, you need to have measurements and runtime data to know where to look. This includes simulating your deployment environment and workload. You also need to know the knobs and switches that influence the runtime behavior. You also need to be bounded by your quality of service requirements so you know when you're done. Scenarios help you prioritize.
Inspections are a white-box technique to proactively check against specific criteria. You can integrate inspections as part of your testing process at key stages, such as design, implementation and deployment.
Design InspectionsIn a design inspection, you evaluate the key engineering decisions. This helps avoid expensive do-overs. Think of inspections as a dry-run of the design assumptions. Here’s some practices I’ve found to be effective for design inspections:
Code InspectionsIn a code inspection, you focus on the implementation. Code inspections are particularly effective for finding lower-level issues, as well as balancing trade-offs. For example, a lot of security issues are implementation level, and they require trade-off decisions. Here’s some practices I’ve found to be effective for code inspections:
Deployment InspectionsDeployment is where application meets infrastructure. Deployment inspections are particularly helpful for quality attributes such as performance, security, reliability and manageability concerns. Here’s some practices I’ve found to be effective for deployment inspections:
In the future, I'll post some more specific techniques for security and performance.
When I review an approach, I find it helpful to distill it to a simple frame so I can get a bird's-eye view. For MSF Agile, I found the most useful frame to be the workstreams and key activities. According to MSF, workstreams are simply groups of activities that flow logically together and are usually associated with a particular role. I couldn't find this view in MSF Agile, so I created one:
I'm a fan of sharing lessons learned along the way. One light-weight technique I do with a distributed team is a simple mail of Do's and Dont's. At the end of the week or as needed, I start the mail with a list of dos and dont's I learned and then ask the team to reply all with their lessons learned.
Example of a Lessons Learned Mail
Guidelines Help Carry Lessons ForwardWhile this approach isn't perfect, I found it makes it easier to carry lessons forward, since each lesson is a simple guideline. I prefer this technique to approaches where there's a lot of dialogue but no results. I also like it because it's a simple enough forum for everybody to share their ideas and focus on objective learnings versus finger point and dwelling. I also find it easy to go back through my projects and quickly thumb through the lessons learned.
Do's and Don'ts Make Great Wiki Pages TooNote that this approach actually works really well in Wikis too. That's where I actually started it. On one project, my team created a lot of lessons learned in a Wiki, where each page was dedicated to something we found useful. The problem was, it was hard to browse the lessons in a useful way. It was part rant, part diatribe, with some ideas on improvements scattered here or there. We then decided to name each page as a Do or Don't and suddenly we had a Wiki of valuable lessons we could act on.
If you're backlogged and you want to get out, here's a quick, low tech, brute force approach. On your whiteboard, first write your key backlog items. Next to it, write down To Do. Under To Do, write the three most valuable things you'll complete today. Not tomorrow or in the future, but what you'll actually get done today. Don't bite off more than you can chew. Bite off enough to feel good about what you accomplished when the day is done.
If you don't have a whiteboard, substitute a sheet of paper. The point is keep it visible and simple. Each day for this week, grab a new set of three. When you nail the three, grab more. Again, only bite off as much as you can chew for the day. At the end of the week, you'll feel good about what you got done.
This is a technique I've seen work for many colleagues and it's stood the test of time. There's a few reasons behind why this tends to work:
Here's a quick rundown of our patterns & practices VSTS related Guidance projects. It's a combination of online knowledge bases, guides, video-based guidance and a community Wiki for public participation. We're using CodePlex for agile release, before baking into MSDN for longer term.
Note that we're busy wrapping up the guides. Once the guides are complete, we'll do a refresh of the online knowledge bases. We'll also push some updated modules to Guidance Explorer.
If you want to tune your software engineering, take a look at Lean. Lean is a great discipline with a rich history and proven practices to draw from. James has a good post on applying Lean principles to software engineering. I think he summarizes a key concept very well:
"You let quality drive your speed by building in quality up front and with increased speed and quality comes lower cost and easier maintenance of the product moving forward."
7 Key Principles in LeanJames writes about 7 key principles in Lean:
Example of Deferring CommitmentI think the trick with any principles is knowing when to use them and how to apply them in context. James gives an example of how Toyota defers commitment until the last possible moment:
"Another key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design."
Examples in Software EngineeringFrom a software perspective, what I've seen teams do is prototype multiple solutions to a problem and then pick the best fit. The anti-pattern that I've seen is committing to one path too early without putting other options on the table.
A Lean Way of LifeHow can you use Lean principles in your software development effort? ... your organization? ... your life?