Lessons from a Scrum Master

I’ve been a ScrumMaster for 6 years and previously at a hospital and not Matterin product development. So I did a “scrum training” session a few months ago and that went really well. Next I worked to condense that session from 2.5 hour scrum training into 30 minutes, and again into 15 minutes.

So read it, and burn some time reading!

I’m Matt “Matter” Raykowski and I’m a Product Developer and “Level 37 JavaScript Sorcerer”. They call me “Matter” because we have a habit of collecting Matts (4) and Brians (4) in the office.

HockeyRinkI built a “hockey rink” in my back yard for my kids.

Okay – so what is agility?

Contrary to some people’s beliefs ‘agility’ is not a process. It is not something that can be condensed into a document, passed out to employees, and then expected to be followed to guaranteed success. It is a way of thinking. It is, and this is important, a culture.

So you might have thought oh no, he’s going to babble on about scrum.

Or ˈkänbän/.

Or some other post-it™ driven process or technique.

Okay, yes, we do use scrum at Kinetic. It’s wonderful. You should try it. You can use it for anything, not just software. Who knows what scrum is? Just in case you don’t it’s one of many agile methodologies, which includes XP (Extreme Programming), Kanban, and Lean Software Development.

But if agile isn’t a process, a framework, or some other finite set of rules I can impose upon my employees to ensure instant success… what is it? What good is it?

We value…

Value in statements on the right, value left more

  • Individuals and Interactions over Process and Tools
  • Working Software over Comprehensive Documentation
  • Customer Collaboration over Contract Negotiation
  • Responding to Change over Following a Plan

Who recognizes this? Agile Manifesto.

Well, that was boring. Right? If you want more, check out the agile manifesto. What is important is what motivates people. It is this: autonomy, mastery, and purpose. How on earth do the Four Core help with this? Well, let’s look at the culture here at Kinetic.

There’s a process in everything. This is how we plan, this is how we do deployments, this is how we do releases. But they’re not sticks used to keep us in line. Our Sonar and coverage reports are important tools but do not dictate how we develop the product. There’s a trust that we’re competent individuals, that we know how best to solve complicated problems. As a matter of fact that’s probably why we were hired in the first place. At Kinetic Data ceremonies are informal and used to collaborate and communicate.

We keep our process light so people solve problems right.

First the manifesto says “software” everywhere. It’s not just software. It’s “stuff” and “things”.

We care less and less about the spec we created over a year and a half ago on how our latest version was to be designed.

Our goal isn’t to deliver a software package designed to spec. Our goal is to provide working, quality software.

It won’t take long for you to develop against a spec before you realize that you totally forgot about something or that the concept is fundamentally flawed in some way. Being forced to make some horrible piece of software people are going to hate just because of ‘what the spec says’ makes me a sad person.

Plus, who wants to write all of that documentation knowing it’ll be totally irrelevant before the  project even ends?

Dogs, working together, cats… being cats.

So I’d rather look at this horrible feature and say, “hey, this is horrible, let’s do this differently.” Okay sure, there’s a legal contract regarding the Statement of Work and yadda yadda. But that doesn’t mean you hand us a piece of paper and we blindly implement it, even if we discover some new information that makes it clear it needs to be redesigned. Or worse, if you do. So let’s work together. It doesn’t need to be a battle, we’re a team, right?

Think bigger, not just within a real legal contract and real customers. Think of that spec document and a “contract” the same way. You have to develop a new financial forecasting report for the CFO and Controller, right? If the data available isn’t sufficient to write the report or realize that summary data isn’t all that useful? Don’t just power through it. Collaborate! Figure it out! We’re a team, right?

Okay so it all leads here, it’s all about plans and change I mean who here has had a project that went exactly as planned? We should plan, because it gives us a guideline, it gives us a purpose. But we have to acknowledge that the path to completion is littered with pitfalls.

It’s important not just to acknowledge that you need to respond to change but provide ways to do it. People need ways to express that there’s a problem. Timebox – break work down into cycles – plan for 2 weeks of work not 2 years of work. This means every 2 weeks you get a chance to say “hey, this isn’t working.” Provide constant feedback loops. And then actually do something about it. Change.

If I don’t love what I’m doing I’ll do it. But I don’t feel like I have a purpose then. I don’t have a vested interest in the success of it. Telling me I get, let’s just say, stock options if a product is successful won’t assuage the fact that I was forced to make a horrible product. Being allowed to try out new tools or technologies, new techniques for solving problems, to rethink and propose changes to the product, to have some level of freedom in my day-to-day development, to have a voice in the course and planning of the project. These are the things that make working at Kinetic an incredible experience. And a happy employee is a productive employee.

At Kinetic we’re “scrumbut” – but getting better. You see, Agile is iterative, adaptive, and timeboxed. And we apply that to our process as well as our work. At Kinetic we plan 2 weeks at a time. This gives everyone a good view into what’s happening. Plans change, we have a retrospective, and then we refactor. We have “daily” standup. It’s transparent and anyone can come and usually we have someone from each area. They’re problem solving sessions, I might find out that the bug I was working on was already solved by Ben.

Agile is also psychological. This is why we have Burndown Charts. It’s really nice to see that line go down, to feel like you’re making progress. We’ve involved in planning involvement and estimation. This really helps prevent burnout.

Finally we have a level of autonomy. John and Kelly say what you want, but we decide on how because, again, that’s what we were hired to do.

Be a Provider… NOT a Broker!

At Kinetic Data we’ve been talking for years about Service Integration and Automation (SIAM) and building software products to enable Service Providers to deliver at scale.  Understanding the SIAM concept has real value for enterprises looking to achieve successful delivery where service models are distributed across fulfillment silos, and customer experience is of paramount importance.

For Shared Service IT organizations, most have an understanding of the Handshake above 2brokering concept with respect to infrastructure delivery.  In this context, the brokering concept is often referred to as the Hybrid Cloud infrastructure model. In this model, Corporate IT is typically the central provider of infrastructure services, while the actual components making up deployed technology stacks live both internally (corporate data centers) and externally (partner provided, Cloud-based data centers).  Often, Corporate IT may involve many back-end partners in providing those infrastructure components.

At a high-level, the Service Brokering concept appears to solve challenges associated with delivering enterprise IT service in the complex world of today’s global economy. In this model, services are made up of component functions where fulfillment tasks are sourced to provider-partners responsible for delivering their individual part.  While this may seem like a broker model, the reality is that if you view things from the customer’s perspective, the “Service Broker” concept doesn’t make sense at all.  

When I think about my experiences with brokers, some are great and some are not.  Regardless of how good the broker, I’ve ended up (as the customer) having to directly interact with downstream providers to resolve issues related to the service I’ve procured.  I’ll spare the gory details, but offhand I can think of examples with healthcare, investments, house-buying and home repair that make up my experiences.

Each time an issue came up in the delivery of a complex service (home-purchase) and I had to get involved in solving them, it was time-consuming, costly and frustrating. More than once, I decided that regardless of how good the broker was in my initial interaction, I would not use them for the same service in the future as it was easier for me to handle things directly with the downstream provider.  That’s an anecdote for IT outsourcing if you are keeping score at home!

Ultimately, the underlying issues with all of any of these challenging “Service Broker” experiences I have lived were due to the difference between my perception and the reality of the service model I was procuring.

As a customer, I expected an experience where the service being provided was truly integrated end-to-end regardless of who was doing the fulfillment.  What I got was a disparate and distributed service experience that was notintegrated and left me looking for an alternative provider for the future.

So, with respect to Enterprise IT and the idea of “Service Brokering”, think about:

  • A customer procures (requests or buys) a service and expects delivery of it, not just “part of it”.
  • That customer has an expectation (SLA) for that service with corporate IT.  It’s not the customer’s responsibility to coordinate sub-contractor agreements (OLA’s) between back-end fulfillers that comprise the component Sub-Services, nor is it their interest to have any complexity added to their experience.
  • They don’t care if Vendor A is responsible for Sub-Service 1, and Vendor B is responsible for Sub-Service 2.  All they want is simple access to the service and a great experience in it’s delivery.   

If there’s an issue with a downstream fulfillment by Vendor B, it’s ridiculous to expect a customer to care about a missed OLA or further, to get involved in the resolution of a stalled service.  When they come to get service from Corporate IT, they expect a great experience by a Service Provider, not a Service Broker.

If you understand what goes into end-to-end service delivery where there is afocus on customer experience, Service Brokering is nothing more than marketing-speak. Another attempt by industry vendors to try to re-label what already exists and sell it to you as “new.”  The multi-sourced delivery model has existed for decades.  It is not new, and there are real Service Providers out there that truly understand the value of Service Integration in driving excellent customer experience!


Remember:  What matters most is customer experience.  Be a ServiceProvider NOT a Broker!

Trying is Everything

How are we going to solve this problem?

It’s impossible to know all the possible solutions to a given problem, and the more complex the problem, the more possible solutions there may be.

Nothing inspires me to grab my toolbox more than problems that need solving. How do you add solutions to your toolbox? How do you hone your skills in applying those tools?

This is why trying is everything.tools

Without the upfront work of experience and trying things, you may not know which tool is sharpest, or the best fit for problem.  In tech work this means trying lots of things, platforms, technologies and approaches to applying those technologies. It means talking to people who have tried lots of things and connecting to people who carry a bigger toolbox or sharpened tools.

Get involved in communities, join meetups focused on solutions and try everything!

Ready to try something new? Join our hackathon: http://developer.kineticdata.com/hackathon

Why I Joined KineticData

TL,DR; I’ve never worked for a company where they could handle the bandwidth of my ideas. It feels good. Kinetic Data is in the perfect position to make a big impact on the technology aspect of many industries. To prove it we’re paying cash to build solutions on top of our platform.

My tech career started with ServiceNow. Actually, it really started on a home-grown filemaker system, then ServiceNow. </tangent>

If you’ve been in the tech industry even slightly longer than me, you probably realize why my short tenure and lack of exposure to “legacy systems” skews my perception. Our industry has a rich history of trials, tribulations and successes. The first exposure to older systems of record taught me that several vendors and tools had gone through a “vicious cycle”.  This was usually because the tools or company had:

  • Become too disparate
  • Relied on archaic code bases (technical debt)
  • Politics or other in-fighting with partners or business practices
  • Overpricing
  • Crazy licensing
  • Undervaluing
  • Overvaluing
  • Poor architecture
  • Grown by acquisition
  • Wasn’t innovative enough
  • Outgrew themselves

and a myriad of other reasons. Having heard these experiences, told by those more experienced, trends appeared and I realized;

History repeats itself.

This isn’t new information, but it’s a new look at our current reality.

The complex becomes the simple, only to become complex again. And we certainly see this in the stories of our industry. The term “coded into a corner” has become a common description for technology platforms that support automation and technology management.

OverComplicatedOverTime

This is a vicious cycle technologists understand very well. Companies implement systems regularly. Some systems have more stickiness than others, some are more durable, some have more staying power. Organizations have baggage too, some can adapt quickly, some have the discipline to squeeze more life or value out of platforms than others.

How can we stop this cycle? It is damaging the reputations of service providers, projects, departments and individuals. Start by not doing anything on the list above. There are two things that are imperative for ideas and companies to survive:

  1. Decentralize work: enabling the customer to manage their own business processes
  2. Well architected technology: make integration and platform value longer lasting by making wise choices

It is cruel to list those two behemoths like that. Both of these goals are massive undertakings with massive benefits.

How to get there

How does a team make progress toward those goals? Firstly, make them organizational goals, secondly make them department goals, and thirdly make decisions to support this direction. Whether it’s hiring or training architects, giving them the proper oversight (by having them report to non technical leadership) and by giving them power to change your systems.

So Why Kinetic Data?

There are a lot of reasons of course. Primarily as a marketer and technologist, I need to strongly believe in a product before I can successfully make others believe. I’ve seen what KD is building and I have faith that it will not only change the way you look at platforms again, but it will help companies achieve the two goals listed above.

I’ve had the pleasure to work at a handful of companies and Kinetic Data has a very healthy and supportive psychological culture and environment. Never have my ideas been so welcome and accepted in a professional setting. People are eager to try new things, fail quickly and feel the support of our team if we make mistakes.

If you want to see what I’ve seen – give it a whirl. Sign up for more information, trials and demos here.

Scoping Technology Differently, Differentiates

tl;dr (too long, didn’t read) – Switching to the latest toolset just catches you up to competitors, it doesn’t take you past them. If your goal is differentiation and increasing value past “par” then design for rapid technology change, perform regular system evaluations and have an honest and transparent tool selection processes.

 

Your enterprise has several platforms that are capable of accomplishing literally anything. With enough development these systems can likely perform many business functions. But should they? Just because your jackknife has a saw doesn’t mean you will enjoy using it; there may be a better tool.

How can you tell what each system should do? Enter the “Enterprise Architect” (EA), this person is essentially a business analyst and technologist, and hopefully has a great deal of understanding how systems fit together. They are ready to tell you which tools should do which tasks. They do this by analyzing toolsets and balancing the goal of optimizing value while decreasing overhead. For instance, building an intranet site for department use on SAP is going to take quite a bit of customization and org-change, while Sharepoint is built for this purpose (and your company already has a license). Bring them your goals.

This applies to all functional areas. Daily work in human resources (HR) handles aspects of talent and career paths, these functions are unique to this team and have specific tools that work great for this space.  Building something from scratch is not a wise investment and can lead quickly to waste and missed opportunity. But if the organization is a talent agency, it’s likely they have a custom system for managing people. This is their differentiation.

So what happens when new tools or demands are raised? Enter the “Business Relationship Manager” (BRM), this role is essentially a business analyst with great listening and persuasion skills. These people partner with the architects mentioned above to make things happen – this can mean pushing features that didn’t exist before, switching platforms or finding better data sources or integrations.

In the HR example above you can quickly see how HR uses these features and technology to differentiate their value. They are collectively better as they improve and iterate their tools and processes. Perhaps their toolset allows them to cross-reference LinkedIn data with compensation, or compare performance with career path; whatever the case, if there is business value in quality talent, enabling these toolsets is the goal. This should be clear to the BRM and Architect alike, and they should know whether the talent management system can handle an integration of that sort. Maybe they get a business intelligence app involved or just work slowly toward this goal.

This applies broadly across the enterprise. If you aren’t able to differentiate, you run the risk of missed value and ultimately irrelevancy. As technology continues to be the differentiator of choice, the importance of having quality Architects and BRMs increases. Getting quality masterful value out of your toolsets is their sweet spot.

How Come Our Culture Isn’t Better?

Week 3 in a three-part series about differentiation.
Hiring the right people. Have you seen this done well? If we accept that failure is inevitable, meaning you How Culturecan’t hire perfectly well %100 of the time, then how do you make sure you’re getting the right people to fill your needs?
That’s easy!
Are you accomplishing your goals? Are you exceeding them? These two questions capture the urgency and essence of how truly great companies look for ideas.
This desire for new ideas, a thirsty exploration and acceptance of ideas is something I’ve seen firsthand at only a couple organizations. If you find it, take note, for you are in the presence of something very great. A culture that begs for change is not something you can create overnight, and something that I suspect doesn’t scale.
In both cases, the culture of the organization was the first goal right at the beginning. If you have competing goals, and a different primary goal you will be quickly distracted with profit, product or performance and one of the millions of details of running a successful organization.

How Come There Are No New Ideas?

Week 2 in a three-part series about differentiation.
We don’t have time to innovate.Ideas and Listening
Everything’s already been tried.
We just aren’t a very innovative company.
Heard them all? Your team has. And the person who doesn’t hear, doesn’t recognize and doesn’t believe them is the employee that’s sure to be innovating. New ideas are everywhere. However, in some cultures, ideas must go into hiding for self preservation. Idea abuse is a real problem and can be recognized by the symptoms including cricket sounds when conference calls open up for questions, people hide their best ideas and people are used to hearing “no”.
Why is this?
What suggestion did your mail room employee just mention to his co-worker on the dock while taking in the daily barrage of Amazon boxes? What if their supervisor doesn’t listen? What if they do, but then their manager doesn’t? How can co-workers cut through the beauracracy quickly and prove ROI without being enabled?
The answer is that they can’t. Or if they can, they won’t.
Here’s the story.
An inspired and new employee has been mentioning new ideas to her boss for 3 years, one day a consultant came in and sold an idea to management. After a lengthy and expensive project, which failed, your new employee is livid. She even takes the time to analyze and report why the idea wouldn’t have provided value even if the project were successful. Yet her ideas go unnoticed, unrecognized by management and never realized by her coworkers.
This employee might muster up the courage to quit, or even look for a new position where their voice will be heard and valued. But maybe they won’t. Maybe they are the primary earner in their household and they can’t take a risk on a new job. In both of these cases this woman will keep quiet and do the minimum possible to complete her “duties as described”.
How can you break this cycle?
Some say new leaders are needed, some people think a feedback process might work. I usually go for something a bit more direct and impactful; transparency.
Your employees need love and care. People want to be heard, valued and rewarded. They want to be part of a team. Not just watching from the sidelines. So cut to the core, build systems of engagement that scale and stop silencing voices with process, approvals and hierarchy.
Next week: Culture as a measure for your ability to differentiate.

Where Do Ideas Come From?

Week 1 in a three-part series about differentiation.
 shutterstock_369924926
In knowledge work, there are typically several unspoken things teammates are expected to contribute. One such tool is brainstorming. Although not many job descriptions really include this in the “required skills and experience”, hiring crews are always trying to understand a candidate’s ability to come up with new ideas. Critical thinking, questioning and trying things are essential skills in any teammate.

 

The second thing most people bring is a network of people who help think through or talk out ideas. Almost every teammate brings this too, along with former co-workers, industry connections and networks, not to mention friends and family.

 

These are the things that can’t be automated, can’t even be ‘manufactured’ per se. Talent takes pride in that kind of value. There is comfort knowing that a person’s skills can’t be replaced by a system, or automation.

 

So?
Your people are your differentiator.

 

Your people may have a passion about work that is so genuine, so pure, that they can’t help but talk about the next project. When they are out and about, their minds wander, usually to topics in which they have real interest. People can see your employees honing ideas and jotting them down everywhere. They take ideas and experiences and apply to them to their craft. Sharpening it and honing it with little oversight and minimal micro-management