Continuing in the series of How to Mess Up Scrum!
Last time I explained how adding work in the middle of the sprint wrecks the rhythm of the team and undermines the concept of setting priorities.
Long story short, if you’re management and your highest-priority requirements repeatedly become visible to you in a shorter time frame than the length of a sprint, your sprints are too long! Finally, if you can’t make your sprints short enough to accommodate changes that are truly of the highest priority… then Scrum is not for you.
But let me talk about another great way to mess up Scrum, if that’s what you insist on doing.
This is another pattern I keep seeing at all kinds of organizations that think they’re doing Scrum, but really aren’t. Predictive Scrum is when (whether or not at a sprint planning meeting) the team or management tries to allocate work to future sprints.
The impulse comes from managers who want to know when the project will be done. I get it! But the thing they’re trying to do isn’t possible, it’s not in the spirit of Agile, and the way they’re trying to coerce it will just backfire.
Why it’s not in the spirit of Agile
Remember that the value of Agile isn’t in hitting deadlines. Let’s go back to basics, the Agile Principles, my emphasis added:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
“Early and continuous delivery of valuable software” is not at all the same thing as hitting a deadline. The purpose of Agile development is to keep delivering value, as much as possible, which doesn’t particularly have a regard for externally imposed deadlines. Of course creating valuable software, early and continuously, will probably help you meet a deadline… but the deadline isn’t part of Agile.
Most importantly, certainty of outcome isn’t an Agile value at all.
Again, if you want to lock in a deadline beyond the current sprint: Scrum is not for you. That’s fine. It doesn’t make you a bad person, a bad manager, or a bad company. It just means this isn’t the tool and mindset you need to accomplish your goals.
Why it backfires
The work you’re fitting into that future sprint is most likely work that nobody has accurately estimated, stories that haven’t been groomed, questions that haven’t been answered. When you pack future sprints with what you know about today, you are denying yourselves the feedback that Agile is made for.
“We don’t know exactly what goes into the GPS relocator story,” you’re saying, “but we figure it’s about 8 story points and it will fit in two sprints from now.” Great, now that everyone’s committed to that, what are you going to do when grooming reveals that it’s actually two stories? What if it has dependencies you didn’t think of yet? What if the developer you had in mind for it gets stuck on something else, a prior story that takes a lot longer than expected?
Okay, in that event you can rearrange those story cards when you get to that sprint. But you and I know that plans have inertia. You’re going to get resistance and pushback from management and other team members when you try to change an allocation that’s already made.
Why it’s not possible
Very simply, Scrum is not designed to provide certainty. People who use Scrum are making a decision that they value other things more than certainty. Thus it is not a tool that will get you certainty. If you want certainty, pick another tool. That’s all there is.
What people really do
It’s a truism in Agile, or it should be, that you never know less about any part of your project than you do right now. You will always know more later. At least you won’t know less.
Why then does everyone try to predict the future when they don’t have to? I don’t get it.
In my experience, more than half of Scrum shops engage in the Predictive Scrum antipattern. It’s tempting for a few reasons:
- It gives the boss something to mess around with and feel better about during the current sprint.
- It gives all of management a solid answer about the future, even if it’s a fake one.
- Therefore, it gives the team some breathing space from an interfering management culture.
- It’s even a bit of job assurance for developers. (“Look, there’s work with our team’s name on it!”) I have seen shops like this.
But here’s the thing. Your software development methodology should be designed to get the job done, not make people arbitrarily comfortable. If you’re messing up Scrum to give management their warm fuzzy feelings, the problem isn’t Scrum. It’s you. Stop doing that.
Renegotiating your codependent relationship with dysfunctional management is out of this blog post’s scope. But it’s essential to making Scrum (or any form of Agile) work for you. Otherwise you are just rearranging story cards on the Titanic, to coin a phrase.
Simple rules for doing it right
Scrum care is self care! These simple rules will increase your ability to get stuff done and make your work life more relaxing.
Always use the Backlog
New stories always go to Backlog. Always.
This is doing yourself a favor! Backlog is where new ideas go to be cultivated, cleaned up, evaluated, prioritized, and made ready for work. If you bypass the Backlog, when were you planning on making a priority list? If you don’t have a priority list, how on earth do you know what’s the most important thing to work on?
Look, it’s not like the Scrum Guide came fully formed from the brows of Sutherland and Schwaber. Well, actually it kind of did, but what I mean to say is that you don’t have to consider it divine revelation. But! That having been said! It shows us a tested and well thought-out process that depends on all its parts. The Backlog is essential. You leave it out, fine, but then you’re not really doing Scrum.
Always get the customer to prioritize the work in the Backlog. They can do this any time they get around to this, and it probably goes better if they do it while sitting side-by-side with a team member who can adjust for and correct any misunderstandings (otherwise known as “grooming”)
At least, you should have groomed (and ready for prioritizing) an amount of work in the Backlog that approximates what you can realistically get done in the next two sprints or so. Of course that’s imprecise: the whole point is that you don’t know exactly how much goes into a sprint. The intention though is to have a fairly sharp idea of what should be in the next couple sprints’ worth of stories so you can at the very least give the customer an informed view of what there is to be prioritized. Of course the customer should also let you know which stories are obviously a low enough priority that they’re not going to get done soon, and those are the stories you don’t have to worry about estimating right now.
Having a separate mental space for making priorities is essential. You do this in your own life, or you should; why do you not want to do it for your software development projects? Juggling a mental list of priorities, or rehashing and reordering them at the daily standup meeting when you need to be focusing on that day’s work, is a counterproductive mess. Do today’s work today. Don’t keep rethinking the priorities for the next sprint.
Stay in the present
And thus, never assign work to a future sprint!
As I said in the prior installment, “The timebox isn’t there to make developers work faster; it’s there to give everyone a short enough planning horizon that surprises won’t derail your work very much.” When you assign work to a future sprint, you’re doing the exact opposite of what the timebox is for! You don’t know what will come up three weeks from now!
Or if you do, make your sprints longer. But decide that, make the call, own it.
Scrum works in sprints so you can have a definitive beginning, middle, and end to a big block of work. It is designed for a little breathing space between the “working” parts of successive sprints. You use that time to show off what you’ve done, to figure out what actually didn’t get done and thus needs to get thrown back into the Backlog, to check in formally with the customer about what the next set of priorities are, and only then make a commitment about what goes into the next sprint.
A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.
Hear that. The Backlog constantly changes so you can make the product appropriate, competitive, and useful. It’s not a dumping ground! It’s there to help you.
I was just reading that 83% of software developers responding to a survey are practicing some form of Agile. Probably, most of those are trying to practice Scrum.
First thing, that’s probably wrong. Dividing all your work into “sprints” and having a daily standup meeting isn’t what Scrum is about, but that’s exactly what I see in the actual industry over and over again.
But rolling with that for a minute, let me talk about one specific thing that you should never do in Scrum…
Adding stories during the sprint
One of the essential Agile Principles is adapting to changing requirements, “even late in the project.” This is a great thing! It makes so much sense, mainly because it’s so unrealistic for the project owners to know in advance exactly what they will need to solve the business problem they have in mind.
Don’t get me wrong. I’m not criticizing the idea of changing (or adding) requirements. What I’m criticizing is changing requirements during a sprint.
The only thing that a sprint is about is the team and the customer making a shared, intentional commitment to finish a certain chunk of work in a certain “time box” period. If you’re not doing that and following through, you’re not doing Scrum.
In my experience, that’s almost always a one-sided commitment. The team, more often individuals in the team, is held responsible for work not done, but the customer often fails to come through with resources, information, decisions, or feedback. But worse, the customer sometimes just drops new stories in mid-sprint.
This is wrong for a few reasons:
- That’s what Backlog is for. Shops that don’t actually have a Backlog fail for all kinds of reasons.
- If the sprint timebox is too long to wait for a feature, then the sprint timebox is too long.
- The team doesn’t have what it needs to fulfill its commitment if it has to keep anticipating “what if the boss adds one more thing?”
At one organization, I frequently pushed back against stories (strictly speaking, “Product Backlog” items) going into the current sprint that were not, in my words, “ready to go” and “in our hands.” The timebox is there because of the mutual commitment: the development team is promising to get something specific done, but that’s only going to happen if they own the work.
“Ready to go and in our hands”
To give you an example of a story not “ready to go and in our hands,” we had a particular story that centered around connecting to an outside vendor’s API. It required a login and password that were only available with a signed contract, and the contract had been bouncing around Legal for a while. For a few sprints in a row, management tried to “assign” this story in spite of the fact that the contract wasn’t signed and thus no access key was available.
They offered a couple of workarounds
- “Well, the key will come through later on in the sprint.” No. First off, it simply didn’t. But even if it did, this breaks our timebox. The team is supposed to control how and when they get things done within the timebox. When management makes finer-grained demands, the team loses the ability to shift and adapt.
- “Just develop against the dummy service you’ve already clean-roomed.” No. That’s not completing the story. Everything in Agile (actually everything in any form of creative work) depends on a definition of done that precludes that kind of sloppiness. Sprint stories have to be either done or not done. There’s no such thing as “done except for the password part.”
Summary: You’re asking for complexity and failure when you push stories on a team that are not “ready to go and in our hands” at the beginning of the sprint.
What could be less “ready to go and in our hands” than a story that didn’t even exist at the sprint planning meeting? Adding a story during the sprint breaks the timebox. It takes away the team’s ability to manage its work and figure out how to get stuff done.
Also, adding a story mid-sprint jumps the priority queue that’s so essential to Scrum too! If it wasn’t a high enough priority to make the cut at the planning meeting, why is it a week later?
The allocation hoax
A lot of managers reading this are going to think something like, “If there’s time in the sprint to get one more thing done, why not do it?” That reveals the false belief that the purpose of Scrum is to keep developers working as much as possible rather than to keep delivering business functionality.
Look at it this way instead: if all the work is done before the end of the sprint, you can call the sprint over early.
Or put another way, the timebox isn’t there to make developers work faster; it’s there to give everyone a short enough planning horizon that surprises won’t derail your work very much. If you’re finding that surprises such as newly discovered requirements are urgent enough to change a sprint commitment, then your timebox is too long.
Therefore, if you can’t make the timebox any shorter–such as when it’s already only a week–the problem isn’t Scrum. The problem is that you have management that can’t think a week ahead. Fix that.
So there I was, slogging away on some .NET code at a largish enterprise that was “really into Agile, we’ve been doing Scrum for like three years now!” We were a week into the current three-week sprint.
At that morning’s standup, we’d gone around the table as usual. Jon said he was taking the refactoring story on the WCF middle tier. Ellen, who I think was Scrum Master of some other team, assigned me the task of resolving an exception that was being thrown by client-side code. Jeff said he couldn’t package the database changes because there simply wasn’t anywhere to check them into TFS (version control). I had code checked out, modified, and working to implement a feature in an upcoming release; but I was holding off on checking it back in because, per the team lead’s policy, we can’t have more than one branch “because people keep doing it wrong.”
That afternoon, the team lead’s boss came around and called a quick meeting.
Phase I, he said, was running late and he wanted to know why. And furthermore, when was Phase II of the project going to get done?
Ellen said she had all our burn-downs and they checked out, as everyone had burned down approximately forty hours. She had also added up all the estimates for the stories that were going into Phase II, and they came out to 990 hours, and since we had six team members Phase II should be done in four weeks. In fact, she said, we could put all of Phase II into the next sprint, which would give us just one week of carry-over.
Okay, that’s good, said the boss–but when can we start testing the current release, the Phase I release?
That’s when the team lead told everyone we don’t really have a deploy script for the test server, and there’s not really a production server at all. It can take IT a while to provision the new production server, he went on, but in the meantime we can host the production system on a spare Windows 2003 server. Jeff pointed out that Windows 2003 won’t run .NET 4.5 applications, so we’d have to retool the application to .NET 4.0. He agreed, though, that it wasn’t worth doing until after QA finished testing the current code.
But there were still a few tasks left before testing.
The boss thought my priorities in particular were off. “Look,” he said, “you can’t possibly need to have the API to FedEx done before the Data Access Layer.” I tried to tell him I wanted to hit the FedEx API first because it was a higher risk and thus would benefit from the greatest possible lead time, but the team lead cut me off, saying it was a low priority and wasn’t going to be in the current release anyway. (I later quietly asked, “Why was it in this sprint if it’s a low priority?” The answer: “We had to allocate all your hours and that was the only thing that would fit.”)
The boss whipped out his “to-do list” for the Phase I release. The FedEx thing wasn’t on it.
I was excused from finishing the API to FedEx, because another team needed that Data Access Layer done as early as possible in the sprint. It wasn’t on the to-do list either.
Our sprint ended successfully!
A couple weeks later, my feature in the upcoming release was still not checked in, but since my code was more or less done we figured it had to count. That WCF middle tier compiled and seemed to run okay, but the refactoring broke several unit tests that hadn’t been fixed yet. We added “Fix or comment out failing unit tests in WCF” to the sprint after the next one so we could get Phase II in first. The exception I’d gotten from Ellen took a couple of days to fix, because it had something to do with the Razor version we were using and I don’t know that much about Razor. Finally, Jeff’s database changes were handed over to a special meeting of the SQL Developers team, which was eventually going to build a schema repository.
As for rolling out Phase I, well, we had to add a story that simply read “Backfill to .NET 4.0.” The boss said that should only take a day so we assigned it three points. (Each developer was expected to do about twenty points per week, so that seemed about right.) Our scrum master said he’d take care of the test deploy script so it wasn’t necessary to add to the actual sprint. And we added a story (which just said “test”) for the QA department to do. We assigned it one to eight points, depending. And we’re not sure when that backup Windows 2003 server is coming through, but we created a story (“migrate to 2003 server”) for me to do. I don’t have production access but I can probably get an IT person to work with me on it.
You know what?
The great thing about working in a Scrum shop is that everyone’s super flexible and does the best they can without relying on management to tell them what to do all the time. It’s so empowering!
This is exciting for me. I really like C++, even though I hardly ever get to use it. It’s a super-sharp power tool that simply isn’t as useful as C# in the database-heavy applications I usually work on. I have a lot of nostalgia wrapped up in C++. I remember running across the Stroustrup book in the public library (of all places!) and being fascinated by the concept and implementation of object orientation.
Sure, a lot of people would say that ruined me, because C++ is far from a purist’s language, but in its era C++ offered a pragmatic solution to a great many typical development challenges.
What’s new in C++
First of all, you know how you can use that
var declaration in C# when it was too inconvenient (or at times impossible) to specify the type of a variable? You can do that in C++ 14 and you can specify the return type of a method the same way!
There’s a new
[[deprecated]] attribute. It doesn’t break any code, it just kicks out a warning when you try to call anything that you’ve flagged as deprecated. Good way to soften the transition away from an API or implementation.
Syntactic sugar: You can now have digit separators in constants. You can write a million now as
1,000,000 if you want.
Generic lambdas with auto type parameters! That’s kind of esoteric, but the point is being able to declare lambdas that will figure out for themselves at compile time what argument types they need. It makes them more reusable.
C++ is still vital. It’s changing and getting better. I like it. I wish I could use it more.
“I haven’t had a real job since 1996.”
That’s what I keep telling people, and that’s largely true. If by having a real job you mean a salary, a long-term connection to a single employer, and company-paid benefits, then no, I haven’t had a real job in that long.
Honestly though, a lot of what I’ve been doing at work in those 18 years has been largely indistinguishable from having a real job.
Much of the time it’s easier and more profitable for me to work with those third-party contracting firms. They take care of a tremendous amount of the work that goes into getting work, and the good ones take a fairly reasonable cut off the top. (Typically it’s 25%, which sounds like a lot but have you seen how much staffing firms in other industries take?) What’s nice about this for me is that these firms have existing staffing contracts, functioning accounts receivable and payable, and a steady flow of open work requisitions. Most of the time, when I’m nearly done with a major project at one client, the same contracting firm goes through its existing client list, finds an open requisition that matches my skills, sets up an interview with the hiring manager, and has me checking in on the very next work day.
When all I care about is remaining “billable,” this is a good system. There are a few downsides though.
Requisitions are pigeonholes.
They are looking for programmers, QA people, project managers, and system administrators. They are looking for these people in either .NET or Open Source flavors. Add one category for network administrators, who seem to be allocated on a platform-neutral basis. (I don’t really know; it’s not my area.) That makes four times two plus one equals nine actual jobs that exist in the world of third-party corporate contracting. There are no coaches, no problem solvers, no interdisciplinary people, no jacks-of-trades. If your background makes you really good at seeing why their waterfall is blocking or at picking out why QA keeps having to look at the same defects over and over again, that job description doesn’t exist to them. So you have to decide which one of those nine things is you, and go with that, even if it’s an oversimplification of what you’re capable of.
Contract-to-hire is a scam.
Another downside, to some of us, is that creepy, weird “contract-to-hire” status. A lot of companies bring on technical people, on a contract basis, with something like a “right to hire” clause in the contract. I’m not clear on what this means exactly, because I don’t even consider those things, but it sounds like they’re asking you to accept a job they haven’t even offered yet. That sounds like a terrible deal. I’m supposed to sign a contract that locks me into a salaried (implied somewhat permanent) job when I’m not clear on what the job is, what it pays, and what the benefits are? What the hell is that about?
I don’t do “contract-to-hire.” It’s designed to put the worker at a disadvantage. Why would I want that?
Yet another downside came up for me a while back, when I was about halfway through a six-month contract gig doing .NET development. It was going pretty well. I felt like I could have caught on faster to how the client’s ancient version control system worked, and it was clear that they were having some trouble allocating people to their three or four Scrum teams, but I did get to help a lot with a new product launch. My handler at the contracting company called me now and then just to say he was hearing good things about my work.
At one point though, I emailed my team manager (who supervises maybe about two dozen people) to let him know I would have to take an unknown amount of unpaid time off, specifically saying “my partner Jamie”–I used those words–was having gall bladder problems and there would be some hospital time. That week I missed a day and a half. My handler called the following Monday to ask why my timesheet read 28 hours rather than 40, and I told him. You would think that would be good enough, right?
That week I also billed 28 hours with another day and a half off of hospital time. It did turn out to be more than your typical gall bladder issue. Keep in mind that I was always keeping the team manager updated.
This place does three-week Scrum sprints, so missing three whole days is somewhat significant, and I had to scramble a great deal to come fairly close to fulfilling my share of the sprint. (That’s another issue: Scrum is a team commitment. We’re supposed to compensate when someone falters. That’s the idea.) Those three weeks were ugly. My personal burn-down chart looked like a jagged sine wave. But it did hit bottom in the end.
Speaking of hitting bottom,
after that, it wasn’t remotely the same. Even though my role going in was clearly to stick with .NET middleware development because I’m not good at front ends and browser scripting, I got handed a lot of browser scripting defects. (Again: not so great Scrum, right?) Planning meetings for the next big project were carried out in my absence. Standup meetings even got a little hostile. One of my handlers called to criticize me for having a personal life, with some reference to not deserving unpaid time off. It was weird.
What Jamie said after all this:
“Next time, just say it’s your wife.”
All I can figure…
…is that in this shop, they feel that a person who’s willing to work on a contract basis should be so grateful for the opportunity that we should drop absolutely everything else, including family and loved ones, for the opportunity to be micromanaged and disrespected. And pretend to be straight while we’re at it.
I chose to finish the six-month engagement quietly before taking a nice vacation. And if that particular staffing company ever wants that 25% of my billing rate again, we’re going to have a rather direct conversation about who gets to have an opinion about their sense of entitlement to my personal life.
So I don’t do that.
Here’s how it goes. I do a lot of straight-up freelance work–custom application development, coaching, training, and team leadership–directly for all kinds of businesses and organizations. Doing my own marketing and business development is actually a huge amount of work, and it gives me all kinds of respect for the people who do that all the time, but it’s still my job so it doesn’t feel like a distraction.
In fact, what I learned from gurus like “Original Mark” Silver and Robert Middleton is that marketing is inseparable from products and services. Part of delivering great work is letting people know it’s available. Part of publicizing what you do is the act of doing it. It’s actually not realistic to say “I only write code, I don’t do sales and marketing.” You’re doing it whether you know it or not. Whether you like it or not.
Thanks but no thanks
So when the rent-a-geek firms call, and they will, I think I’ll start referring them back to this blog post and thank them for their interest. I like having tons of billable hours handed to me, but at this point the attached strings aren’t worth it.
I’m doing a new thing now!
If you’re currently on my eZine and announcements opt-in list–and you should be, because it’s usually not boring–you found out about it this morning.
Long story short, and not to kill the suspense, the main thing is that if you send me some problematic C# code, along with a very reasonable amount of money, I will turn around a solid code review, complete with prose narrative, suggestions, and maybe even bug fixes. (I’ll put all the details up next week, but that’s next week’s problem. You should be on the opt-in list!)
One thing I won’t do, though, is impose “coding standards.” I don’t think you should have them.
Why you shouldn’t have “coding standards”
Okay, that’s actually wrong. I do think you should have coding standards, even if you work by yourself as a lot of my fans do. Have a regular, standardized way of naming things. Of indenting. Of when to break something into more than one class. Of when to unroll loops.
Sure. There’s nothing wrong with that if it makes you feel better.
The benefit of having standards is that you don’t have to think about them. That’s why I’m saying… don’t have them.
Here’s what I really mean.
Again I’m going to play the “I’ve worked in sixty development shops” card. I’ve seen a lot of single developers, startups, growing concerns, flailing concerns, and mega-corporations do software development to a WIDE range of success. And pretty much always, someone senior at some point calls a meeting and says…
…Let’s Have Standards.
In practice, that means you spend a few hours in more meetings going over the oh-so-important issue of whether to name your classes in camelCase or PascalCase. Where the curly brackets go. You know, all that stuff that ReSharper already does for you.
I’m saying those meetings are not a productive use of time. Your deliverable becomes a set of rules that everyone either has to try hard to remember, or rules that nobody bothers to follow at all. And I keep asking, what is the problem you are trying to solve here? Nobody’s totally clear on that.
- If your architecture is too complicated, reduce the architecture.
- If you lack unit tests, build code with unit tests.
- If your code is too tightly coupled, think about where the seams should go.
- If it’s hard to find the class you want, pick better class names.
- If you have a lot of duplicated code, refactor it to remove the duplication.
- If your problem is excessive defects, then “standards” aren’t going to help at all.
So either you think about these rules and they get in your way, or you don’t follow them and they don’t help you. In any event, they don’t solve any actual known problem. Come on, when was the last time you honestly couldn’t get something to work because the curly braces were in the wrong place? Ever?
Here. Let’s make it easy.
Why not save everyone some time and annoyance and just use ReSharper? You can leave the default ruleset, which is a pretty reasonable one, or customize it if you really really want to, but the important thing is to set it up and not worry about ever again.
The main thing is to know what the problem is that you are trying to solve instead of getting excited about a solution that may not help you at all.
I’ve found that the shops that take more than about fifteen minutes, ever, to discuss “coding standards” are the ones with pretty severe process issues that “standards” won’t at all fix. The right path is directly to the source of those problems, not one of avoidance.
A while ago I posted about Baqbeat, an enterprise systems management tool being developed by my college homie Dave. A lot of things have changed since then.
For one thing, the name has been updated to the less quirky but more descriptive “Congruence.” For another thing, the code is actually getting done. And, as we were discussing the other day, the minimum usable product concept has been pretty well refined.
Why this thing even matters
In a recent Facebook chat, Dave put it this way:
That is my real, underlying motivation… cutting back on the bickering and finger-pointing! It starts with replacing “But we didn’t change anything!” with “What changed when?” and getting a computed rather than human answer.
Then I ran into John, who runs a pretty substantial outsourced data center, at my favorite coffee joint in Lakewood and talked his ear off for an hour and a half. The thing he picked up on was the distinction between change control, which everyone wants to do but nobody has figured out, and change observation, which is actually feasible. I think it was John who said that trying impose a global solution to maintain all the database structures, configuration files, source code releases, and other knicknacks in your big corporate setting is “boiling the ocean.” He’s right. Strategically, you can try to control everything–which becomes a huge top-down endeavor that depends on someone making a big decision and making scores of underlings follow through–or you can take the gentler approach of watching what does change, and correlating it when something goes wrong.
I could go on for a while about the Congruence architecture that supports all this monitoring and correlation, but the cool part for me is that it has Agents and Minions and Dave doesn’t know very much about .NET. So in a couple months you may see me coding a base Congruence Agent for .NET.
For another perspective, Dave summarized his “aha! moment” on this point about observation.
What you can (and should) do now
If you have anything to do with changing or managing stuff in a network that has more than about three computers, go to the pretty placeholder site for Congruence right now and get yourself on the email notification list.
Start thinking about things in your network that change and break stuff. Think about how much it will help to have something that just lets you know what changed.
Get ready for a fall pre-beta thing.
In the past five to eight years, as I’ve worked in a lot of big corporations that have “gone agile,” I’ve been in hundreds of daily standup meetings. Many of them have been great. Many more have completely sucked.
Let me talk about the suckage and how to deal with it.
First, fundamentally: actually standing up
First thing, if your standups are honestly too long for people to be standing up comfortably, they are too long. “Standup” isn’t just a cute name. The idea really is to make it super fast and get back to work.
Maybe I’m a little biased in this because of this worn cartilage in my left knee that gets rough when I stand still for too long.
How to deal with standups that run more than about ten minutes:
- Consider a smaller team. Maybe five to seven “pigs” is best.
- Quiet the chickens. If you’re observing as a stakeholder, great! But this is not your meeting. Just listen.
- Stick to three questions. Everything, and I mean everything, comes back to the three questions.
- What did you get done yesterday?
- What are you trying to get done before tomorrow?
- What are your obstacles?
Second: keep it on track
A pattern I keep seeing is when the team lead, or more often that person’s manager, has decided that someone’s work isn’t up to par and uses the standup as a way to focus pressure on that person. That’s bad management style in its own right but it also makes the meeting itself less useful. If you use the gathering to point out how many defects one team member is generating, everyone else will minimize their defects to avoid being similarly called out. If you bust one team member for overshooting an estimate, the rest of team will tend to pad their estimates. And so on.
To eliminate this particular kind of suckage, make sure you’re talking about today’s work today. That’s all the standup is for. Discipline, correction, motivation, and evaluation are not on the agenda. It is for planning one day’s work. You want another meeting, make another meeting. Don’t impose on this one.
Finally: the team owns the sprint
Whether or not you’re organized as an actual Scrum team, team ownership is always a good idea. If something’s not going well, the individual team members are almost always aware of that first. If you’re doing it right, they have already started to make adjustments even without the formal intervention of a standup meeting. When that’s the case, and it usually is, less management is probably better.
If you find yourself dictating solutions, you’re undermining the team’s ability to solve its own problems. Resist the impulse. Step back. Give the team at least a couple of standup cycles (which means two or three work days) to figure it out before you consider imposing a plan. At worst, the time “wasted” this way will pay off in education and experience.
Again citing the Agile Principles: Give them the environment and support they need, and trust them to get the job done. More support, less intervention, fewer distractions. That’s how to make your standups not suck.
I saw this on LinkedIn a few years ago:
The bulk of my professional career has been spent working on software solutions for start-up companies. These projects typically (1) do not have established coding practices, (2) have tight timelines, and (3) have requirements that can change on a day-to-day basis.
With this in mind, I am always interested in learning about more effective approaches to software development. So my question is: “Is agile development yet another buzzword, or is there substance to this approach?”
Here’s how I responded:
Think about Agile as a means to get solid, well-tested software that is designed well, solves problems, and is amenable to change. You don’t need to have every coding standard determined up front–perhaps you’ll want to use an Agile process and mindset just to develop those standards–but your efforts will definitely fail if you think of Agile as a mess of shortcuts.
If it’s slapdash, it ain’t Agile. If it’s a shortcut, it ain’t Agile. Agile probably feels like the long way, actually, because you have to pay more attention as you go along.
Agile usually means less design up front in exchange for continuous design as the project evolves. The exchange part is important: there’s still no free lunch. But it’s not design-design-design-code-code-code. It’s design, code, design, code, design, code. (Or better still, it’s design, test, code, design, test, code…)
Your item #3 in particular (daily requirements changes) could point to managerial dysfunction, which makes Agile really hard; or it could point to a dynamic business model, which makes Agile incredibly useful. Or both. You may well find that a well-executed Agile development process draws attention to poor executive management. (Whoops.)
In answer to your question, though, Agility is definitely real. What’s not real is the idea that you can sprinkle Agile fairy dust on a hierarchical mess and everything is all better.
In fact, about the worst thing you can do is to impose Agile practices (such as daily standups, user stories, and sprints) without working the cultural changes that motivate them. For example, I’ve seen the daily standup used as a manager’s checkin and problem-solving session. That’s not a bad thing to do, but it’s not Agile because it makes one person the bottleneck, and it almost always becomes a scorecard situation rather a collaboration.
Likewise, the essence of the sprint (in Scrum) is that you use each one’s retrospective to inform the plans for the next one. The idea is to get rapid feedback from everyone and actually adjust to it. Which explained why I laffed out loud when overhearing a neighboring team’s project manager crow that “We’re really Agile! We have all our sprints planned for the next two years!” Sure, she got her Gantt chart filled out, but she precluded all meaningful input from the team.
Long story short: it’s real. But the key is to forget about the Agile practices and “tricks” you want to learn. Stop, pay attention to what your team is (overtly or covertly) asking for, and go about changing things in response to how your team really works. There are no buzzwords or shortcuts to it. You have to be willing to listen, to give up power, and in many cases to find out you are totally wrong.
If you’re up to that? Then it’s not a buzzword. But that’s up to you.