Search results: "agile" Page 3 of 8

You may be Agile, but you still need documentation

writing

One of the principles of Agile is “working software over comprehensive documentation”.

I’ve seen many project teams misinterpret this principle. In Agile, working software is valued more than comprehensive documentation. This doesn’t mean documentation is not required. If you start a software project without documentation, you are in for trouble.

Even in Agile, a small set of critical documents are required.

Below are the 4 critical documents needed for software projects:

1) Why (objectives): The Project Charter – All projects need a written document that explains why the project is needed. What problem is going to be solved? What benefits will be had by delivering the project?

This doesn’t need to be a large detailed document. The point is that the team and organization have taken the time to document clear objectives. I’ve seen teams document the MVP (Minimal Viable Product) in the charter. This helps give the team focus on the end goal.

2) What (requirements/user stories) – After creating the charter, the scope of the work needs to be captured. In Agile, the scope is documented in the form of user stories. In Waterfall, the scope is documented as requirements.

3) When (schedule):All projects need to have some form of a schedule. Whoever is paying for the project deserves this. Imagine you are considering paying a builder a large sum of money to build you a new deck. You’re about to sign the contract and the builder tells you he has no idea how long it will take to build the deck. I think the chances of hiring that contractor are slim.

4) How much (budget): The cost of the project has to be estimated, approved, and documented. Through the project, the cost needs to be monitored to ensure you stay on budget.

The act of creating these four documents will force the team to make clear decisions. The documents will also provide direction for the project.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Team building – 3 proven methods to develop trust on Agile teams

hand-reaching-out

All well performing teams have one thing in common, they trust each other. Whether it be a military team, a sports team, or an Agile software development team, trust is key. Team members need to feel that they are in a safe environment so they can do their best. They need to feel that it’s okay to make mistakes.

For software development teams newly transitioning to Agile, developing trust doesn’t come easy. Here are 3 proven methods to help develop trust on your Agile team:

Communicate trust – Let the team know that trust is foundational to success. Empower team members to make decisions and mistakes. Foster a decentralized culture of empowerment. Remember that Agile teams don’t work in a hierarchy structure. There is no project manager calling the shots. It’s the team that has the power. Team collaboration is essential for success and when there’s trust, collaboration will shine.

Now, communicating a team dynamic built on trust is just the start. Just because you’ve let the team know they can trust each other, doesn’t mean they will. The team will be wary of diving into the trust pool. Although they may not be ready to trust, you have planted the seed and the team is interested. Now is the time to walk the walk.

Walk the walk: Show vulnerability and humility – After communicating trust, it’s time to lead by example. We do this by showing vulnerability and humility. This can be difficult for some to do, but it’s absolutely essential. Let the team know when you have made a mistake. Let them know your weaknesses. By showing vulnerability and humility, it lets everyone know they can drop their guards.

If you’re collaborating as a group and a team member is quiet and not engaged, try to pull them in. Let them know their thoughts and ideas are important. Voicing opinions may be new to some team members, so they’ll need a little encouragement. By valuing team members and showing vulnerability, you’ll make great strides towards building trust.

Give it time – The last and perhaps most important need for trust building is time. There is no substitute for time and the positive effect it has on team building. Bruce Tuckman’s 1965 model of forming, storming, norming, and performing still holds true. If you are part of newly formed Agile team, don’t get frustrated when there’s a lack of trust. Just like any relationship, it takes time to get to know and trust each other.

Often, management doesn’t understand the importance of time when it comes to teams. When management shifts people from team to team, it hinders team performance. The best teams consist of people who have worked together for some time. They know and trust each other. Advice to management – Don’t form teams around projects. Instead, form projects around cross functional teams.  

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

3 mammoth reasons your Agile adoption strategy is doomed

Over the past decade companies finally realized there’s a better way to deliver software. It’s called Agile. If you work in technology, this shouldn’t be news to you. If you are unfamiliar with Agile, check out the Agile manifesto here. In Agile, the development team delivers software in short iterations. They partner with stakeholders to ensure they are building the right product. The process is faster, more efficient, and more collaborative than traditional software development.

standup-modell1

Companies have caught on to the benefits of Agile. Agile began as an organic evolution of software development. It has now become a top down order. Thou shalt be Agile! Executives and managers order their technology teams to go and “be Agile”. They force people to leave the comfort of their cubicles. They put them in a overcrowded pod with no privacy co-located work space. They bring in coaches and expect teams to become Agile out of the gate.

What is the result of this forced top down order to be Agile? Unhappy teams who give off the external appearance of being Agile, but are far from it. They have daily standups, report velocity, and produce burn down charts. They do all they can to show the leadership team that they have become Agile, and the leadership team buys it.

Here’s the thing:    

Moving from a traditional SDLC to Agile is a huge change. Combine that with the fact that people in general don’t like change and you have a major challenge. It’s more than just a changing processes, it’s changing culture. In an Agile environment, team members need to collaborate. They need to be open and honest. They need to sit near each other. They need to actually talk to each other (what a concept)!

Becoming Agile is difficult for employees that worked in isolation for many years. They may feel insecure about being transparent with their work. They may also be afraid that by being more transparent, they will have less job security. They can be quick to judge or find fault with any new processes introduced. All it takes is one team member who isn’t drinking the Agile Kool-Aid to infect a whole team.

Here are 3 reasons why companies fail when trying to become Agile:

1) They don’t invest – Making the change to Agile is an organizational investment. I’m not just referring to a time and emotional investment (which it is). I’m also referring to the cold hard green stuff. Especially for large organizations, if you want to do this right, you will need to bring in help. You’ll also need to invest in the right tool set like Atlassian JIRA or VersionOne. This is where most companies go wrong. They hire one person to come in as an Agile coach. The coach will try to help for several months. Employees are then sent to a 1 or 2 day Agile training course. 

2) They are not in it for the long haul –  Spotify, Twitter and Yahoo had success implementing Agile. They did so by bringing in coaches, implementing training, tools, and organizing practice groups. Their Agile adoption didn’t happen over a matter of months, the transition took years. Leadership teams need to approach Agile adoption with a long term strategy.

3) They under communicate – Agile adoption is a huge change initiative. When taking on any change initiative, companies tend to under communicate by a lot. It is the responsibility of the leadership team to put a communication plan in place. Employees need to understand why the company is making the change to Agile. They need to know how it benefits them and the organization. Some creative ways to communicate include emails, newsletters, meetings, focus groups, and social media. The communication needs to be happening on a daily basis. Below is a great video on communicating a vision for change. The video is by Harvard leadership professor John Kotter:

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

3 Ways To Start Your 2020 Projects Off On The Right Foot

Here we go, 2020 is here and you are ready to kick off those new projects. Before you dive right in, now’s a good time to do a quick check to make sure you are setup for success. Below are three ways to ensure you start your new projects off on the right foot:

1 – Clearly define and communicate the project goal: Many projects fail because the goal of the project is too ambiguous. If there isn’t a specific goal outlined in a project charter, you end up with a team that goes in different directions. This causes scope creep and chaos, and I’ve seen it time and time again. It is the responsibility of the project manager to work with the sponsor to define and communicate the project goal. The communication about the project goal needs to happen often for the project team and stakeholders. This will create alignment and keep everyone marching in the right direction. In my post about managing business analytics projects, I described a good framework that can be used to define the project goal.

2 – Set boundaries for non-project team members: When it comes to high visibility projects, often too many people get involved. The project manager, with help of the sponsor, needs to communicate who is on the project team. Some people may have their feelings hurt when they learn they are not part of the project, but this must be done. Only core project team members should be in team meetings. Anyone who is not a core team member distracts from the team chemistry and productivity. Often in software delivery projects, small cross functional teams are the highest performing. If your core team has more than eight people, you may need to check whether you have people on the team who don’t need to be.

3 – Plan for change: Whether you are running a Waterfall or Agile project, plan for change. Today’s project teams must be able to adapt to uncertain or changing requirements. This requires recurring retrospectives to see what needs to be improved or changed. The caveat is that if the team has a low level of Agile maturity, it is important they follow a change management process. If they don’t, change can cause big problems. For mature Agile teams, late changes to requirements can be a competitive advantage.

Summary

As we kick off the new year, take a step back and make sure your projects are setup for success. If you know that any of the three areas I mentioned have been neglected, address them now while it’s early. What you don’t want is to be 6-12 months into a project and realize the project goal was unclear.

About the Author: Mike MacIsaac is a c0-founder and principal consultant for MacIsaac Consulting. MacIsaac Consulting, based out of Minneapolis MN, provides IT Agile delivery consulting and staffing.

Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

2019 Year in Review at MacIsaac Consulting

I’m grateful for the opportunities MacIsaac Consulting had in 2019. We had some challenging IT projects to manage and I am proud that we stayed true to our core values of trust, commitment and results. There were two projects this year that stood out.

The first was a DevOps project, led by Ryan Shea, to improve dotcom operational efficiency for one of the nation’s largest big box retailers. Ryan led the initiative to migrate company applications from an internal data center to a cloud platform. The cloud computing technology uses “container” virtualization technology. This helped to drive efficiency, save costs, and increase agility. Ryan also managed a continuous delivery team that automated the deployment process for web applications.

Ryan Shea – Agile Delivery Consultant

The second project was a challenging identity and access management (IAM) initiative I managed for a financial institution. IAM is a specialty discipline within cyber security. It increases productivity while securely enabling access to systems. To deliver the project, a cross-functional Agile team was used. The team used a Kanban process to integrate 30 legacy financial systems into one centralized IAM platform (SailPoint IIQ).

Looking Forward

In 2020 we plan to grow our talent and focus on our core competency of delivering Agile IT projects. We are also looking to do more work in the business analytics space, as well as help private equity backed companies deliver IT projects.

I’m excited about the changes and opportunities to come, especially in our local area. Minnesota has a thriving business community and a great talent pool! If your company needs help delivering IT projects, or if you’re interested in joining MacIsaac Consulting, give us a shout!

About the Author: Mike MacIsaac is the founder and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master/Coach. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Gratitude

Thanksgiving is here. It is time for gratitude and reflection. A time to take a step back from work and focus on what is important.

Today I am grateful for my family, having food on the table and a roof over our head. I’m also grateful for turkey and football!

Wishing you and your family a Happy Thanksgiving filled with gratitude!

About the Author: Mike MacIsaac is the founder and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master/Coach. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

How To Avoid Common Pitfalls of Business Analytics Projects

business analytics

We live in the early stages of a data analytics revolution. Data is driving the world and transforming the global economy. In a report published in December of 2016, McKinsey estimated that “45% of work activities could potentially be automated by today’s technologies and 80% of that is enabled by machine learning.”

While big data and AI investments are on the rise, many companies are struggling in their efforts to be data driven. A 2019 HBR article found in a study that “An eye-opening 77% of executives report that business adoption of Big Data/AI initiatives is a major challenge, up from 65% last year.”

To better understand business analytics and why companies are struggling, I recently attended an executive education course at the Carlson School of Management. The class covered a range of topics including artificial intelligence (AI), machine learning, big data. As a consultant who manages IT projects, I wanted to learn about what it takes to deliver analytics projects.

What Is Business Analytics?

Business analytics is an exploration of an organizations data, with emphasis on statistical analysis. It enables companies to make data driven decisions that help gain a competitive advantage. Companies that deliver business analytics projects treat data as a corporate asset. Below are the four main types of business analytics:

  • Descriptive Analytics – Descriptive analytics answers the question, what happened? It is an exploratory analysis that provides visualization and BI dashboards. This can help companies to use key performance indicators to understand the state of the business.
  • Predictive Analytics – Predictive analytics answers the question, what will happen next? It analyzes trend data to predict future outcomes. Data mining, machine learning, model lifting, and forecasting are techniques used.
  • Prescriptive Analytics – Prescriptive analytics uses past performance to generate recommendations for the future. Optimization, simulation and rules are used in prescriptive analytics.
  • Causal Analytics – Causal analytics answers the question, did x truly cause y? Before business decisions can be made based on analytics, you need a high degree of confidence. It’s not enough to go by gut feel, data trends or correlations. Casual provides the confidence using a/b testing, econometrics and experimentation.

Why Most Business Analytics Projects Fail

Gartner CIO research reports that more than 50% of analytics projects fail. Why do they fail? In short, most fail because companies neglect to connect the analytics to business value. They focus on analytics output, tools and technologies verses business outcomes. Some common pitfalls include not knowing what the problem is, force fitting a solution, or trying to boil the ocean. Poor data quality and a lack of technical expertise are also big issues.

Another reason business analytics project fail is due to the way they are managed. The traditional plan driven approach does not work for analytics projects. “Business analytics projects are often characterized by uncertain or changing requirements and a high implementation of risk. So, it takes a special breed of project manager to execute and deliver them.” (Viaene, Van Den Bunder, MIT Sloan Mgmt Review).

Setting Up Analytics Projects For Success

The best way to setup analytics projects for success is with framing. The goal of framing is to define the problem boundaries, break down the problem and determine the analytics method. This helps to reduce ambiguity and the risk of project failure.

There are different frameworks that can be used throughout an analytics project life cycle. Below is a description of a common framework that can help:

Situation, Complication, Key Question (S, C, KQ) – The S, C, KQ framework helps gather the information needed to provide a clear and holistic problem statement. The Situation provides the information relevant to the problem. It is the context that sets up the complication. The situation must lead to the complication. The two must connect.

The complication clarifies the need for change. It specifies why a change is needed and a decision must be made. The key question then follows from the situation and complication. It is the one focus of the project and it makes clear the decisions to be made. The key question should use the SMART guideline – Specific, measurable, action-oriented, relevant and time bound.

Below is a basic example of what the S, C, KQ framework might look like in a project definition sheet. The example provided is to solve a business problem for a health club:

The example gives provides a basic idea of the S, C, KQ framework. Once the problem statement is clear, the analytics project team can decide on which type of model to use. The final step in the framework process is to provide an outcome that is measurable and actionable. The outcome explains what business decisions will be made based on the results of the analysis. The outcome also explains how success will be measured.

With a solid framework in place, a cross-functional analytics team can then develop a model. A typical deliverable from an analytics project team might include a web dashboard that provides predictive or prescriptive analytics. Data engineers and data scientists write algorithms and build the models. They also perform data cleansing, aggregation, integration and transformation.

Summary

Companies need to treat their data as a corporate asset. The ability to use data to predict future performance provides a competitive advantage. While business analytics is growing in importance, many companies are failing in their efforts to become data driven.

A key to success with business analytics projects is to use a framework that will align the analytics with business value. Analytics projects must be managed in an agile way that adapts to changing requirements. An iterative and experimental approach to project delivery is best.

Often the biggest roadblock to business analytics success is the business imagination. Companies must find ways for human intelligence and machine intelligence to work together. 

A special thanks goes out to the Carlson Executive Education program and professors Ravi Bapna, Gedas Adomavicius, Ellen Trader, and De Liu. Below is a picture of our business analytics class filled with business leaders from the Twin Cities.

About the Author: Mike MacIsaac is the founder and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master/Coach. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Identity and Access Management (IAM) Is More Important Than Ever

It’s a company’s worst nightmare. A data breach or cyber-attack. Cyber-attacks continue to be a growing threat, but not all data breaches are caused by outside hackers. Ask Morgan Stanley. In 2015, the financial services firm revealed that an employee had stolen data from more than 350,000 accounts. Forrester estimates that 80% of data breaches have a connection to compromised privileged credentials, such as passwords, tokens, keys, and certificates.

To avoid a data breach nightmare, company’s must ensure only the right people can access appropriate systems, data, and resources, for the right reasons. This is accomplished through Identity and access management (IAM). IAM is a specialty discipline within cyber-security. It helps companies increase productivity while securely enabling access to applications and systems.

IAM has to be an essential part of your IT toolkit. The typical business user has dozens (even hundreds) of applications they must access to do their jobs. These applications span cloud, mobile and on-premise solutions, and all can hold confidential, sensitive and regulated information.

To address the access management problem, there are many different IAM products on the market. I’m currently finishing a project to put SailPoint IIQ in place for a large financial institution. SailPoint is a Java based web application that integrates with legacy systems and Active Directory (AD) enabled applications. Auto-provisioning, native change detection, reporting and access certifications are some of the features SailPoint IIQ offers. Some of the other popular IAM products include Oracle Identity Management (OIM), Microsoft Identity Manager and Microsoft Azure Active Directory.

Regardless of the product you choose, having the right IAM strategy in place is key. The implementation of IAM can be very challenging. It takes strong collaboration between business, IT and operational teams. It also takes prioritization from leadership. Without executive sponsorship, business system owners and stakeholders may be reluctant to assist.

If you are in early stages of IAM or if you are already into delivery, MacIsaac Consulting can help. We provide services to help you put the right IAM strategy in place and we provide delivery resources.

Below are pictures of the cross-functional IAM team in action from my current project which is winding down. The work is very challenging, as most IAM projects are. Yet, the project will be successful because the client made IAM a top priority. They made the investment and provided the support to get the job done. That’s what it takes.

If your company is ready to deliver IAM, or if you need help on your current journey, let’s talk!

We used a Kanban board to track each Application going through the IAM integration process
Cross-functional team made up of IAM engineers and business members
Expert SailPoint IAM engineers working hard in the team War Room

About the Author: Mike MacIsaac is the founder and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master/Coach. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Why Middle Management Is The Ultimate Agility Killer

“So much of what we call management consists in making it difficult for people to work.” – Peter Drucker

For the past seven months I have been managing a difficult IT project for a large organization. The experience has me convinced that middle management is the ultimate roadblock to agility. I get why they call it the frozen middle. To understand the root of the problem, you must look beyond managers themselves. The core of the issue lies within organizational structure and culture.

While many companies are undergoing agile transformations, most still use old organizational models. The matrix structure is a top offender. Loaded with hierarchy, bureaucracy and management layers, it is anything but agile. If an agile team were superman, the matrix organization would be kryptonite.

Below are some of the ways the matrix organization impedes agility:

Disjointed Functional Areas

The matrix organization splits functional areas into groups. In IT for example, developers belong to one group, QA analyst to another, and so on. The employees within the group’s report to a manager. The manager then places employees on projects within the company.

Here’s the problem. Functional groups are setup to be in conflict against each other. I can’t tell you how many times I’ve seen functional areas point blame at each other when challenges arise. “It’s development’s fault”, or ” its QA’s fault”. Instead of promoting an attitude of one team, the matrix environment sets the stage for political strife. Managers snipe at one another as they fight to stand their ground.

The result of all the political warfare is hindered project teams. Team members just want to accomplish their work. Instead they get harassed by managers who need ammo to defend their functional area.

The Value-Add Dilemma for Functional Managers

IT functional managers working in a matrix environment have a dilemma. They usually come from a background of product delivery, where their contributions were clear to see. When they leave the trenches of project work to become managers, they realize their new role is about staffing. How then are they to prove their value if they are not delivering work? They attempt this in two ways.

First, they involve themselves into areas where they aren’t needed. As a project manager and Scrum Master, I have had to ask functional managers to not attend project team meetings. In teams, the presence of non-core members causes disruption. Teams operate at peak performance when each member of the team knows and trusts each other. The moment you introduce someone who is not part of a team, especially a ‘manager’, everyone clams up. The team reverts to the ‘forming’ stage of Bruce Tuckman’s four stage team building model.

Second, functional managers try to prove their worth by raising ‘concerns’ to leadership. Since they are on the sidelines for projects, voicing concerns about potential issues gives them an outlet for exposure. It’s a way for them to say, hey I think there is an issue, see how I’m adding value? Unfortunately, this often results in a lot of noise and distractions. While their intentions may be good, they end up stirring the pot.

These behaviors are not the fault of the managers themselves. They are usually good people with strong backgrounds. The problem is not the people. The problem is the functional management role itself. It doesn’t give people a way to add value.

Forming teams around projects

The matrix organization forms teams around projects. It’s not uncommon for people to be on two, three or even four projects at a time. This results in switching costs, the cost of doing more than one complex task as a time. Studies show that when people switch their thinking to different topics, their productivity goes down.

Poor team development is another result of forming teams around projects. Assigning employees to new projects doesn’t allow enough time for team development. It takes people working together for a while before a high performing team emerges. The moment you assemble a new team for a project, the team building process starts from scratch.

PMO’s

When it comes to process overload, the PMO (Project Management Office) is the worst. PMO’s force organizations to follow rigid standards, processes and tools. Many are trying to adapt to agile practices, but the results are the same. Too much process and bureaucracy. It goes against the first principle outlined in the popular Agile manifesto. Individuals and interactions are valued more than processes and tools.

While processes and controls are necessary for organizations, too much is an agility killer. Forcing project teams to create wasteful documentation is a common problem. I once had a manager ask that a large test plan be created for each Agile two-week sprint. The result was a QA analyst spending more time working on a test plan than collaborating with the team. To achieve agility, you must value working software more than documentation.

The Solutions to the Middle Management Conundrum

The best way to combat these issues is by forming stable, cross functional, capability teams. True agile teams. The teams can use whatever framework, processes or tools that work best for them. They don’t have to follow arbitrary processes from a PMO.

There are many benefits to the stable product delivery teams’ model. It eliminates the need for excessive management by doing away with functional groups. This puts emphasis on product delivery and providing value to the customer. It also reduces the internal politics that the matrix organization creates.

By keeping teams intact, it allows enough time for team development. Instead of forming teams around projects, project work goes through teams. This is a mindset shift away from traditional project management to modern product delivery.

Agile teams report up through one line of management. Managers are responsible for strategy and ownership of their capability. This gives managers clear roles and responsibilities that provide value. They engage in product delivery.

Part of the goal with the product team model is to create a flatter organization and to adopt an agile culture. While these changes are hard for large organizations, many companies are having success. In Minneapolis, where I live, companies like Best Buy, Target, United Health Group, and TCF Bank are making significant progress. They understand that the balanced matrix organization is no longer adequate to stay competitive.

Organizations still using the balanced matrix structure need to change. Implementing a stable product team model improves agility and benefits the customer. It also provides a more enjoyable work environment for managers and employees.

About the Author: Mike MacIsaac is the principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

The one trait that the greatest leaders have in common


Throughout my career, I’ve had the benefit of learning from different types of leaders. I have found that the greatest of them, all have one thing in common. They all strive to help others succeed. They enjoy helping people. It gives them sense of fulfillment that goes beyond personal gains.

We often here people in leadership positions speak about their commitment to service. They tout “servant leadership” as their motto, yet their words often ring hollow. Too often we learn that self-interest is their true motivation. These people are leadership impostors.

True leaders are different. What is it about them that makes them enjoy helping others? Are they some sort of special breed, predisposed to become servant leaders? Or is caring about the success of others a skill they developed over time? The answer may be, both.

First, caring for others is a skill that we can develop. By receiving honest feedback from our peers, we can improve our emotional intelligence. Studies have shown that we can develop empathy. Second, we know that each of our brains are wired in a certain way. For example, the brain areas necessary for remorse, do not function for sociopaths. So, there is a genetic predisposition factor.

Great leaders may have a generosity gene, but most also developed their skills. They did this throughout their life. Many have lived through difficult experiences, some going back to their childhood. At some point, someone helped them. It could have been a teacher, coach, manager or friend. These experiences taught them the importance of helping others to succeed.

You may say, all this talk about helping others is great, but isn’t leadership about results? That’s a good question, and here’s my answer. Leadership is about achieving results through others, so why wouldn’t you want others to succeed?

About the Author: Mike MacIsaac is the principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.

Page 3 of 8

Powered by WordPress & Theme by Anders Norén