Kanban is the last stage of software delivery evolution. Right now, at least, as evolution never really stops. The path is usually the same, starting with a disorderly “let’s just code”, moving gradually towards a waterfall system, then painfully stumbling towards a formal Agile framework, say Scrum, and once a Scrum team truly matures, they realize they’re really doing Kanban with a bit of unnecessary paperwork.
The jump from chaos to waterfall is rather obvious. So is usually the next step to go Scrum (or any other framework you like). We love all the Agile principles, user stories help focus on business outcomes, expecting changes makes Product Owners happy and programmers less stressed. Estimates made in story points help the management see when things will be done and ready, and make decisions based on that.
In Scrum for a new project you define a whole bag of user stories, estimate them, order by business value and call it a “Release”. That Release gets split into Iterations, each of 1 or 2 weeks in length. When you’re done with all the Iterations, you’re done with the Release and ready to unleash your product onto the general audience.
We’re often working, however, with software that’s relatively inexpensive to release. Like web applications, where you upload code to a server and all your users instantly get the latest version. There’s obviously the question of stability, quality and testing, but Scrum says strictly that the definition of “done” is “designed, developed and tested.” So, by that definition, you should have a release-quality product after every Iteration.
Add the two things together and you soon have a Product Owner asking you whether it’s possible to do an interim-release, before the whole scope is done. Sure, it is. It takes a while to work out discipline and processes right, so that the quality really is good, but once you’re there, you can release right after the Iteration summary meeting. And the Product Owner has a point: why do we wait another X weeks for the whole Release to be ready, when we can have something live now? Competition never sleeps and some of these things could make users seriously happy.
Here’s where Kanban comes in: once you’re ready to release after every Iteration, then the answer to “when will this be ready?” becomes “right after the Iteration you put it in.” Long-term estimations become irrelevant, as they always were anyway. Just because you have a user story planned for 3 Iterations from now doesn’t mean it’ll really be done there and then. Things shift all the time.
Why bother with the “Release” planning then anyway? Switch to a higher-level roadmap of changes, so that the team continues to follow a vision for the product, but plan actual work only for the next Iteration. Then release it immediately. Now you’re doing Kanban.
Try, fail, adjust, go back to step one. So it goes on until failure turns into success or you get bored and leave to do other stuff. Such is business. It’s extremely rare that an original idea becomes immediately successful. Most ideas go through an iterative process of trial and error and the end success comes from a sometimes completely different idea than the initial one.
Take the Confected application that we are building. We set out with certain expectations, built and tried it out during this year’s TEDxWarsaw. Some of the expectations were correct, some were utter failures. We collected all the lessons and went back to our workshops to adjust the project. Meanwhile, while we’re talking to other conferences about setting up the application for them, we often stumble upon ideas for the application that are significantly different from the direction we’re pursuing. And our success relies upon whether and how we’ll take those offshoots into account, because as they say, climbing a ladder faster won’t help you if it’s placed against the wrong wall.
So when you consider any Agile methodology for software development, irrespective of whether that’s Scrum, Kanban or any other funny name, they’re nothing else than a business approach to engineering. You correctly assume that you’re unlikely to get it right the first time, so you try, fail, and adjust. You collect feedback and put it right into production, often completely changing the original designs.
It’s a way of working that’s quite familiar to business people but often strange to programmers. “But the specs said nothing about this!” Indeed they haven’t, but our knowledge of the world changes (or the world itself does) and refusing to adjust is asking to become evolution’s prey.
Agile? Yeah, we do Kanban. We’ve got our user stories, backlog and deliver iteratively. All good. Except that that’s not what Agile is. Not at all. It’s not the planning poker, story points nor squadrons of Scrum Masters. It’s the spirit.
Whenever the name Agile pops-up, invariably follows the “manifesto”. The 4 principles that you and I have seen over and over again and know by heart. Or do we? We definitively should because they are the Agile. They’re a way of approaching software development, while Kanban, Scrum, XP and all the others are just tools built to serve these very principles.
By declaring to be Agile software developers, we commit to value:
Individuals and interactions over processes and tools
Joel Spolsky has a fun recall of a conversation with a programmer:
It’s people, who make the software that works wonders. No process or tool ever produced anything on its own. It’s the combined power of all the team’s brains that spawns code and turns dreams into reality. It’s in the casual conversations that new ideas are born. It’s in the war rooms that they’re developed.
Processes are only there to get repeatable tasks off people’s mind. If you find yourself repeating the same steps over and over again, for instance when releasing code to a live environment, write a checklist, so you don’t have to rediscover the wheel every time.
Better yet, write a script to automate the the tasks. Tools are there to support programmers so that mundane work takes less time and more brainpower can be used for creative work. Neither tools nor processes should limit people in any way.
That’s why Agile development methodologies are often very open bags of best practices, rather than hands-on manuals. They’re meant for people to digest and adapt to their needs.
Working software over comprehensive documentation
We can always tell whether we like the software we work with. Whether it meets our needs and expectations. But we can’t reliably say whether we will like the software based on specifications. We can’t even properly express our thoughts in writing. It’s insane to expect a programmer to understand our intentions based their flawed description. While the natural reaction is to produce even more documents, it only ensures that they either:
An Agile team demonstrates small portions of fully working software to collect feedback and stick it right into the development process. The team delivers all layers that make up a particular feature, because then and only then does the result have business value. Only then can it be measured as a completed step towards the ultimate goal. And that goal is never the software itself but always solving real-world problems. That is why requirements are described as user stories, so that everyone involved stays focused on the business impact of their work.
Customer collaboration over contract negotiation
Everyone involved in producing a piece of software plays on the same team. The customer wants a product that will meet his needs and the developer wants to make the customer happy by delivering one. Any conflicts inside the team are nothing but a waste of energy, that should be used elsewhere.
There is no space for complaining about incompetent customers, lazy programmes, stupid managers and those a**holes that are “too stupid to get it.” Every person is probably pretty smart and reasonable, or else she wouldn’t have her job in the first place. Communication issues must be distinguished from emotionally charged judgments.
Agile teams keep their customers close. Perhaps not “on” the team and in the office daily, but staying in touch often, asking questions, clarifying issues as they pop up, and regularly demonstrating progress.
Contracts are created merely to protect their signees. When projects work well, everyone may as well forget that they exist.
Responding to change over following a plan
“Another layout change? They’ve got to be kidding.” is the attitude most programmers present towards modification in project scope. “Why can’t they make up their minds?” I already argued that that is not possible. Everything about a project may change at any moment, because the reality around us changes and because our minds change once we face reality. Accept it, embrace it.
A plan is still necessary so that everyone knows where the project’s heading and can make credible commitments about it. Therefore, in the words of general Eisenhower “plans are nothing; planning is everything.”
Agile teams keep their plans light and flexible, so that adjustments don’t require hours of fixing dependencies (I’m looking at you, Microsoft Project). Changes are expected to pop up until the last minutes of the schedule, so everyone treats them as regular, daily business.
Customers are happy, being free to produce new ideas and see them implemented. In the end they will still receive something of true value.
So, are you an Agile software developer? Stop talking about user stories and Kanban. Start talking about business and people.