Software Engineering, Project Management, and Effectiveness
Routines help build efficiency and effectiveness. Consistent action over time is the key to real results. If you add continuous improvement or Kaizen to the picture, you have an unbeatable recipe for success. The following are some of my rituals for results:
Try the ones you like. Experiment with the ones you don't. You might get surprised. As Tony would put it, "If you do what you've always done, you'll get what you've always gotten". Adopt a growth mind-set over a fixed mind-set. I'd be interested in hearing success stories or your favorite rituals for results -- what techniques have personally served you well?
You can tell the maturity of a market by the consumer patterns. If you know the life cycle stages of a market you can better anticipate what level of "needs" your product needs to match to be successful. (I always think of needs in stages like Maslow's hierarchy.)
The Four Stages of Market Maturity
From Survival to CustomizationIn the Autumn Special Edition of "strategy+business" magazine, Alonso Martinez and Ronald Haddock describe how a country evolves from developing nation to industrialized nation:
"As a country evolves from developing nation to indusrialized nation, the population's basic needs pass through four distinct stages. In developing countries, most of hte population is preocupied with basic survival - obtaining adequate food, shelter, and clothing. (Much of sub-Saharan Africa is in the stage right now.) As a middle class emerges, people seek greater quality in their food, housing, and clothing (This is currently happening, for example, in much of China and India.) Once a transitioning market's population can afford relatively high quality, they begin to seek convenience; they buy time-saving appliances and processed foods, and they may move closer to work. (This stage is emerging today in Eastern Europ and Latin America.) Finally, as the market graduates into the realm of developed nations, the population wants customization; with needs for survival, quality, and convenience now met, people will spend a premium (as many do in North America, Japan, and western Europe) to satisfy individual tastes and desires."
Key Take AwaysI think to successfully anticipate global market needs, you need to understand where in the stack, various consumers are. I've noticed a lot more attention on customization, particularly in social software and personal devices.
If you're looking for yet another way to help you prioritize your backlog or to help you shape your product's design, consider the Kano model. One concept in the Kano model is satisfiers and dissatisfiers. You can think of satisfiers as features you might ask for. You can think of a dissatisfier as an unmet need. It's something you wouldn't necessarily ask for (latent need.) You just expect it. It's absence is a dissatisfier.
ExamplesHere's a few examples:
Key PointsHere's the keys:
My Relates Posts
This is a significant release for Guidance Explorer (GE). Our online "guidance store" is now hosted on MSDN. To take advantage of this, you need to download the new version of Guidance Explorer (release 20071206)
What Is the Guidance StoreOur guidance store is a catalog of reusable guidance nuggets for helping you build applications. The catalog is organized by the following:
At a high-level, you can think of the catalog as a collection of application scenarios, "building codes" and engineering practices.
What is Guidance ExplorerGuidance Explorer is a smart client application that talks to the Guidance Store over a Web service. You can use GE to create, organize and share your favorite guidance nuggets.
Key Usage ScenariosThe key usage scenarios are:
To put it another way, you can use GE to slice and dice the patterns & practices catalog, tailor the guidance, or build your own guidance.
What's New in the Latest ReleaseWhat you can expect in Guidance Explorer version 20071206:
How's that for guidance as a service? (Personally, I think the next step is relevant guidance feeds for guidance mash up scenarios.)
When you run GE the first time, let it synch for about 10 minutes. It's downloading more than 3,000 items from our catalog.
Test Driving Guidance ExplorerHere's a few of the first things to try
One of the key experiences you get with Guidance Explorer (GE) is support for manual security inspections. We call them inspections versus reviews because we inspect against specific criteria. We supply you with a starter set of inspection questions, but you can tailor them or add your own.
Security Code InspectionWe use three distinct types of inspections: design, code and deployment. For this example, we'll use Guidance Explorer to do a security code inspection of an ASP.NET application.
Summary of Steps
Step 1. Create a new View. In this step, you add a new view to My Views. To do so, in GE, right-click, My Views, and add a new View. You can name your View whatever you like, but for this example, I'll name mine "Security Code Inspection."
Step 2. Add inspection questions to your view.In this step, you add relevant security inspection questions. To do so, in GE, click the patterns & practices Library, next click Security, next click Security Engineering, next click Code Inspections. Expand the ASP.NET 2.0 set of security inspection questions.
For this example, drag and drop the questions from the following categories: Input and Data Validation, Forms Authentication, and SQL Injection. This will give you a nice focused set of questions to drive your inspection.
Step 3. Save your View to Word.In this step, you save your View as a Word doc. To do so, right-click your view (e.g. "Security Code Inspection") and click Save Vew as .... Name your doc (e.g. "My Security Code Inspection.doc") and click Save.
You just built your own security code inspection set!
Extending and ExploringThere's a lot of exploring you can do and ways you can extend:
Share Your StoriesI'm sure you're bound to have stories. If you haven't done security code inspections before, you're in for a treat. Security Code Inspections are a proven practice. While the criteria and context may vary, the technique pretty much remains the same. Share your stories either in this post or send email to email@example.com.
My Related Posts
Book building is art and science. I've built a few books over the years at patterns & practices. In this post, I'll share a behind the scenes look at what it takes to do so. I'll save the project management piece for another day, and focus on the core of book building.
Book ExamplesBefore we get into the details, here's a quick look at my past books:
If you're familiar with the books, particularly Improving Web Application Security and Improving .NET Application Performance and Scalability, you'll know that the books aren't like typical books. They're optimized to be executed rather than read. The expectation is you'll use them to improve your effectiveness on the job. That's why you can get the books in the bookstore, online or in Visual Studio ... in print, PDF or HTML.
Competitive AssessmentsThe books are targeted at real-world problems and real-world solutions. They've been used for competitive assessments:
Book ApproachAt a high-level, you can think of the approach in five main workstreams:
It's a "test-driven" approach, meaning we start with tests (questions and tasks) that our prescriptive guidance needs to pass. The bulk of the work is building "nuggets" that can be used standalone. We then assemble an end-to-end guide. Throughout the process we verify with test cases, lab repros, internal and external reviews, both with subject matter experts and every day users.
Researching and Analysis This workstream is about getting clarity on the problem space. It includes:
For more information on researching, see my related posts: Analyzing a Problem Space and How To Research Efficiently.
Designing This workstream is an iterative process of spiraling down on solutions. It includes:
For more information, see my related posts: Guidance 2.0, Scenarios in Practice, Scenario Frames for Guidance, and Driver's Guide vs. Owner's Manual.
BuildingThis workstream is where we do the bulk of our solution engineering. It includes:
TestingThis workstream is about verifying the solutions from both a technical and user experience perspective. It includes:
For more information, see my related post: Test-Driven Guidance.
Release This workstream is about making the guidance customer available. It's incremental, iterative and we stabilize over time. it includes:
Keep in mind that it's a stabilization process over time of various form factors and channels. We do our agile guidance on CodePlex, then stabilize and port to MSDN and a book when we're baked. For more information, see my related post CodePlex, GE and MSDN.
Key ConceptsI walked through the process first so that you have a good idea of the end-to-end approach. Here I'll highlight some of the key concepts that underlie my approach:
FeedbackHow do you build books? If you have thoughts, questions or feedback on my book building approach, feel free to share them here or drop me a mail. While this approach has been proven effective over time, there's always room for improvement. I'd like to hear what works for you. If you're a fellow book builder, please share your approach.
I read an interesting article on behavioral economics by Harry Quarls, Thomas Pernsteine, and Kasturi Rangan, in "strategy+business" magazine. According to the authors, behavioral finance supports a counter-intuitive strategy of loving your market "dogs" (underperformers) over your stars. They pose a few questions up front:
Conventional Approach is Stars Over Dogs Quarls, Pernsteine, and Rangan write:
"In the course of maximizing shareholder value, senior executives routinely face decisions about which of their companies' businesses should be nurtured, which should be starved, and which should be sold. The typical strategy is to invest more heavily in the 'stars' that are earning superior returns on capital, while starting or selling the underperforming 'dogs' This is the conventional approach in corporate finance and has become so ingrained in corporate finance and has become so ingrained in management practice that it is almost impossible to question it."
Way to Thrive is Love Your Dogs Quarls, Pernsteine, and Rangan write:
"There is, in fact, reason to believe that the conventional wisdom is wrong. Corporate managers often rely on accounting metrics to make business decisions. However, these metrics are based on past performance; the market is interested only in the future. And past performance is generally a poor predictor of the future. Thus, when performance is assessed over time, greater shareholder value can be created by improving the operations of the company's worst-performing business. The way to thrive is to love your dogs.
Just as some fund managers earn superior returns by identifying and buying undervalued 'market dogs' - better known as value stocks - corporate leadership can learn to identify 'value assets,' hold and nurture them, and produce superior performance. This in turn will ultimately lead to an increase in shareholder value."
3 Messages for Corporate Leaders Quarls, Pernsteine, and Rangan have three messages for corporate leaders:
Key Take AwaysI think there's several interesting points.
Personal DevelopmentTo sanity check ideas, I like to test them against personal development concepts. It can help quickly put things in perspective. For example, should you invest more in your star skills or improve your dogs? Conventional wisdom to go from good to great is work on your star skills. However, a liability can hold you back (think in terms of Kano -- a dissatisfier can really undermine all your satisfiers.) But, what if you have a few skills that are diamonds in the rough, or what if there's a good chance of downstream market demand?
Project ManagementI manage a portfolio of results, so I also like to test ideas against project management practices. For me, I tend to use a few key factors around deciding where to spend energy and time:
From a dog and star standpoint, I like to count on my stars, but I experiment with a lot of dogs, since the rate of failure is pretty high, but it's the future of the dogs that help me stay adaptable over getting overly adapted. Put it another way, what got me here today, won't get me there tomorrow.
Kaizen is a Japanese term for continuous improvement. A little Kaizen goes a long way over time. From a personal development standoint, it's key for overcoming resistance.
Threat Modeling is a way to identify potential security issues to help you shape your application's security design. If you need to create a threat model, and you aren't sure how, here's some links to get you started. (Note that our patterns & practices threat modeling approach is adaptable for agile scenarios. In fact, our dominant set of customers we tested our approach with were using agile methodologies. I'll cover doing agile security another day. )
What's one path the SDL (Security Development Life Cycle) can take to amplify impact? From my perspective, I think the key is specialization for app types and verticals. I base this on lessons learned from shaping prescriptive guidance over the years, the market trend for specialization, and what I learned doing competitive assessments. I also know the enormous difference that getting specific can make (for example, our original patterns & practices threat modeling was one-size fits all -- now we shape it based on app type. This lets us integrate more precise "building codes," patterns, and recommendations.)
Conceptual Framework / Mental ModelHere's a strawman I put together of a conceptual model to paint the possibilities.
App TypesImagine app-type specific prescriptive guidance, services, tooling, process ...
VerticalsImagine SDL for verticals ...
Key AssetsMy take on what the various parties bring to the table ...
While it requires a bit of coordination and focus in key areas, I think it's both technically feasible and would deliver a ton of customer value. The sum is better than the parts. Thoughts?
I created a recurring appointment in Outlook for Fridays. It's a checklist of key leadership practices from The Leadership Challenge. Each Friday, I scan this checklist and reflect on how well I've demonstrated the practices and where I need to tune for the upcoming week.
How do you design an org? While there's lots of approaches, one of my mentors shared the 5 Ps approach with me. To think about the org, you need to enumerate the 5 Ps to define the organization, the type of talent you need, overall organizational competencies, culture, etc. If you don't know what you're trying to do, you don't know who to hire.
The Five P'sThe 5 P's are:
If you have to compete for resources or budget or sell an idea, one of the keys is a business case. One way to think of a business case is "how big is the pie" and "what's your slice." You use the business case either to argue for your project or in argument against other projects competing for the same resources and budget.
The Three Keys of a Business CaseBecause the business case is such a critical piece of the project puzzle, I asked one of my mentors for their take on an effective business case. Here's the keys:
The Fourth KeyMy mentor was on a roll and added an additional key:
4. Risk / reward "options." The key is to be able to chunk down the value or the risk into an acceptable size (right-size the risk.) For example "I like your idea, but it's too big a chunk to bite off."
Do you have a favorite set of forcing functions? In patterns & practices, one of our forcing functions is building a slide deck. Building a deck is a forcing function because it forces us to distill the points, close down on issues, identify what we know, don't know and need to know next in a fairly constrained way. It helps to balance our elaboration on certain issues.
I like to use blog posts as a forcing function. There's plenty of topics I could write books on, but I like using a post as a forcing function to chunk something down into a nugget of insight, or a collection of nuggets of insight.
One of the questions I get is how we build and publish our guides and what's the relationship of CodePlex, GE and MSDN. At a high-level, we build reusable guidance nuggets for customer questions and tasks. We then build a larger guide to bring the nuggets together into a story. Together, this gives us both a knowledge base of nuggets and a series of guides. We can incrementally deliver value, refactor as appropriate, and respond to changing needs.
Bird's-Eye View of Agile Guidance EngineeringYou can think of our approach as progressive rendering of solutions (incrementally sharing and stabilizing.)
From CodePlex to MSDNAs we build guidance modules, we publish them to GE and CodePlex. GE lets you, the user, build more relevant views or tailor the nuggets to your own needs. CodePlex gives us a place to experiment with views and get direct user feedback, while we vet the guidance.
Once we're stable, we do a focused, batch effort to port to MSDN. MSDN gives us a bunch more channels and hooks including integration in Visual Studio / Visual Studio Team System.
There's much more to the story, so if there's interest, I'll share a behind the scenes look at how we build books.
My Related Posts
It's one thing to get results. It's another to articulate them. Having a way to frame results can help both for personal learning, as well as review time when you have to reflect on accomplishments.
Commitment, Results, How, Evidence, Analysis
I've found framing results by listing the commitment, the results, the how, the evidence and the analysis to be pretty effective over the years. I'm a fan of concrete examples, so here's an example:
Our patterns & practices Performance Testing Guidance for Web Applications book is now available on Amazon.
Our patterns & practices Team Development with Visual Studio Team Foundation Server book is now available on Amazon.
This is an oldie but a goodie. Alex (from our original team) walks through our patterns & practices Security Engineering Approach. I knew the video exists, but I had a hard time finding it again so I'm posting the link here.
Key ChangesA few things have changed since our original video: