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.
My attention was drawn this morning to an article on “10 Technology Skills That Will No Longer Help You Get A Job.” I’m not so impressed, mainly because I spend a lot of time around people who do research. This… isn’t research.
#3, “Software Support,” has no support.
The evidence for #4, “SEO Specialist,” is that Google renamed its Search Group. Nomenclature has power! That’s why my retirement account is named “Piña Coladas on the Beach With Jodie Foster.” (I am not making this up.) It should work, right?
#5, “QA Specialists and Managers,” seriously? “These days, the tech industry seems to be following Google’s lead and turning everyone into beta testers.” Hey, just because it is being done doesn’t mean it really can be done. This is a trend that won’t work out. (As some of the commenters pointed out, how’s that going for military and medical applications?)
I could go on, but the main thing I’m seeing in this article is a host of extrapolations, half-baked wishes, and flip assumptions. I do that all the time, too, but I save it for when I’m bored on long driving trips with anarchists. Heck, even my speculative blog posts here are full of anecdotes, not wild guesses.
Honestly, I’m just not seeing the value-add in that article. Maybe it would have been a good “link collection roundup” kind of post. Nothing wrong with that.
I got a kick out of today’s XKCD comic strip. (Chart: “How long can you work on making a routine task more efficient before you’re spending more time than you save?”) It reminds me a lot of a conversation I had last Friday with an entrepreneur who’s trying to automate some, but not all! of his information business.
See, “Allan” gets a lot of documents that are not so well standardized, puts their contents into a database, and essentially gets paid by his client companies to let them know when and where they–or their subsidiaries–are mentioned. (There’s more to it than that, but this is the relevant part right now.)
Baqbeat is a little hard to describe. Dave filled me in:
Baqbeat generates timelines of configuration changes to all the servers in
your development and operations environments – version control, build
servers, app servers, databases, and others. It automatically infers
related events on different timelines. So for example, you can see problems
in your production environment and immediately trace it to the code change
that broke it.
(tl;dr: Answer a few easy questions to see if I can help your startup!)
Do you have a startup company that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Are you still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?
I’m hearing you.
So you have this small business. You probably just started it. You’ve got a pretty good business plan, you’ve stashed some money to keep it going until it breaks even and can pay you, you’ve worked out health insurance and stuff… or maybe you’re keeping your day job and working a lot of nights and weekends to get it together. And it’s a cool idea: some product or service that people are definitely going to want to pay money for. It’s exciting and terrifying, because you don’t know what could go wrong, but you’re also a little apprehensive about how it will go right in the end.
Well! I just spent a lot of time with various tech-related startup companies. Some of them have Projects That Suck; others are simply getting started with new things. I’ve learned a lot more about what does and doesn’t work, and I’m ready to share the results with you.
Do you have a startup that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?
If this sounds like you, watch here next Wednesday for the plan and the details. We can work together to get your startup project on track, within budget, and under control. I’m really excited about this. I think you will be too.
I’ve been underground and off the blog for quite a while now. A lot of distractions have been going on, and the biggest project over my last couple of years has been under heavy non-disclosure, so there hasn’t been much to write about and even less time to write it in.
But one of the biggest distractions is on its way out. That’s right… the criticalresults.com server is getting an upgrade! Yay!
I was recently developing a significant new feature on an ASP.NET application. The client’s regular dev team is located in India, but for this new feature they wanted somebody whom they could work with face-to-face, and having me dedicated to the project (for a short time) seemed like an advantage.
We started off really well. I was able to get into TFS for version control, connect to the development database, and add a few basic pages to get started.