Software Engineering, Project Management, and Effectiveness
Change happens. One of the many things Ward Cunningham taught me years ago was that Agile isn't about fast. It's about "responding to change." It's the Agile way.
I thought it was great that rather than pretend change doesn't happen, simply embrace it.
Simplicity was another aspect that I found compelling. Ward had a way to keep things simple. If something felt heavy or complicated, he would cut right through -- "What's the simplest thing we can do now?" Rather than get overwhelmed or lost in analysis paralysis, he simply decides to take action.
I remember thinking how sweet it is to put your burden down, and travel light.
One burden for me was all the stuff that was yet to be done. The other burden was all the stuff that might matter someday. The problem is, how do you plan for what you don't know or can't expect? You don't. Instead, you figure out the most valuable thing now to work on, and when you come to a bridge, you cross it. When there's no bridge, you build one. If that becomes the next most important thing now.
The sense of now vs. someday maybe is important. There's something empowering about knowing that you're on the right path, and that the path you're on flows value -- to yourself, for others, or whatever matters. Mistakes turn into lessons, and success builds momentum. Paving a path of value down a road of learning and responding beats betting on a map that no longer works or is no longer relevant.
Speaking of relevancy, time changes what's important. All the things we think we know, and all the things we thing we want, don't always match what we find, once we're there. The ladder may be up against the wrong wall, or the grass isn't any greener. In fact, sometimes there's no grass.
The irony is, the trip is lighter when we don’t carry the burden, and the trip mean more when we know it matters. If we don't enjoy the journey, and we don't end up with what we want, what's the point? Life's short. Throwing your time and energy down a path should matter. But, how do we carve out these paths that matter?
Stories. Stories help you find what matters. I remember the first time Ward asked me to tell him a story. He wasn't looking for once upon a time. No, he wanted to explore and test possible paths. He wasn't interested in a laundry list of requirements. He wanted a simple story told from the user perspective of a single, meaningful goal. We used the whiteboard and mapped out one scenario. Disney would have been proud.
This one chunk of value was compelling. The story put things in context. The flow made sense. Value was obvious and explicit. More than that, it was testable. A testable chunk of value. We could test whether it mattered, and we could test whether it was feasible. We could even test the risk early and reduce the gap from what we know, don't know, and need to know next.
Having a story helped us do a dry run. The dry run produced immediate feedback. Feedback is a good thing, and it supports learning and responding, the Agile way.
All this goodness in approach, painted a better picture, of a better way forward. Rather than over-engineer up front, or over-plan for some day maybe, start flowing value now. Rather than travel with burden and assumptions, travel lightweight and sustainable. Rather than fear change, allow for it, and embrace it – be adaptable. But does this approach to work, also work for life?
I asked Ward how he did his career planning and figured out his year ahead. He said he simply works backward from the experiences he wants. He writes his story forward, by focusing on the experiences he wants to create. He leads an experience-driven life. What a simple, yet elegant, and insightful approach. What an empowering way forward.
The journey is the trip and the destination. It's the way we travel and it's the end in mind. It's the Agile way.
This is why my latest book is Getting Results the Agile Way.
As part of our patterns & practices Azure Security Guidance project, we’re putting together a series of Application Scenarios and Solutions. Our goal is to show the most common application scenarios on the Microsoft Azure platform. This is your chance to give us feedback on whether we have the right scenarios, and whether you agree with the baseline solution.
ASP.NET Security Scenarios on Windows Azure We’re taking a crawl, walk, run approach and starting with the basic scenarios first. This is our application scenario set for ASP.NET:
ASP.NET Forms Auth to Azure Storage
Solution Summary Table
ASP.NET Forms Authentication to SQL Azure
ASP.NET to AD with Claims
ASP.NET to AD with Claims (Federation)
This is a comprehensive roundup of our patterns & practices security guidance for the Microsoft platform. I put it together based on customers looking for our security guidance, but having a hard time finding it. While you might come across a guide here or a How To there, it can be difficult to see the full map, including the breadth and depth of our security guidance. This is a simple map. organized by “guidance type” (i.e. Guides, App Scenarios, Checklists, Guidelines, How Tos, … etc.)
Books / Guides (“Blue Books”) If you’re familiar with IBM Redbooks, then you can think of our guides as Microsoft “Blue Books.” Our patterns & practices Security Guides provide prescriptive guidance and proven practices for security. Each guide is a comprehensive collection of principles, patterns, and practices for security. These are also the same guides used to compete in competitive platform studies. Here are our patterns & practices Security Guides:
The HTML and PDF version of the guides are available for free on MSDN. The print versions are available for sale on on Amazon.
For more on the impact of Blue Books for platform success, see The Power of Blue Books for Platform Impact.
Key Features of the Guides Key Features of the guides include:
Security Engineering To meet your security objectives, security engineering activities must be an integral part of your software development practices. Our patterns & practices Security Engineering builds on, refines, and extends core life cycle practices to create security-specific practices. You can adopt these activities incrementally as you see fit. These security activities are integrated in MSF Agile, available with Visual Studio Team System. This provides tools, guidance, and workflow to help make security a seamless part of your development experience.
Application Scenarios and Solutions
ASP.NET Application Scenarios
WCF (Intranet Application Scenarios)
WCF (Internet Application Scenarios)
Cheat Sheets A Cheat Sheet present reference information as a quick view. They are easy to print out and put up on the wall as a quick reference or reminder of key information. Here are our security Cheat Sheets:
Checklists A Checklist present a verification to perform ("what to check for", "how to check" and "how to fix".) Checklists work hand-in-hand with Guidelines. Whereas Guidelines are the “what to do”, “why”, and “how”, the Checklist is a distilled set of checks to perform. Here are our security Checklists:
Guidelines Our Guidelines present the “what to do”, “why”, and “how”. Here are our security Guidelines:
Practices at a Glance Our Practices at a Glance are brief problem and solution pairs that summarize solutions and link to more information.
Explained An Explained article exposes the what and how mechanics (e.g. how things work, basic architecture, design intentions, usage scenarios). Here are our security Explained articles:
FAQs A FAQ article is a collection of frequently asked question related to a technology, product, technique. They aren’t restricted to high-level questions. In fact, many of the questions actually cut pretty deep. Here are our security FAQs:
How Tos A How To article provides steps to execute an end to end task. They compliment the Guidelines and Checklists. While the Guidelines will simply provide a high-level of the “what to do” or a Checklist will simply identify a check to perform, our How Tos actually elaborate and walkthrough the steps to perform it. Here are our security How Tos:
Security Engineering How Tos
ASP.NET How Tos
WCF How Tos
Most Recent patterns & practices Security Guidance Work Most recent patterns & practices security guidance efforts include the following:
My Related Posts
One of my key projects over the last six months was to figure out an Information Architecture (IA) for the Microsoft Windows platform. This post is a behind the scenes look at how I went about figuring out a simple IA for the Windows platform.
You can think of an IA simply as how you structure, organize, and share the information for a particular domain. In general, an IA is used for Web sites, because you’re thinking through the user experiences and user interaction patterns, as well as how to showcase key information in a consumable way.
It’s like a test-first platform strategy. You can test yourself against the customer’s tests for success.
The real secret is this -- you can use IAs to evaluate a platform, shape a platform, test a platform, or create guidance for a platform. How do I know? I’ve used this approach very successfully for each of the key platform stories I’ve worked on: Security, Performance, Architecture, Team Foundation Server, WCF, etc. You can browse some of the competitive studies.
The Why The key driver for this was pretty simple. We needed a simple lens for looking at our Windows platform, from a prescriptive guidance perspective. By creating a shared lens, we could look at the Windows platform space in a simpler way, rationalize our body of knowledge, and evaluate existing content, as well as identify new opportunities.
Another key driver was simplicity. It wasn’t about going off into a black box and come back with a taxonomy. Instead, it was create a simple language or way of looking at the Windows platform to create a shared map of the space.
The Approach I left like a fish out of water, but one thing that helps me is I don’t ever expect to have the right answers. Instead, I expect to ask the right questions, and find the people that do. My super skill is framing things out and making sense of things and hacking through complexity.
In this case, I followed my proven approach of collecting customer scenarios and organizing them into buckets. I reached out to experts across our Microsoft Developer Support, our Microsoft Consulting Services, Microsoft DPE, product teams, community experts, industry experts, and customers that I’ve worked with of all company shapes and sizes.
Before you organize the rocks … gather the rocks.
Simple Windows IA Frame This is a high-level view of the map:
Since my role was not be the Windows expert, I could focus on simplicity. I could be a champion for the customer and focus on a simple map. I wanted a map that was simple, but effective as a lens at the macro level and the micro level. At the macro-level, we can look at the architectures and the application types and application scenarios, and even hot spots. At the micro-level, we could look at the topics, APIs and features.
Expanded Windows IA Frame Here’s a look at fleshing out the frame. The beauty is that it was extensible and made it very easy to prioritize items within the frame – to show the simple and show the complete as needed:
Finding Hot Spots A Hot Spot is a bucket. It’s not a taxonomy exercise. It has to be relevant.To test for a good Hot Spot is that it’s actionable. In other words, it can organize principles, patterns, anti-patterns.
To find the key hot spots, I first gathered collections of customer scenarios to find themes. Microsoft Developer Support was especially handy for finding the customer scenarios. My friend Dan Ruder was the hero here and helped round up scenarios from his team. His team has the bird’s-eye view of all the issues our developer customers see.
For example, here are some of the scenarios they see for the User Interface hot spot:
Improving the IA An IA is always a work in progress. It’s a durable, evolvable backdrop for looking at a space. As the space changes, your lens changes. That’s why it’s important to keep your map lightweight and flexible.
There are many ways to improve an IA once you have a strawman:
Once you have a baseline IA, it’s easy to build on top of it or carve out for specific focuses or create variations that address specific segments.
One thing I can say about IAs if you’re bent on being right, you’re bound to be wrong. The best IA is a shared understanding of the space. It’s a map built from various perspectives. Multiple perspectives are a must. The trick is to synthesize the input and make a useful map, where the sum of the whole is more than the parts.
However, the worst IA is one that’s design by committee or where you don’t have an opinion. The secret is having an opinion, and being OK with being wrong, learning and improving. When you have no opinion, you don’t know what good looks like and you can’t synthesize the input.
The second batch of releases for patterns & practices Enterprise Library 5.0 (EntLib) is now available on MSDN. This release includes the following:
The main sites for Enterprise Library and Unity are:
WCF Security Scenarios on Windows Azure We’re taking a crawl, walk, run approach and starting with the basic scenarios first. This is our application scenario set for WCF:
ASP.NET to WCF on Azure
ASP.NET On-Site to WCF on Azure
ASP.NET with Claims to WCF on Azure
I wasn't sure who should write the foreword for my latest book, Getting Results the Agile Way. A few people had suggested Oprah Winfrey and Tony Robbins because it's all about getting results, firing on all cylinders, and living your best life. Since it's focused on meaningful results over just productivity, I thought maybe Guy Kawasaki or Seth Godin might be appropriate.
Luckily, one of my mentees knocked some sense in to me. She said I should have one of my most significant mentors at Microsoft write my foreword. She said it would be authentic and more meaningful since it's directly connected to the story behind the book. Beautiful point and I think she was right. In fact, I knew she was right as soon as she said it.
Mike Kropp has been an influential mentor for me over several of my years at Microsoft. Here is his foreword:
One thing is certain—change happens. It happens in your job and in your personal life. One of my favorite quotes on change and the importance of managing it effectively is from John F. Kennedy:
“Change is the law of life. And those who look only to the past or present are certain to miss the future.”
As is the law of nature, our ability to adapt to change determines our success. To that end, we seek out the tools and practices that will bring about that success. When it comes to books, there are a wide variety of books that describe the next new “approach” or “method,” promising to improve efficiency and effectiveness if we just follow their prescription for success. Most of these models usually fall short because they fail to factor in the “ability to adapt” as a primary premise.
Agile Results has “adaptability” baked into the entire framework so you’ll be able to factor in and manage changes when they happen instead of them managing you. One of the things I like most about Agile Results is it has simple tools and techniques to help you break a problem down, determine the key outcomes, and think through what’s most important to get done daily, weekly, and monthly—all without losing sight of the end game or your long term objectives. Having these great tools and practices that really work will help you to embrace change.
Although written for a wider audience, those of us in software development will find some of the concepts in Agile Results familiar. With agile software development techniques, there are several core premises that we follow to get more meaningful, impactful results. When we recognize we aren’t getting the right result, we adapt and change our documented plan that is no longer working for us. If it has become out of date, we don’t necessarily throw everything out, but we evaluate our standing plan. We focus on making sure we are always developing the next most important features by working with our key stakeholders and customers—having direct interactions with them instead of just following a process. These Agile practices have become mainstream in the software development arena because they really help you get better results and have a greater impact.
At Microsoft we measure impact, not activities or effort. It’s critical that you constantly zero in on what’s most important, stay connected with your customers, and drive hard to deliver them value and exceed their expectations. This is easy to say but much harder to put into practice. I was in an executive review where my boss at the time was describing all the actions the team had taken to drive for better results; a very senior Microsoft Executive replied:
“Don’t confuse Brownian Motion with having an impact!”
Bottom line is it’s all about the impact—not the activities. This is precisely where Agile Results can help.
I’ve seen J.D. Meier time and time again use the core principles outlined in Agile Results to deliver outstanding value which has had a positive impact for our customers and partners across the world. In the past, he has shared Agile Results with anyone who has asked. Now, he shares it with the rest of you. May you enjoy the rewards of bringing value, making an impact, and getting results!
Sincerely, Michael Kropp General Manager Solutions Engineering
“We are what we repeatedly do. Excellence, then, is not an act, but a habit.” -- Aristotle
You can master your time management only to spend your time on the wrong things. You can master task management and miss windows of opportunity. What are the real secrets to great results?
I’ve found that there are 3 keys to effective results:
As I explain this, it should become obvious why.
Time When you don’t put in your time, you don’t get the results. It’s that simple. The treadmill isn’t going to walk itself. The project isn’t going to finish itself. As one of my marathon runner friends says, “You have to put in your hours.”
Whenever I’m not getting effective results in an area, I have to ask myself, am I actually putting in the time? Putting in time is one of the keys to deliberate practice. To give you the quick generalized idea of deliberate practice, it’s one great hour of time spent mastering your craft, using a technique that you can improve, refine, and get better over time. It’s living the idea that practice makes perfect.
However, just throwing time at things isn’t the whole answer. Especially, in a knowledge worker world and information age where what you do or why you do it, is as important as how you do it, and sometimes even more important.
Know the minimum time you need to spend to get meaningful results.
Some good sanity checks for time are:
Time is just a piece of the puzzle though. Another key is …
Energy Have you ever spent 40, 60, 80 hours or more in a week, only to wonder what you actually accomplished? Have you ever accomplished more in a day, than you have in a week? Have you ever accomplished more in an hour than you have in a day? This is the stuff that power hours are made of. This is the secret of productive artists.
This is also the secret of changing the game when it comes to time.
Energy is the secret of time management. Whether you live by the 80/20 rule (the pareto principle), or read The 4-Hour Work Week, or The Power of Full Engagement, the simple pattern or principle at play here is that you’re more productive when your energy is strong.
If you want to spin circles and move mountains, then before your throw more time at problems, first fix your energy. Whether you feel like The Little Engine that Could, or you feel like The Little Engine That Can’t … makes all the difference in getting results.
I’ve interviewed many people across Microsoft at all levels to find the keys to energy management. Here’s the surprise. The surprise is that it’s simple:
Fix time for eating, sleeping, and working out.
Yes, that really is the pattern across all the Softies I interviewed. The ones that mastered their energy, got more power hours in their week, and accomplished more, by doing less, fixed time for eating, sleeping, and working out. Their day worked around these 3 things, not the other way around (as a tangent, a surprise for me was how many people’s best sleep pattern was 11pm – 7am. I haven’t figured out why yet or if it’s just correlation.)
So if you want to get more done, by spending less time, while improving results, improve your energy. Add power hours to your week and add creative hours to your week.
But that’s not the whole secret. There’s more. If you really want to drive your energy, you need to know another secret:
Spend more time in your strengths, and less time in your weaknesses.
Marcus Buckingham, Martin Seligman, and countless others taught us that. Spending time in your strengths gives you energy. It feeds on itself. Spending time in your weaknesses drains you. It sucks your life force. If you know the game Gauntlet, you know what I’m talking about (“warrior is about to die …”)
Your strengths are not simply what you’re good at, just like weaknesses aren’t what you are bad at. They aren’t your skills. If anything, strengths are your natural talents. A good way to figure out your strengths is to look at your week and find the things you can do all day. The way to find your weaknesses is to find the things you can’t do for more than a short-burst without getting drained. In fact, just thinking about it drains you.
Some good checks for energy are:
If this doesn’t open your eyes to endless possibilities for improving every day of your life, please see me. It’s a first.
Technique This is the skills game. It’s where strategies and tactics make all the difference in the world. This is also where you experience and wisdom can truly pay off.
You can throw time and energy at things, but if you use the wrong technique, this is why you can churn and burn. A lot of people come to me for email best practices. They spend too much time in email, but email is part of their core job. They’re always curious how I spend no more than 30 minutes a day in mail, yet deal with a couple hundred mails a day, and always keep a zero inbox. It’s technique. Seriously.
Sure I could use the Force or will my way through it. But that’s either lucking into success or success through heroic effort … if it even works. That’s not repeatable or sustainable. Instead, it’s better to find and master the proven practices.
I will say that I’ve learned to value the ROI of proven practices. I’ve spent 10+ years of deliberate practice in finding and sharing proven practices on the patterns & practices team. It’s an art and skill to find the practices, methods, and techniques that actually work. But when you do, it’s gold.
The problem is, there’s no silver bullet. Instead, it’s about exploring and adding arrows to your quiver, more tools to your your mental toolbox, and more skills to your tool belt. It’s also about using mentors – mentors are the short-cut. It’s also about looking for patterns and testing what works for you. Context matters. It’s also about knowing how to measure and test success. It’s also about continuously innovating in your approach. This is how you take advantage of the latest science, and leap frog ahead.
The beauty is that working on your technique is an integral part of deliberate practice. It’s also how you can find your flow and be fully engaged in what you do. It’s also how you can get amazing impact with less effort … and less time. It’s part of mastering your craft, and getting the system on your side.
So putting it all together …
… the foundation for achieving great results is the masterful blending of time, energy, and technique.
If you want to amplify your impact or improve your results, look to each of these areas, but remember that the whole is greater than the sum of its parts.
If you like this secret, there are plenty more where that came from in my first non-technical book, Getting Results the Agile Way.
This is a draft of our REST with ACS application scenario for your feedback. It’s a whiteboard sketch of how to secure a REST service on Azure.
REST with ACS Scenario
I’m a fan of standing on the shoulder’s of giants. In today’s world, you need all the advantages you can get just to stay in the game. One way to stack the deck in your favor is to “model the best” and learn from the people that pave the way.
In my latest edition of “Greatness Distilled” I share Lessons Learned from John Maxwell. If you don’t know Maxwell, his books are probably the greatest collection of patterns and practices for leadership.
I draw from various unsung heroes and across industry greats. The idea is to capture and distill the distinctions in a way that makes it easy for you to quickly glean the pearls of wisdom, primarily drawing from their quotes where possible (quotes are how we share wisdom of the ages and modern day sages.)
Here are additional lessons learned as part of the “Greatness Distilled” series:
Who’s your hero or heroine that you draw from for insight, inspiration, and action?
As part of our patterns & practices Azure Security Guidance project, we’re starting off by focusing end-to-end application scenarios. We’re taking a crawl, walk, run approach by starting with the simplest combinations of application types and authentication, authorization, and communication patterns. This is the same Application Scenarios approach we used in Building Secure ASP.NET Applications.
This approach is helpful for mapping out a path and driving architectural spikes. You can think of Application Scenarios and Solutions as what you would sketch on the whiteboard. It’s a minimalist representation of the end-in-mind primarily focused on deployment and runtime patterns. It’s about putting the Leggos together, before diving into the details (though the Devil is rumored to hang out there, and I’ve seen this first-hand.)
Example Application Scenario and Solution The basic format is to show the Scenario, the Solution, and a Solution Summary Table. The Scenario is a simple visual of the application from a deployment standpoint. The Solution is a visual of how you might address authentication, authorization, and communication (the security runtime patterns.) The Solution Summary Table is a quick description of how you would address the authentication, authorization, and communication from a security standpoint.
Here’s an example:
Scenario ASP.NET application on Azure.
As you can see, it’s lean by design. The idea is to put together a strawman of the solution so that we can first evaluate whether the direction even makes any sense. This also lets us assemble many solutions pretty quickly so that we can chart out the potential paths and then pick the ones that make the most sense, and test them with customer feedback.
The next level down would be creating repros of the architectural spikes and creating step-by-step How Tos. We’ve found this approach to be the fastest and most effective when it comes to sharing know-how.
Getting Results the Agile Way is my first non-technical book. You can read Getting Results for free in HTML. This book wraps up and shares my simple system for meaningful results. It's the best of what I've learned in terms of focus, personal productivity, time management, energy management, and making things happen—in work and life.
The Plan for the Book The plan for the book is pretty simple—finish the final edits and ship it. It should be out later this month, pending any surprises. (Although I’ve authored books for Microsoft, it's my first time through the self-publishing process, so I've hit a few surprises.)
The Ups ... Here are the ups so far ...
Since announcing Getting Results last month, I've had more than 15,000 visits to the site. That's not the interesting part though. The interesting part for me is the success stories from people who adopted Getting Results the Agile Way. (Note that there are many more success stories behind the scenes, but I only share the ones that folks say is fine.) I like hearing how people change their life and unleash their best. It's still up to them, but Getting Results helps them stack the deck in their favor.
It's also very inspiring that people offer their time and talent to translate the book because they believe in it so much. This is already on top of the amazing people in the community that have shared their stories, helped shape the book, and contributed in various ways. You can view the growing list of acknowledgments.
The Downs ... Here are the downs ...
Even the downsides have an upside though. While editing is taking longer than expected, it's a chance to incorporate more feedback. While I've had other priorities, new opportunities have come along the way, where people are helping me with everything from marketing to getting the word out. While I'm taking the hit on learning the self-publishing path this round, the beauty is I'll be more prepared for the next book. I'm always learning and it’s definitely a growth path.
More on Getting Results the Agile Way ... Here's a little more on Getting Results the Agile Way if you don’t already know what it's all about ...
Work AND Life ... It's for work and life. It's about getting more out of the time you already spend, and freeing you up to spend more time in doing what you want. It's also about amplifying your impact. Rather than compartmentalize your work from life, it's about living your values and playing to your strengths on the job. This is where you connect your work to your values, find more energy, and get your best results.
Fire on All Cylinders ... It's geared towards Softies, since that's mostly who I mentor, but it's perfectly applicable to anyone wants to get results in any situation. Why? It combines proven practices from project management, positive psychology, Agile, Scrum, ... etc. The bottom line is, it's a simple way to fire on all cylinders.
The bottom line is, this could very well be one of the most important books in your life. It’s a system for personal results. The goal of the book is to give you the skills to go the distance in an ever-changing world … while enjoying the process, and flowing value for yourself and others … the agile way :)