I’ve been a ScrumMaster for 6 years and previously at a hospital and not 
in 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.
I 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.
Cassy Lueneburg