We’ve all been there: the calendar turns against us, stakeholders –known and unknown– are coming by more frequently. People are asking for status more often than they’re asking to help. There’s no choice but to hunker down and Hero-up. Stay late for nights on end. Bang out the release. Make that date and turn the calendar back into a neutral party. You’re a Hero! You got it done!
And you need a break. That break could be a couple days and it could have lingering effects for weeks. The next planning session, there’s no enthusiasm. The retrospective is lackluster — you’ve been working on the same thing so long that you don’t know what to even address or talk about (a lackluster retro is another topic, coming soon). Being a hero has a cost: the post-release hangover is hard to get out of. It’s hard to fire up the engines when they’ve burned so hot for a long time. Being a hero is great: we feel good for helping our client, the client appreciates it (most of the time), and we get amazing amounts of work done in a short period of time. Unfortunately, the ensuing lull negates most of that productivity. Our motivation is sapped. Our discipline is questionable. We start losing touch and eventually, burn out completely.
Agile principles –iterative and incremental development, specifically– are designed to prevent heroism. Sustainable pace rules the day. It’s better to be 80% productive across three months than it is to be 150% productive for one month– inevitably followed by 10-20% productivity for the next three.
Heroism happens –some situations demand it, and for those exceptions, sure, be a hero. Please, don’t make a habit of it. Plan for gaps. Plan for slack. Plan in sustainability. The team will be happier, and though it may sound counter-intuitive, more productive.
One of the common questions asked during scrum master training is, “what does a PM do on a scrum team?” It’s a fair question –scrum and agile practices totally de-emphasize traditional activities of a project manager. The PM isn’t accountable any more, the team is; the PM isn’t handing out tasks, the team is; the PM isn’t even driving anymore, the product owner and the team are driving together. Probably the hardest transition is the PM is no longer the captain of the ship. Especially on a well-functioning team, a PM may feel like there’s nothing to do except set up meetings here and there. I’ve heard one PM say he felt he was relegated to project “administration.” It’s not that bleak. Fear not, dear PMs, for an agile team still needs you. And needs you desperately. This is my call to you:
You protect the team from outside forces.
You know enough about the product to keep the team focused when it starts to wander.
You support whatever they need to stay focused (even if it’s bringing in a coffee maker).
You are eyes and ears to the outside world –you are their scout.
You listen to what else is going on, looking for crossover points that affect your team.
You listen for requests to talk to external teams.
You jump in to push people to talk to each other.
You listen first, read your ALM tool second.
You are inquisitive and Socratic, confirming that the team is aware of its decisions.
You are the bridge and vehicle that connects the team to everyone else, working hallways and meetings like an experienced politician.
You are shepherd, coach, early warning system, confidant and reality check.
How, on a day-to-day basis, can you do this? Know your tools. Outlook, WebEx, Rally, Excel, whiteboards, sticky notes, pen, paper, your feet, ears, voice. Be expert in the nuances of meeting requests. Have the WebEx started a couple minutes prior to the meeting. Take notes as if you have amnesia, and make them public. Know when the tool is getting in the way, too. Don’t hold up the velocity of conversation by reordering columns in Excel. Take notes and clean-up later, sharing the results.
You have a lot to do, and I look forward to your success.
Part of agile development is a notion of deferring decisions until the last responsible moment. Like many over-referenced attributions, there is a lot of context and background to the statement. For example, if you quote this out of nowhere in a sprint planning, you may be received with some strange looks. Especially if there are people on your team who like to answer every question up front.
In Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck spend some time on this subject: “The moment at which failing to make a decision eliminates an important alternative.” They go on to elaborate some techniques of deferring that moment as long as possible, notably highlighting well-understood Object Oriented Design principles. Good OO practices keep options open longer, make alternatives easier to try, and make final decisions easier to implement. Aside from OO coding practices, how do you keep this notion in mind when there are sprint deadlines to meet, architectures to design, and functionality to build?
Easy does it
- Keep solutions simple –sure you should abstract literals to a config file, but don’t overdesign a super-robust-survive-the-apocalypse configuration reader. And do you really need to put them in a file now?
Know your story map
- Did you write code last sprint that will get touched again in two sprints?
- Will you encounter similar entities? Similar functionality? Great! Do some future-proofing (empty base class, anyone?) but don’t go too far –things will change
Let the patterns emerge
- Designing a Façade pattern on top of a Factory implementing a Repository is great way to start, if you’re taking a Patterns exam. Solving the problem pattern-first eliminates alternatives. –You’ve already decided! If you have three or more instances of similar action, and things start taking on an identity, thendecide if it merits an official Pattern
Are you in a corner?
- If you’re in a situation where inaction stops forward progress, you’ve gone too far. In other words, are you in a situation where there is only one choice, and that choice is expensive? What is the slimmest solution that gets the project moving again?
Always ask, “what if we don’t?”
- What happens –I mean really happens, not some theoretical case– if you don’t implement a particular pattern, or abstraction, or architectural nuance? Consider this seriously and frequently.
The last responsible moment is different than the very last moment. The very last moment is panic. Major refactoring is the very last moment –and isn’t responsible (in any sense). Keeping an eye on “responsible,” you’ll guide your project to do what makes sense, one small decision at a time.
Happy Holidays!
(This started as a response to a question on LinkedIn)
Refactoring — the development practice of making improvements to the code base as it evolves– can be a trouble spot for new teams. At a client, it may be a bad word, carrying a connotation of shoddy workmanship, “why are you refactoring, isn’t it right the first time?” Refactoring (like unit tests) is an intrinsic portion of the development cycle. The longer it’s ignored, deferred, or separated, the more fragile the system will be. Refactoring is a day-to-day, hour-to-hour, minute-by-minute process. As I’m writing this line of code, what other code am I affecting, and how can I eliminate duplication, separate responsibilities, and decouple the code this line interacts with? What other code in the application needs to be enhanced to support what I’m doing right now?
In teams that are resisting to refactor in this mode, I’ve asked them to include task-level items for refactoring initially to get the process part of completing the story. However, I’d say this isn’t best practice. –As a task, a developer (and I include myself here) too easily segregates the activities: “first I’ll code, then I’ll test. Oh yeah, I have to refactor. Well, it doesn’t need it, so I’ll just mark the task complete.” It doesn’t happen. One the other end of the spectrum is the refactoring task that takes 4 days on a 1-point story. Refactoring isn’t the blank check to redesign the entire data layer. It’s small improvements, made constantly, adding up to large improvements. Once there is some muscle memory of refactoring in smaller chunks, I give the team the option of not explicitly tasking the activity.
By making it a separate story, you’re subjecting that story to ranking, and your product owner (and team) may rank it low, then lower, then off the backlog. Bad news for refactoring. The other impression it makes on the team is that it’s a separate activity, meaning it can be negotiated, deferred, and possibly not done — especially if the sprint is tight and not all stories are getting done and there’s the big release coming up. Again, refactoring must happen in tiny increments, as the code evolves during the day.
Now, if by “refactoring,” you are talking about a hardening sprint(s) where the everything freezes and whole team retrofits large portions of the system, then that’s a smell all on its own, with a different approach. Do you have developers writing code all day long before running the code even once? Or writing code for a couple hours before one test is written? How many days do you go before “integration?” Work to shorten these cycles. These are the loops to draw in. The tighter the test/dev/build cycle the more naturally refactoring happens. A good developer in a groove is compiling and testing after every few lines of code. Sounds radical, but it’s how the Good Stuff works.
Let’s say you’re on a team in the middle of a project and together you decide to implement some agile. Great! There’s a lot to do, enough to send any mild-mannered IT person into analysis paralysis. Do we start unit testing? Who knows how to set up a build server –and is it TFS, or Hudson, or TeamCity? What’s Selenium? Where’s our project plan, and who knows how to turn it into a backlog? Heck, who’s going to be scrum master? It’s overwhelming. Take a breath. First of all, congratulations on the first faithful step: the decision to give this agile thing a shot. Second, shifting an existing team into “agile mode” is a little easier if you start with a retrospective. We’re going to start moving forward by first looking just behind us, in our first retro.
Set up a significant block of time (a few hours). I suggest a Thursday afternoon –it’s late enough in the week to get quality work done, but not so late that everyone is checked out or mentally drained.
Your attendees are the core team: the people that are responsible for the daily delivery of the project. Essentially, your Dev and QA. No stakeholders. No management. No client representatives (unless they are a dedicated member of delivery). You need to have one person acting as facilitator –but this person is not “leading” the retro (more on that in a second). Most importantly, make sure everyone on the team can and will attend in person. If your team is scattered across the map, impress upon the Powers That Be that costs in airfare and hotel are insignificant to the resulting improvement in productivity. Seriously.
Go somewhere offsite. Get away from the same conference rooms, the same hallways, the same lighting that you and your teammates endure every day. It can be a coffee shop, a park, library, anywhere quiet and private enough to hear each other. Give everyone the chance to decompress.
Now, let’s start our first retro.
One person (the scrum master or PM) facilitates the following discussion with a few ground rules: 1) everyone speaks, 2) the PM/leads/strong voices in the room speak last, 3) nothing is off limits.
Capture the following (pluses):
• What about the team makes it successful?
• What about the team is unique and special? (Do you have a mascot? Does everyone wear Hawaiian shirts on Fridays? Is yours the only team with a COBOL programmer?)
• What about the current process or flow is working well?
Now talk about what isn’t going well (deltas):
• What are the team’s pain points?
• What are individual pain points?(Be honest and open)
• What can we do starting tomorrow? (A favorite of mine is to ask each person, “if there was one thing changed tomorrow that made your day-to-day more productive, what would that be?”
Capture these pain points in a format that can be voted on. This is more than just airing laundry. If there are things that aren’t going well, then the only people that can improve the situation are sitting right next to you. Have the team narrow the list to a workable set of items (dot voting is one way). For a first retrospective, I suggest no more than three tangible action items. Here’s the fun part: the team self-assigns those items, with commitments to complete. Set a date for the next retrospective, ideally between two and four weeks away.
Wrap up by revisiting positives. Thank everyone for their hard work. Appreciate each other. Remember that you are on a team, and a team operates, improves, and succeeds together.
I had the opportunity to take a couple days with just the bike last weekend. –And I can’t go any further without thanking my wife. The planets aligned, the nieces and Sis-in-law came over for the weekend, and I had free reign to take the bike, drive somewhere, and disappear for an overnight weekend of solitude and turning my legs into butter.
No white noise machines.
No baby monitors.
No 23% chance of my son waking up in the middle of the night, needing attention.
Don’t get me wrong, I love my family. My kids are the best thing I could ever have, and my wife is simply the Best Woman on Earth. Still, spending ~30hrs solo is dreamy, healthy, and I needed it. I’m a firm believer that time spent on #1 frees one to be totally dedicated to others. Counter-intuitive, I know, but there’s plenty of evidence and publications on it in addition to my personal empirical evidence. So when the wife mentioned I could take a little jaunt, I only confirmed twice before making plans.
By making plans, I mean going as far as picking a locale with the minimal requirements: close-by to not spend all day in the car, road biking on roads I haven’t seen, and relatively cheap accommodations. Other than that, it didn’t matter. I planned on driving somewhere, riding a little bit on Saturday, have a beer and some reflection, and ride on Sunday before heading home. And I wanted to do riding reflective of Colorado– mountains. With those parameters in mind, I started scoping out locations within a couple hours’ drive. Steamboat? Just a hair too far. Vail? I’ve ridden Vail Pass and surrounding enough that it wouldn’t be unique. Durango, Crested Butte, too far. Salida and Winter Park I know as a mountain bike spots, and I’m too much a wimp on the SS to take it for a weekend. A group of friends were camping in Rocky Mtn National Park, but I wanted to sleep in an actual bed (and I’ve ridden Trail Ridge before, and I wanted solo time).
What about Leadville? It is known as a mountain bike destination, but there is Turquoise Lake, and Independence Pass down the road. And, Independence Pass played host to the USA Pro Cycling Challenge just a month prior. And I could get a night for under a hundred bucks. Done. The Plan solidified into: Drive to Leadville. Ride a couple laps around Turquoise Lake. Have a beer. Think about Things. Sleep. Ride Independence Pass. Come home. A pretty good plan, if you ask me.
(I’m skipping the part about getting a speeding ticket just 25 minutes into the trip. Ugh.) I chose to drive out 285 to Buena Vista then north to Leadville instead of I70. Kenosha Pass rewarded my decision with some stunning fall colors. It’s going to be a good weekend.
I got into Leadville around noon-ish, too early to check into the Silver King Inn and Suites (I’m also going to not mention that the Silver King had a sign on the front door warning prospective guests that they didn’t have heat in 2/3 of the hotel — renovations). I took that opportunity to drive around Turquoise Lake.
Now I’d heard about a “lap the lake” race held every year. I didn’t realize that it was a real Strong Man’s Race. There are two climbs as you circumnavigate the lake, one being pretty stiff. I drove around it wondering if I was really in shape to do a couple laps (~15mi per). I’ve been riding some this year, though it’s mostly been commuting to work –a 14 mi round trip. To this point the longest ride I’ve had this year was ~50mi, but that route is 90% flat. Lapping this lake is something a little different –mostly because it’s at 10,000 feet. That’s a significant impact, even to someone who lives a mile high. I checked into the Inn wondering if I do just one lap, telling myself I’ll just take it as it comes. After all, I’m up here to enjoy myself, and Independence Pass (topping out at 12,095 feet, by the way) loomed for the next morning. I got settled and drove back to the lake. Yes, drove. I know, I’m a wimp.
Regardless of your fitness, this is a must-do ride. It’s beautiful. You lap a lake at 10,000 feet with 14er’s in the backdrop. It was near 70 and sunny (which at this altitude is downright hot). Oh, and it’s late September, which means fall colors. What else do you need?
I ended up with just one lap. Took me a little under an hour, I’ll take that. The altitude was definitely noticeable, but I also had a chance to test out some fitness that’s new for me this year: I’ve been using my 7mi ride home from work as a time-trial of sorts, pushing on uphill sections that previously I wouldn’t have. Doing so has given me strength on pitches I haven’t had previous years. It felt good going a couple mph faster in some places. And then the altitude hit me. The “big” climb was no picnic. Took me 20 minutes. Then I started thinking about what it would be like to do it more than once. Eh, no thanks. Not today.
I had some mexican food in town, including a margarita –the first alcohol in about a month. I headed back to the Inn, showered, and took a small nap while watching college football. Yes, this is what solo time is about.
Allow me to take a moment to plug High Mountain Pies. I picked up the name from a little Google, and I wasn’t disappointed. They were slammed. Just flying. Listening to the crew was like eaves-dropping on a shuttle mission. Pretty cool (despite some frustration I overheard, but that’s the way it goes when you’re slammed). They squeezed in my order and it was just awesome. Just awesome. I’d drive up there just for the pie. I ate the entire pizza. Happily.
And then I decided to fade off to sleep. Thing is, after 2+ years of sleeping with a noise machine either in the room or via baby monitor, the still quiet of 10,000 feet was eerie. Deafening. Took me a while to fall asleep, actually. Or it was all the thinking about Things I was doing. I was tackling Independence Pass in the morning, and though I was already shortening the route (not starting in Leadville), I was nervous. Excited. And thankful for my wife and kids.
What if we removed release dates? Let’s think about that for a few minutes.
Was your first reaction, “well then nothing will get done?” Was it, “how will I know when I have my project?” Was it a simple, “Ha! no way!” I understand, I do. We want certainty, we want to point at a calendar and say, “there, that’s when something is going to happen,” and then rush into all sorts of planning and analysis of how that something will happen, by how many people, and costing how much, before any actual work gets under way.
Sometimes there are dates that drive projects. Or at least, we think they do. The annual sales convention is an easy example. If your company has user conferences, you know all too well the amount of effort and planning that goes into delivering something special –accompanied by the promises for next year’s conference. We use dates as motivation. If it’s not on the calendar; if we don’t make a declaration, then the task won’t get done. For low-cognitive tasks, this is a great tool. My wife and I routinely look at the calendar and plan dates for entertaining friends, for going to Costco, heck even for when I’m going to mow the lawn. Again, for tasks that don’t require a lot of thinking, working date-first is a great method to ensure things get done.
However, building software requires a lot of thinking.
Let me rephrase: building software requires a lot of thinking.
(okay, I didn’t rephrase; you’re paying attention)
Do you trust your developers? What would happen (for instance) if they came in Monday to no calendar, no release dates? What if, instead, you presented them with a goal, a few technical constraints, and then promised to protect them from every distraction? Chaos, or beautiful productivity?
Here’s my point: if your delivery organization (and I’ll skip pointing out that your entire organization is about delivery) is geared around releasing software quickly and frequently, if those folks who actually build the applications have nothing detracting from releasing software, then you can throw away predicated release dates. At this point, the date doesn’t define the end of the project, the amount of functionality does. And if functionality is constantly being delivered, that end can be anytime.
People who program (ok, so I mean most people, and that’s a separate post) love to write code. Love to solve problems, and love to –ahem– release software. So what’s preventing us from giving those really smart people all the free reign to do just that? Sounds pretty good, eh? Give your software folks a loose leash, a goal, and come back in six months to something magical. Easy, right?
Okay, it doesn’t quite go that simply. First of all, it’s really hard to not distract your software folks. Either they’re working on more than one thing, or there are internal political issues, or the tools suck, or the CIO likes LAMP this month then prefers DB2 next month –there’s always something. Your job is to insulate all that stuff, and give the developers their chance to do all that hard thinking.
Second of all, organizations tend (I’m trying to be diplomatic here) to not trust their people –remember your reaction to the title of this post? Won’t the developers just sit around “geeking out” or whatever it is software geeks do, and we’ll never get our product? Do you want a magic bullet? I’ll give you one: shorten the horizon.* I know this sounds immediately contradictory to ‘no release date’ but allow me to explain (and here is where some Agile dogma comes in, only it’s actually the truth, proven throughout software communities).
It’s pretty hard to focus on a (well, any) goal that takes a couple months to complete. All the little nuances, alternate paths, fear of the unknown and constraints, on top of the actual goal is hard to keep in one place, and is damn near impossible to keep in one’s head. So don’t do it. Break it down into two or three tangible “acts” (notice I didn’t say ‘releases.’ This is intentional). Break those acts into pieces until you have valuable chunks that are about a week to two-weeks of effort. Please don’t spend two weeks doing this. Do it in one day. Rank that list as if you had to have something delivered in two weeks. Give that list to the team, and check up on them every two weeks, where they can show what they’ve done (which is ready to be in Production, by the way), and where you ask how they’re doing. Release to Production whenever you want.
Here’s the primary switch from ‘traditional’ development that really makes this possible: The application is always functional –even if some very minuscule fashion, it’s available and valuable. In this model, the demonstration for this year’s user conference is a relatively known quantity. It actually works. The variable is how much works –which is also no surprise because we’ve checked with the team every two weeks for a number of months. We’ve released software when it’s convenient, not to (sometimes) arbitrary dates. In effect, the ceremony of releasing software becomes an afterthought, with the focus up front on the short time cycles to complete something of worth. Constant delivery to production means release dates cease to motivate; they become meaningless.
*I feel I should address a caveat with the statement, “shorten the horizon.” I’ve witnessed too many environments across industries where teams try to practice shorter time boxes, but inevitably, somehow, there is an implication that the same amount of value will get done –just on a shorter time scale. That magically, what took four weeks will now only take two because we’ve shortened the window and we’re now “Agile.” I’m sorry, it doesn’t quite work that way. Four weeks of work is still four weeks of work. The difference is we focus on a week or two at a time, completely completing functionality little by little. There isn’t a big-bang at the four-week mark; there are two, three, even four reveals along the way. That is where confidence is built, that’s where trust is established –the developers aren’t just sitting around ‘geeking out,’ they’re constantly delivering something.
