← Older posts

Get Reworked

In its dust jacket, it claims to show you a better, easier way to succeed in business. Rework (http://www.amazon.ca/Rework-Jason-Fried/dp/0307463745/ref=sr_1_1?ie=UTF8&qid=1336313211&sr=8-1), a New York Times Bestseller book by Jason Fried and David Heinemeier Hansson, explains that to succeed in business you must stop talking and start working – and promises to show you the way. A tall order, but it is backed by the success of the authors with their revered 37signals (http://37signals.com/) suite of collaborative productivity tools and their popular blog, Signal vs. Noise (http://37signals.com/svn).

I love this book for its no-nonsense, pull-no-punches messages. I recently reread it and thought I could write about some gems that I think apply well to technology and consulting. Here are four that I can relate to.

Embrace Constraints

“I don’t have enough time/money/people/experience.”

I know, I know, these words never come up on your projects. The authors suggest that less is a good thing. They say that constraints are actually advantages and that limited resources force out the waste and encourage creativity. As a consultant I live in this reality most of the time, with pressures to deliver a system or a plan sooner, to do it with a smaller team, or with cheaper hardware or software. On a recent engagement, the team shifted to two-day sprints in an effort to go through five analysis, design, develop, test cycles in just two weeks. We all thought it was a little bit crazy, but I would argue that the results were of higher quality than had we spent twice as long and allowed the feature set to bloat. In my experience, constraints are real, but with the right attitude and leadership, they can be motivating.

Illusions of Agreement

“The problem with reports and documents is that they create illusions of agreement. One hundred people can read the same words, but in their heads, they’re imagining a hundred different things.”

I’ve been lucky to have a career in technology with variety, but I’ve filled a developer role the most. Where this hits home for me is when building a system based on Use Cases provided by an analyst. Analysts, go easy on me, I’ve filled that role too, I know how frustrating it can be when some hapless developer builds a bungalow rather than the Taj Mahal that was imagined. The authors suggest that it is prudent to remove abstraction as much as possible. In my experience, if one can build a mockup, a prototype, or a proof of concept, one can build consensus and discover misunderstanding much faster than words, tables or flowcharts can. At the very least, team members should imagine ways to come to real consensus and never be afraid to say “I don’t understand. Show me again.”

Your Estimates Suck

“Estimates that stretch weeks, months, and years into the future are fantasies. The truth is you just don’t know what’s going to happen that far in advance.”

My belief is that this statement is a bit too bold. On projects I’ve been on, the trend is that if you don’t know what’s happening at least a few weeks out without at least some amount of certainty, you are probably destined for failure; it is said “a failure to plan is a plan to fail.” Still, the sentiment rings true. We almost always think about best case scenarios and we don’t know what we can’t know. I have heard it described as a “lost keys” scenario: You get up in the morning, ready to head to work, but you can’t find your keys; imagine your Project Manager asking you how long it will take you to find them. Still, without estimates, planning any kind of deliverables involving a contract is unimaginable, and I wouldn’t hire a contractor to build my new garage who couldn’t give me an estimate. The solution is to estimate in the smallest chunks you possibly can. You’re still going to be wrong, but you’ll find out sooner, adjust sooner, and be able to communicate in terms that all parties can understand. The impact will be far easier to absorb.

Four Letter Words

“There are four letter words you should never use in business… need, must, can’t, easy, just, only, and fast.”

The authors argue that these words create a black or white situation and should therefore be avoided. 

I enjoy this because consulting is often about compromise. I have worked on more than one project where we had taken over after one or more failed attempts. In each case, I believe our team was able to succeed because we avoided four letter words and asked “Can we get away with…”, “Which is more important?”, “What’s the best result?”, or “What else can we try?” From another angle, I’ve definitely made the mistake of uttering “easy” and “fast,” and my project managers and teams will tell you it was often anything but. I’ve learned this lesson. Be flexible and resourceful. Look for the grey in any tough spots. Oh, and you probably shouldn’t use the other four letter words either. 

In tone, Rework doesn’t take itself too seriously, and you won’t find anything revolutionary. But if you think on its points and relate them to work you’ve done or are doing, I’m sure you’ll pick up some quick wins.

 

Managing Remote Teams and Projects

• Remote customers/users – Sometimes the team might be working in a remote development center set up where you and the project team are in same location and the customer is in a different location. You must have regular face-to-face meetings with the customer(s) in the beginning to establish the trust and expectations. The communication must be constant and should contain formal reports and informal updates. It is especially true in a remote situation that you will need to establish relationships with senior users in addition to the sponsor. Ideally, lot of communication should take place with end users throughout the life of the project.   
• Set ground rules and expectations for team – Not everyone is comfortable (especially at the   beginning) working with people they have never seen or met. On many occasions there might be cultural as well as organizational differences which you as the PM must respect and ensure that everyone on the team respects those differences.  You should set ground rules in the very beginning to ensure mutual respect and equality of opportunity for everyone to present thoughts and share knowledge across the team. You will need to encourage use of all communication methods available. 
• Set up the teams based on similarity of work – If possible, assign team members work which they can do with others at the same location; for example, having all testing resources at one location will help them benefit from each other’s experience and knowledge of the application.
• Protect your distributed team – Sometimes team members may be allocated to the project on a part-time basis and, with their remaining time, working on other commitments for which they report to local (functional area) management. This, on some occasions, can lead to your project taking lower priority. Regular communication with expectation setting and monitoring with the remote team is one of the ways to ensure that this doesn’t happen. This situation becomes more complex when there is a matrix structure involved and functional managers are collocated with the team. You as a PM always need to work out clear (formal or informal) terms of references (ToR) with the functional managers. 
• Do not be a distant “ruler” – This sounds like a medieval term, however it is still true at a psychological level. When you have a team at a location with the manager, the teams at other locations can sometimes feel like they are being “ruled” from a distant city. This can bring down team morale and trust level like nothing else. As a PM, you will need to ensure that the team local to management is never perceived as being favored. A PM of a distributed team should never identify himself as belonging to specific location. Make sure you visit each location at least once during the life of the project; the sooner you meet the teams face to face the better it will be. A success celebration at one location needs to have similar celebrations at other locations; you as a leader might have to work hard to achieve this. Different locations might have different holidays, so you will also need to maintain a holiday calendar. 
• Time zone difference – More often than not there will be a time difference between various locations. It is easy to manage a time difference of a couple of hours by having conference calls during the “core” part of the day. However, if you have more than 4-5 hours of time difference, then the practical solution is to have various locations work on a slightly early/late schedule on a rotation basis so that the pain is shared by everyone. There is no silver bullet for this scenario and needs to be managed on a case by case basis.
• Collaboration tools – There is a vast collection of technologies which enable distributed teams to share information and solve problems together. You will need a conference call facility and might need more than one “virtual” conference room depending upon the size of the project. Products such as GoToMeeting or WebEx will be needed to enable people to share desktops. If needed, you can also make use of video calling facilities like traditional video conferencing, Skype, Google+ hangouts, etc. You will need to setup file sharing mechanism for the project team like shared folders, or collaboration sites like SharePoint or some other tool. Get your people headsets for desk phones because telephone calls will be more frequent than when the team is collocated. 
• Communicate, Communicate, Communicate – A common theme in all of the above points is communication. Communication in general can make or break a project team and the impact of a good or bad communication strategy is amplified in a distributed team setting. Both formal and informal communication has its place in a distributed setup. Many times, casual one to one discussions can bring a lot more issues to your attention than formal meetings and reports. You will need to make sure that the calls do not stretch any longer than they have to, have a clear agenda and stick to it. Ensure that people know in advance what information they need to bring to the call so they don’t end up looking for it during the call. 

In summary, the soft leadership skills of a PM become even more important in a distributed setup as a PM must form and maintain a culture of openness and mutual respect, as well as promote team culture across locations.

Further reading

• Conference call tips – http://bloggertone.com/technology/2010/08/30/creating-a-successful-conference-call/
• Managing teams across time zones – http://www.inmagazine.cgsm.org/indepth/hr-perspective?p=all

Getting Things Done with OmniFocus

“Being cool, you’ll find, is a state of mind – a refreshing attitude.” –Mountain Dew ad

It’s amazing how many productive things get done while putting off something else – usually a much bigger and uglier something else. I’ve always wondered if there was a correlation between the rearrangement of living room furniture and tax season. I know that working on this piece was the perfect opportunity to get caught up on this season of “Game of Thrones.”

Traditional time and task management tend to focus on priorities and to-do lists. In his book Getting Things Done, David Allen asserts that human minds tend to work a certain way and that the old ways are usually doomed to failure in the long run.

If we imagine a pond of still water, we can easily envision the effect that dropping a pebble of any size, large or small, will have on the stillness of the pool. We can anticipate the reaction with clarity and can prepare for it. In contrast, a maelstrom of noise and chaos is difficult to manage and rife with stress and wasted energy. We want to reach that “productivity Happy Place,” as Chubbs Peterson used to say.

David Allen prescribes a method called “Getting Things Done” (GTD) to achieve the mental focus needed to deal with our never-ending to-do pile. In the modern age, it just so happens that there is no shortage of mobile apps ready to assist us by managing our workflows. One such app is OnmiFocus by The Omni Group, and we’ll look at an overview of GTD in that context.

Step 1: Collect

Getting started with the “Getting Things Done” philosophy involves the typically non-trivial task of performing what is essentially a core dump of all concerns of which one is currently aware. The idea is to capture and externalize this information into a trusted system leaving the mind to get on with more focused pursuits.

What needs to be captured are the items that you more or less need to get done. As you can imagine, this is no mean feat. This can be anything – organizing the shop tools, constructing a new light saber, world domination, and so on. We’ll worry about the details later.

When initially capturing these items, the most important thing is to get started and capture as much as possible. A complete compilation of outstanding items can take time as new items are uncovered, recollected or introduced as a natural course of events.

As new items arise, they are best dealt with as quickly as possible, lest they start to pile up and cause noise and distractions.

New items are added with the Quick Entry button. The new entry can be fleshed out with further detail on initial entry, but only a title is required, then the entry can be saved. This handily makes adding new entries as painless as possible, which is good because new items will always arise as the cycle continues. The spice must flow.

Step 2: Process

The next step is to start processing this collection of items. To keep things moving along in your new GTD lifestyle, the app launches with a prominent Inbox view representing unprocessed items. Ideally this Inbox is maintained at zero items as new items are moved into the various workflows.

One option at this or most any other stage is to simply delete the item altogether once you’ve decided that an item that’s been nagging you is going to be banished forever, never to be completed nor thought of again. The importance and consideration of this decision cannot be overstated. It’s important for a healthy intellect to maintain goals and aspirations, but many times these are pushed aside for the more mundane and unimportant matters that linger on out of sheer momentum or neglect.

Other items may be trivially (or even non-trivially) completed at this stage and simply checked off before they have a chance to complicate your mind. Sha-la-la live for today!

Sometimes a task will have to wait for some future event, such as delegating the task to one of your many minions altogether. A neat feature is the ability to defer the item’s start date to some point in the future. The item will be greyed-out and less prominent in some views while hidden in others. This is very much in the GTD philosophy. There are many reasons to defer an item in this manner. The item might not be actionable today or it may be a more abstract goal you might be considering for some time in the future. What matters here is that the items are captured and will be reviewed at some point and not forgotten.

Every item is accompanied by a large, handy check box for you to check off as you get things done – isn’t that the goal after all? GTD encourages that small tasks be performed or scheduled quickly to ultimately clear them out of play. For the rest of the Inbox items, the next step is to transform these items into their next actionable form. To keep things simple, there are two general flows – to fold the item into a project or into a context.

Step 3: Organize

GTD defines a project as any item which you intend to finish, but may be aided by some decomposition into subtasks. After all, it’s easier to take on a large task one step at a time than to regard it as a whole. This way progress is made on the larger goal while staying sharply focused on more manageable tasks. You’re not going to organize a second Death Star with the project capabilities of this app, but you can easily add new items to projects or slot Inbox items into existing projects as they arise. A key to the GTD workflow is defining a Next Action for project items. This is accomplished implicitly by simply rearranging project subtasks with a standard edit/drag control.

As the saying goes, “Out of sight, out of mind.” The GTD philosophy exploits this to productive ends with the concept of Contexts. Some items are naturally accomplished together because they are physically or thematically related, such as “the Grocery Store” or “At a Computer” or “In Cloud City.” Items can be project actions and still be co-located contextually with disparate project items so they can be quickly viewed from an optimal frame of reference.

Step 4: Review

Ultimately, the weakness of traditional to-do lists is their limited window of usefulness. They’re generally relevant for a single point in time and eventually subject to diminishing returns.

A large part of unburdening the mind from distractions is establishing a mental contract with your own intentions. If it’s understood that each item will be visited in due course, you’re less inclined to worry about various random tasks at a given time and are able to stay focused on the task at hand. This ensures that projects and actions fit into the larger scheme of things, like having a strong quarter or meeting academic goals, for example.

GTD contends that stress and failure are created by the mental exhaustion of juggling too many concerns at once, whether one realizes it or not. The idea is to focus on manageable items and thereby affect much greater impact and effectiveness on any single task. Only by constant review can the quality of the captured items be maintained.

OmniFocus enforces constant review of task items with Forecast and Review views. Forecast displays items which are due within the next week. Review enables items to be periodically visited until they are completed or discarded. The idea is to not let items get lost in the system while not being constantly bombarded with them.

Step 5: Do

This is where the rubber hits the road. If you’ve made it this far, it’s basically a game of task Tetris. You have full awareness of the present context. You’ve already identified the next actions which are doable, and are also better equipped to gauge your own time, energy and priorities. All that’s left is the doing.

The Beginning

OmniFocus is an app dedicated to the Getting Things Done methodology. It enforces the collection, organization and review of tasks. The GTD method relies on these elements working in tandem to achieve its goal of quality productivity.

The app adheres to the broadest mechanics of GTD while conceding to its goals and capabilities as a mobile app. OmniFocus features some basic annotation for action items, but is not suitable as a store of reference material, a significant component of GTD. OmniFocus does what it does with clarity and simplicity without overreaching and coming up short.

Getting Things Done was published at the right time when it offered much needed respite and insight to many beleaguered knowledge workers. Like any methodology, ultimately the proof is in the doing. David Allen’s greatest lessons are to be unafraid to discard tasks (sometimes forever), and to do the rest to the absolute best of your creative ability. Make Chubbs proud!

“GETTING THINGS DONE” (2002) BY DAVID ALLEN, PUBLISHED BY PENGUIN

OMNIFOCUS BY THE OMNI GROUP

 

Scrum Puts the “Science” into “Computer Science”

“In general we look for a new law by the following process. First we guess it. Then we compute the consequences of the guess to see what would be implied if this law that we guessed is right. Then we compare the result of the computation to nature, with experiment or experience, compare it directly with observation, to see if it works. If it disagrees with experiment it is wrong. In that simple statement is the key to science. It does not make any difference how beautiful your guess is. It does not make any difference how smart you are, who made the guess, or what his name is—if it disagrees with experiment it is wrong. That is all there is to it.” — Richard P. Feynman, Nobel Prize-winning physicist, in “The Character of Physical Law”

Software development has always been the red-headed stepchild of engineering and the sciences. Software engineers are not like other engineers. When civil engineers sit for their exams, they bring well-vetted reference works with them to solve problems. These references exist because the properties of materials, and the ways that materials are combined, are well-understood. A straight design-build-test development path can work well for building a bridge.

On the other hand, software developers build solutions through the organization and use of data and domain-knowledge. While they may use established technologies and techniques such as design patterns, software developers are dealing with information – a material that is not well-understood.

Instead of engineering, software developers and stakeholders can look to science for the answer.

Very simplified, the steps of the scientific method are as Feynman outlines them in the quote above:

1. Find a problem.
2. Guess an answer.
3. Check the guess by performing an experiment and collecting data.
4. Analyze the data to prove the guess right or wrong.
5. Repeat.

Don’t be fooled by the simplicity. The scientific method is one of the most powerful tools we have to solve problems.

When we design and build a software product using science, we can either build it in one big expensive experiment or in a series of small inexpensive experiments.

The waterfall method of software development treats a software product as one big expensive experiment. In the waterfall method of software development, first we try to understand all of the stakeholders’ requirements in a single big theory; then we design software to meet those requirements; then we implement the software; then we test it; and then we release it in a single big experiment. But, as Thomas Huxley said, “Science is organized common sense where many a beautiful theory was killed by an ugly fact.” We want the costs of those ugly facts to be minimal.

Scrum is a software development process that uses the scientific method in a series of small, inexpensive experiments.

The basic unit of a Scrum project is a sprint which lasts between a week and a month.

A sprint has the following steps:

1. Add to a list of requirements for a product. This is called the “product backlog.” (Find a problem.)
2. Decide what work items can be done in the sprint. This is called the “sprint backlog.” (Guess an answer.)
3. Implement the work items in the backlog and present the completed work to the product owners. (Check the guess by experiment.)
4. Review the work that was completed and not completed. (Analyze the data.)
5. Repeat.

A sprint is a scientific experiment that is in a cycle of continuous data collection and evaluation. There is nothing hidden from the product owners (stakeholders) and nothing taken on faith. In Dr. Feyman’s words, “If it disagrees with experiment it is wrong.”

At the end of a sprint, there is actual concrete work done that the product owners can evaluate and give concrete feedback to the developers. The product requirements may change. Previous work items may be deemed to be incomplete or incorrect so new requirements are added to the product backlog. And then a new sprint begins.

Each work item within a sprint also parallels the scientific method:

1. Create a requirement. This is often in the form of a fill-in-the-blank story: “As a {user} I want {do something} so that {I get a desired result}.” (Find a problem.)
2. Design the work item. (Guess an answer.)
3. Implement the work item. (Check the guess by experiment.)
4. Review the work item against the “Definition of Done.” (Analyze the data.)
5. Repeat.

Scrum is a simple yet very effective way of using structured thinking to build solutions through the scientific organization and use of data and domain-knowledge. Scrum acknowledges the simple fact that at the beginning of projects, software developers and product owners usually do not completely understand the problem that they are solving. However, through continuous experimentation and analysis, the problem is not only understood, but also solved at the same time. Many small bets add up to one big success.

New Features in VS.NET 11 and .NET 4.5

2012 is a big year for Microsoft, with a number of big product launches happening. SQL Server 2012 is out, there’s this little thing called Windows 8, and not to leave the developers out of the fun, we have Visual Studio 11 and .NET 4.5 being released as well! They are currently out in Beta, and there are a lot of great new features that are being bundled with these releases. I wanted to highlight a few of them that you should definitely check out.

ASP.NET

ASP.NET has become quite fractured in the last few years. Saying you’re developing in ASP.NET might mean Web Forms, MVC, MS Ajax, jQuery, HTML 5, etc. With the next release, there are still a number of options, but Microsoft is trying to pull things together to be more concise – a “One ASP.NET” as Scott Hanselman mentioned in a recent blog post.

One of the major additions is Web API. This is a framework for building HTTP services on top of the .NET framework, and is part of MVC 4. This fantastic feature makes it easy to expose web-based services (but note, these aren’t web-services in the traditional sense) without the overhead of WCF. Plus, it leverages the same development model you use for web applications with MVC 4! In their messaging, Microsoft is pushing the idea that HTTP is a valid application-level protocol, and it will be interesting to see the adoption of this concept once the final version is released.  For a good discussion of WebAPI, see Brad Newman’s blog: “ASP.NET MVC 4 Web API: HTTP Isn’t Just For Browsers Anymore” (http://ig.obsglobal.com/2012/03/asp-net-mvc-4-web-api-http-isnt-just-for-browsers-anymore/).

To see a list of all the new features for web developers, go to http://www.asp.net/vnext/overview/whitepapers/whats-new.

WCF

WCF is a funny technology, as you can spend just as much time configuring services – if not more – as you do writing code for them. For VS.NET 11 and .NET 4.5, there are some great new productivity features. I want to highlight a couple.

For one, the amount of generated default configuration text is greatly reduced. Instead of putting in a huge block of config that you may not want or that might even set values counterproductive to how your service needs to run, you’ll now see only minimalist config settings by default.

Also (and this is a big one) there’s now intellisense and tool tips INSIDE THE CONFIGURATION FILES! That’s right, you can now get the aid of intellisense as you work within WCF configuration files – greatly reducing the headaches and frustrations typically associated with having to make changes to a WCF service config.

WPF

Contrary to what you may have heard, WPF is not dead at all and gets some fantastic feature additions in the next version.

In addition to a stock Ribbon control, performance and UI features are a plenty! There’s this idea of Live Shaping – having data visualization react to modifications in the data. The example given on MSDN is a stock price app (aren’t they always a stock price app?) where when a collection of stock prices change, a datagrid displaying them will automatically re-sort them based on the new values.

Other enhancements include binding to static properties, accessing collections on non-UI threads, and automatically updating the source of a data binding. You can read up on all the improvements to WPF here: http://msdn.microsoft.com/en-us/library/bb613588(v=vs.110).aspx.

VS.NET 11 and .NET 4.5 is Not Just About Metro

Of course, Visual Studio 11 also brings the Metro paradigm to developers in anticipation of Windows 8. But there’s so much more that’s going to be bundled with the development tools and the update to the .NET 4 framework that developers shouldn’t get focussed on the new and shiny. For developers working in traditional web or desktop application and service-based architectures, there are a ton of new features that shouldn’t be missed! I’ve just scratched the surface with what I’ve mentioned in this post, so check out the following links to get more information on what’s coming!

VS.NET 11 Beta – http://www.microsoft.com/visualstudio/11/en-us

What’s New in .NET Framework 4.5 Beta – http://msdn.microsoft.com/en-us/library/ms171868(v=vs.110).aspx

 

Repository Pattern – Beyond the Generic Repository

Introduction

The Repository Pattern is a great way to extract the low level data access code from your business logic. This separation of concerns also eases the testability of a system. Repositories could either use web services, databases or even in-memory collections, all without your business layer even knowing about them. Persistence ignorance is an important aspect of Domain-Driven Design and the Repository Pattern will help you attain this premise.

A number of posts already exist explaining the Repository Pattern, but most stop at the concept of the generic repository (or IRepository<T>). In this example, we will explore concrete implementations and important aspects to consider when implementing the Repository Pattern.

1) Favour Composition Over Inheritance

So, you have created a base generic repository for an NHibernate concrete implementation (NHRepository<T>) and now you want your repositories to use it. The logic progression would be to extend your base repository (NHRepository<T>) along with your aggregate specific interfaces (i.e., IMovieRepository). Bad! By doing so, you are exposing all of the base repository’s details and behaviour to the subclass that you might not even need. Do you really need a Save? Do you really want to expose the IQueryable from the Find and risk queries being created in other layers of your application? A better approach would be to inject an IRepository<Movie> in your concrete repository and delegate the base repository calls to it. Doing it this way, you can also inject any types of IRepository<T>, decoupling the dependencies on the NHRepository<T>.

Here is an example of the first (bad) approach using inheritance:

And then here is a better approach using delegation:

You can see how the class MovieRepository doesn’t extend the NHRepository<Movie> anymore but instead is being injected by an IRepository<Movie>. Not only doesn’t it expose all of the parent’s details, but it can also be used with any types of repository.

2) Exposing the IQueryable (vs the IEnumerable)

Now, if you are using a specific data source like SQL Server along with an ORM tool, you can easily expose the LINQ IQueryable interface through your repository. This can help to optimize your queries when they are converted into SQL statements against the database. By using the IQueryable, you can further refine your query that will be executed in the database. Contrary to the IEnumerable, where you would need to load all the objects in memory and only then apply some filtering.

For example, if your generic repository exposes an IEnumerable and you wanted to return the top 10 items, your repository will need to first load all the items in memory and then take the top 10.

But, if your generic repository exposes the IQueryable, the expression will be translated to the appropriate SQL statement and load only 10 rows from the database into memory.

However, the IQueryable should be kept at the Repository layer only. Exposing IQueryable past your repository increases the possibility of an error occurring in other layers of your application. A developer could modify the query at the UI layer, retrieving entire tables from the database and bringing the entire system to a slow state. The “GetTop10″ method in the above example should still return an IEnumerable to stop the IQueryable from bubbling up into the business and UI layers.

Summary

This post covered two simple concepts about the Repository Pattern which are often neglected when building the data/infrastructure layer. First, we covered why you should not extend you IRepository<T> but instead use delegation. Second we looked at the debate of exposing an IQueryable versus an IEnumerable and why the IQueryable is favorable when “shut” at the repository layer.

What is Successful Change Management Anyway?

If you grew up in a large family setting, you likely learned early on that each individual deals with their environment in totally unique ways. I was fortunate to be the youngest of a very large family and well positioned to observe how all my older siblings dealt with change. Some sought change and instigated change, some accepted change readily, while others approached change very cautiously. Their characters have not changed much over the years – these traits are simply part of their DNA.

Consider for a moment that when an organization embarks on a significant business technology project, they may be introducing change to 100, 500 or 1,000 unique individuals, and you start getting a sense of what you might be up against. Some will readily accept change, some will need time to assess and internalize the changes at hand, while others may decide to reject the changes outright for personal reasons.

The issue of how to manage change successfully has taken on added prominence in recent years, as organizations grapple with the challenges associated with the ever increasing operational changes necessary to remain competitive within a global economy. But what exactly does “managing change successfully” mean within the context of technology changes?

Business technology changes have typically been measured on three fronts: time, budget and scope. In recent years, a fourth metric has entered the equation: end user adoption. On the surface, these metrics appear to provide an accurate assessment of a project’s success. After all, if a technology project delivers all the changes identified within scope, on time, within budget and the new system is being used, it’s a success, right?

Not necessarily.

A better metric for measuring success is one that answers the question “Has this project created the business result it was intended to?”  And to answer that question, one needs to clearly understand why business leaders approved the project in the first place. The traditional metrics of scope, budget, time and adoption are all relevant, but mean little if the changes don’t materialize in the business results intended. It’s not uncommon for business leaders to accept a cost increase or a delayed implementation and still deem a project successful if it delivers business results. In short, delivering business results is the only metric that really counts and the one that will resonate with business leaders.

This has serious implications regarding how to successfully manage business technology changes. It means that the business case supporting the change must be clearly understood by all project team members as well as all business stakeholders. It means that business results must remain at the core of the decision-making process throughout the project lifecycle. And finally, it means that the targeted business results identified at the start of the project can be, and are being, measured at some point following completion of the project.

In summary, here’s a quick recipe for successfully managing change on business technology projects:

1. Start by identifying and gaining formal acceptance on what business results are expected by the business leaders (Critical Success Factors).
2. Next, identify and gain formal acceptance on how, when and by whom these business results will be measured, both during the project lifecycle and following completion of the project (Benefits Realization).
3. Fold in project management and organizational change management best practices to ensure that all stakeholders clearly understand why the changes are being undertaken and what their roles are relative to supporting the change.
4. Recognize that each stakeholder is a unique individual that will process change in their own way, and ensure that change is managed at both the personal and organizational levels.
5. Keep your eye on the ball! Timelines, scope and budgets often change through a project’s lifecycle, however targeted business results rarely do.

In the end, the business results envisioned by business leaders at the start of a technology change can only be realized through the support and endorsement of the people who are being asked to change the way they do things on a daily basis. Although change can introduce a plethora of emotions including anger, disorientation, confusion, sadness and even depression, employees will rally around change if they understand why the changes are required as well as what their role is in achieving the results. Successful transition requires that all aspects of project management and change management be aligned and focused on delivering business results. The traditional project management metrics of time, scope, and budget as well as user adoption are all important, but must be managed within the context of business results.

 

Polyglot Programming

Nikon vs. Canon. Cubs vs. White Sox. Java vs. .NET. These debates have polarized camera buffs, Chicago baseball fans, and software developers so fiercely that they have been called “Holy Wars,” a tongue-in-cheek reference to the passion and vitriol with which many real battles have been fought over religious differences. To be sure, arguments over technology by name or brand still have their supporters, but I like to think that many of us in the industry have moved past that. I have been fortunate to work with vets who approach problems and projects by first choosing the most effective tool or platform based on their comparative strengths and weaknesses and how those relate to the task at hand. I love this approach, and these are the practitioners I choose to emulate.

In this light, I have been exploring what has come to be known as the Polyglot Programmer, a term I first heard Neal Ford (http://www.nealford.com) use years ago at a conference I attended. Polyglot Programming embraces the notion that combining multiple languages and frameworks to solve the domain problem at hand can yield the most efficient results.

We are seeing this play out in many ways. The two dominant enterprise development platforms, Java and .NET, have both grown to support development in many different languages. The Java Virtual Machine currently supports Clojure, a functional Lisp dialect, scripting languages Groovy, Rhino and JavaFX Script, and Scala, which is both object-oriented and functional. It even supports popular dynamic languages such as Ruby and Python through JRuby and Jython implementations, and aspect-oriented development with AspectJ. A less well-known language called Oxygene, with roots in Object Pascal and Delphi is also supported. These languages each offer wildly varying strengths and weaknesses and allow you to build a system using any combination, all running against the same deployment environment.

.NET brings even more to the table, offering support for no fewer than 50 languages, in categories like those in Java plus more exotic animals I hadn’t heard of such as Nemerie or Cobra, and older, formerly popular languages such as Fortran, Cobol, Smalltalk or Ada. Check out the full list for yourself if you are interested (http://en.wikipedia.org/wiki/List_of_CLI_languages).

More evidence for the polyglot approach can be seen in web programming going back nearly to the birth of the browser. Since Javascript, CSS, and Java applet support was added to native HTML, you’d be hard pressed to find many web projects of appreciable size that didn’t mix some combination of these with languages such as XML for configuration and SQL for the database – at a minimum.

I would argue that this explosion of languages is primarily a result of organic growth. Enterprising developers have tacked onto existing environments as needed – and some ideas have caught on while others disappeared. The multiple-language paradigm has snuck up on us, particularly on web developers. I believe that the industry now has a great opportunity to capitalize on this growth by making more tactical decisions about how projects are implemented that can take us to a new productivity level. But we must be prepared, for the story is not all good news.

Certainly, there is a cost to the polyglot approach. Debugging can be harder, testing can be harder. Time spent wiring up all the pieces can be time consuming until it becomes a familiar pattern. Taking the idea too far is a pitfall we must avoid. It’s easy to argue that two or three languages would offer up the tactical advantages of each language without excessive overhead, but it’s even easier to argue that wiring up 10 languages to solve one problem most assuredly is not a good idea!

We must strike a balance. Approaches such as Test Driven Development and evolving build and provisioning tools will help make these approaches easier. There is no doubt in my mind that this area is one to watch.

I believe that taking the Polyglot approach to problem solving and system architecture is one that all developers should be thinking about. I suggest you take a look at the platform you are most familiar with. Are there other languages you could be taking advantage of on your existing deployment platform to be more efficient or to open up new solutions for your clients? Are there certain classifications of problems where your solutions feel forced or don’t quite seem to fit, and you really prefer a more elegant, maintainable and economical approach? Have you considered another language?

Polyglot Programming Resources

• If you like to read, Bruce Tate wrote Seven Languages in Seven Weeks (http://pragprog.com/book/btlang/seven-languages-in-seven-weeks), where each section approaches a problem and applies techniques that best showcase one of seven languages. Following along in the book will pace you through each of these.
• If you prefer podcasts, a great piece on Hanselminutes last year features Ivan Towlson talking about writing an app with C#, F#, Javascript and Ruby (http://www.hanselminutes.com/277/polyglot-programming-and-net-lessons-learned-with-ivan-towlson-from-mindscape).
• Expected in June 2012 is another book titled The Well-Grounded Java Developer: Java 7 and Polyglot Programming on the JVM (http://www.amazon.com/gp/product/1617290068/ref=as_li_ss_tl?ie=UTF8&tag=bookwaspcom-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=1617290068). This book promises to demonstrate techniques that the Polyglot can harness in Java 7.

 

Right-Sizing UX: Running With Scissors and Making It Work

Traditional UCD-based UX tasks are thorough and weighted toward “making sure.” They tend to work well in a waterfall methodology because the model supports the “plan twice, execute once” philosophy.

I feel the need for Speed…

1. Agile and Lean Programming

A lot of organizations are adopting Agile, Extreme Programming, RUP, etc. as ways of shortening release cycles and reducing costs. This challenges UX practitioners – we’ve had to re-think how we integrate UCD in mini-cycles.

The motto here? Speed.

2. Innovation Economy

With the recent economic challenges, successful companies are those who partner with their customers to create the type of innovation that their customers want and need rather than doing more of the same old thing. This “freshening” of the business model requires that UX practitioners focus on facilitating innovation and co-creation.  In this economy, companies live and die based on timing.

The motto? Speed.

3. New Platforms

UX practitioners typically use shortcuts based on what we already know. While the pool of knowledge about mobile users is growing, we still don’t have the rich tribal knowledge for the various platforms that we did for desktop/laptop users. Because this is a new, exciting space to work in, lots of people are doing it. It’s important for these businesses to be first AND best.

And we’re focused on? You got it! Speed.

Running with Scissors

Because speed is one of the major themes in UX changes, our focus has been on adapting our processes to keep up.

How? The short answer is: Know the processes so you know where you can take shortcuts.

And, you’re in good company. There are a number of talented people out there who are working through the same issues. Some of the biggest are:

Lean UX

This is one of the most exciting changes I’ve seen in UX in a while (since emotional design, in fact).

Jeff Gothelf has been really vocal about Lean UX and what that means. He’s written a number of articles and blog posts recently about this, and has just released a book. In a nutshell, Lean UX puts the focus on designing great experiences rather than creating documents.

In Jeff’s words:

The process in a nutshell? Do this every five days (Jeff’s diagram):

Because you’re repeating this every five days, the failure points become clear really fast. You’re constantly validating the designs, so the developers can have the confidence they need, and the entire process is transparent because the whole team is involved at various stages.

Jeff’s links:

• Jeff’s blog: Perception is the Experience
• Lean UX and Agile integration
• Lean UX in Smashing Magazine – Check the section aimed at consultants!
• Slideshare.net’s How To for Lean UX

UX + Agile

Lean UX works great for Agile projects. There’s a great case study from TheLadders.com.

There are other philosophies around including UX in Agile as well:

• Prototyping as the Agile power-tool
• Use parallel track development to work ahead and follow behind
• UX as the gatekeeper

The bottom line for each of these philosophies is this:

• Involve the user at all stages
• Deliver prototypes
• Simplify the process, lighten the tasks

Entrepreneurial UX

This is new. So far, at least, it’s kind of a confluence between the upcoming generation’s response to the economic crisis, social media, and the new generalists.

So far, it’s mostly an idea (and a BUNCH of job postings) rather than anything formalized. A few organizations are aware of this and are attempting to incorporate it into their vision:

• LUXr: (Janice Fraser has a great slide deck about this)
• Eric Reis: the Lean Startup Movement: his work is really similar to what Steve Krug discusses in Rocket Surgery Made Easy.
• Bootup.com: they host events for entrepreneurs, and a focus this year was around UX.

Fail Fast, but keep Moving

We can’t wait to see how it’s going to turn out, because our projects are due now. The best thing we can do is to move forward. One of UX’s mottos is “Fail fast.” We’re a natural group to try new things and learn from our mistakes.

My advice is to do the best you can with the time and budget you have – negotiate. Be transparent about your goals and process. Don’t stop.

ASP.NET MVC 4 Web API: HTTP Isn’t Just For Browsers Anymore

The samples and walkthroughs of the Web API in the ASP.NET MVC 4 beta have been proliferating ever since it was released a few weeks back. Rather than rehash them here, I’d like to point you in their direction and then spend some of this space to talk about the implications of this latest development in Microsoft’s web stack.

Jon Galloway’s announcement of the beta is a good start: http://weblogs.asp.net/jgalloway/archive/2012/02/16/asp-net-4-beta-released.aspx.

Scott Hanselman’s “One ASP.NET” post is also excellent: http://www.hanselman.com/blog/OneASPNETMakingJSONWebAPIsWithASPNETMVC4BetaAndASPNETWebAPI.aspx.

Henrik Nielsen’s blog is a treasure trove for getting a handle on the potential of Web API: http://blogs.msdn.com/b/henrikn/.

Finally, the official ASP.NET site has a Web API focused area: http://www.asp.net/web-api.

What you quickly discover as you survey these resources is that the Web API represents full recognition on the part of the Microsoft team that the browser is becoming just one platform among many for connecting people to information. More profoundly still is the elevation of HTTP as an application protocol that is no longer conjoined to browsers. Any kind of client that can communicate using the CRUD verbs of HTTP is a candidate for making use of the Web API; it doesn’t matter whether that client is a browser, a native phone application, or some sort of medical device that needs to communicate data in real-time.

The Web API presents developers with the opportunity to use a strongly typed object model that represents the full protocol and can host HTTP services as well as consume them. For example, the new HttpResponseMessage generics knows how to serialize model objects into the body of an HTTP response and can further negotiate content representations based on accept headers specified by the client. The HttpClient type is not tied to any HTTP server, and is optimized for handling asynchronous requests. This means that developers get to focus on the kind of application service they want without having to constrain their conceptions to the capabilities of a web browser. This results in a wider set of clients that can be supported with a single code base, and more options for hosting applications outside of IIS.

It’s an exciting time in the web stack. The eco-system of modular components that started cropping up when Microsoft opened up their ASP.NET MVC framework is exploding. Now that we have the Web API, I’m looking forward to an even richer set of possibilities ahead.

 

← Older posts