Designed, developed, handed over to QA for testing. Then all hell breaks loose. “How do I test it?” “Where’s the documentation?” “This is broken; not it’s not, it’s not our component.” “I’m not signing this off!” Or my personal favorite: “I’ve other priorities to test now. I’ll get to your stuff tomorrow.” for three days in a row. Keeping QA separate from development teams is a recipe for trouble, friction and lots of missed opportunities. It has to stop.
Once you put a QA Engineer in the same team with developers, sharing the same manager, several things happen:
Sounds obvious if you’re an Agile zealot, right? Notice how I never used the “A” word? I didn’t have to, because the above ideas have nothing to do with the movement. Even Microsoft knew the value [PDF] of pairing developers and testers way before Agile was even manifested.
Testing is not separate from developing. It never has been, but today, when software requirements and markets change all the time, and so does source code, it’s more expensive than ever to keep a QA team separated from development. For the sake of your company’s success, stop doing that now.
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.
I’ve yet to see a company that, having sound leadership, failed. I’ve also never seen one to succeed with bad leaders. And the surprise is that being a “good” or “bad” leader has nothing to do with how you treat people around you. You can be a tyrant (Steve Jobs), a bully (Bill Gates), a corsair (Larry Ellisson) or a friendly, passionate geek (Larry Page, Sergey Brin) and succeed nonetheless. But if you lead in the wrong direction, then boy, you’ll hit an iceberg sooner than you can spell “Titanic”.
This isn’t to say that you should immediately burn your copy of “How to Win Friends and Influence People” and start screaming around at your team like a drill instructor. But it does mean that if you’re not naturally a social, likeable person, trying to change yourself is probably a misallocated effort. You may rather want to spend time getting to know your market and learning as much as you can about your domain. Put a lot of work into becoming the best expert in your field.
Being a great leader may motivate people to row faster, but it won’t help anyone if you’re all heading for a cliff.
Human resources they call them. The drones that keep typing on their keyboards producing lines of text that make monitors light up in different colors, depending on what other drones type. They’re characterized by output, productivity, typing speed, number of bugs introduced to code, days taken off for holidays or sick leave, availability as percentage of time. Those pesky employees.
People are not machines. A machine is something built in a cumulative output of human knowledge. An expression of human potential. For any machine there is a constructor, who
Can someone construct a person? Does anyone understand how each and every part of the human body works?
We are creative, surprising, non-deterministic, self-repairing and irreplaceable. If we were easy to replace, why would we have cemeteries?
Do you really think you can move your employees around, from desk to desk, from office to office, from city to city, from project to project, from task to task, without taking their opinion into account and without any loss of their creativity, productivity, devotion and thus quality of results they deliver to the company?
I came up to a coworker and asked how long it would take him to complete a task for me and whether he’d be able to do it within a few days. “Sure, that’ll be quick and I can probably do it. But I need to ask by team leader.” Excuse me? I would expect that answer from a 7-year old, having to consult his mom for allowance to go out and play, but a tall man in his late twenties is something completely different. Why aren’t you in charge of your own work?
If you’re dreaming of making any sort of career beyond line employment, then you need to start thinking for yourself. Of course you report to someone and of course he or she will be handing you over assignments, tasks and projects. But you have a mind of your own and perhaps an agenda for yourself as well. Ask your team leader, manager or whoever else is above you for goals - descriptions of areas you should head with your work towards, and don’t accept tasks or todo lists. Obviously you can’t tell your manager to go to hell with his orders, but what you can do is to analyze what you received, come up with your own way of getting there and propose that back.
The difference is profound. It’s not about rejecting orders, but about making your own plan. “Boss, I’d like to do it this way. It’ll let me achieve A, B and C on time. And there’s this other task a colleague asked me for. I’d like to do this tomorrow and shouldn’t impact any other goal and deadline I have. Is that fine?” Of course it is.
If you read Stephen Covey’s 7 Habits of Highly Effective People, then the above should remind you of habit 1: be proactive. Very true so, because that’s the very same thing. I just can’t stand the whining of people who are continuously dissatisfied with their work assignments, yet when asked about what they do to change their situation, claim they have no influence on what’s coming at them.
You do. The sooner you understand it the quicker your career will take off. Don’t ask for permission. Act.