Category Archives: Uncategorized

Future Commitment

Posted on by
Reply

In early April, I spent a fun weekend at Pace University with Allen Wirfs-Brock and Mary Lynn Manns speaking with students of Pace University’s Doctor of Professional Studies in Computing program.

Mary Lynn

Mary Lynn Manns

It was a good opportunity to reconnect with Mary Lynn and to hear about new patterns in her latest book, More Fearless Change: Strategies for Making Your Ideas Happen.

Mary Lynn and Linda Rising have been working on these patterns for over a dozen years. They aren’t finished (curating long-lived patterns is an ongoing task). They continue to collect and write patterns for those who want to initiate, inspire, and sustain change in organizations they are part of or in their personal or professional life.

There isn’t one magic thing to do to institute change. Mary Lynn and Linda advise,

“You are working with humans, often in complex organizations, so results are rarely straightforward and the emergent behavior might be totally unexpected. Therefore, upfront detailed planning is rarely effective. Instead, take one small step toward your goal and see what happens. You will inevitably encounter missteps and failures along the way….uneven progress can be discouraging but may also teach you about the idea, about the organization, and, most of all, about yourself.”

Significant change often includes performing an ongoing series of experiments.

One new pattern (or strategy) in their book is Future Commitment. This one has hooked me many times.

Instead of asking a busy person for immediate help, ask them do something you need later and then wait for them to commit. Don’t worry about trying to get them to agree right away. Be patient. Keep in touch. Provide them regular information that encourages them to become more interested in your change initiative. Don’t be a pest.

Once they agree to help, solidify their commitment by recording the date and sending it in writing (along with gentle reminders so they are kept aware of their commitment). Reminders can be annoying. So include an update of what is happening and how their contribution will fit as part of a reminder. Have an alternate lined up in case that busy person can’t commit. There’s more to this strategy and the psychology behind how people commit (along with 14 other new strategies) in their book.

Like Mary Lynn and Linda, I don’t view change patterns as evil or manipulative. They are simply tools, that once aware of, you can use to engage people and get them to help you make changes.

And so here’s a future commitment if you have an urge to write about your agile experiences: We need experience reports for Agile 2016. Submit a proposal to the Agile Experience Report program. Do it soon. Within the next 30 days.

You don’t have to start writing now, but if you send in a proposal to me, it will grab my attention. Even better, if you are attending Agile 2015, we can also talk over your proposal. We ask that you write up a proposal so you get in the practice of collecting and communicating your thoughts in written form.

You could wait and submit your experience report idea via the Agile conference submission system in November. If you do, your chance of it being selected is limited. The format of the submission system makes it difficult to include details or have an ongoing conversation to sharpen your ideas. This year we had maybe 100 submissions from which we selected 20.

If you wait to submit your proposal via the conference system, it will have to really stand out from the crowd to grab our attention.

Instead, if you submit your proposal to the Agile Experience Program, it will be carefully read as soon as we receive it. If selected, we will work with you throughout the coming year. You don’t have to start writing immediately. You will get help from a shepherd as you write. As soon as you finish, your work will be published on the Agile Alliance website. You will be also invited to present your report at a future Agile conference.

I’m ready to help you write about your experience if you are ready to make a future commitment to writing. It all starts with your proposal.

Making New Behaviors Stick

Posted on by
Reply

My last post argued that knowing about cognitive biases and how our brain works is valuable, even if knowing isn’t enough to effectively change our behavior. Tweeter Jessica Kerr sums this up nicely, “Knowing isn’t half the battle, but without it, we don’t know the battle exists.”  Knowing doesn’t prevent  automatic behaviors and biased reactions. However, knowing gives us words we can use to reflect on our actions and feelings.

And then what? After awareness comes the really hard parts: consciously replacing undesirable, semi-automatic behaviors with more desirable ones.

Much of our daily behavior is driven by habit. Social psychologists estimate around 35-50% of our daily behaviors are driven by habit. Personally, I think that may be somewhat on the low end.

There’s a good reason for habits. If we had to consciously think through every action we took, we’d be exhausted.  When we have to consciously think about how to perform any task, it takes mental energy. And that wears us out. When we are tired we unconsciously fall back on our fast (associative) thinking to conserve mental energy and provide easy (if not always well-reasoned) answers to difficult questions.

It’s better if we can slip on our shoes in the morning and tie them without thinking.

We actively use our system 2 brain when we learn new skills or are placed into unfamiliar situations (think trying to navigate around a new neighborhood, learning customs in an unfamiliar country, learning a new problem domain or new programming language, or tracking down a tricky intermittent software bug).

When we’re not forced to work so hard, we mentally take it easy. We’re NOT lazy. But we do many things out of habit, to conserve our slow thinking, system 2 brain for when we really need it.

But what if we want to replace an old habit with a new improved one—and make that new habit automatic?

To change entrenched habits, we have to find effective replacements, insert them into our daily life…and be vigilant. This takes energy and effort.

The bad news: Old habits can still be triggered. They don’t disappear. They are simply supplanted by more recent habits (if those new habits can be successfully triggered).

One way to thwart undesirable habits is to remove their triggers from your environment. That’s why some people recommend removing unhealthy food from your household and  environment when wanting to develop healthier eating habits (easier said than done when you live with others or if there are always donuts at work on Fridays).

When it’s impractical to remove undesirable triggers, you’ve simply got to deal with them. Instead of reacting blindly to that old trigger, you can experiment with introducing new behaviors for that trigger with even stronger rewards. When the donuts show up at work, treat yourself to a good cup of coffee and slightly healthier biscotti instead (if you really really like donuts this isn’t going to work).  Better yet, avoid the strongest morning donut trigger by coming later on Friday after all the good donuts are gone (those stale donuts may be a trigger that you are still suceptible to, especially if you are tired).

This isn’t easy. Change rarely is.

Perhaps another solution to making changes stick is diligence. Be on the lookout for undesired behaviors/actions/triggers. Spot them, then quickly squelch ’em. Then go back to doing the desired behavior. This works, for a while.

Exercising diligence takes mental energy. You only have limited amounts of willpower to spare and when it is gone, well, things can get ugly. That’s why after a stressful day (when your system 2 is already tired from everything else you used it for) that you can let down your guard in a heartbeat. And then, dammit!…you slip up. You notice you slip up, beat yourself up about it, and vow to be even more vigilant. But you slip up again and…rinse, repeat….  I am not going to continue down this rat hole because it IS depressing.

So how do we get ourselves out of these mental ruts?

Evidence suggests that too much retrospection isn’t good. So don’t beat yourself up when you slip up. Recognize that you’ve slipped up  and try again. Switch things up and keep on trying (identify a better trigger or reward, experiment, try and try again). Don’t give up or give in to a defeatist attitude.

Some good news: Research suggests we are more successful at changing behaviors when we go through life changing events—when we move, retire, graduate from school, go off to college, start a new job, quit a job, marry, get ill—we are more open to change.

But I don’t wait for a big event to effect big changes. I don’t make New Year’s resolutions, either. Instead, I periodically mix things up and try new things just for their novelty. Life is a grand experiment.

But still…research hasn’t yet shown how to sustain new behaviors. Even years after embracing new behaviors, we are prone to slipping up, given the right triggers (think vacations, travel, holidays).

Knowing how we can slip-up is not enough to avoid slip-ups. Santos and Gendler are right.

But believing that you can recover after a slip up is key to getting back on track. And that’s where a positive mindset, determination, the belief that you can learn from mistakes, and resilience go a long way towards making change and making changes stick.

Footnote: The Power of Habit by Charles Duhigg is a good book for those wanting to know more about habits in their life and business.

Evangelizing New Software Architecture Ideas and Practices

Posted on by
Reply

Last December I spoke at the YOW Conferences in Australia on Why We Need Architects (and Architecture) on Agile Projects.

I wanted convince agile developers that emergent design doesn’t guarantee good software architecture. And often, you need to pay extra attention to architecture, especially if you are working on a large project.

There can be many reasons for paying attention to architecture: Meaningful progress may be blocked by architectural flaws. Some intricate tricky technical stuff may need to be worked out before you can implement functionality that relies on it. Critical components outside your control may need to be integrated. Achieving performance targets may be difficult and you need to explore what you can do before choosing among expensive or hard to reverse alternatives. Many other developers may depend on some new technical bit working well (whether it be infrastructure, that particular NoSQL database, or that unproven framework). Some design conventions need to be established before a large number of developers start whacking away at gobs of user stories.
I characterized the role of an agile architect as being hands-on; a steward of sustainable development, and someone who balances technical concerns with other perspectives. One difference between large agile and small agile projects is that you often need to do more significant wayfinding and architectural risk mitigation on larger projects.

I hoped to inspire agile developers to care more about sustainable architecture and to consider picking up some more architecture practices.

Unfortunately, my talk sorely disappointed a thoughtful architect who faces an entirely different dilemma: He needs to convince non-agile architects to adapt agile architectural practices. And my talk didn’t give him any arguments that would persuade them.

My first reaction to his rant was to want to shout: Give up! It is impossible to convince anyone to adopt new way of working that conflict with his or her deeply held values.

But then again, how do new ways of working ever take hold in an organization? By having some buzz around them. By being brought in (naively or conscientiously) by leaders and instigators who know how to build organizational support for new ideas. By being new and sexy instead of dull and boring. By demonstrating results. By capturing people’s imagination or assuaging their fears. Surreptitiously, quietly replacing older practices when reasons for doing them are no longer remembered. When the old guard dies out or gives up.

Attitudes rarely change through compelling discussions or persuasive argumentation. I look to Mary Lynn Manns and Linda Rising’s Fearless Change: Patterns for Introducing New Ideas for inspiration.

I take stock of how much energy I want to invest in changing attitudes and how much investment people have in the way they are doing things now. I don’t think of myself as a professional change agent. Yet, as a consultant I am often brought in when organizations (not necessarily every person, mind you) want to do things differently.
People generally aren’t receptive to new ideas or practices or technologies when they feel threatened, dismissed, disrespected, underappreciated, or misunderstood. I am successful at introducing new techniques when they are presented as ways to reduce or manage risks or increase productivity or reliability or improve performance or whatever hot button the people who I am exposing these new ways of working are receptive to. Labeling techniques as “agile” or “lean” may create a buzz in those that already receptive. But the reaction can be almost allergic in those who are not. The last thing I want do is to foster divisiveness. Labels do that. If I get people comfortable taking just that next small step, that is often enough for them to carry on and make even more significant changes. Changing practices takes patience and persistence. At the end of the day I can only convince, demonstrate and empathize; I cannot compel people to make changes.

Thanks to Joe and Jason…this blog is live again

Posted on by
2

It has been months since I’ve posted a blog entry. Why? Initially, life got busy. Then, in October my wordpress site was hacked. making it impossible to see or use my admin console. I went searching for fixes to this problem on the internet and at the wordpress community site, but didn’t find a whole lot of useful information. I was advised to reinstall a later version of wordpress and clear out my plugins…

I tried those suggested fixes. But I took conservative measures. Instead of reinstalling over my existing directories, I cleared out my plugins and only reuploaded portions of my wordpress installation. That did not fix my problem. I then backed up my wordpress database and tried a new installation of all wordpress files. I installed my new wordpress files into a separate directory (just to test whether it would fix my blank admin page problem). This did not work either. Little did I know that wordpress kindly redirects you back to your known directory path (which is conveniently stored in in the wordpress database) so it was accessing my corrupted wordpress installation directory structure, not the new installation.

If I’d only overwritten my existing wordpress directory with a fresh installation that would’ve fixed the problem. But I didn’t. Why? Because I thought I was being conservative by pointing a new wordpress installation of wordpress files to my database (and leaving the old installation intact). Big mistake.

I spent a day sleuthing my “blank” admin screen. I turned on php debugging. WordPress was getting redirected to a non-existent file (supposedly), but it seemed that the file was in my blog directory path. What was going on? I wasn’t sure. Never did figure out why that happens. (I really want to know about paths during execution of wordpress).

Next, I rooted around in all my directories after perusing some scanty but helpful documentation on the path and file structure of wordpress installations. When I did, I discovered a few suspicious php files in my wp-contents directory. I renamed they (hoping they wouldn’t be invoked, and that maybe they were causing the problem). But no luck. Gr.

Finally, I turned to my colleague and good friend Joe Yoder of The Refactory for help. Joe, who in addition to being a world class designer and Adaptive Object guru, also hosts a fair number of websites. He, along with his colleague Jason Frye, fixed my problem within the hour. First they installed wordpress and my database contents on their servers to check that my database wasn’t corrupted (wordpress ran just fine). Then they FTPed a fresh version of wordpress onto my server, and presto! I was back in business. They left me my old, corrupted version of wordpress in a newly renamed directory, just so it’s there in case I want to ever go figure out what was wrong.

I learned a few lessons during this very painful process: Advice on wordpress troubleshooting you find online is pretty sketchy. The “real” experts out there are sysadmin folks who’ve done enough wordpress installations and troubleshooting to know what to look for…and when they can, they reinstall a new version of wordpress rather than try to hack on a partially working installation. Not everyone has a Jason or a Joe to lean on. I’m glad I did. Thanks, guys!

I’ve been told by another friend that the wordpress’ execution model is pretty complex. Lots of paths and looking in different places…But after this experience, I’d be happy to help someone who is a guru, more fully document how wordpress works, what the database table structure and contents are, what the contents of subdirectories and when they are invoked, etc., etc. I’m serious about this.

Why?

I like to know how things work. I’m a designer, after all. I like to know how software works. I’d also like it if people who had wordpress installation problems had an easier time than I did (I got pretty discouraged). In my explorations, I uncovered many frustrated people who were asking for help and didn’t get very far. It doesn’t have to be that way.

If a deeply wordpress savvy person would like to talk about co-writing a small guide on “principles” of operation of wordpress, I’m game. I like to write. And explain how things work. Simply. So people don’t just have to “guess” and hack in as they struggle to fix problems. And with such a guide, I believe life would be for those who want to blog as well as know what’s going on, under the hood.

Evangelizing New (Software Architecture) Ideas and Practices

Posted on by
4

Last December I spoke at the YOW Conferences in Australia on Why We Need Architects (and Architecture) on Agile Projects.

I wanted convince agile developers that emergent design doesn’t guarantee good software architecture. And often, you need to pay extra attention to architecture, especially if you are working on a large project.

There can be many reasons for paying attention to architecture: Meaningful progress may be blocked by architectural flaws. Some intricate tricky technical stuff may need to be worked out before you can implement functionality that relies on it. Critical components outside your control may need to be integrated. Achieving performance targets may be difficult and you need to explore what you can do before choosing among expensive or hard to reverse alternatives. Many other developers may depend on some new technical bit working well (whether it be infrastructure, that particular NoSQL database, or that unproven framework). Some design conventions need to be established before a large number of developers start whacking away at gobs of user stories.

I characterized the role of an agile architect as being hands-on; a steward of sustainable development, and someone who balances technical concerns with other perspectives. One difference between large agile and small agile projects is that you often need to do more significant wayfinding and architectural risk mitigation on larger projects.

I hoped to inspire agile developers to care more about sustainable architecture and to consider picking up some more architecture practices.

Unfortunately, my talk sorely disappointed a thoughtful architect who faces an entirely different dilemma: He needs to convince non-agile architects to adapt agile architectural practices. And my talk didn’t give him any arguments that would persuade them.

My first reaction to his rant was to want to shout: Give up! It is impossible to convince anyone to adopt new way of working that conflict with his or her deeply held values.

But then again, how do new ways of working ever take hold in an organization? By having some buzz around them. By being brought in (naively or conscientiously) by leaders and instigators who know how to build organizational support for new ideas. By being new and sexy instead of dull and boring. By demonstrating results. By capturing people’s imagination or assuaging their fears. Surreptitiously, quietly replacing older practices when reasons for doing them are no longer remembered. When the old guard dies out or gives up.

Attitudes rarely change through compelling discussions or persuasive argumentation. I look to Mary Lynn Manns and Linda Rising’s Fearless Change: Patterns for Introducing New Ideas for inspiration.

I take stock of how much energy I want to invest in changing attitudes and how much investment people have in the way they are doing things now. I don’t think of myself as a professional change agent. Yet, as a consultant I am often brought in when organizations (not necessarily every person, mind you) want to do things differently.
People generally aren’t receptive to new ideas or practices or technologies when they feel threatened, dismissed, disrespected, underappreciated, or misunderstood. I am successful at introducing new techniques when they are presented as ways to reduce or manage risks or increase productivity or reliability or improve performance or whatever hot button the people who I am exposing these new ways of working are receptive to. Labeling techniques as “agile” or “lean” may create a buzz in those that already receptive. But the reaction can be almost allergic in those who are not. The last thing I want do is to foster divisiveness. Labels do that. If I get people comfortable taking just that next small step, that is often enough for them to carry on and make even more significant changes. Changing practices takes patience and persistence. At the end of the day I can only convince, demonstrate and empathize; I cannot compel people to make changes.

What is Pragmatic Testing All About?

Posted on by
Reply

-Rebecca Wirfs-Brock and Joe Yoder

We’re excited to be offering a new course, Pragmatic Test-Driven Development, with a practical bent to testing. Test-driven development (TDD) traditionally means writing unit and acceptance tests along with production code. Some agile thought leaders push a hardnosed test-first practice, insisting that you always write a failing test before you write any production code. Then, in short programming and testing cycles, evolve your test as you complete your code.

One common objection to TDD done this way is that writing tests this way doesn’t seem “natural”. Instead, you may want to write a coherent chunk of code before writing any tests. We agree with that. In our course we explore several different ways you can do Test-Driven Development, making TDD much more approachable to a wider audience.

We believe that you should pay attention to testing and that it should be an integral part of your daily programming practice. But we don’t insist that you always evolve tests along with your code in many short cycles. Some find it more natural to outline some tests first, and use those test scenarios to guide them as they write code. Once they’ve completed a “good enough” implementation that supports the test scenarios, they then write those tests and incrementally fix any bugs as they go. As long as you don’t write hundreds of lines of code without any testing, we think this style is OK too (and we don’t insist on one style over the other).

As long as you check in your production code along with unit tests that pass, your programming is being “driven” by tests.

We believe that it’s not so important to test first as it is to test frequently! Testing should be integral to your daily coding and design rhythms. And your production code should only be checked in along with its passing tests.

There’s a lot more to becoming proficient at TDD. Developing automated test suites, refactoring and reworking tests to eliminate duplication, and testing for exceptional conditions, are just a few. And acceptance tests, smoke tests, integration, performance and load tests support incremental development, too. If all this testing sounds like too much work, well, let’s get practical. Testing shouldn’t be done just for testing’s sake. Instead, the tests you write should give you leverage to confidently change and evolve your code base and validate the requirements of the system.. That’s why it is important to know what to test, what not to test, and when to stop testing.

Agile Architecture Myths #4 Because you are agile you can change your system fast!

Posted on by
2

Agile designers embrace change. But that doesn’t mean change is always easy. Some things are harder to change than others. So it is good to know how to explain this to impatient product stakeholders, program managers, or product owners when they ask you to handle a new requirement that to them appears to be easy but isn’t.

Joe Yoder and Brian Foote, of the Big Ball of Mud fame, provide insights into ways systems can change without too much friction. They drew inspiration from Stuart Brand’s How Buildings Learn. Brand explains that buildings are made of components organized into shearing layers. He identifies six layers: the site, the structure, the skin, the services, the space plan, and physical stuff in the building.

Each shearing layer has its own value and speed of change, or pace. According to Brand, buildings are able to adapt because faster changing layers (e.g. the services layers and spaces) are purposefully designed so to not be obstructed by slower changing layers. If you design your building well, it is fairly easy to change the plumbing. Much easier than revising the foundation. And it is even easier to rearrange the furniture. Sometimes designers go to extra efforts to make a component easier to change. For example, most conference centers are designed so that sliding panels form walls that allow inside space to be quickly modified.

Brand’s ideas should’t be surprising to software developers who follow good design practices that enable us to adapt our software: keep systems modular, remove unnecessary dependencies between components, and hide implementation details behind stable interfaces.

Foote and Yoder’s advice for avoiding tangled, hard-to-change software is to, “Factor your system so that artifacts that change at similar rates are together.” They also present a chart of typical layers in a software system and their rates of change:

Frequently, we are asked to support new functionality that requires us to make changes deep in our system. We are asked to tinker with the underlying (supposedly slower changing) layers that the rest of our software relies upon. And often, we do achieve this miraculous feat of engineering because interfaces between layers were stable and performed adequately. We got away with tinkering with the foundations without serious disruption. But sometimes we aren’t so lucky. A new requirement might demand significantly more capabilities of our underlying layers. These types of changes require significant architectural rework. And no matter how matter how agile we are, major rework requires more effort.

Because we are agile, we recognize that change is inevitable. But embracing change doesn’t make it easier, just expected. I’d be interested in hearing your thoughts about Foote and Yoder’s shearing layers and ways you’ve found to ease the pain of making significant software changes.

Agile Architecture Myths #3 Good Architecture Emerges

Posted on by
5

Last time I left the cap off of the toothpaste, a small blob of toothpaste flowed onto the counter. No planning; it just emerged.

Now I know that emergent software architecture is another thing entirely. We can’t anticipate everything about our software’s architecture before we start building it. It is impossible to get design “right” the first or the second or the third time. That’s why it is so important to iterate. Yet I don’t like to think that good software architecture simply emerges. It’s a bit more complicated than that.

Several synonyms for emerge leave me feeling uncomfortable. I’d rather not have my architecture materialize, loom or just crop up! Emergent behaviors are a reality with complex software. But emergence doesn’t equate to goodness, no matter how hard you wish it did.

Yet I’m not a fan of big upfront architecture theoretical architecture, either. Emergent behavior can be an opportunity. I like the sense of learning and anticipation in these synonyms: become known, become visible and come into view.

The architecture of complex systems simply has to unfold. We make architecturally relevant decisions based on what we know at any given point in time. And when we don’t know how to proceed we experiment (don’t tell your boss that, call it a design spike instead).

Our architectural ideas should change as we write more code and build more of a system. The many micro-decisions we make along the way should lead us to change our minds and our architecture. We shouldn’t have to live forever with bad choices. That’s the beauty of iterative and agile practices. We can fix and repair things. So this is my way of thinking about how good software architecture comes into being:

Good architecture doesn’t emerge; it evolves.

It’s deceptive to say, good architecture emerges. I find that good architecture rarely œemerges. We aren’t magicians who materialize good architecture. Good architecture involves hard work, reflection, and paying attention to details. Ideas for architectural improvements emerge from coding. And as long as you have the skills and chops and know-how to make significant changes when they are needed you can improve your architecture. It takes skill to keep your software’s architecture on a good path. Refactoring and redesign is essential. Only when you have the courage (and permission) to refactor and rework your design will your architecture keep pace with your software

Slicing and Dicing Complex Projects…

Posted on by
1

In a recent post, Johanna Rothman asked the question, should agile teams Develop by Feature, Develop by Component, or Some Combination? Well, in a nutshell, my answer is, it depends.

I have seen teams try different approaches to this problem. And there is ample experience out there to draw upon. As Julian Sammy points out in his remarks, “My experience is that the feature and component layers have several many to many relationships, depending on the level of detail you’re working at…If you are building a new feature… then you should be able to factor this [into several components.]” Yep, a big feature needs to be broken down into smaller, bite-sized chunks. And sometimes, those components can stand in relative isolation from each other. But if you are basing a feature on a common domain model, you may want to develop in a way that feature code interacts with a common domain model. That’s how followers of domain driven design approaches tackle this problem. So that one way to split up the work…one group works on building up a “core” of domain objects that other components that comprise the feature use. And in more complex projects there are even more layers of complexity. Your code that implements a feature may need to interact with other systems and pre-existing components and services. And there may be parts of a system that have “upstream” and “downstream” relationships with your stuff. It can get all quite complictated. It can get hard to keep a clear picture of relations between things in your head.

So it isn’t always the case that a group of people developing a feature are in control of their own destiny (in fact, they often are relying on components or other systems developed by people who are working far away).

One thing that Bernd, another commenter points out, is that managing the dependencies between can get quite complicated. My experience matches up with Bernd’s. Even though you may have a timeline with expected deliveries between components, it still can be difficult to manage. No matter how well you specify an interface for what you need, it is always open to interpretation. Even with tests and exemplary code to illustrate what you want…or what you are providing, the devil is in the details. That’s why people like to encourage developing code that exercises functionality that cuts across the systems and components you are trying to integrate. And if those systems or components aren’t ready yet, mocking is one way to get you ready to integrate. But still. It isn’t easy.

So while it is ideal to have control of a feature, on complex projects there will always be dependencies on other things that not totally under your control. That’s what makes life so interesting, and the role of agile architecture and looking at what lies ahead while keeping yourself firmly planted in today’s realities so challenging. And if you are working in an agile world you take every opportunity to test out the difficult bits before you lock them down. That’s both a challenge and an opportunity.