Software and technology are bringing a lot of changes to our lives - just think of the things in the news set to make waves in the near future - robots, AI, blockchain, and self-driving vehicles.
If only part of the revolutionary claims for this tech comes true, the world will look very different.
This cocktail of technologies brings a lot of opportunity as well a great deal of upheaval.
One thing I've noticed about this digitally transformed world: every technical requirement of a project is also a business requirement.
I've often heard these words spoken: "That's just technical detail."
But I agree with less and less as time goes on.
It sounds wrong now. Just a technical detail? What product are we building here?
Yet it's true, in a way. It is a technical detail. But that doesn't mean that it isn't important or you can just ignore it or you can pretend to ignore it until it becomes a problem.
So how do we deal with this?
Over time we'll all benefit from current changes in eduction - more focus on reasoning, outcomes, and learning code will help. More people who know what code is and who have written a line or two will help demystify the whole thing a bit.
Business people: You need technical awareness and patience and you need to ask the good questions. Again, eduction will help.
Technical people: You also need patience and improved listening and communication skills. I've written before about the pain of the unasked question. Ignoring hard questions because you don't like the answer isn't OK. Ask the question you know is there.
We all need to get better at explaining trade-offs in non-technical ways. This really shouldn't be that hard.
But what is the quickest fix? What can happen now? Where do I see people stumble?
The answer is more agile adoption and commitment to great product owners.
Needed to spend half their time talking to people buying the product (getting their thoughts on the latest incremental release and how it delivered value) and half their time with the team creating the Backlog (showing them what the customers valued and what they didn't).
That would definitely help a team move fast and understand the right technical/business requirements very quickly.
It's why I believe so strongly that Agile is the right methodology and that following as closely as possible to the recommendations makes sense. I've seen a lot of product owners who did a lot of the first or a lot of the second, but only a few who did a great job of balancing both (and who were given the organizational bandwidth and charter to do it).
Today everything - every part of an application - is a business requirement. Waiting around for business experts to answer questions, when they have many other responsibilities, is a delay that almost no one can afford any more.
We all have to go fast.
And we all need the business expertise and customer awareness built into our teams.
I recently conducted a book club using Dr. Alan Watkins book Coherence. The most useful tool in the book is the idea of the emotional roller-coaster related to change in an organization.
The basic idea is that for every change in a company (and we all have no shortage of those) the individuals that make up the company must pass through a spectrum of emotions that looks like this:
Yes, every time, with every change.
The picture in the book is better, but I don't have permission to reproduce it so I've Cliff-Noted it for you.
We've all seen this before. When confronted with change, people resist. This turns out to be normal (and required) human behavior to process this change.
The key insight for leaders? You can't force people to move forward on the roller-coaster. You can appreciate where people are, acknowledge it, and help them move toward the future.
This was a very helpful insight for me. I know that several times over the course of my career I have tried to force people to where I was on the roller-coaster. I remember one series of meetings in particular where a group of unsuspecting people were essentially expected to attend a 30 minute meeting and arrive on the right hand side, without any time to process at all.
I've also questioned why they couldn't instantaneously reach acceptance (at the tail-end of the upswing on the right). They can't because none of us can. Though time and the right kinds of experience can help you move faster.
But something has occurred to me after all this. The roller-coaster image is very helpful in order to grasp the initial idea, but it misses something important. As a leader, you need to help people with the left side so that you can gain their help on the right.
In real life the down part of a roller-coaster is the fun part. It's the pay-off for have ridden up to the top. So, with organizational change: you work through the hard part on the left to get the help you need on the right-hand side.
So initially I wondered if something like this wouldn't be more useful:
This is nice in that it matches how you actually feel on a roller-coaster. Trepidation going up, thrilled going down.
But it doesn't work at all and here's why. It flies in the face of the up=good, down=bad metaphor that is deeply written into the brain of every human on earth.
Even looking at it and seeing negative emotions going up sort of gives me the heebie-jeebies.
So, that's a no go. What it gets right (in addition to how it feels to be on a roller-coaster) is the notion that in the emotional build-up is a build-up of potential energy. Going through the necessary negative emotions helps us to be ready for what comes next. We wouldn't be sent careening down the thrilling part of the coaster without the build-up of potential energy that occurs.
Similarly, people who can work their way through the change and the associated negative emotions are really positioned to truly accept the change, embrace it, and become champions once they reach the right-hand side.
The processing of negative emotions are what sets that positive trend in motion in a real way.
So what visual does capture this? The best visual I've been able to come up with is the idea of the slingshot. In the slingshot, potential energy is captured as the sling is drawn back - nicely matching the work required (as both a leader and individual) in order to actually pass (constructively) through the negative side.
Then, with the potential energy of the work captured, you can release the slingshot and actually draw all the momentum you need on the positive side.
I could not come up with a way to capture this in a single drawing, but I think a two part drawing does the trick:
My apologies to the artists in the room.
This is really a leadership view of this path through change. I think the original roller-coaster is probably best and sufficient for everyone else in an organization.
In searching for images on potential energy, I came across this image:
This turtle is about to undergo a change (and probably highly negative emotions).
But that doesn't have much to do with organizational change. I'm not sure it has a lot to do with potential energy either - at least the turtle part.
The result of a recent discussion of some side projects and whether or not it was professional development.
The project had business stakeholders separate from development team.
The project had testers separate from development team.
The project had end users separate from development team.
The project had a development plan.
The project was deployed to production.
The project has end users who continue to use the system.
The project had at least three significant challenges - challenges not solved by Googling or reading stack overflow. These are hard things you had to solve as an individual or team.
1, 2, and 3 need not always be completely distinct groups, but they do need to be distinct from development team.
1 through 6 can be easy at times, and can happen very fast, if you know what you're doing.
It is usually number 7 that distinguishes professional development from amateur work, hobbyist side-projects, or other simple coding endeavors.
Notice that there is not a Number 8 - 'You got paid for doing it.', becaucse being paid for it isn't an absolute requirement to make it real work. I've seen a lot of people get paid for things that don't count. And I've seen a lot of great work that was created because someone cared enough to do it, even though they weren't getting paid in dollars or other currency.
If your work checks off number 7 on the list then you were getting paid in experience, and this can be invaluable to you.
Clients frequently request that we use existing applications as the basis for work when we are rebuilding or recreating a system with them.
This is very difficult. It can work, but it is much less effective for developers and results in a lot of iterations as the dev team goes back and forth figuring out what an application needs to do. It leads to a lot of bugs that are only discovered in UAT.
In the beginning it is much more efficient for your business stakeholders, which is why they ask for it. Why go through the existing application and document it? That's a lot of work for users and business people, not to mention the BAs you have to pay to do it.
In the end, the same people who didn't want to go through the process of documenting will be mad because it is taking so long. It is your responsibility as a developer, lead, or PM to set the right expectations in the beginning.
If your stakeholder (whether client, boss, CEO, etc.) requires you to work this way you need to expose the risk and set appropriate expectations. The very best case scenario is that you have to set aside time for late project iterations when you run into these challenges. The worst case scenario is that the project will drag on so long that will be cancelled. It happens all the time. Also possible: you fixed-bid the project and put your company out of business trying to complete it.
Setting the right expectations can be difficult, and that is a topic for another post some time. My goal today is just to describe a few of the ways this has come up over the years, so you know what to look out for.
Just make the new app do what the old one does. Why do you need requirements? An all-time classic. Why not? I mean there's already code, how hard can be to just: read it, understand it, understand all the subcomponents and UI, assess whether or not it is still necessary, talk to users, and figure out how to test it. It definitely wouldn't be easier to have that done and approved before you start development. Danger level: Red Flag
Preserve the business logic, everything else you can get rid of. This assumes that preserving the business logic is easy, which it usually isn't. Even when someone has done a good job of separating business logic from UI and data access (very rare) often the technical and business requirements of the rebuild make reusing the code in its original form impossible. Danger level: Yellow Flag
We'll figure it out as we go along. This one can seem reassuring in that your stakeholder has seemingly granted you permission to iterate. But be careful here: set expectations, ask follow-up questions, establish what 'figuring it out' will really look like. Danger level: Yellow Flag
There's a lot you can re-use. Just tell me what it will cost to rewrite the things that you can't re-use when it comes up. You should assume that you are rewriting everything. If you get to re-use something that's a win. It will most likely save you a little time in testing, but not anywhere else. Danger level: Yellow Flag
You don't need to talk to users. Bob knows everything about this application and Bob is your main point of contact. Unless Bob is the only user (and even then) he almost certainly doesn't know everything. Even if Bob isn't an ego-maniac (and he might be) you are still facing delays in understanding the system because Bob has to go ask someone instead of you asking them. Danger level: Red Flag
This spreadsheet will tell you everything that you need to know about the system. AKA Our old system was a spreadsheet, just look at that. Usually these are worse than looking at code because in addition to code (like VBA) you also get things like embedded charts, formulas in cells, and obsure data access thrown into the mix, requiring even more detailed reading to understand. Danger level: Red Flag
Jennifer developed most of the original system and she'll be working closely with you on this project. Usually Jennifer is retiring, and that is a hard deadline. Also, what does most mean? Danger level: Red Flag
We have all the requirements from 20 years of work we did on the old system. You can read through that. To paraphrase Sartre, Hell is other people's requirements documents There are a few reasons why this is true, but probably the most profound is that writing the requirements document immerses the team members in the system. Without having written it, asked the questions, and fully digested the material then you or your BA will always be at a deep disadvantage. I wish this weren't true, but it is. At least 50% of the reason for documenting stuff is to make sure the person responsible really understands it. Danger level: Red Flag
In my continued quest for biometric insights and stress management, I recently picked up a Spire Stone. It monitors respiration and it can give you real-time feedback on your breathing patterns. Very handy for identifying and managing stressful moments throughout the day.
Breathe less than 14 times in a minute? You are calm. Your breath is full and consistent. Feels pretty good, doesn't it?
Breathe more than 22 times in a minute? You are stressed. Your breathing has become quick and shallow.
If this happens, the Spire device gives you a small nudge in the form of vibration to let you know.
The great news? You can do something about it. Take deeper, more normal breaths and help your body relax and feel less stressed-out.
I like it because, like FitBit, it gives me a way to impact my health that I can make conscious choices about. Breathing? There's always time for that. And improved awareness leads to small changes that can have a big impact.
With the HRV, brain wave, and sleep devices I've tried, you just don't control those things as directly as breathing or steps.
Spire gives you control over your stress level. Changing your breathing helps you feel less anxious and it can help you BE less anxious by sending a calming signal to all the other systems in the body.
It is a really good device. I've noticed that I don't always agree 100% with its breath count. During meditation I think it over counts, slightly, depending on the position of the device.
I also have had a few false positives on the 'stress vibration'. But not more than 1 a day.
These are very minor flaws in my opinion, and the value it provides more than outweigh these (small) negatives.
The additional awareness it provides to your current breathing pattern is very helpful.
They also have an app with some nice features. They have helpful guided breathing exercises and stats on how much time you were calm, anxious, active, and focused.
Spire has a new product coming out called the Health Tag which is designed to be attached to clothes, more or less permanently (it can be washed). In addition to respiration it also monitors HRV.