I make things better. I amuse myself in the meantime.
Ah, product maintenance:
Programmers: a short story (high quality: http://t.co/2H8JT49H23 ) pic.twitter.com/ewu6phQxb8
— badidea đȘ (@0xabad1dea) May 22, 2014
Working with talented people who are constantly learning is amazing. Thinking that every piece of code that is even slightly aged is incorrect or wrong is not as amazing.
Compromise is a skill. And not one that we only use with clients. đ
I’m helping a buddy with his site, doing some analysis of the analytics to see what’s working and what isn’t, and to try to identify some places where he could bump up the site’s revenue a bit.
The whole things feels quite luxurious. It’s a side project for him, and I’m just doing it for fun, so there are no timelines, no pressures, just long, leisurely dives into some data.
It feels so decadent, this abundance of time.
It makes me stop and realize just how fast the team really moves some days. How quickly we encounter information, analyze the options, make choices, and then DO. Problem, data, tradeoffs, choice, action. We run through that at light speed, dozens of times a day.
Over time, I think it’s made me and my team incredibly efficient problem solvers. We focus in on exactly what is happening. They bring the technical information, I bring the product and client knowledge. We weigh options, pick, and then DO. Clean and targeted, and ending with action.
We should spend a little more time reviewing our choices and actions, but overall, I’m pretty proud of this little decision making machine we’ve created.
I think we are defined by who we become in a crisis.
When we are under stress, when things go wrong, when you’ve made a mistake, when the unexpected happens. Our reaction in times of trouble can be telling.
Do you take action to fix things, or do you just talk about fixing things?
Do you figure out what went wrong, or do you try to forget it ever happened?
Do you own up to your mistakes, or do you sweep them under the rug?
Are you interested in solving problems and fixing things, or are you only interested in who’s to blame?
Stress strips away all the pleasant veneer of interactions, and you get down to the center of who you are. It’s not always pretty what you find there, but I think it is an important place to visit occasionally.
But only occasionally.
I feel like I’ve been operating from that crisis stress center all week, raw and angry and frustrated. It has been a challenge to temper reactions to events that normally I would handle in stride.
How do you heal over-stress? How do you put back the protective layers of normality, of things going as planned, of occasional wins and compliments?
And more so, how do I ensure my team gets those things?
I know this is a joke. An intended exaggeration. But it is frustrating nonetheless.
Comic I made in honour of the dev's out there who struggle to context switch – (with thanks to XKCD) #standups #agile pic.twitter.com/f08C4sXOjJ
— Brad Barrow (@foxwisp) May 13, 2014
As I was watching a show on Hulu last night, this commercial kept playing for an online K-12 school. One of the âstudentsâ was saying how awesome it was that she could do 5 classes in one day on the days she felt like doing a lot, and none on the days she didnât.
Which is great. But then it kinda isnât.
Thatâs really not life, for most of us. We donât get to do whatever we want to do, and only when we want to do it.
We work together. We accomplish things as teams. We need other people to support and inform and help us, therefore we must do our work at roughly the same time to be efficient. Just because you donât feel like doing your work on some days doesnât alleviate your responsibility to do it. Your team is counting on you, so you do what you need to do on the appointed day.
Perhaps it was just the combination of this illustration and that commercial, but I got peeved. I feel it furthers the notion that developers are delicate flowers that should never be interrupted, that their concentration should be preserved above all else.
I totally agree that devs need long uninterrupted stretches of time to do work to be most efficient. And I strive to provide that. But to be effective as a team, you have to be willing to stop and talk to your team. And the daily standup is that method.
Sometimes, you have to subjugate your individual needs to better the team. Thatâs what a team is all about. Being pissy about a standup means no information gets transferred into other brains, which makes you a silo, and if you go on vacation, the work comes to a halt because you couldnât take 15 min a day to have a very short conversation. You are not that important, that you should be able to bring a team down by taking a vacation.
Do the standup. Support your team. Donât be a silo.
I keep a little note on my desk at work to remind me of the one thing I need to be above all else:
Proactive – not reactive.
This post was in my feed reader today, and I appreciate the message. Sometimes, we are so busy running around fixing the consequences of problems that we donât ever get to the solving part of problems. It is stunningly easy to get caught in that mode.
Itâs a daily effort, to stop and think – what am I reacting to, that I should be taking the time to solve and keep from happening again?
Without my intent, empathy tends to be a recurring theme for me here. I love this:
In the UX field we talk about a lot of things. Tools, processes, research, design, etc. But it’s easy to forget that a lot of those things are supposed to be ways of finding, feeling, and fixing friction and pain points of the people you’re trying to serve. Recognizing moments when you feel as others do are good reminders that all the work we do â no matter what our specialties, strengths, or backgrounds might be â has a common throughline: Empathy.
I do very firmly believe that taking care of your client’s experience, anticipating and fixing their pain points, is the key to success. And the same goes for your staff – take care of your people. The rest will follow naturally.
After going through the Certified Scrum Master class (I am fancy now!), Iâve been re-evaluating how projects are âmanagedâ at work. We are not fully agile, but weâve been slowly applying some of the agile concepts and structures to our workflows. In an agency environment, where projects are fast, furious, and many at the same time, there is not always the luxury of doing full scrum processes.
In addition, I play both Product Owner and Scrum Master, which is less than ideal. I represent the clientâs interests, prioritize backlogs, and also try to help the team organize themselves for delivery, remove their roadblocks, and basically keep them running smoothly. I think I play Product Owner well. But Iâve realized Iâm not an awesome Scrum Master right now.
We need to shift towards more team choices where the team decides what to do next – Iâm trying to adjust my phrasing and my approach to conversations so that the team feels more empowered to make choices on their own, that they donât depend on me to tell them what to do. Itâs an interesting shift. I feel like Iâm forcing them to take more control – and that they donât always want it!
Itâs a good transition, and a necessary one as well. The process is a little bumpy, but weâre getting there. I have this vision of a group of awesome people who can discuss issues, make choices, and perform to their stated expectations all on their own initiative. A group that can control their own environment, and that feels not only empowered to make change, but a group that feels the ability to change and improve is their opportunity and obligation.
Weâre gonna get there. Strap in and hunker down. Weâre gonna get used to being uncomfortable. It’s a price of change that I’m willing to pay.
Until you can reliably deliver what you thought you could deliver, focus on how you define and build software. You donât need Lean or Kanban or to improve your stand-up meeting. You need to learn how to define, build, and deliver software.
Donât be distracted by nuance if you canât get the basic gist correct. Deliver what you say you will deliver. And only work on that until you can do it. Be functional first. And then work on refinements.
Somewhat cynical, but amusing:
Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.
Thereâs never enough time, right? This world moves so fast. Even if a client had granted unlimited time to produce something (I can hear you laughing. Stop it.), the technology changes so fast that as soon as you build something, there is already a better way to do it. By the time you build your fourth feature, you already want to rewrite and optimize the first one you built.
But beyond the speed of technology, itâs just the cost of gaining knowledge. The more you know, the more you realize what youâve done before could be better. Itâs an awesome monster that we feed with every step. The faster you learn, the more the past haunts you. The refactoring monster is on your doorstep. Would you want it to be any other way?
I wouldnât. The adventure of learning and exploring is worth the potential regret that we canât refactor everything behind us.
Onward.
Damned if you do, and damned if you donât.
Sometimes, I feel caught in that conundrum. Especially when it comes to things like planning meetings, or retrospectives. If we stop to plan better, we lose development time, but we should make up that time by doing the work properly the first time. If we stop to figure out what we did well and what we did not so well, then we lose development time, but we should be making ourselves more efficient by reflecting and improving.
Specifically in an agency environment, where the pressure to deliver MORE ALWAYS MORE AND EVEN MORE NOW AND WHY CANâT WE JUST SQUEEZE THIS IN TODAY, it can be difficult to prioritize those things. We live or die by happy clients and billable hours.
Sure, we plan. But do we sit down and do nothing but plan and do deep thinking exercises over what really is needed? Not consistently.
Itâs a matter of priorities, really. If we donât feel the meetings are important enough, then they slide by.
So whatâs in the way of prioritizing these events?
Constant adjustment of client expectations.
âŠwhich can lead to unhappy clients.
The loss of billable hours, potentially.
The lack of staff buy-in, that these things are valuable.
The lack of a process champion to convince the staff to just try it for a while.
Itâs all about how much risk weâre willing to take on. Is it more risky to slow down delivery for these clients, understanding the theory that development becomes more effective over time, ultimately (one hopes) leading to happier clients? Or is it more risky to devote as little time as possible to planning and reviewing, only enough for a general understanding, while keeping billable hours and deliveries as frequent and comprehensive as possible?
Can you convince an unseasoned client to value quality over volume? How many meetings will a client tolerate on their invoice before they start to balk at what most clients think is just useless overhead? On a 4 month project, how much client education can you legitimately expect to accomplish?
I suppose thereâs only one way to find out!
I walked by our âatta-boyâ wall the other day and realized that I hadnât updated it in a while. I used to be better about pointing out our successes, both as a team and as individuals, and I have let that fall by the wayside.
I do deeply appreciate the staff here. And I need to be more explicit about that.
For all the effort we put into the experience of our products, we arenât focused on the experience of the staff. Whatâs the UX of your workplace?
It got me thinking about the unexpectedly delightful. How do you fashion an experience where each person feels appreciated, feels safe, and still experiences moments of delight in the workplace? Itâs a challenge, since we are all such individuals. There are some team members who are truly overjoyed by a free burrito lunch. And there are some who feel a long office lunch is an intrusion on their workday, it doesnât match their style.
There really is no one-size-fits-all answer here, but I feel a solution is worth pursuing. Time to inspect, adapt, and deliver.
Agile delightment FTW!
An interesting post on the Ken Schwaber blog:
Our shortcomings were surprising to me. When I rolled out Scrum, I thought that the excellent developers that had been stifled by waterfall processes would emerge, and we would again do great work and build great software. Much to my surprise, many never had those skills or had lost any skills they had. The pressure of âget it all out now, cut quality to do soâ had reduced most developers to unskilled, unprofessional, angry drones. The larger the organization, the worse the situation as âmediocrity scaled.â Organizations whose software is only five years old are already crippled by technical debt.
He posits that governance of software developers is imminent – whether the industry elects to self impose these guidelines or the government demands it – and that formal regulation of skills and capabilities is needed.
It reminds me of my real estate days – an industry with a very low barrier to entry, and an extraordinary range of practitioner proficiency. Â (Sound like software development to you? Â Yeah, to me, too.) Â There is a plethora of “certifications” that are intended to provide proof of an agent’s skill. Â A Certified Residential Specialist? Â How about a Graduate of the REALTOR Institute? Â When working with an agent with a set of fancy letters after their name, did the transaction proceed more smoothly?
Not generally, no. Â In my experience. Â They’re generally pay to play: read the handout, sit in a chair and exist for the required number of hours, pass a simple test, pay the man for the honor of putting the letters after your name for a year. Â Clearly, this is not the model to adopt.
This, however, is certainly a problem:
If I were on a team, I wish that I knew the level of the developer that I was bringing on board, instead relying on personal references and âthe usual suspectsâ to avoid getting swamped by unfounded braggarts.
I don’t personally believe a governance board can replace screening candidates for my personal standards for proficiency. Â Might it give me some warm fuzzies that the candidate has at least tried to gain a skill? Â Possibly. Â But in a world where even a college degree is seen as optional, an archaic proof of capacity, what can a governance board provide?
It’s an interesting thought. Â Can you regulate development processes across an entire industry? Â Can anyone really certify skill, if proficiency is a relative determination? Â Things to ponder.
Every once in a while, we finish something we think is awesome. Shiny. Spectacular. Perfect in every way. A tiny little flawless newborn code-baby, clearly demanding your adoration and unbounded love.
And then the client doesnât like it. âTake that head off,â they say. âPaste it to the stomach, and then put both arms on the same side.â âCan we make it more monochrome? And thereâs no reason for five toes on each foot, we only need seven toes, total.â
Agency work can be tough, sometimes. We want to be proud of our work, we want to build awesome things. And sometimes, we have to build what we think are monsters.
Thatâs okay though. Opinions are like, uhm, belly buttons. Everyone has one. And clients are always going to have their own. They are entitled. Itâs their money and time and product, after all.
I do believe we have the obligation to advise when we see clients turning down the road to creating monster babies. We may have expertise, and I believe we have the responsibility to advise and inform. But ultimately, though we are building this thing, it is not ours. It is theirs. It is their right to not agree with us.
Perhaps we can take pride, instead, in our process. In the ability to build a great *anything.* To make happy clients. To enjoy the opportunity to shape a product, even if we are not the final decision makers. To enjoy and welcome the diversity of opinion.
âŠeven if we do think thatâs the ugliest baby weâve ever produced.
I have a client that we have favored highly over the past few weeks – often at the expense of other clients, or at the expense of my development staffâs sanity. After riding out a wave of unforeseen emergencies, we are now transitioning into a regular maintenance schedule.
Itâs difficult, at times, to transition clients to new expectations while still keeping them happy. We generally release to production weekly for our web maintenance clients – but for some people, that just seems too infrequent. On their side, they are not accustomed to planning that far in advance. Or a low priority item suddenly becomes urgent because of the time spent waiting in the backlog.
Therefore, we live in a reactionary state to their lack of planning.
Transitional times like this, I try to focus on my empathy – what is the client feeling now? Why arenât they thinking ahead? Have they ever done this sort of thing before? What pressures are they feeling, and how can I help them feel more in control?
There is certainly a balance – how much Iâm willing to give, how much I need to enforce the rules. And certainly, the more precedent I set of disregarding our process, the more difficult it is to enforce process. In the end, an open mind and an open line of communication, laced with a heavy dose of empathy and understanding, tends to do the trick.
I went and got myself a certification this week – I am now a Certified Scrum Master, thank you very much.
Overall, the class was interesting. The teacher was engaging and the format was interactive. I enjoyed having time to dive into “true” scrum practices, see them at work, and better understand the reasoning behind the process.
A common complaint about scrum is the volume of meetings – the sprint planning, the daily scrum, the backlog grooming, the review, the retrospective. That’s 5 mandated meetings per sprint!
The teacher made an interesting comment, however, that scrum is an effective solution, but it might not always be the most efficient solution. This, I believe, is very true, at least from the day to day perspective. As a project, using scrum might indeed be more efficient, but as an individual contributor on a daily basis, scrum can seem like a lot of overhead.
Indeed, in some agency environments, and in very small teams, scrum may be too much process – there are many situations where a leaner solution like kanban would be more appropriate.
As a systems engineer, I am typically hyper-focused on efficiency – but that should never come at the price of effectiveness. What may be most efficient on a daily basis might not be most effective in the long run.
Things to consider.
One of the fascinating things about agile team structure is the delineation between responsibility and accountability. While I may be in charge of making sure something gets done, I may not actually be the one to perform the work. I am accountable to a task without being responsible for actually doing it.
As a scrum master, I may be accountable for explaining and improving the teamâs velocity, but I do not directly impact the velocity – I am not responsible for the work done that creates or alters the velocity. Only the development team can be responsible for the estimation and volume of work that is completed.
Itâs an interesting paradigm, to separate who is held to the fire for something from who will actually do that something. That takes a huge amount of trust within the team – to trust the responsible party will do what they say they will do.
And if there is no trust? Thatâs a huge problem if a team member doesnât fulfill their responsibilities. Which gets exacerbated if there are no reciprocal dependencies between us – if mutually assured destruction is not an option, albeit a last resort, clearly.
If I am accountable for things that you are responsible for, and you never fulfill your responsibilities, then there is a problem. A foundational breakdown of trust and responsibility, fracturing a team from the inside.
Be on the lookout, team leader, for small breaches that may lead to larger collapses. Defend your team vigilantly against actions that erode trust.
This video has been making the rounds via social media:
It’s painful and hilarious at the same time.
The thought that niggles at the back of my brain is how everyone identifies with the expert – and we can’t all possibly be the expert. Surely, there are times that we play each role in this little spectacle, to some degree or another. We aren’t all experts at everything. We can’t possibly be. At some point, we must all say something incredibly backwards and painful to real experts, and cause in them the frustration and disbelief portrayed here.
Our reaction as ‘expert’ when we come across these situations is important. Are we able to gently teach and clarify without making another party feel dumb or – worse – attacked? Can we speak plainly and communicate well? That’s such a vital skill. It is well worth our time to focus on developing and nurturing this skill in ourselves, and in our teams.
An excellent point:
When you stand and petulantly demand some course of action without regard for the bigger picture, you immediately place yourself into a tiny little box. This person doesnât understand the full scope of what he is asking, so I can disregard this particular request. Sure, you might know what you are talking about (might even be right in absolution), but the fact that you present your case in isolation makes it less compelling to the person you are trying to influence.
Instead of just taking the free ice cream, try a simple acknowledgment of the associated costs. By placing your request in context, you do a couple of things. First, you demonstrate that you are informed, which lends your position more weight. Second, you highlight that you understand the other personâs position, which helps build rapport. And finally, you open up a conversation about costs and tradeoffs, which is typically the core of the problem in the first place.
What are you demanding from others without regard to what it will cost them? Â Is that why you’re not getting results?
Iâve been wrangling my feed reader today – culling, adding, focusing, absorbing. Admittedly, recently, the only category of feeds that were read with any regularity was the âentertainingâ category. Followed by the âcrossfitâ and âpaleoâ categories. This may explain my exuberance for my workouts, and my general sense of malaise at work. Iâve been uninspired.
And thatâs no fun for anyone.
So itâs time to feed my brain some new information. I cut several older real estate categories. Trimmed the entertaining feeds to those that I enjoy most. And I beefed up my agile, analytics, and CRO related feeds. I added far more than I can reasonably consume, but Iâll spend the next few weeks evaluating which I enjoy, and will unsubscribe individually to those that are more noise than signal.
Letâs see what happens if I soak my little brain in some new voices.
What do you do for inspiration?
Expanding spiritual capacity requires subordinating our own needs to something beyond our self-interest. Â Because we often perceive our own needs as urgent, shifting attention away from them can prompt very primitive survival fears. Â If I truly focus my attention on others, we worry, who is going to look out for me?
— The Power of Full Engagement, Loehr, Schwartz
And so it goes in team building. Â How do you convince a curmudgeonly team member to let go of fiercely protecting their personal needs in favor of the good of the team? Â Fear – primitive survival fear – is not to be taken lightly. Â What are they missing? Â Trust of the team, most certainly. Â Trust that their needs will be met.
It’s likely not resistance to new ideas out of a selfish or miserly spirit, but rather an indication of a perceived lack of safety and of trust. Â Perhaps empathy is called for – seek first to understand. Â Display the qualities you wish to embolden in others, oh fearless leader.