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.

Kinetic Community Re-launched on Latest MindTouch Release

Kinetic Data’s information hub for customers, Kinetic Community, was re-launched in early November. Kinetic Community is the place to find and discuss product documentation, videos, presentations, training class materials, downloads, example service items, task handlers, bundles, bridges, and presentations from past Kinetic Enthusiasts Group (KEG) events.

MindTouch software and Kinetic CommunityOur redesigned customer hub is built on the latest release of MindTouch customer success software. The MindTouch platform makes it easy for customers to find the specific information they are looking for, get answers quickly, and interact with our product experts as well as other Kinetic Data software users.

What’s New on Community

For our customers, the new Kinetic Community has an undated interface that’s simpler and clearer, and uses responsive design to display optimally on any mobile device. Continue reading “Kinetic Community Re-launched on Latest MindTouch Release”

Agile, DevOps Feed the Need for (Business) Speed

Remember the story of the tortoise and the hare? “Slow and steady wins the race”? Econ 101 lectures about economies of scale? Business truisms like “Nobody ever got fired for buying…” (insert any large, established vendor name here)?

Such nuggets of business wisdom seem to no longer apply. Today, in the words of author Jason Jennings, “It’s not the big that eat the small, it’s the fast that eat the slow.” Competitive advantage comes from reworking business processes and service delivery models to improve speed not by 10% or even 100%, but by multiples. Consider:

  • How Agile, Scrum and DevOps meet need for business speedAccording to a recent Financial Times story by Lisa Pollack, “A Berlin company, founded in 2013, built an online service that allows new customers to open a bank account in under eight minutes…The company, Number26, has signed up more than 30,000 customers after launching what it deems ‘Europe’s most modern bank account’ in January.”

Continue reading “Agile, DevOps Feed the Need for (Business) Speed”

New Definitions Added to the Ultimate ITSM Glossary

As noted here previously, there are numerous words, phrases, and acronyms which are either unique to the IT service management and ITIL world, or have a specific meaning within those contexts.

To help clarify these terms and concepts, Kinetic Data has compiled definitions for nearly 60 items in our ITIL – ITSM glossary.

ITSM-ITIL glossary - new terms addedBut the IT discipline is constantly evolving, with new practices, technology, concepts, models, trends and ideas being introduced. Reflecting these ongoing changes, four new entries were recently added to the glossary of ITSM terms.

DevOps

Few terms in the realm of ITIL and IT service management are as controversial to define as DevOps; there seem to be nearly as many definitions as the number of people trying to define it. Continue reading “New Definitions Added to the Ultimate ITSM Glossary”

Introducing Kinetic Core: The New Foundation for Kinetic Request

Kinetic Data’s director of products Kelly Heikkila is presenting “Kinetic Core — The New Platform for Kinetic Request″ today at the 4th annual KEG (Kinetic Enthusiasts Group) Conference. For those who couldn’t make it to the event in the Twin Cities, or just want to relive the session in blog format, here are highlights of the presentation.

by Kelly Heikkila

We’re excited to have the opportunity to introduce KEG attendees to the Kinetic Core platform and discuss what it means for the next generation of Kinetic Request.

Kinetic Core presentation at KEG 2015Our customers are doing great things with the current version of Kinetic Request—building out not only great service catalogs for IT, HR, Facilities and more—but also developing solutions that extend beyond the catalog. They’re creatively applying Kinetic Request technology in areas like:

  • Facility Check-Ins
  • Project Management
  • Light Inventory Management
  • Marketing Automation
  • Incident Management

Continue reading “Introducing Kinetic Core: The New Foundation for Kinetic Request”

The IT Skills Enterprises Need Next

As the focus of IT departments shifts from providing information and infrastructure to improving business processes, the mix of skills they require is evolving as well.

Writing on ZDNet, Brian Sommer contends in As IT’s industrial age ends, the humanist era begins that:
Which IT skills will be vital in 2015?

“Systems of Record are giving way to Systems of Engagement. User Interfaces are being updated to permit a better User Experience. Cloud solutions are displacing on-premises applications. Lighter, leaner IT groups are using utility computing (e.g., public) cloud solutions. Developers are building mobile and e-commerce apps. The list just goes on and on.”

Continue reading “The IT Skills Enterprises Need Next”

What’s New on Kinetic Community – October 2014

Kinetic Community is the information and interaction hub for users of Kinetic Data software. It’s the place to find and discuss product documentation, videos, presentations, training class materials, downloads, example service items, task handlers, bundles, bridges and more–as well as presentations and training materials from the 2014 Kinetic Enthusiasts Group (KEG) event.

Kinetic Community
Here is what’s new on the site since our last blog update: Continue reading “What’s New on Kinetic Community – October 2014”

Lessons Learned for Successful Request Projects – How to Scale the Heights of Success, not Plumb the Depths of Despair

It is rather surreal doing this blog post. I feel as if I am in a re-run of “Back to the Future.”

I am putting the finishing touches on this post before I present the session KEG, but because my internal clock is still set to Australian time, I am really doing it on the day after. These are some of the problems in living life “Down Under,” or as we Australians think of it, “Up Over.”

Australia- Up Over

 

Other problems include the “two nations separated by a common language”  that I encounter every time I visit. Please don’t ask me what team I “root” for or whether I would like to buy a Denver souvenir “fanny-pack.” Be careful asking me the way to the “bathroom” as it will get the response: “I’ve got a bath in my room, haven’t you?” We only have loos, dunnies, lavs, bogs or, if in polite company, toilets, and I take great delight in directing any American visitors to the room in my house that has only a hand-basin, shower and bath and not the other small room that has the toilet pedestal and watching their faces when they return with cleaner hands but a slightly more distressed look.

But enough of the cultural differences.

A little about myself and why you may be sitting in this presentation (if so, please put the iPad away and look at me) or reading this alone in your office or home (I assume because you have come to such a boring moment in your life when reading a blog entry of mine adds some excitement).

Well, I discovered the other day—through an automated message sent by our internal version of Facebook called Yammer (hopefully I get something for the plug—but not another bloody t-shirt please) that I have been with Kinetic Data (hereafter, KD) for over 8 years! That re-assured me, because I thought it had been forever…

I also have to admit that I am the oldest person in KD—but of course this does not mean that I am the wisest—as this blog post is proving!

Prior to KD—I can dimly recall that there was such a time—I have been with a number of IT companies working with BMC Remedy and other applications (they do exist), many of which have now melted away like the snow flakes which may be falling outside, when the sun warms them.

So, I hate to admit it, but I have been in this industry for over 40 years, so probably before most of you in this room or looking at this blog post were even in “project initiation phase” and probably before “requirements gathering” and putting out the “RFI or RFP.”

Since then I have worked as a Consultant, Analyst, Designer, Project Manager, Developer, Trainer and even once, on the “Dark Side,” as a Client in this industry of ours.

So, I think I have a right to have a few opinions on this whole “Requirements” business. Hopefully these opinions will inspire some thought, maybe even controversy, and hopefully someone might feel interested enough to have bought me a drink (Single Malt Scotch over 12 YO) to get me to share a little more of my “wisdom.”

OK—here we go.

I was told my Power Point did not have enough bullet points, so I added a second Agenda page. Apart from these two pages, there will be:

NO MORE BULLET POINTS!  JUST PICTURES.

This achieves two things: 1) you might listen, and 2) I don’t have to think of another way to say the same things without using the words in the bullet points.

(For those reading this blog, who want to look at the pictures, someone will have posted my presentation somewhere on the KD website—so you could download it and enjoy the full experience of course, without the “gosh I like the way you Aussies speak” audio component.

Let me “share with you” my first EDP (look it up) job, programming a door opener. I got paid about $50 for it (in those days that would be USD25—now it would be USD60—how the weak become the strong). After the stunning success I had in fulfilling the requirements—door must open, door must stay open for a while, door must close—the requirements were expanded to encompass the concept of “small room – moving up and down in a controlled way,” so I programmed a bigger controller that incorporated all the great work I had done with the  “Project Door” and added moving a room up and down in a vertical shaft, stopping and then doing the door bit. We called this “Project Lift”—or in American—”Project Elevator.”

This was the first time I had been confronted with the idea of requirements analysis in the “real world.” I was obviously excited.

They were simple requirements. We did have a discussion as to whether the doors should open in an “organic, caring and cool way”—it was the 70’s—but we knew that person was a closet hippy, so we ignored this suggestion and just went for “slamming open and slamming shut.” A lot of people nearly lost limbs because of this —but I had the cheque (check) and had moved on to bigger and better things like the Traffic & Parking Infringement Notice system for my home state (Australians have the same urge to make an acronym of everything—that is, when they cannot add an “ie or y” to a name—and we called it the “Project Tin-Pins’.” Yes, there were nerds even in those days and we were they.)

So that brings me to the point of the is session.

How to achieve a successful Kinetic Request project—and—taking a leaf from the “Self Help and Actualisation Movement,” or as I like to call it, “SHAM”the path to success is:

Achieving Oneness with Request ManagementONENESS…

Normally the first interaction you have with any vendor is through the sales team.

Sometimes the interaction is like this…

Over-promise…Get the deal…Under-quote…Under-resource…Under-deliver

At Kinetic Data, we try to make sure that we do not do that.

At the heart of achieving this is ONENESS between the client and Kinetic Data.

INITIAL REQUIREMENTS

Without clearly stated initial requirements everyone is working in a fog of doubt and uncertainty.

Vendors build-in large buffers for this uncertainty and often still under-quote for the project.

Once you have decided on a vendor for your project, work with the internal and vendor teams to:

DEFINE AND REFINE THE REAL REQUIREMENTS

Things to consider when doing this:

  • You may not have all the information; consult widely with ALL stake-holders.
  • There is only  piece of clothing where “ONE-SIZE-FITS-ALL”—a straight-jacket.
  • Trying to combine features of different offerings is rarely a success.
  • Just because it can be done, does not mean it should be done.
  • It may be a solution—but is it practical?

There is a reason why you are initiating this project, and it normally not just to:

  • Replicate the existing application
  • Change the appearance slightly
  • Bolt-on some new functionality
  • Get a more powerful application but restrict it to the old limitations

A successful project should deliver improvement. Not repackage the status quo!

To achieve this, all the parties have to be able to be flexible and willing to change expectations and requirements to deliver the BEST solution within budget and on time.

TIMING, EFFORT and BUDGET

Be realistic. Rome was not built in a day.

If you have been set firm dates  and budget to deliver, then make sure that the requirements are aligned.

LISTEN

We are now in partnership with you to deliver SUCCESS.

It is not a battle between two sides—one trying to get more than agreed and the other trying to do less.

Remember that in a difference of approach, the consultant will advise on the best solution, but at the end of the day—if the client wants it, we will build it.

DELIVERY

So we now have a project that has REAL, WELL DEFINED and ACHIEVABLE requirements.

So, let’s stick with them when we develop the SOW and during the delivery period.

Tacking on new requirements while development is going on does not work. It adds to costs and delays.

Importantly, it just shows that the requirements gathering was a failure.

Finally, remember the ultimate measure of success is the satisfaction of your users.