Software Engineering, Project Management, and Effectiveness
In the article, The Strategy Accelerator, Alfred Griffioen identifies three models that have been used for strategic competitive differentiation:
Griffioen raises the question whether the models are still relevant, given Porter’s is circa 1980, Traeacy and Wiersema’s are circa 1995, and the BCG portfolio mix is from 1959.
I think the key is that while the landscape may change, the principles remain the same, they just need to be adapted.
This helps show why knowing the *why* and the context behind a principle is always key (as in *why* or *how* does it work … or even *when* does it work?) That’s why patterns are a key way to share principles and strategies (they not only build a shared language, while sharing a problem and solution pair, but they also bound it to a context.)
In the article, The Strategy Accelerator, Alfred Griffioen shares four gears for differentiation and competitive advantage:
Strategies for Each Gear Griffioen shares strategies for each of the gears, to make the most of your market position:
In the article, The Strategy Accelerator, Alfred Griffioen shares some specific examples of how today’s landscape changes the competitive arena:
I’ve seen this in action, and I like how Alfred called these out. It helps us not just see the landscape, but start to form new rules for the road.
My Related Posts
One town that all roads seem to lead to, is that … brand is the ultimate differentiator.
It’s a reflection of the perception of perceived value, the emotional benefits, the intangibles and the culture and the values that the brand stands for. In fact, a good way to test your brand is to figure out the three to five attributes that it represents.
Brand is a powerful thing because it’s a position in the mind. For some categories, especially on the Web, sometimes you only need one brand at the top, and the rest don’t matter. That’s why sometimes the only way to play, is to divide the niche, or expand to a new category.
As an individual, your brand can serve you in many ways at your company, from opening doors to creating glide paths … especially, when your reputation proceeds you in a good way.
The trick as an individual is, how do you fit in, while finding ways to stand out and sharing your unique value?
I put together a trends map in my trends for 2011 post.
I took a look across consumer trends, Enterprise trends, market trends, and what's on the minds of CIOs, CFOs, and CEOs. I also drew from my experience from talking with key folks on what's going on, including many customers and what they're focused on. I included a round up and distillation of many sources, so you can drill into even more.
The post is long, but I've saved you several hours, if not days, of research and bubbled up several key sources that will help you create your own map of trends. I designed the post to be very scannable so you can hop around pretty fast.
Trends are your extreme advantage. By knowing where the action is, you can focus your energy for better results. You also avoid surprises. You can also reshape your job to be more relevant, and you can use market insights to follow the growth, or create new growth. As cycles of change get shorter, one of your best skills to build is anticipation. Anticipation helps you respond over react. Key tip – The Art of the Long View teaches us to have multiple long views.
Explore trends for 2011.
If you’re interested in development with the Microsoft Windows Phone, this map is for you. Microsoft has an extensive collection of developer guidance available in the form of Code Samples, How Tos, Videos, and Training. The challenge is -- how do you find all of the various content collections? … and part of that challenge is knowing *exactly* where to look. This is where the map comes in. It helps you find your way around the online jungle and gives you short-cuts to the treasure troves of available content.
The Windows Phone Developer Guidance Map helps you kill a few birds with one stone:
Download the Windows Phone Developer Guidance Map
Contents at a Glance
Mental Model of the Map The map is a simple collection of content types from multiple sources, organized by common tasks, common topics, and Windows Phone features:
Special Thanks … Special thanks to Adam Grocholski, Allison Kent, Constanze Roman, Dan Reagan, Dragos Manolescu, Georgia Pettigrove, Kevin Lam, Mark Chamberlain, Paul Enfield, Pete Brown, Srinivas Iragavarapu, and Will Clevenger for helping me find and round up our various content collections.
Enjoy and share the map with a friend.
I’ve been thinking about execution and the lessons learned. I’ve summarized some insights and reminders.
I’ve been lucky enough to grow up with patterns & practices over the last 10 years, so I’ve been able to see what works, what doesn’t, and the difference that makes the difference.
The Vital Few Here are the vital few lessons:
20 Additional Game-Changers … Here are some additional ways to improve execution:
I added a map of Leadership Blogs, A- Z at http://sourcesofinsight.com/2010/12/06/leadership-blogs/.
Here is my short list:
Do you have a favorite blog on leadership I should know about? Tell me about it – I think of my collection of leadership blogs as a living list.
Here is a sketch of the mental model I use when thinking through how to address a space with prescriptive guidance:
At a high level, it’s a “stack,” and by having a model of the stack, you can choose how far up the stack to go:
One thing I didn’t explicitly show in the model, is the idea of media, such as videos and slides, and train-the-trainer material. To really get adoption, the media and train-the-trainer material help spread the word. They make it easier for raving fans to adopt and to help spread, as well as to help teach others.
Together, all these parts work to create a “platform” and an “ecosystem” for prescriptive guidance. While it’s not a hard and fast model, it has helped me both figure out the opportunities, as well as evaluate competition, and it helps me see where various types of deliverables fit into a bigger backdrop for impact.
I happened to look over to my bookshelf and noticed that I have two books that landed together by chance:
I’m a fan of “just enough.” One of my mentors liked to quiz me with the question:
“How much process do you need?”
The answer was always, “just enough.”
The question, of course, then becomes, how much is “just enough?” The answer to that is, it depends on what’s the risk? … what’s at stake? It should be commensurate to risk.
I always liked the example we gave regarding how much to invest in performance modeling:
“The time, effort, and money you invest up front in performance modeling should be proportional to project risk. For a project with significant risk, where performance is critical, you may spend more time and energy up front developing your model. For a project where performance is less of a concern, your modeling approach might be as simple as white-boarding your performance scenarios.”
Just enough not only helps you eliminate waste, in the form of unnecessary overhead, but it frees you up to better balance your other trade-offs and priorities.
I saw the Facebook privacy issue on the news. I remember somebody saying, developers should just be responsible. A common practice is to "make it work, then make it right." The problem is, you don't always get a chance to "make it right." That very much depends on what your organization values. The values define the culture.
I flashed back to our early values in patterns & practices. The thing to know about values, is that values flow down. It's what the leaders say, it's what they reward and punish. It reminded me of why our collective set of values was so important.
If you value cost …
If you value execution …
If you value learning …
If you value quality …
If you value customer-connection ...
When I look back to the values we had in patterns & practices, I see how they helped pave the way for great:
If you don't think you, your team, your company, etc. are on a path to great, check the values for clues. It’s not about having this value or that (after all, all values are … well … valuable) ... the magic is in the blend, and often the difference is in what’s missing or out of balance.
I shared some lessons learned from Bill Gates. He sets a high bar and pushes the envelope of what's possible in a lifetime. That's what's great. Thinking back, he was one of the key reasons I joined Microsoft. He'd rather be making impact, than sitting on the beach. His passion is contagious. He set the bar for “smart and gets results.”
Read lessons learned from Bill Gates and if you have a lesson or insight from Bill, be sure to share.
While hunting and gathering cloud-related white papers, I found a nice collection of our Windows Azure white papers:
For more whitepapers, see the Windows Azure Home at http://www.microsoft.com/windowsazure/whitepapers/default.aspx
If you know of some great Windows Azure or cloud-related whitepapers, please share in the comments.
This is a collection of user stories for the cloud. This collection is a simple way to share the most common scenarios that Enterprise Architects, business leaders, and IT leaders will be facing as they adopt cloud technologies.
I decided to kill two birds with one stone. First, I wanted to share a simple example of how to share user stories. User stories are a powerful way to identify and enumerate the problems, wants, and needs within a given domain. Having a bird’s-eye view helps you see the forest from the trees so that you can better prioritize as well as see trends and patterns. Second, I wanted to share a real example that’s relevant and easy to relate to. In this case, I’m sharing cloud user stories. I can’t think of a more relevant body of knowledge for this significant inflection point in our industry.
There are two key outcomes from this post: 1) You can effectively share user stories for a problem space, and 2) You have a good understanding of some of the key challenges facing Enterprise Architects, business leaders, and IT leaders in terms of cloud technologies.
An example is worth a 1000 words, but one of the things I want you to notice in the user stories below, is the wording. The secret to wording effective user stories is to use persona-based scenarios with goals. For example, “As an Enterprise Architect, I want to …” or “As an IT Leader, I need to ….” Yes, this looks simple, but this phrasing is powerful. It makes it easy to collect user stories in a fast way. The mistake is to have a bunch of user stories that are over-generalized and over-loaded. With user stories, the key is to be clear, simple, and straightforward. Clever is the enemy. It should be easy for anybody to read the user stories and easily make sense of them without having to do a bunch of mental gymnastics or parsing. The simpler the better.
If you see key stories that I’m missing, feel free to share in the comments. The beauty of having a map of user stories is that it’s easy to add or reshape the map. This is the key to being able to leverage multiple smart people in an organized way.
Cloud Enterprise Strategy Scenarios Map
Awareness / Education
Governance and Regulation
Service Levels / Quality of Service
One of the most common questions I get with Getting Results the Agile Way is, “What tools do I use to implement it?”
The answer is, it depends on how "lightweight" or "heavy" I need to be for a given scenario. The thing to keep in mind is that the system is stretch to fit because it's based on a simple set of principles, patterns, and practices. See Values, Principles, and Practices of Getting Results the Agile Way.
That said, I have a few key scenarios:
The Just Me Scenario In the "Just Me" scenario, I don't use any tools. I just take "mental notes." I use The Rule of Three to identify three outcomes for the day. I simply ask the question, "What are the three most important results for today?" Because it's three things, it's easy to remember, and it helps me stay on track. Because it's results or outcomes, not activities, I don't get lost in the minutia.
The Pen and Paper Scenario In the Pen and Paper scenario, I carry a little yellow sticky pad. I like yellow stickies because they are portable and help me free up my mind by writing things down. The act of writing it down, also forces me to get a bit more clarity. As a practice, I either write the three results I want for the day on the first note, or I write one outcome per note. The main reason I write one result per sticky note is so that I can either jot supporting notes, such as tasks, or so I can throw it away when I've achieve that particular result. It's a simple way to game my day and build a sense of progress.
I do find that writing things down, even as a simple reference, helps me stay on track way more than just having it in my head.
The Evernote Scenario The Evernote scenario is my high-end scenario. This is for when I'm dealing with multiple projects, leading teams, etc. It's still incredibly light-weight, but it helps me stay on top of my game, while juggling many things. It also helps me quickly see when I have too much open work, or when I'm splitting my time and energy across too many things. It also helps me see patterns by flipping back through my daily outcomes, weekly outcomes, etc.
It's hard to believe, but already I've been using Evernote with Getting Results the Agile Way for years. I just checked the dates of my daily outcomes, and I had switched to Evernote back in 2009. Time sure flies. It really does.
Anyway, I put together a simple step-by-step How To to walk you through setting up Getting Results the Agile Way in Evernote. Here it is:
OneNote If you’re a OneNote user, and you want to see how to use Getting Results the Agile Way with OneNote, check out Anu’s post on using Getting Results the Agile Way with OneNote.
Adam Grocholski has a great post on timeboxing. In his post, he shares his secrets of how he’s applied Getting Results the Agile Way to take control of his time. One of my favorite parts is where he explains how he made a business case with his customers to spend less time in meetings, and more time producing results.
Check out Adam’s post on Timeboxing.
Jeff Braaten let me know that the MSDN Library Home is now featuring Quick Links … and it’s poetry in motion:
The point behind the Quick Links is to help you jump quickly to some of the most popular areas of the MSDN Library.
App Types / Platform Technology Clusters The links are clustered around key application types and platform technology areas:
API Reference, Code Samples, and How Tos by Technology At a glance, you can quickly jump to API references, Code Samples, and How Tos for some of your favorite technologies:
Enjoy browsing the Quick Links!
While researching some cloud topics, I came across a nice resource on TechNet called How Microsoft IT Does It.
It’s an insider’s look showcasing how our Microsoft IT department plans for, deploys, and manages our enterprise solutions across the business lines using our Microsoft product and technology platforms.
Here is a roundup of the cloud-focused resources.
One of my new favorite books is, Enterprise Architecture as Strategy, by Jeanee W. Ross, Peter Weill, and David C. Robertson. My colleague, Danny Cohen recommended it as one of the best books on enterprise strategy and I agree.
A big focus of the book is on execution and how to build a strong foundation for execution. The key is an effective enterprise architecture. With an effective enterprise architecture, you can improve business agility, achieve higher profitability, reduce time to market, lower IT costs, improve access to shared customer data, lower the risk of mission-critical systems failures. Enterprise architecture as strategy means your enterprise architecture is addressing two key challenges: 1) integration and 2) standardization across the company.
Six Steps to Build a Foundation for Execution Here are six steps Ross, Weill, and Robertson identify for re-thinking a foundation for execution and creating and effective enterprise architecture:
Summary Table and Notes In this table, I summarized key notes along with each step:
"All models are wrong, but some are useful." -- George Box
I often see confusion over reference models, reference architectures, and reference implementations. In this post, I’ll share my experience and learnings and observations:
I think the confusion is usually because the argument usually hinges on whether a reference architecture or reference implementation needs to be in code, when that’s really just a form factor decision. The distinction is actually the focus and concern, independent of how you share it, although code can help illuminate a reference implementation and a reference architecture. The other confusion is often around how big or small it needs to be to determine whether it’s a reference architecture or reference implementation, but that’ also a herring. Again, it goes back to what the focus of the example is. If it’s an exemplar of the architecture, it’s a reference architecture. If it’s an exemplar of the implementation, then it’s a reference implementation, and each serve different purposes, and require different levels of detail or abstraction.
Reference Model Examples Reference models give us a quick way to see and talk about a given problem space. Here is an example of a simple reference model that does nothing more than frame out some cornerstone concepts for cloud computing. In this case, it’s a visual model for cloud computing:
This is another of my favorite reference models. In this case, this is a continuum of moving up the stack with types of cloud services from IaaS to PaaS to SaaS :
I also like a few of the cloud reference models, especially how they can be used for overlaying security concerns.
Reference Architecture Examples The beauty of the reference architecture is that you can shape the application before you implement it. One of the simplest ways to achieve this is to whiteboard it. When you put it on the whiteboard, you can focus on key engineering decisions and avoid getting lost in the details. You can focus on a conceptual, physical, or logical view, … you can focus on the business perspective, user perspective, or technical perspective … and you can move up and down the stack to zoom in or zoom out … but the main point is to show how the bits and pieces should fit together. The power of a reference architecture is that it creates a shared mental model for the architecture and design and it can help you identify the key decisions and key risks early on. This helps you both shape a skeleton solution as well as identify what you need to prototype, especially in terms of cross-cutting concerns, or tracer-bullets. From an agile perspective, the Reference Architecture complements the system metaphor and it helps you identify potential areas to spike on. Here are a few examples …
One of my favorite reference architecture examples is the reference architecture from the ESB Toolkit.
Another of my favorite reference architectures is the reference architecture for the PetShop Sample Application:
One approach I like to use for sharing reference architectures is what I call Application Scenarios or Scenarios and Solutions. It’s a whiteboard sketch of the end-to-end solution. Here is an example:
Another of my favorite approaches is to use what I refer to as Application Patterns. It’s like the Application Scenarios, but I overlay patterns on top. Here is an example:
The real key of reference architectures is that they help you explore the thinking and design at a higher-level before getting lost in the weeds. Getting lost in the weeds is a common problem with reference implementations. That’s why it’s helpful when they include a reference to their corresponding reference architecture.
The best combinations I find for nailing a problem space include a reference model + reference architecture + reference implementation.
"All projects experience changing requirements. Traditional projects view this as bad. Agile projects embrace it." -- Steven Thomas, BBC
Kelley Hunsberger writes about embracing scope creep, rather than fight it in her article “Change is Good”, in PM Network.
According to Hunsberger, scope creep can create three key opportunities:
In my experience, this tends to be true, especially for knowledge work or where the work is not well known. Change is a good thing, especially when it means acting on windows of opportunity, and delivering more value, in a timely way. Customers tend to embrace the change when they are involved throughout the process.
My favorite point in the article is about shaping scope as you go -- "With every sprint or iteration in agile, you are adding more clarity to the project's scope and reacting to it. But just because you are changing the scope of a project doesn't mean you are adding more scope to it."
One way to drive more effective product design is to start with scenarios. One way to think of this is “Persona-based scenarios with goals.” You can use the scenarios as test cases. The scenarios can help you evaluate the design and they can help you evaluate implementation. Simply put, “Can the persona or user perform the particular scenario effectively?” You can then use criteria to evaluate.
It’s test-driven product design.
You can imagine how you can start with key themes and then break those down into more specific groups or frames. You end up with unit tests for experiences or scenarios and you can evaluate key things. For example, if you were doing a competitive assessment, you might evaluate against the following criteria:
The frames approach is a common approach for how platform competitive assessments are performed. That’s why we adopted it as an approach for how we do prescriptive guidance … it’s a proven practice for mapping out the problem domain within a given domain or space.
Example Scenarios Map This is an example of mapping out core scenarios, in this case, developer scenarios for source control:
Example of Sub-Scenarios This is an example of elaborating the core Branch/Label/Merge scenarios above:
There are many ways to gather, organize and use scenarios. In the end, what’s important is that you have the user scenarios validated with the actual users, and that you use them as a hub to bring together the customer, the developers, and the testers.
The beauty is that you can re-use the scenarios, whether it’s to explain your product, write documentation, or create prescriptive guidance.
I often find myself sharing examples of evaluation criteria in the prescriptive guidance space. Here are some examples of criteria from one of my favorite platform assessments:
Here is an example of a simple, but surprisingly effective way to test your product success. Around patterns & practices, a few of us affectionately called this a “consumer reports” view. Whether your product is prescriptive guidance or code, the concept is the same – you’re testing your product against user scenarios.
To create a Scenario Scoreboard, simply put together a matrix of scenarios. Next, add criteria. Next, test against the scenarios and rate the criteria. Note – There are two keys to making this successful: 1) have a useful collection of scenarios, and 2) get agreement on the criteria. You want agreement on the criteria so that people can stand behind the results. Tuning your criteria can help you tune your product success. You’re basically creating a feedback loop to measure the success of your product against user scenarios.
Example of a Scenario Scoreboard What’s important in the example is the simple frame: scenarios and criteria. The scenarios are grouped into buckets.
Scenarios / Tasks
Best Practice Compliance
Time to Implement
Arch / Design
Auditing and Logging
Monitoring / Health
Performance and Scalability
Best Practice Compliance Ratings
Implementation Complexity Ratings
Quality of Documentation and Sample Code Ratings
Developer/Administrator Competence Ratings
What proven practices have you seen are vital behaviors that significantly contribute to customer success? …
That’s a common question I get, having spent the bulk of my time at Microsoft in patterns & practices. In fact, that’s a question the Windows Azure team asked me last Summer, as a way to boil down my lessons learned from patterns & practices and turn the insight into action.
Let me first set the stage that this information is primarily what contributes to a product’s success aimed at “developers.”
Banging on Products from Multiple Angles Helps You See the Good, the Bad, and the Ugly I’ve had a chance to see the good, the bad, and the ugly in terms of our products and how they land with customers. I’ve participated in many dog-fooding exercises, supportability reviews, platform evaluations, etc., so I‘ve learned what to look for. Because I’ve worked across so many products and technologies, I’ve had the chance to see what success patterns, as well as anti-patterns, show up time and again. In fact, one of the things I often do is cross-pollinate the best practices that I see across various product teams.
As an aside, before I joined patterns & practices, I worked in Microsoft Developer Support, which means I was on the receiving end of customer pain, and I learned how to walk a product from a usability and supportability standpoint, as well as learn many of the supportability (and “un-supportability”) patterns.
Some Products are Destined for Success To share what I’ve learned, I’ve created a simple frame that encapsulates some of the things that I’ve seen make a key difference. Creating prescriptive guidance has always been a combination of creating a “driver’s guide,” test driving the product against customer scenarios, finding effective solutions and workarounds, and improving the story around qualities, such as security or performance. During the process, I’ve found that some products are destined for success and have a strong customer adoption story out of the gate, while others face an uphill battle or never really succeed.
Sadly, I can easily see products that will fail, right up front too.
Product Success Frame Here is the frame I’ve been using for sharing some of the most important product success patterns.
It needs some iterations, but it’s been useful so far for putting some key success patterns into buckets. The table below shares some examples of what would fall under these buckets. After the table, I’ve provide some visual examples to help illustrate.
How to picture, think about, and talk about the problem space.
Sharing and scaling expertise, including driver’s guides and proven practices.
“Train-the-Trainer” material for wide-spread adoption and viral expertise.
Knowing your unique value and where you stand in the market or how you relate.
Building for the customer and with the customer to co-create a better future, as well as simplifying the user experience, and making it easy to find all the blocks.
Assume bad things happen to good people and making it easy to fall into the pit of success or get back to a successful state, or avoid falling off the cliff in the first place.
Know the touch points and the constellation of channels where users interact with your stuff, along with the user experiences for each of those channels.
Get the network on your side, from a tribe of raving fans, and closer followers, to a wider community base.
A Quick Tour of Examples … The following is a quick visual tour of some of the common things that help customers make the most of the product.
Application Scenarios and Solutions Example Application Scenarios and Solutions are a quick sketch of how to solve an end-to-end problem, along with key information on how to prototype the solution and test whether the solution will work for your scenario.
Canonical Application Architecture Example A canonical application architecture helps customer see how to put the building block technologies together into an ideal pattern.
CAT “Customer Advisory Team” Teams Customer Advisory Teams site between the product and the customer and they help address the patterns of customer problems through prescriptive guidance and hands-on support. They can also provide in-depth product feedback because they see the patterns and practices of large sets of customers, against specific scenarios and solutions.
For an example, see the SQL CAT Team.
Catalog of Solution Assets Example When you build out a catalog of solution assets, it’s a proven practice to have a set of content types. This helps users know what to expect in your catalog. This also helps you streamline your efforts for populating your catalog. The key is to focus on a small set of high ROI content types. For example, a common pattern is to focus on code samples, how tos, videos, and tutorials.
Customer Proof Points Customer Proof points are simply verbatums and scores on a slide from a customer to help show impact. The verbatums provide qualitative and the scores provide quantitative. The two key numbers to see are overall satisfaction and a change in confidence in the product, tool, or platform.
Deployment Patterns Deployment Patterns show how the common ways that the application is physically distributed. This can help you very quickly see the end in mind.
Feature Set Example Having your feature set at a glance, helps users quickly see all the dials, knobs, switches at a glance. Having the features at a glance is also an easy way to help your users learn the scope of your product. You can also use the features at a glance as one way for organizing, driving, and prioritizing your documentation. This, in conjunction with a scenarios map is a powerful combination.
Hot Spots for Architecture Hot Spots are basically a heat map of common pain points or key engineering decisions. They help you quickly see the forest from the trees in a given domain. For example, in a typical application, some of the cross-cutting concerns are auditing and logging, authentication, authorization, data access, exception management, etc. Knowing the Hot Spots helps inform you as an product designer or engineering, by helping inform you where to invest more energy.
Hot Spots for Security Example You can think of Hot Spots as a lens and you can overlay or focus on a particular topic, such as security, and highlight just those Hot Spots.
Hot Spots for Performance Example Here is an example of bubbling up common performance Hot Spots for a Web application.
How Tos How Tos provide step-by-step instructions for performing a task or solving a problem. When done well, they are among the most valued content because they directly map to user challenges, scenarios, and tasks.
See Security How Tos for an example of a How Tos collection.
Scenario Frames / Maps Example Scenario Maps are an easy way to gather and organize all the user scenarios in a meaningful way. Scenarios put requirements into context by showing what a particular user would try to accomplish. A collection of scenarios acts as a map that helps you see the landscape of your product, from both the engineering and the user view.
Scenario Scoreboard Example A Scenario Scoreboard is a simple way to evaluate the effectiveness of your product against the user scenarios. You simply add evaluation criteria and rate each scenario against the products, tools, and platform.
QuickStarts (Simple Starts for Common Tasks) QuickStarts are a way to share a quick map of common tasks, along with examples and step-by-step guidance.
See example at - http://quickstart.developerfusion.co.uk/QuickStart/howto/