This is not unusual. We're just using new words to describe the same old stuff. Except now we have more meetings and less time to do development. Where did we go wrong? We meet daily, we have reviews and planning meetings every two weeks.
I work for a large company. This large company whole heartedly, from the tippy top of the management pyramid to the basement of the bottom wants to use agile. Yet I still hear things like "we'd be able to use agile if management was on board." Funny, I thought management just paid to send all developers, project managers, and quality engineers to Scrum/Agile training? I hear many, many other excuses as well, like "this isn't the right kind of project" or "we're too far into the project to do anything about it now" or "change hurts!" Well, ok, I don't really hear people say that last one, but I can see it in their eyes.
Change does hurt, and people don't like hurt. They get used to hurting in one way and change makes them hurt in a wholly new ways. Trust me on this too, being the agile evangelist can make you somewhat unpopular. People don't like it when you point out what is wrong with the way they are doing things. They especially don't like it when you then go on to tell them how you have all the answers!
Change is needed. I hear in in words like "never ending project", or "requirements aren't complete yet, development just started, and we launch in 5 days", or "throw it over the wall to <some department>". I see the struggles, and I see the pain. I just want to help. Here's how to get from there, to here.
- Stop calling people resources and start calling them people.
- There is no time like the now (to start agile). Quit procrastinating.
- Fix your daily standups.
- Quit throwing over the wall (aka, what does QA do when everyone is busy developing?)
- Take as much time as you need, and fix your backlog
- Make a task board (really, I promise that a whiteboard and some stickies are better than any software tool)
- Listen to your developers.
1. What are you? A fossil fuel? A stream?
People are people. They are not resources. If they were resources, then our impulse is to mine/deforest until they are depleted. We're people. We want to be treated like people. We get married. We get sick. We have kids. Occasionally, we like to take vacations. These things affect the project. We also don't respond well to 60 hour weeks. We usually don't just up and quit, we usually start finding short cuts. Short cuts cause good code to go bad. Bad code costs way more money than good code in the long run.
2. Like pulling off a bandaid
Yeah, it's going to hurt, but it's gotta happen so might as well make it fast and do it now. There is no perfect golden moment, where angels come down from high, blowing their heavenly horns. No one hands you a golden ticket. There is no sign. There is also no time like the now. Quit making excuses, none of them are valid. Do it. Do it now. The patient is dying on the table, nothing to do but put your hands in his body cavity and squeeze the heart. It's going to be painful, but it has to be done, and the sooner the better.
3. Oh lord, another status meeting...
I spent 4 weeks or so repeating this mantra at the beginning of every daily standup:
"This is not a status meeting. This is not a meeting for the managers. This is a meeting for the developers. Tell your team (not your project manager or your boss) what you did yesterday. Also, work with your team to establish your goals for the day. Lastly, let your team know if you have any impediments. We want to hear about what you did yesterday, but we are way more interested in planning our day".
Get it. It's your team. That's a very important thing to keep in mind.
Here are signs that you are doing it wrong:
- Team members look at their manager/scrum master/project manager when it is their turn to talk
- People have "turns" to talk
- Focus is on what was done yesterday
- The manager speaks more than the developers
- You consistently take more than 15 minutes
- People are sitting down
Here's why you are not doing it right:
Team members should be talking to each other to plan their day. They should be focusing on their task board (more to come on that). They should be telling each other their impediments and working them out as a team.
If people are taking "turns", they stand up, say what their status is, and then immediately become disengaged again. This is a collaborative effort. The team is deciding their priorities for the day together. They should be deciding their priorities with the sprint goals in mind.
4. I'm done with that task. I assigned it to QA.
I cringe every time I hear "throw it over the wall". QA has been very angry with developers for a long time. I know why. Picture a waterfall. Now picture a toilet at each step in the waterfall. Now imagine everyone at each step flushing those toilets. The guys at the top (requirements, design), don't really notice a difference. The developers, well they definitely catch some crap. Usually the "crap" is in the form of less time to develop because the requirements and design weren't finished in time. Now look down another level. There's QA, catching crap from developers, and the business. They have (if they are lucky) one week to figure out what the requirements are and test this whole complicated beast. Bug reports with hundreds of defects get "thrown over the wall" to developers. Developers get mad at QA because they don't think most of these are bugs. It usually boils down to a difference in interpretation of the requirements.
Now look a little further down the waterfall. Yeah, down there at the very bottom. See who that is? No, probably not because they are flooded with a whole waterfall of crap. Well, I'll just tell you whose down there. It's the customer. At the end of the day, the whole reason for our existence is getting crapped on by everyone working on the project. <sarcasm>Sounds like a great way to walk away feeling good about what we've built eh</sarcasm>.
So how do we fix this? Well, in scrum a QA specialist is supposed to "do stuff" during the sprint while the developer is busy developing. Sounds great right? I think it does. It's not as easy as it sounds though. Here's how we're working towards doing it.
First step, and this is a big one, is to make sure that everyone on the team is present and engaged in a requirements workshop. This is where we all sit down with the customer and build our backlog. During this process, the team needs to figure out how hard something is. This is where story points come in. The important point here is (and this is a big one), the QA specialist absolutely must be actively engaged in the conversation around each user story (or feature, or widget, or whatever you want to call it). They should be asking questions about how it works. They should be pointing out inconsistencies, or things that don't make sense. They've logged hours looking at broken software. They should know by now what makes sense. Same goes for every member of the team. From this requirements workshop, every user story the team is going to attempt to complete in the next sprint or two should be clearly and unambiguously (and verbally) explained. The QA specialist should have an idea on how to test it. The developer should have an idea on how to build it. Most importantly, the developer must know what is going to be tested before developing the feature! It is insane to expect developers to build complete features with zero defects if they have no idea how it is going to be tested. This is the "stuff" that QA needs to do during the sprint. If every feature is 99% guaranteed to pass QA, then there is not a whole lot for QA to do at the end of a sprint other than running a bunch of tests that pass (hopefully this is automated).
5. The straw that broke the camel's back(log)
Your backlog is your single most important tool for prioritizing your work. It is critical to the success of an agile project. If your backlog is a confusing mess of un-prioritized garbage, you will design garbage. There's an old adage in there somewhere.
Take the time to fix your backlog (or create it for a new project). This might take half a day. It might take a week. The goal is to have a prioritized backlog. Your prioritization matters most for the next sprint or two. It matters less the further out in time you go. Why? Because things change. So there is no point in spending time nitpicking things that are 3 months down the road. Take the time to work through each user story/feature in your backlog for the next sprint or two. Assign story points. Explain why you think a user story costs 200,000, and everyone else thinks it is a 2. Thar's gold in them hills. Talking through the misunderstandings shines a huge spotlight on the issue, and everyone will have a greater understanding of what is involved if these discussions happen.
Lastly, your backlog is a garden. You need to let it grow, but you also have to take the time to maintain it. Some pruning might be needed. There might be several new tomato plants needed, and you're just now finding out. So now you need to have a talk with the business to say "hey, I can plant those tomatos for you, but I might not be able to plant the fava beans in time". Oh my, now the business has to make the decision. They really need to think about how important those tomatos are. Are they more important than fava beans? Can we survive the winter without fava beans? How about tomatos?
Most importantly, you communicated with the business on the impact their decisions make to the product. Trust me, they love this a hell of a lot more than being told "no, sorry, can't do it. You signed this piece of paper here, 3 years ago."
6. Back to the stone ages
Yeah, we love technology. We're developers. It's in our blood. We get excited about gadgets, and software. There are some really cool software packages out there for managing agile projects. They are all great. And well and good. They suck at giving the team a big picture view of their progress. They aren't physical. You don't get the same satisfaction clicking and dragging a virtual card that you do when taking a post it and moving it from left to right.
Also, as a manager, do not force your developers to use a task board. Suggest it, and coach them on it as soon as someone says "we have no visibility into the project." We have 3 teams here, all working on different threads of the same project. Each team has their own task board. Each board is different. They are a thing of beauty. Each team knows exactly what work they signed up for in their sprint planning. Each team knows how far they've gotten and know if they are on track to accomplish their sprint goals. It's truly uber, and at a glance any one (manager or otherwise) can see progress.
7. Developers don't plan projects... or do they?
Who typically creates the project plan? Well, usually it is the business. There is a business plan. It involves a product. This product has features. Every single feature is absolutely needed, and the business will fail without it. Some huge industry convention is happening, or some market condition, or some sporting event (March Madness, Playoffs, Allstar). All of this usually happens before the development team is ever even made aware of the project. Timelines are set. Features are determined. Cost is fixed. Where do we go from here?
This is where things break down. Developers start at the beginning. They are usually starting at this beginning several weeks later than they were supposed to (because the business couldn't make up their mind about how feature x should work, or design couldn't quit quibbling over the font size, or one of several other factors). The business usually drags their feet on signing off on the final set of requirements. We've trained them to ask for the world, because they've learned that if it is not in writing when the contract is signed, they'll never get it. We did this to ourselves, now how do we undo it?
Here's how agile should work, if given a chance (and assuming every one can get over their ingrained fears).
- The business needs to define a set of core features. These are the features that make up a minimum viable product. We don't need to know the exact message that needs to be shown for a form email validator. We just need to know that you want form validation. These features are then prioritized.
- Developers need to work with the customer (usually the business). Story points need to be assigned, and if we are all good little agile boys and girls, we'll have a good guess at our velocity. These don't have to be perfect, they are just estimates after all.
- We can then plot out our sprints on a calendar, and show that x number of features can be developed in y amount of time with z amount of resources.
- If this isn't good enough, well the business needs to figure out if we are going to increase resources, move the project release date, or cut back on the feature set (or some mix of all 3).
- Do a requirements workshop on the first couple of sprints worth of use stories. At the end of the first sprint, show the customer what's been built (sometimes this might not happen until sprint 2 or 3, and that's OK).
- Enter any changes to the system as new user stories in the backlog. Prioritize them against everything else in the backlog. Show the customer "hey, putting this change in means that we can't finish this other feature during this sprint, and we may even have some other features fall off the last sprint. Is this what you want?"
- Wash, rinse, repeat.
What does this get us?
Well, we are being honest with ourselves now. We are accepting changes to the product, but we are also easily able to show what the consequences are. We are tuning time, money, and features to get the right balance instead of being told what all 3 should be (which is physically impossible to accomplish most of the time). We are agile. We quit bitching about our problems and we started doing something about it. We now have a huge spotlight of truth, pointing out any bottle necks in our project, and we know that change is hard but feels so good afterwards (hey, a lot like working out!) We also have the motivation to fix those problems that we worked so hard to illuminate. The customer gets a useable product (sans crap), and developers get to go home to their families every night after an 8 hour day. Sounds good to me!
Special thanks to Bob Schatz (aka "Scrum Bob") for showing me the way.
