Software Engineering, Project Management, and Effectiveness
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
My Related Posts
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/
“Productivity is never an accident. It is always the result of a commitment to excellence, intelligent planning, and focused effort.” -- Paul J. Meyer
Anutthara Bharadwaj, a Program Manager on the Microsoft Visual Studio team shares her experience on adopting the Agile Results system in her post, Getting Results the Agile Way. In her story, Anu writes how she went from being overwhelmed to on top of her game by adopting three core practices:
I like her concrete examples. In her case, she uses One Note to implement the system. That’s the power of the Agile Results system. It’s a principle-based system so you can use whatever tools works best for you for adopting the practices. (I’ve used everything from pen and paper, whiteboards, Evernote, Outlook, One Note, simple text files, etc.)
Small changes in your day, add up to big changes in life. I’ve had the chance first-hand to watch Anu transform and it’s been an amazing journey.
Stop by and check out Anu’s post on Getting Results the Agile Way.
What's the best way to do it?
Time management tips #9 is pair up. Paring up simply means find somebody that will work with you on something, rather than go it alone. When you pair up, you create a team of capabilities and you learn how to love the things you might otherwise hate. Worst case, you at least make doing what you don’t enjoy, more fun. Best case, you find a new passion for something you didn’t know you had.
We all have things to do that we're not great at, or slow us down. Maybe it's because we don't have talent for it. Maybe it's because we hate doing it. Maybe it's because we just don't know a few tricks of the trade. (Sadly, I find the that it’s missing the tricks of the trade, that holds us back the most … and learning the tricks, actually unleashes a passion in us, because we no longer suck at it … it’s such a chicken and an egg scenario time and time again.)
Chances are you know somebody who is great at whatever it is that you need to do, or at least better than you. Just because you might hate to do something, doesn't mean that somebody else does not live for it. One person's trash is another's treasure. And that's a good thing.
Pairing up is the fastest way to transfer tribal knowledge. It’s visceral. You *feel* it. You immerse yourself in it. You get to see how somebody that likes doing this activity, actually goes about it. It's your chance to learn everything from the mindset they have, to the questions they ask, to the short-cuts they use, or how they make it fun.
One of my favorite phrases at work is, "Show me how."
So many experts love to show and share how they do their magic. It puts them in their element. Sometimes they will genuinely want to help you succeed. Other times, it's just so they can show off. Either way, it doesn't matter. What matters is that you make the most of it.
One of the best pairing situations is where you find a "workout buddy" for work. Maybe you are good at doing slides, and maybe they are good at technical details. When you pair up, you can both look good, and you both have something to gain.
Pairing works best when it's a mutual gain, so it's always helpful to bring something to the table. Sometimes, all you bring to the table is appreciation for their amazing skill, and sometimes that is enough.
Another great pattern for pairing is if you are a "starter" -- you like to start things, but you aren't a strong "finisher." A strong "starter" and "finisher" pair is like a dynamic duo in action that amplify each other's success. One's strength is another's weakness, and your goal is to build a mini-team of capabilities over a one-man band.
It's not just effective, it's strategic. By doing what you do best, and supplementing where you are not, you maximize your ability to make things happen in the most effective way, while staying true to you.
In 30 Days of Getting Results, you can use the time management exercises to be a more effective starter or finisher and get exponential results on a daily and weekly basis. You can also find more time management tips in my book, Getting Results the Agile Way, and on Getting Results.com
You Might Also Like
I wrote a post about how to embrace the effort. Effort is something I knew very well, and it's helped me differentiate in many scenarios.
It's easy to downplay the benefit of effort, especially because you aren’t rewarded for effort, you’re rewarded for results. I never got an A for effort (although I did get an E.)
But here's the catch: YOU have to reward yourself for your own effort. And just because you don't get the results you wanted, you still need to acknowledge and appreciate your own effort. It’s critical to your long-term success.
Effort really is an essential ingredient of your personal greatness. Sure, you can luck into success some of the time, and talent can get you so far, but effort is the difference that makes the difference, and it’s the maker of more consistent success. Effort is also the key to making more meaning in your life, and it's an integral part of the path of fulfillment. Yeah, fulfillment happens more when we give our best, where we have our best to give, on a meaningful mission. Giving your best takes effort, and meaningful missions are always filled with challenges. That’s why in life … it’s the journey AND the destination (and sometimes the journey is all we’ve got.)
It's wise advice that we should focus on what we control, and let the rest go. One of the toughest lessons in life is that we can't control everything … and many times, the results are out of our hands. Sure, we get to influence, but the bigger the challenge, the less we control how the cards will fall.
But what do we always control? The effort that we put in. That’s the difference maker in our lives.
If you're not getting the results you want in work or life, take a look at the effort you are putting in. If you aren't putting in the effort required, try adding some effort to see if that makes the difference. In fact, embrace the effort. Effort is what expands what we're capable of. Feel the effort, and feel your growth.
When effort is not the trick, it's often a matter of strategy. Working harder isn't always the answer (though sometimes it is.) A lot of times it's working smarter. In many cases, the answer is "AND" ... it’s about working smarter AND working harder. (What a powerful combo.)
The beauty is that well-applied effort, often pays off.
And if you acknowledge and reward yourself along the way for the effort you put in, that always pays off.
Check out embrace the effort, and put the power of effort on your side.
I hate quotas. For me, I'm about quality, not quantity. And yet quotas have consistently helped me get the ball rolling, or find out what I'm capable of.
Time management tips # 10 – set limits. When we set a quota, we have a target. It helps turn a goal into something we can count. And when we can count it, we build momentum.
In my early days of Microsoft, my manager set a limit that I needed to write two Knowledge Base articles per month. I did that, and more. Way more. It turned out to be a big deal. Before that limit, I didn't think I could do any or would ever do any.
A few years back, I set a limit that my posts would be no longer than six inches (yeah, that sounds like a weird size limit, but I wanted to fill no more than where the gray box on my blog faded to white.) My blog ended up in the top 50 blogs on MSDN, of more than 5,000 blogs, and my readership grew exponentially that month. The reason I set the size limit is because my original limit was "write no more than 20 minutes." The problem is, when I'm in my execution mode, I write fast, and my posts were getting really long, even if I only wrote for 20 minutes.
Setting limits in time, size, or quantity can help you in so many ways. Especially, if getting started is tough. One great way to start, is simply to ask, "What's one thing I can do today towards XYZ?" Limits also help us avoid from getting overwhelmed or bogged down. If we’re feeling heavy or overburdened, start chopping at limits until your load feels lighter.
Here are some example of some limits you can try:
Once you set a limit, you suddenly get resourceful in findings new ways to optimize, or new ways to make it happen. When there is no limit, it's tough to optimize because you don't know when you are done.
While I'm a fan of quality, the trick is to first "flow some water through the pipe" so you can tune, prune, and improve it.
If you're feeling rusty, try setting little limits to bootstrap what you're capable of.
In 30 Days of Getting Results, you can use the time management exercises to be more effective and get exponential results on a daily and weekly basis. You can also find more time management tips in my book, Getting Results the Agile Way, and on Getting Results.com
Do you have something that you've been wanting to learn, but just don't have the time? Do you have an area at work that you struggle with? Do you dabble in too many things at once, and never make real progress?
Enter 30 Day Sprints.
Time management tip # 11 is 30 Day Sprints. 30 Day Sprints let you try something out for 30 days and make progress. 30 Day Sprints also give you a way to cycle through something new each month. It’s a great way to embrace continuous learning. Each month you can add something new to your portfolio of skills, so at the end of the day, you can have 12 big changes under your belt.
I adopted 30 Day Improvement Sprints several years ago to deal with a couple of challenges:
What I learned is that committing to 30 days of improvement in a focused area, is easier to swallow than changing for life. However, improving an area for 30 days, is actually life changing.
With 30 days, persistence and time are on my side. It's a big enough time box that I can try different techniques, while building proficiency. Using 30 days makes working through hurdles easier too. A lot of the hurdles I hit in my first week, are gone by week 2. Little improvements each day, add up quickly. I look back on how many things I tried for a week and stopped thinking I hadn't made progress. The trick was, I didn't get to week 2 or week 3 to see my results.
That last point is a big deal. When you stick with something for more than two weeks, you get over the humps and hurdles that hold you back. It's like chipping away at the stone, and sometimes the breakthroughs don't happen until you're a few weeks in.
This is also a powerful way to add habits or change a habit. Why? Because you can do something small today. And tomorrow you can do another small thing. You can keep little commitments with yourself. You can glide your way into your habit, versus run out of steam. If you’ve ever been gung-ho for a week, and then fizzled out, 30 Day Sprints can be your answer.
As we turn the page to a new month, pick a focus for the month, and make it your 30 Day Sprint.
In 30 Days of Getting Results, you can use the time management exercises to get exponential results on a daily and weekly basis. You can also find more time management tips in my book, Getting Results the Agile Way, and on Getting Results.com
Sometimes small is the best way to make progress. In fact, sometimes it's the only way.
If you don't have time to do something big, do something small. Don't make a major production out of it, don't make a mountain out of a molehill. Chunk it down. It's a skill you can practice daily.
What's one small thing you could do … today?
Sometimes getting started is the hardest part. In fact, sometimes the start takes more effort than the work:
"It is always the start that requires the greatest effort." -- James Cash Penney (Yeah, the guy that started J.C. Penney’s)
If you don't know where to start, then start with something small.
Be a fire-starter ... use your little victories for kindling.
How do you get started?
Here are seven practices I’ve experienced that worked well with meetings:
It’s really about momentum … we can spiral up or spiral down. Energy is our best asset to spend on the right things.
On #7 -- Any time I've seen meetings have momentum (and I can think of multiple vignettes), it’s when somebody put their thoughts out on the table first, without being sliced and diced along the way. I also think of examples, where somebody finishes painting the broad strokes of their picture ... and we get the bigger picture, before needling at the fine points, and fracturing great ideas in the making … or at least getting the bird’s-eye view before chasing the rabbit down the hole.
When we practice #7, it builds trust, people are heard and understood, and people will be less long-winded, and defensive, etc.
Bonus --- Have a skilled facilitator, manage the shot clock, set time for things (timebox), take decisive actions, and have a parking lot to put things.
“If you want something done, ask a busy person to do it. The more things you do, the more you can do." -- Lucille Ball”
I was reading Scott Hanselman's post on Productivity vs. Guilt and Self-Loathing. In his post, Scott shares what he does when he feels unproductive. If you know Scott, he's the opposite of unproductive. So the question then is ...
Why do we sometimes feel unproductive?
I played with this question on my way to work, and then a few dots connected.
We See the Work I connected the dots when I was surprised by a few people that said they didn’t really see all the work ahead. They were working on a few things, but there was not an amazing forest of challenges and opportunities ahead of them. Instead, it was just a tree here or there. It baffled me, but then it clicked. Not everybody looks to see the forest.
As a Program Manager, I'm constantly breaking work down. I need to map out paths from A to B. I'm constantly sorting massive lists of work to be done. I'm always looking at the system. I need to find the bottlenecks in our system and ecosystem and unblock them. I need to orchestrate people to bring out their best. I need to foresee and anticipate humps and hurdles and have a game plan to get around them.
It's not that the job of a Program Manager is never done (It isn't BTW.) It's that some people see the task at hand, while others see the bigger map.
Any idea that comes my way, I have to start breaking it down into experiences, scenarios, features, requirements, timelines, milestones, etc. I always see the work.
Some people don't "see the work." I've run into this pattern multiple times, where somebody looks like they have nothing to do. In their mind they don't. Nobody told them to do anything. They aren't a self-starter. If nothing is assigned to them, then there's nothing to do. For others, they are looking for work, but they can't see the work. They haven't done work-breakdown-structures, or iteration planning, or any sort of planning, so they just aren't familiar with how to look for work ... and more importantly, they don’t know how to identify meaningful and game-changing work.
When you see the bigger map, it can feel like people are re-arranging deck chairs on the Titanic. Your job then becomes to educate people on the why, the what, and the goals of the work, so people can put the deck chairs down, and re-focus their efforts.
So when I measure myself against the work to be done, I always fall short. When I get to the top of the mountain, I see more mountains.
The solution? Set milestones, identity tests for success, and stop to smell the roses. Look back on achievements, to balance always looking ahead.
We Have Ideas When you constantly flow ideas, you are brutally aware of missed opportunities, and worse, missed windows of opportunity. The backlog of ideas just keeps growing, and, it's not a shortage of good or even great ideas, there is a shortage of execution.
It's OK for bad ideas or lesser ideas to die a slow death, but it's a real shame when the game changers die due to lack of love.
It's amazing how many ideas can flow when you know how to debottleneck your mind. When I learned that Thomas Edison had an idea quota, I thought that was interesting. You get what you measure, and you get more of what you focus on. When I learned how to clear my head by dumping my state, and to capture ideas with a thought catcher, my speed of ideas outpaced my execution by a long shot. As a Program Manager, I'm skilled in making things happen and going from idea to done ... but my pace of ideas outpaced what was possible within time, resource, and budget constraints.
The solution? Focus on the whitelist of great ideas, versus the blacklist ... Hit more windows of opportunity, ruthlessly prioritize, trade bad, good, or great for oustanding, and really focus on wins ... three wins for the day, three wins for the week, three wins for the month, three wins for the year.
We Feel the Impact This one is tough. When you know what's possible from excellent execution, and when you know the power of productivity, it's actually painful when opportunities slip through your fingers. When you can step into the future and you know how the world could be a better place, and yet at the same time, you know that without the right things happening, it's not going to happen ... it's tough.
When you know that a lack of execution or lack of effective productivity will translate into businesses going under, or people losing their jobs, or evil winning the day, it's tough to rest. On the flip side, when you know that giving a little more, and then a little more, can create powerful transformation, it's tough not to fight the good fight, and march onward and updward.
Again, it can be tough to stop and smell the roses, and it can feel like the weight of the world on your shoulders.
We Don't Always Keep Score We learn in school to focus on what we got wrong, not what we got right. We forget to ask the simple questions like:
- What's on my "Done" list? - What were my wins for the day? - What were my wins for the week? - What were my wins for the month? - What were my wins for the year?
One of the people I mentor asked me if it was important to keep her "Done" list. (A "Done" list is simply a list of things you completed during the day.) I said, "Absolutely. It's a reminder of what you achieved during the day. And you can balance it against your three wins that you identified at the top of your list."
The idea here is that, as simple as it sounds, a little progress can go a long way toward feeling productive, and feeling fulfilled. Little lists help, even as simple as having a "Done" list for your day.
We Have to Trim the Tree Periodically, we have to “Trim the Tree.” We have to put the bags down, and start with a clean slate. We need a fresh look, and a fresh perspective. We need to recharge and renew. We need to let our “mighty mounds of work-to-be-done”, crumble and fall, so we can build better, more meaningful mounds.
The reality is that time changes what’s important, and if we keep carrying the weight forward, it holds up back or holds us down. We have to cut the dead wood.
I like using a “Trim the Tree” metaphor because I think of trimming branches, beyond just leaves. My goal is always to get back to the essential that matters … here and now … and to shape what will matter … so that the way forward is sustainable, inspiring, and lifts us in ways we know are possible.
The goal – at the end of the day – is this …
You need to be who you want to be, and create the experiences you want to create.
Your best strategy for that is to follow your personal strategy for work and life, including your vision, mission, and values, and playing to your strengths, and differentiating through your unique experience, capabilities, and approach. We also know three paths of happiness you can follow:
When you combine strategy with your productivity, you help not only life your meaningful life, but you help lift the life of others, by bringing your unique value to the world. Or, to put it another way, it’s a great way to build skills to pay the bills and lead a better life.
I’ve baked many of these strategies and techniques from hard lessons learned in the most challenging scenarios into a simple system for meaningful results. It’s Agile Results, and it’s introduced in my book, Getting Results the Agile Way. You can read it free online, or get Getting Results the Agile Way on Kindle and take it with you wherever you go.
When it comes to time management, one of the most common questions I get is, “How do you dump your state?” Meaning, how do you dump what's on your mind to a place you trust, and how do you pick up where you left off?
Time management tips #14 is dump your state. Dumping your state helps you pick back up where you left off, and it frees your mind to focus on the tasks at hand. It also helps you move up the stack. After all, if your mind is filled with little unclosed loops, you are not at your most resourceful and creative best.
When you have baggage of the brain, it's tough to focus. Your mind is busy circling back on the loops it hasn't closed. It's also buzzing endlessly in the background to remind you of the things you should not forget. All the mental chatter gets in the way of you having peace of mind, clarity of thought, and focused attention ... right here, right now.
That's one scenario of why dumping your state matters.
Another scenario where dumping your state matters is when we want to pick up from where we left off. We spend all day working on a problem, building up state, but then we can't finish, so we have to park if for the day. The problem is we want to be able to pick back up the next day, from where we left off. Worse, sometimes we can't pick up back up the next day, and then all the state we built up starts to rot on the shelf of our minds, or decays in some place that we may never find again.
So what can you do?
It's very simple, and I call it brain dumps or "Session Dumps." To do a “Session Dump”, just dump what's on your mind, down onto paper or onto a page, using your favorite system. For me, sometimes this is an email that where I will dump my whiteboard fast, or I use Onenote to dump, or I use EverNote to dump plain text. In most scenarios, I have notepad open on my desktop, and I constantly dump to it ... so instead of little insights or actions floating in my head, they are jotted down to where I can see and organize them.
It might seem like an endless list in your mind, but you’ll be surprised that the more you dump, the less it is. It gets faster too. And thinking on paper is powerful. When you see the list in front of you, you may very quickly realize what you can let go, and what you really need to hold on to.
Here's the real trick though. Since I do this daily, I found that the best approach is to simply "dump state" to a clean sheet each day, and to name it the current date. For example, for today, I would title my Session Dump as follows:
Naming my Session Dump by date means I never need to figure out a good title, and by keeping all of my dumps in one folder, it's easy for me to always find them. I use that simple format because I can easily flip through in sequence.
I have to let a lot of things go, so I can focus on the best opportunities and challenges that lie before me. Time is always changing what’s important. Having a rapid way to dump state or pick up where I left off is a big deal. Now I never have to wonder where I dumped straggling ideas, or things that were percolating on my mind.
At the end of the day, dump your state before you go home and see how much it frees you up.
For free, self-paced modules on time management training, check out 30 Days of Getting Results.
Every time you have to remember what’s next to do, you waste your time. You've heard of "paper shuffling." This is like "thought shuffling." You spend a lot of time shuffling your thoughts around, but not actually doing anything.
Enter stage right … the power of lists.
Time management tips #15 is make lists for action. Use lists to organize and take more effective action. Lists are your friend. They help you organize your thoughts and ideas into action. Pilots use checklists. Sure they know what to do, but they also know that having the checklist helps free up their mind (specifically, their prefontal cortex). Teams use inspection lists to drive quality, share processes, and share work. Companies large and small use checklists for quality control and streamlining performance.
You can use lists to streamline yourself, improve your own quality, and simplify your work.
When you make your lists, test them against effectiveness. Keep them as simple as possible, but make sure they help you. Never become a slave to your list. If your list gets too big, start a new one and carry the good forward. Let things slough off.
Here are some of the most useful lists to have, when it comes to organizing your work and guiding your action:
Another useful list is a quick list of the steps for a given task. This can help you stay on track, or remember where you are, or easily find the next step. The trick is not to over do this, or over-engineer your steps, or worse, forget to be flexible in your approach. Focus on the goal, but stay flexible in how you achieve it.
Goals are always your guide.
Use lists to organize your work, organize your actions, and simplify your work and life.
For free, self-paced modules on time management training , check out 30 Days of Getting Results, and for more time management tips check out Getting Results.com.
Sometimes you need to Just Start. Other times, you need to Just Finish.
One of the best ways never to finish something, is to spread it out over time. Time changes what's important. People lose interest. Changes of heart happen along the way. Spreading things over time or pushing them out is a great way to kill projects.
Open items, open loops, and unfinished tasks compound the problem. The more unfinished work there is, the more task switching, and context switching you do. Now you're spending more time switching between things, trying to pick up where you left off, and losing momentum.
This is how backlogs grow and great ideas die. This is how people that "do" become people that "don't."
Time management tips #19 is just finish. If you have a bunch of open work, start closing it down. Swarm it. Overwhelm your open items with brute force. Set deadlines: - Today, I clear my desk. - Today, I decide on A, B, or C and run with it. - Today, I close the loop. - Today, I solve it. - Today, I clear my backlog.
If you want to finish something, then “own” it and drive it. To finish requires ruthless prioritization. It requires relentless focus. It requires putting your full force on the 20% of the things that deliver 80% of the value. It requires deciding on an outcome and plowing through until you are done.
Stop taking on more, until you finish what's on your plate. If you want to take on more, then finish more. The more you finish, the better you get.
The more you finish, the more you will trust yourself to actually complete things.
The more you finish, the more others will trust you to actually take things on.
The more you finish, the more you build your momentum for great results.
For time management skills , check out 30 Days of Getting Results, and for a time management system check out Agile Results at Getting Results.com.