Recently, I started working with a client that derives its revenue from intellectual property generated in-house by a creative team. This client maintains several delivery platforms for their IP, and they are facing extensive change by moving to a cloud/CDN-based delivery model, adding platforms, and having to retool just because of routine IT progress: address 64-bit platforms, tablets, and so on.

Some of their delivery platforms are custom-built software, written in-house by a developer or by various consultants over the years. Several changes now loom at nearly the same time, while also preparing the company for significant impending growth (a good problem to have, of course!). There was also (typical) frustration built up: management felt that IT never delivered anything, and IT felt that management didn’t acknowledge what they did do, and constantly chased after the next bright, shiny thing.

Because the people who wrote the existing platforms had moved on and are mostly no longer available, and to accommodate the coming growth with some planning and organization, we decided to implement Scrum for all its benefits: minimum bureaucracy, flexible roles, available tools with out-of-box artifacts like burndown charts, a rapid-delivery mindset, quick ramp-up curve, and of course due to the involvement of “product owners”, increased interaction between technical implementers and management/marketing.

Additionally, we wanted to give everyone more visibility into what each technical person was working on: by making stories and tasks public, management could see at a glance what was being worked on and what was completed – and gain understanding of what some technical tasks actually involve.

Bringing even Scrum – when well done, not as a poor excuse for “great, we don’t need to do any planning anymore, it’s Agile” – into an organization that has a culture of ongoing context-switching and no background of routine planning and periodic re-prioritizing can be a challenge to all involved. Built-up history can make “both sides” wary of what they’re giving up: for example, technical people often dislike the idea that “product owners” get to prioritize what will be worked on at the start of each iteration, while management is uneasy with the idea that they will need to stop re-prioritizing project work daily or hourly and instead trust their team to complete their commitments by the end of the iteration, in the order they deem best.

Because this was a new mindset and a new methodology for all, we decided to start “analog”. Some tape, some index cards and post-its, and voila! We had our planning board on a convenient blank wall. While this looks primitive (OK, downright ugly), this “see it all at once” setup makes it easier to explain how planning boards, stories, tasks, daily scrums, estimations, and iteration startup and closedown meetings work – of course, these then need to be done routinely so they take hold – without also telling someone where to click. As we see whether Scrum will work, we can focus on the mindset and the methodology with our primitive tools without also forcing everyone to learn a new piece of software.

Once we complete one or two iterations and people “get” the processes and artifacts, we’re going to revisit whether Scrum works at this organization. If so, then we’ll tackle the next change and look at software to manage stories and tasks and produce artifacts like burndown charts for us.

I have seen this approach work wonderfully well. One of my mentors (and the most expert Scrum master, leader, and implementer I have worked with) implemented Scrum this way a couple of years ago at a similar, larger organization where the management team was justifiably unimpressed with an IT team that had a history of routinely missed commitments. Within a couple of months of implementing Scrum – and doing it thoroughly, well, and consistently – this person turned the IT organization around and made it into a team that consistently met or exceeded its commitments.

Factors that aided this transformation were not only my mentor’s Scrum expertise but his general management skill, a senior management team that publicly acknowledged and supported Scrum once the successes started, and a development team that was very enthusiastic to try a modern, rapid, lean methodology. These aren’t present in every organization, of course: hence, an approach that first emphasizes more structured, goal-oriented interpersonal interaction and mindset (see the Agile Manifesto) before also throwing new tools into the mix.

Lastly, I want to acknowledge one particular tool we’ve used on several Scrum projects. We have no affiliation with this company (other than being a completely ordinary client). Assembla.com offers agile project management artifacts and tools, several source control repositories with online code browsing, wikis, tickets, and much more. Each “space” for a project can be individually configured with just the right tools, and for us consultants, Assembla also supports multi-tenancy: one login enables access both to spaces we pay for as well as spaces our clients maintain and in which we are only members, and all the billing “just works”. If you’re trying out Scrum or your budget is lean, you should definitely try Assembla; after well over a year of constant use, we have yet to have a single glitch or problem, and we’ve seen it appeal both to staid enterprise developers as well as lone-wolf open-source types.

Have fun with Scrum!

IT can be frustratingly complex and opaque, especially to decision makers or non-technologists. Growing a business when IT is disconnected, change-resistant, or outright broken is hard! And just trying to understand and fix IT in the face of busy staff, lacking documentation, ad-hoc processes, and no IT roadmap can feel practically impossible. Where to start?

What do we have? How well is it working?

First, you need to know what you have and how well it’s working. We examine your entire IT operation including governance, procurement, deployment and configuration, training, support, continuity, development and testing, staffing, and more.

Our IT Baseline starts with a detailed data-gathering protocol based on the industry-standard ISACA CobiT 4.1 framework; we gather information by interviewing staff, examining practices and operational data, performing network and system scans, and other means.

What happens with all that data?

The data is then scored by us. Each area, process, and control is graded on its maturity, current risk level, priority to the business, and a range of specific risk categories. Scores are numeric to make prioritization and quick interpretation easier.

For example, a process that is highly automated and consistent, centrally monitored for failures and exceptions, and routinely improved based on collected operational data is probably very mature.

On the other hand, a process that is manual, carried out when someone remembers, breaks often but is never improved, and isn’t monitored is probably at a low maturity level.

The mature process may present a low risk level since it’s working well, but may be a high priority to the business since it’s critical to continuity. The immature process, by contrast, could be a high risk and, if it’s important, also a medium or high priority.

Let’s use some numbers

We use a Risk+Priority score to determine tactical priorities.
Mature process: Risk 1 (low) + Priority 5 (high) = Risk+Priority 6
Immature process: Risk 5 (high) + Priority 3 (medium) = Risk+Priority 8
Which one should the organization address first? Probably the higher Risk+Priority score.

This scoring approach can seem trivially obvious in isolation. But when an IT Baseline consists of hundreds of scored processes and controls, this type of approach allows for very quick prioritization and lets decision makers at least group high-priority issues together for finer-grained consideration. It’s not mathematically fancy, but it’s a great way to get direction very quickly.

What about the Risk Assessment?

We can also provide a Risk Assessment follow-on to the IT Baseline. The Risk Assessment goes beyond a simple numeric risk score and highlights specific risks found in each IT area. Risk categories include Continuity, Compliance, Financial, Operational, and Security. In each case the actual risk and its implications is described, and concrete recommendations are made to mitigate the risk so that concrete projects and goals can immediately be planned.

How long does all this take?

As with a financial audit, there’s a fine line between doing too little and only scratching the surface… and taking so long that patience, relevance, and funds are exhausted. High-level for a small company, this process will take two to three intense days of on-site time, plus as much time for deliverable preparation. Larger company size, complex infrastructure, lacking documentation, and other factors may increase the time needed for a useful baseline.

How do we start?

Get in touch with us and schedule an initial, no-obligation scoping meeting. During that, we’ll ask you lots of questions about your organization, strategy, products and services, challenges, and plans. Both sides have an opportunity – without commitment – to assess “chemistry” and fit, and we’ll have what we need to present you a candid, factual proposal.

Welcome to the new Net Gain Solutions web site! We hope you like the new look.

Since 2003, we’ve provided a wide range of IT services in areas including software development, database development and administration, ETL, reporting, procurement, staffing, project management, networking, server and desktop implementation and deployment, virtualization, security, and more.

This summer, it was time for us to (re)focus. We have trimmed our portfolio of services down to three main competencies: Expertise, Software, and Cloud IT.

Expertise refers to what we sometimes call “outsourced CIO” services. Organizations that don’t have a CIO, CTO, VP of IT or other high-level IT leadership nevertheless find themselves needing strategic-level help as they decide on IT investment, especially with the transition to cloud, mobile, and hybrid IT models now underway.

In Software, we’ve sharpened our focus to concentrate on agile development using scrum, which we think is superbly suited for rapid-delivery, change-friendly projects. We’ve always delivered on the Microsoft platform, and now also the Microsoft Azure and Amazon AWS clouds as well as Android.

Cloud is the buzzword of the moment, and organizations of all sizes are looking at cloud IT offerings. Our Cloud IT services distill work done with clients to help them match their IT needs to cloud offerings and do the due diligence and risk management to make the transition a well-considered one. We also offer technical services to help with transitioning to the cloud, such as preparing and transforming data for upload.

At the same time as we decided to focus our service offerings, we’ve also partnered with some other IT organizations that we think can do a great job in areas that are no longer a primary focus for us.

We’re really happy with our new look, site, and sharpened focus, though it was at times nerve-wracking deciding what to focus down to. Still, rethinking one’s business and being bluntly candid about asking “Should we do this? Is this something we are excellent or merely good at?” is a productive and re-energizing process. We look forward to working with you.