Red Balloon Winning Method

Really found this contest interesting and exciting.  MIT won it.  Their technique: divide the total pool equally between the outcomes.  Give 1/2 to the winner, 1/4 to the person that referred the winner, 1/8 to the next, 1/16 to the next, and 1/16th to charity. 

That to me is  kicking positive butt but they didn't keep any money for themselves.  But they're rolling in the acclaim and accolades, so I'm sure it didn't do them any harm!

Don't Just Kick Butt...Kick Positive Butt

In this post, I explain my two core business principles: Kicking Butt and more importantly Kicking Positive Butt.  Briefly, the point is to do good work for the communities you care about but in order to do that, you have to get out there first.  I hope that me sharing my principles with you will help you better understand what your principles might be. 

My overall philosophy is pretty simple: Kick Positive Booty.  But this has a sub-part to it and is really TWO steps: Kick Positive Booty (principle 1) requies that you first Kick Booty (principle 2).  Together these principles focus and balance me toward getting things done.

1. Kick Booty - First you have to get out there and connect with people.  This means getting off your butt and taking charge of your life.  You have to be hungry, aggressive, and focused and ready to change things and take them as they come.
   
2. Kick Positive Booty - For me, I don't want to just "kick butt", I want to kick good butt.  A specific type of butt.  I want to do good for mankind and society first, and myself second.  I care fundamentally about myself and my situation but if I don't put others in front of myself and their needs in front of mine I will not be successful.  This is like having good customer service and not being too self-serving.

In summary, you learned that I'm not just about kicking butt but I want to kick positive butt and make a change to things that matter.  I hope that knowing this will help you think about what POSITIVE butts you are going to kick!

An Easy-To-Follow, Scalable, Agile Process for Anything

In this article, I outline a quick and easy-to-follow process for getting lots of things done (the agile way).  I think you'll find it useful and informative.  It doesn't matter if you're scheduling improvements to your home, hometown, or business, you can follow this process on any and get results. 

1. Note the request(s) (high level) in the backlog…you don’t have to understand what it is fully…just the gist of what’s being requested.  Make sure you include who its from and anything else.  Make sure it's fluid, too, and always be willing to go all of the way to the end of the process if the rules allow.  Don't let yourself or the process be the bottleneck!
   
2. Backlog and prioritize this work.  Figure out where the request should sit in the queue.  Use a method like FIFO or LIFO as a reference.  You could also create a "value index" to score the cost/benefit of the request.  Sometimes you may choose to do ANYTHING you can just to demonstrate value and show the customer that you are doing SOMETHING toward their objectives.
   
3. Define the request in concrete terms including the problem, required output and success criteria.  This may also include the specific implementation method and input required to get the job done.  Be clear what the customer needs and make sure there's a clear agreement and understanding of output at this time.
   
4. Optionally train the person(s) performing the work—even if it’s yourself—how to do the tasks necessary.  Remember the goals and make sure there is no "loss" in the communication process. 
   
5. Assign the work and start executing.
6. When the work is reported to be completed to spec by the person, verify.  Repeat this step until you accept the quality. Note: you could see all changes you make here as backlog items as well, so beware of "churn" and be fair to the people and process (team!).
   
7. You may queue or hold the result at this time as to efficiently deliver a collection of things to your customers or you may deliver it as well.  Queuing your results will promote longer, larger cycle times but could be more efficient for your business.  Delivering now will shorten the cycle and create for much higher customer interaction, which can be good, especially for very small teams (even teams of one).
   
8. Deliver the result to the end customer.  This is a similar verification (validation?) process but is facilitated by you, the process owner; that way expectations and feedback can be set and the overall process and deliver method improved.

I hope you found this process for getting things done useful and are able to apply it to things in your life.  Please offer any feedback or questions to me through the blog or to eric.veal@efficitrends.com.  Thanks!

Be Versatile or Be Gone

One of the keys to being a high-functioning technology consultant is to be versatile in your role.  You have to be able to do a lot of things well to make the client happy.  Common roles you (should) have to play well are Analyst, Builder, and Project Manager.  Here’s a quick description of each:

Analyst - Understand and define the problem using your skills of interviewing, math, statistics, process flow, data and information analysis.
Builder - put the necessary pieces together to create the solution.
Project manager – Integrate and communicate what’s necessary about the related parts of the project such that the involved parties understand what’s going on and continue to want what's being produced.  

In total, you have to be willing to do whichever job is necessary to get the job done and make the customer happy.  This requires experience, risk-taking, research, and networking.

6 Ways I'll Make a Better Professional Blog

I recently wrote a blog post (here) that I shared with several people.  Some liked it and were "with me" yet others wrote somewhat lengthy feedback about how I needed to improve my delivery method.  They were commenting more on my style more than the content.  So I guess I'll focus on style for the moment. 

Here's what I'm going to do about it.  I hope you'll take what I'm  learning and apply it to your own experiences writing, blogging, and career management. 

Thanks to Don L. and John S. for their feedback and insight.

How I'll Offer More Quality Content to My Audience:

1. I'll get to know my audience better and understand their needs and desires in order to offer more relevant information and conversation about the topics that interest me most. 
2. I'll be more clear about my point and ramble less.  I'll try to capture the audience's attention ASAP, get to the point and get out the information that I'm trying to convey as compactly and rapidly as possible.  Maybe I'll use more graphics (see this post).
3. I'll be more precise and specific and cite references more. I'll read more as an input.
   
4. I'll have a call to action if possible, directing my audience to next steps, further reading, engagement, etc.
   
5. I'll build a community and drum up input from them on my delivery and content (effectiveness).  
6. I'll tell more people how to sign up for my blog and think of other methods of reaching my audience (podcast, email, speaking engagements, etc.)
   

My overall goal online here and professionally is to create a dialog and debate with my audience about topics that matter a great deal to me.  I'm trying to learn and help my audience as much as I can with insight that matters to them.  I'm seeking insight from them on the topics that matter most to me and also looking for feedback on delivering the best way possible.  Thanks for your patience and participation in this process.

8 Ways to Be Agile with All Customers and Grow Your Business

1. Say yes to all work being requested, regardless of your ability to deliver on it now
   
2. Seek to define all work completely with success criteria, method, etc. and add it to your backlog
3. Make your backlog/pipeline visible and available to your customers
   
4. Make it clear to your customers what you're working on now and next
   
5. Have your customers prioritize your backlog and "fight" amongst each other (you should probably facilitate this so you're not purely randomized) for your time, driving up demand
6. Work on and complete the well-defined problems and learn from the experiences.  Feed lessons learned and changes back into the backlog.
7. Make customer after customer happy and make sure the the prioritization method is fair and best for your business and total customer satisfaction.
   
8. Try to delegate as much work as you can to your team but make sure that the process documents all work, regardless of who does it.  

Your value is how much you are getting done in total, though your system.  This means that you should be developing more business, working less, defining more.  You should focus on the demand AND supply side and grow this business.

Refusing to Use the Tie-Breaker Role

My friend Bruce today told me about a book called The Seven-Day Weekend: Changing the Way Work Works http://www.amazon.com/Seven-Day-Weekend-Changing-Work-Works/dp/1591840260 and brought up an interesting point about systems that are "open" but also have a "tie-breaker" role (manager or authoritarian).  In the system that Bruce described in the book, although this role existed, the manager never used his power as tie-breaker and would always put it back onto the group.  I thought that was interesting.

The Ideal Dev Process Parts

What parts do you think must be included in the ideal, high-scale web and software development process today?  (As judged by such factors as most Secure, Scalable, Stable, Collaborative, Clear, Easy to Use, Powerful, etc.)

I'd say it needs to have:

• For a web site / CMS:
• .NET Nuke, Ning, or WordPress
• .NET 4.0
• For code:
• TDD, unit testing
• Asp.net MVC 2.0
• Subversion, TFS, or CodePlex for code sharing
• OnTime for backlog, requirements, bug tracking, and communication
• SeleniumRC for test automation
• Team City
• For a team:
• A Digital Whiteboard

Forming a Consulting Group (that is World-Changing, Profitable, Enjoyable, Sustainable, Continuously-Improving, etc.)

The world is full today with people in business who are doing good things and making compelling change to our organizations.  These people are not generally organized as a collective.  It's likely the goal for many of these individuals to find other like-minded people and establish "guilds" around their particular part of the technology and change delivery puzzle, be it sales, product definition, development, delivery, or support.  In total, our system today requires many quality professionals to deliver the services that it has; and the quality of these services and their density is highly variable and in some cases poor, some cases excellent.  The goal is to make high-quality products that the world needs and for which the market will be willing to pay.  "It takes a village" but this village that we will need for this change is smart, involved, well-organized, and planned.  This is not a government, it is an uprising.

What are the attributes of this village we require to bring about the quality products and services of tomorrow?  From where does this village come?  The crowd, I say!  From our networks; current and future.  In my opinion, it is possible to find and support--with the appropriate tools, incentives, practices, and resources--people willing to capably contribute to our current firms and to the firms that we need to bring about.  The goal for the support organization and consulting group would be to offer the training, staffing, and project/program/product services necessary to allow the resources we have today to turn out the products we need tomorrow as fast and at as high of a quality and leading to the greatest economic value possible. The technologies we have today are mature enough to support and sustain such a group.

Today's organizations are either A) antiquated B) outdated C) unprepared or D) non-existing.  Let's fix this!


Critical Components of the Consulting Organization (EfficiTrends):

• Sales & Marketing -- responsibilities are to build the network, filter associates/partners/relationships, educate and train our stakeholders and members.
• Operations & Delivery -- responsible for getting the job done as it's defined and communicating to others when things aren't going according to plan.
• Product Definition and Contracting -- responsible for strategic planning, fine-grained management of relationships, project/program/product management, and contracting.
• Product Support and Operations, Sustainability -- responsible for the ongoing "care and feeding" of completed products and services as well as the definition of new, more streamlined ways of providing those products and services at a lower cost.

Critical Inputs to the Process:

• People in jobs
• Make the most out of the person's role and support them with a great staff and "back office"
• Provide personal marketing, coaching, and resume services about what they're doing, how to market their strengths, develop their weaknesses, and work toward demonstrable results and efficient engagement
• On-site staff augmentation and support services to fill gaps within client team.
• Project and program management definition and sales -- how to "stealthily" grow the scope of the consulting group's influence at the client.
• Replacement services when the individual isn't the best fit
• "Graceful exit" services when the client or engagement should not be the focus of the consulting organization
• Leads, hiring managers, entrepreneurs
• Assist in the definition of programs and offerings
• Put consultants and partners in place
• Seek to define measurable results and a consistent, visible practice, and knowledge base
• Partner via Master Service Agreement (MSA), Joint Venture (JV), etc.
  

My Personal and Company's Mission Statement

"To provide the best ways for people to create the most productive communities and networks about their most critical interests using the most current communications technologies."

That's it.  Any thoughts?

Eric

Developing the Right Metrics Matters the Most

There are several ways a person could view an organization:

• As a collection of business processes (activities) that the business has to perform to meet its strategic objectives
• As a collection of IT applications that support the processes
• As a collection of people and suppliers who provide the resources necessary to achieve the organizational objectives
• As a collection of metrics or measures that describe the performance of the organization

Although each of these perspectives is equally real, only one is RIGHT in my opinion. Which one? METRICS, I say. Unless we boil our organizations into numbers and shared things that people can understand -- not complex and changing things like systems, processes, tools, and people -- can we really manage our organization as a program. I'm not making an argument for ACCOUNTING, per se, I'm talking about those facts and figures that tell us whether or not our business is being successful at achieving its objectives.

Therefore, it's my contention that a key part of the strategic planning and communications processes is to define and communicate about the key performance indicators (KPIs) of your business. KPIs are a bit of a cliche term but they're critical. The fundamental question we have to agree upon is, "How will we know that we are doing well?".

The more we develop this language of numbers and measurement, the more clear we will be together on our perception of what matters and how to allocate our resources and attention.

Replacing Problems with Solutions -- More thoughts on Pragmatism

After I published my last article “15 ways to be more pragmatic at work” I started to wonder if I’d overdone it by citing fifteen points about being pragmatic. Maybe I personally wasn’t very pragmatic since it took me fifteen points to make my case!

When I wrote my 15 points, the problem that I was trying to solve for was that for me the idea of pragmatism seemed very complex and I felt that I had to create an equally complex solution (one that required a fifteen-point process) to solve for it. The basic point here is that pragmatism has a lot to do with efficiency and perception.

If the input requirement I'm given is “build a box” and I create something wildly complex like a computer, you may say that I wasn't being very pragmatic. Whereas if I instead drew a box with paper and pencil and you liked it, you may say that I'm rather pragmatic. It all depends on how we define the problem, who's the audience or judge, and what's really at stake.

When it comes to making new things and getting the most out of life, all of us probably want to know what to expect before we take something on so we are prepared to advocate or defend what we’ve done once we get to the end. We don’t want to do anything without a purpose or to have a story to tell! We know that we won’t be able to mitigate all of the risks involved in doing what we want to do decide to choose the most important risks to mitigate and go down the road to fixing them. Along the way we may have to defend our actions and tell others that what we’re doing is the right thing and the step we’re taking is the right one. In others eyes, we want to be seen as capable, confident, and intelligent; independent.

A pragmatic solution to me is one that includes only as much complexity as is required to be deemed by the people who defined and/or are defining the immediate problem at hand as acceptable. To provide for this we have to know what expectations others will have once we’re finished. This is why we have to inquire and wonder and include others on our journey. This is why planning matters and this is why it’s nearly impossible to create solutions in a vacuum.

Let’s set our sights on replacing problems we have with solutions we like.

Top 15 Tips for Becoming a More Pragmatic Worker

I recently completed an engagement leading several software development projects for Microsoft and learned quite a bit from the experience. Times are tough right now in our economy and I want to express to you how I think we all can be more pragmatic in our work styles and rise to the occasion of these tough times.

Answers.com defines pragmatism as, “having or indicating an awareness of things as they really are.” Well, how are things REALLY? I’d say—given our down-economy and business in general—the world is “really”:

• Competitive. There’s a lot of people out there competing for the same resources and business that you are.


• Impatient. Due to the competition customers may have very high expectations for what is possible and what “value” they think you can deliver to them. They want it all now, perfect.


• At Times Cut-Throat. Managers in today’s environment may be threatened by the realities of competition or the complexities of their tasks. This may cause in them agitation and desire to force workers to realize the inherent risks of today’s environment.

If we see and accept the world as competitive as described above, then we next have to figure out how we can best operate in such a context. Below is my list of top recommendations for becoming more pragmatic—and successful—in our work today. I hope you find this list useful to your situation. Please feel free to comment and augment based on your thoughts!

1. Use induction. Induction is defined as “the process of deriving general principles from particular facts or instances.” What this means to me is that we must learn by demonstrating things to our customers, ie “get real data and feedback”. Turn that real data and feedback into something real.


2. Identify and appropriately manage all assumptions. Assumptions will kill you and your organization can’t afford to run on them. Make sure you identify all of them, understand them and determine how to manage them. Some possible strategyies: a) document them and look the other way b) validate them with the customer either by asking a question or demonstrating your interpretation of the assumption in your work or c) (not recommended but sometimes necessary) cover them up.


3. Demonstrate as quickly as possible that you understand customer requests via the end product. Build as many of your unchecked assumptions and thinking into the end product so you can get feedback from the customer as soon as possible. Make sure that you are flexible in listening to the feedback integrate those changes into the next iteration.


4. Have your work process be the way that you continuously demonstrate your understanding of the customer’s requests. Be flexible. It’s okay to be wrong. Listen hard and show them that you understand through demonstration.


5. Your work backlog will grow and you need to manage it. Develop a way that you manage the things that are requested but you’re not currently doing. Expose the work backlog to your customer and work with them to set aside chunks of work that you’ll get to. Prioritize the work between what’s immediate and what’s future. Understand what’s future but don’t spend any time working toward it. Limit feedback until the next demo with the customer if at all possible.


6. Don’t over-engineer. Building too much “value” into the product will kill you. Only put in “hooks” architecturally for future possibilities but never spend too much time engineering toward them until the customer decides they are in scope. When it’s time, you’ll have a platform that makes you ready.


7. Ensure you have the right contract type setup. Using an iterative process like that which I’m suggesting is difficult. Be prepared for the rigor an negotiation required to engage with someone in such a structured and regimented manner. Make sure that the contract terms align with your goals.


8. Be clear with everyone about what the process is and isn’t. Listening, demonstrating, and responding sounds like a simple process to follow but you have to make sure that everyone gets it. Teach and coach everyone on this repetitive process so they understand their role in supporting the next increment and improvement overall.


9. Advocate less and inquire more with the customer. Your goal with the customer is to listen to their needs more and uncover more and more work that they want you to do; open up a realm of business opportunity.


10. Keep some things secret. Don’t share all of your best ideas with the customer. You may want to keep some things secret for when the time is right for a surprise.


11. Advocate more and inquire less with your team. Your team is there to support you. They need to be listened to and understood. So much innovation can come from your team if you can figure out how to integrate it and suggest it to the customer in a fair way.


12. Building products is a partnership and shouldn’t be a dictatorship. Seek to bridge the gap between all parties involved but let the product owner (customer) be the ultimate decider.


13. (Removed as it was a duplicate of a point made above. Was: "Build “hooks for the future” into your current solution")


14. Elaborate on assumptions but only when the customer thinks it’s time. Your job is to build to the “immediate core” of what the customer is stating as their need but also to add “hooks” (not total solutions, rather starting points) for what you think they could mean.


15. Use the Kano Model to think through a balanced approach with your customer. The Kano Model is a handy tool for considering customer satisfaction. Make sure you’re always doing what qualifies in the customer’s eyes but keep them excited and engaged with performance and excitement features at the same time. If you can keep them engaged enough, then not too many features should be “qualifying”.

I hope you found these tips helpful. Please offer your comments.

3 Keys to Making Your Product Development Effort Successful

Through Six Hour Startup--where a new web-based product is developed and launched by a team of 20+ strangers in six hours--I learned what it takes to lead in chaotic situations. At BluWater Consulting I was Scrum Master to three concurrent software development projects and learned that there are a few key principles required to succeed: strength, (team) commitment, systems thinking, and creativity. Based on this I define agility as “a willingness to seek, accept and integrate feedback as frequently and rapidly as possible”.

In my opinion, there are “3 Keys to Making Your Product Development Effort Successful”:

1. Develop relationships with key suppliers. Rely on your suppliers to coach you on the best tools and methods for your organization and situation. Invest the time and resources necessary to procure what’s required to lead the change you seek! At a minimum, put up a whiteboard to track each project and use “stickies” to track the work as it flows through the process. Ensure that there’s shared accountability within the team and the roles of shepherd, pairing partner, and QA are clear. Synchronize your stickie-note process with a powerful information system so you can get real-time statistics, detect, and analyze process variances.


2. Identify and establish the leadership required. The program will only succeed if you have the support and understanding of the right people. This requires persistence and a strong will! Seek to continuously understand who is in charge (the team) and govern as required. Make the roles of Scrum Master, Product Owner, etc. clear but don’t be surprised when they change.


3. Make sure that your team gets it. There are some critical things that your team has to understand before they’ll do well in an agile process. One example is understanding the difference between burning time “up” (tracking actual hours in the case of work that involves uncertainty or risk) and burning time “down” (tracking how much time is left against work that can be reasonably estimated). Make sure that your team has the training it needs to succeed, move forward, and communicate with each other effectively.

If you would like help getting your project or practice off the ground, I'm happy to quickly assess where you're at and help you get get to where you’d like to be!

Managing Schedule Risk in an Agile Scrum Process

Managing time and the team in an agile scrum project is difficult but it's gotta get done. In all projects, we have to estimate what we're going to do and try to get it done. If we aren't getting it done, we have to either work more and meet our deadline or communicate to our sponsors how things are going to be different at the deadline or move the deadline out. It's all about delivery and customer service in the end. At any rate, typical software projects have two distinct parts, each requiring their own management techniques:

1. New feature development



2. Bug fix, customer service and support

Since we have to manage both of these types of work, and they behave very differently, we need to develop a language around getting things done to support effective communications within the delivery team and to our customer community. The choice we use at my company is Agile/Scrum, where we plan and deliver our work in 2-week increments called sprints. By doing this we're able to execute and significantly re-tweak our process every two weeks. We are given a quote-unquote new lease on life every two weeks; it should be a refreshing way to work and partner.

In our methodology, new feature development is handled by the Agile/Scrum methodology burndown method to track work. The burndown method is the typical agile/scrum way of tracking work: we create a definition of done in terms of scope and features, then estimate how many hours we think it will take to do it. Between the ScrumMaster and the team, we track how the hours are burning (up or down since maybe your last estimate wasn't great and there was unseen work) on a recurring basis and if we think our velocity is what it needs to be. If the velocity starts to slow down, the team addresses how to remove impediments and get the velocity up to such a degree that the project is scheduled to finish on time. If things don't go well, we figure out how to mitigate the risk with the customer.

Burnup is a different but important concept to understand and use to manage our work. Our example of using burnup here is a 50-hour max promise to the customer to deliver customer service. We don't have to provide all 50 hours in our example but we do want to know how much of this time we're spending because it's a distraction to the other part of the project since we can share resources and sharing resources is efficient. This method requires tracking ACTUAL hours spent, which is different from the burndown method. Note that this is a key difference from burndown, where we really only care about how many hours are left. We can see how many hours are left on a burndown type of project but what's potentially left on it is certain, whereas what's left in burndown is only estimated.

These two methods of burnup and burndown are two very different ways to think about work: the former is a picture of what's necessarily remaining and the latter is a guess of what's left. The latter is best mitigated by good planning and knowledge of what tasks and how much time is required to get to "done". Together, we use these two techniques to manage risk and communicate effectively.

Conclusion: We Can Now Manage Projects That Burn Time Up and Burn Time Down

By understanding how these types of work are different and how we can manage each, we're able to develop and speak a language about risk and progress making our velocity increase and our projects more fun.

Interface of Your Choice for all Media Types

I want an API that does this:

Video.SaveAsAudio() - http://www.softpedia.com/get/Multimedia/Audio/Other-AUDIO-Tools/Free-Video-to-Mp3-Converter.shtml
Video.SaveAsText() - http://everyzing.com/
Video.Search(string TextToFind) - http://everyzing.com/
Voice.SaveAsText() - http://jott.com/
Voice.Search(string TextToFind) - http://everyzing.com/
Text.SaveAsAudio() - http://www.naturalreaders.com/

Recording the Web

Just found a free new tool called Braincast (http://www.blogger.com/www.braincast.com) that allows anyone to call a number from their phone and make a recording. The service then emails you a WAV file of that recording that you can post online. Pretty cool. Great for bloggers or podcasters! Here's a file I just recorded: http://tr.im/2xrg