Richard Seroter’s 10 Architecture Tips From “The Timeless Way of Building” is highly relevant to software development as well:

“Each building when it is first built, is an attempt to make a self-maintaining whole configuration … But our predictions are invariably wrong … It is therefore necessary to keep changing the buildings, according to the real events which actually happen there.” (p. 479-480) The last portion of the book drives home that fact that no building  (software application) is ever perfect.  We shouldn’t look down on “repair” but instead see it as a way to continually mature what we’ve built and apply what we’ve learned along they way.

Just as buildings need “repair”, software takes iteration to get right.

There are a few controversial ideas in Benjamin Sandofsky’s You Can’t Go Home Again, in which he basically says that Agile methodologies shouldn’t be used in mobile app development. I did find this perspective on QA interesting in our increasingly post-QA world:

Sit down with a software engineer from anywhere but the web, and ask them about QA. Tell a game developer you don’t need it, they’ll tell you you’re nuts. Maybe these agile people have been burned by bad QA, but a great QA team is far from a bunch of monkeys clicking buttons all day.

Formal QA provides a counterpoint to “move fast and break things.” Their job isn’t to say, “No.” It’s perfectly fine to ship bugs– otherwise software would never ship. You need someone who is aware of all the bugs, and help you make the decision if the risk is worth it.

Also see Michael Lopp’s The QA Mindset for some really good perspective.

Scott Sehlhorst makes some very good points about different levels of roadmap detail in Opposite Views of a Product Roadmap:

Depending on your role in your organization you will be biased towards viewing your roadmap either as a view of what the team will be building into your product, or a view of why the team will be building things into your product.  As a product manager, it is imperative that you can view it both ways.

When it comes to what you’re building, the roadmap gets less precise as you move further out:

I describe rolling-wave planning as being precise about the immediate-term future, having less specificity about the near future, and being nonspecific (but still helpful) about the more distant future. This is because – from the perspective of someone focusing on what they will be doing – there is too much uncertainty about what will happen between now and the future. (BTW, this is where waterfall is wasteful – it assumes incorrectly an ability to predict the future in detail.)

In contrast, when it comes to why you are building what you’re building, it starts off fairly broad and becomes more precise as you go on:

In the “right now” the team is testing hypotheses. Given a customer, and a problem the customer is trying to solve, there is a hypothesis about how best to help. That hypothesis is a design. The design may or may not be a good one. The implementation of the design may be great, adequate, failing, or incomplete. In this time horizon, the activities of the team building the product are concrete – build, test, learn.

The way I would summarize Scott’s post is as follows. When it comes to product planning, be rock solid on what problems you’re solving for which customers, but be open to data-informed change when it comes to short-term implementation details.

Marysol Elorriaga discusses the challenges of implementing Lean methodologies in large companies in Getting buy-in while moving at rocket speed. One of the guiding principles is to “Release early and show results”:

To make the stakeholders feel like they are getting something equally valuable out of taking the “Lean approach”, deliver the MVP early and show results. Ensure that all features to be released can be measured and there is a proper feedback gathering mechanism in place. Ease the concerns of working under the Lean philosophy with weekly dashboards, including customer feedback, learnings from user validation/testing and analytics. Ultimately, having big data and skilled professionals to transform customer feedback and analytics into business insights is a pre-requisite for improvement and innovation.

From the same blog, Elizabeth White gives some advice on embedding a Lean team in a large company in Building the Right Culture in a Lab Environment. It’s especially important to understand that “We are Lean Enterprise – not Lean Start-up”:

Our room is lean but we are surrounded by a waterfall. While we are fully supported by TELUS, and most internal teams want to roll out what we are doing, we are a big company, depending on some serious backend systems. And while I can go on about our fantastic experience and the merits of working in a lean environment, it is important to note, waterfall shouldn’t become taboo either. There will be projects where waterfall methodology makes perfect sense, there are some – much like ours, where a hybrid approach is best and there will be some, where lean, in its purest form, is the correct path.

If you’re thinking of trying a Lean approach in a large company, there’s some great advice in these two articles.

There are some great answers in the Quora thread How do you prevent scope creep in agile projects when usability testing? From Todd Zaki Warfel’s answer:

Usability testing doesn’t have to be a formal 3 month engagement. There are plenty of resources out there for doing rapid testing, which can easily be worked into a typical 3-6 week sprint cycle. We do it all the time. Take a week out of the sprint to plan, test, compile recommendations and get to work implementing them. Or as Jeff Gothelf commented, just pick a single day each week to test. You won’t need may participants. If you test weekly, then 3-5 will show a pattern. And anything you don’t catch this week, you’ll catch next week.

From Jeff Gothelf’s answer:

Usability testing needs to be worked in to the sprint timeline. In fact, it should take place during each and every sprint. We test every Thursday. It’s never more than 3 or 4 people. We show whatever we have ready on that day. Sometimes it’s live code and sometimes it’s a paper sketch. Everything in between is fair game. The purpose of this is to get constant feedback, mid-iteration, on the work being designed. In many cases, developers and product owners view portions of these sessions and see the issues that arise. An expectation is built within the team that, based on how things test on Thursday, there may be some tweaks to the scope.

I was a little reluctant to click on Greg Satell’s How Wells Fargo Learned To Innovate Around the Customer. First, it’s on Forbes, which has become virtually impossible to read on mobile devices because there’s so much blegh on the page that’s not related to the article. Second, whenever you see people talking about “The Customer”, you should be sceptical. There is no average “user” or “customer”, so this kind of thinking usually results in defining an impossibe target market:

Image source: Tom Fishburne.

That said, despite my fears, the article is quite good. It discusses how Wells Fargo uses ethnography in their business, and there are also signs that they don’t operate like a large, slow-moving corporation at all:

However, it is not just internal processes that have changed, but the culture as well. Ellis’s bankers don’t sit in cozy offices, quietly examining financial statements (nor does Ellis himself), but work in open cubicles designed to promote collaboration. They are constantly iterating, experimenting and testing.

This part, especially, surprised me:

Perhaps most importantly, they are not limited by a long range plan. There is no “five year death march” toward a transformation that will never happen—or be outdated by the time it does. Instead, their purpose is to improve their customers’ businesses and adapt quickly to shifts in technology and the marketplace.

I’d love to see more detail on how Wells Fargo remains lean despite being such a large company. If this is really how they operate, it’s encouraging proof that big doesn’t have to equal slow and tired.

I like the work Growing Agile does, so I clicked on Karen Greeves’s Agile & UX: What’s wrong with working one sprint ahead? with great interest. I’ve been struggling with this issue myself, but I’ve just never come across a better way to integrate UX and Agile, so I was very interested in their viewpoint. The post definitely got me thinking, but I have some issues with their objections. In the interest of letting you in on the thought process, I’m going to take some lines from the post and explain why I don’t agree1. Let’s start with their main concern with UX working one sprint ahead:

The main issue with this is one of focus. If the UX designers work one sprint ahead of the rest of the team, then the UX designers and the team actually never work on the same stuff at the same time. This means they are never focused on the same thing.

This is (partially) true, but isn’t it also true for individual developers on the team? They’ll be working on different stories. That’s the reason we have standup meetings: to make sure that those individual tasks work together to finish the whole.

I say it’s only partially true, because people can focus on more than one thing… So while the UX team is working on the next sprint, they can still be available to help with changes and questions on the current implementation work.

It doesn’t make sense to have the same standup meeting because you aren’t working on the same stuff.

Again, very few people are working on the same stuff. And this is actually an opportunity for the UX team to highlight any issues they have that developers can help them with.

It’s harder to help each other out because you are focused on finishing different stuff.

I don’t really get this point — we should be able to shift focus, and helping each other in different contexts often produce better results. Isn’t that the principle that code reviews are based on as well?

The people working ahead consider their deliverable some interim artefact, not working software, so there is a handover of both knowledge and responsibility.

In our context the UX team’s deliverable is working software in the pattern library, which uses the same frameworks and environment as our front-end developers, so that they can keep going seamlessly. So it’s possible to solve this problem.

People don’t see themselves as part of the same team, so you end up having a UX team and a dev team. This inhibits collaboration and communication.

I don’t agree with this point, either. We’re always going to have different skills on teams. Product Owners have different skills than the development team too. In fact, I think it can increase collaboration if developers are asked to provide input while the UX team is working on an upcoming feature.

The people working behind aren’t involved in the decision making that happened without them and as a result they don’t understand the reasons for certain design choices, this often leads to assumptions, and rework.

This doesn’t have to be the case. We have developers involved from Product Discovery all the way through prototyping, testing, and final specifications.

I’m not advocating writing code before an UX work has taken place. I’m saying the whole team should be involved in that work. Obviously the UX designer(s) take the lead here, but everyone on the team needs to see users use their product and understand the user journey map.

Ok, on this we agree!

In each sprint the whole team should set aside time to look at UX designs for the next sprint, as well as usability testing whatever has been completed.

I agree with this, and it’s how we work. But where I’m confused is that this still means that the UX team is working one sprint ahead of development — they’re working on “UX designs for the next sprint.” The only difference from how it’s usually done when UX and Agile works together, is that it formalizes the time that developers spend on being involved in the UX process.

If I understood that correctly, then it turns out we agree after all, and maybe this post wasn’t necessary…

---

1. This is an important discussion, and I think they add valuable points to it, so please don’t see this as some kind of takedown attempt. I know (and like) Karen and Sam, but I also believe in public, respectful disagreement. So that’s my disclaimer! ↩

I really like the James Buckhouse explains in is article Story Map:

Halfway between a storyboard and a treasure map, it bundles the value and functional flow of your product with the delight people might feel at each step in your product. It sketches the UX flow without locking it down, and it delivers the gist of an idea and the emotional gestalt without prematurely belaboring the details.

A story map depicts how your product works and why it matters—but crucially—it does not explicitly spell out the final design, UI or in-the-weeds UX logic. It does, however, hold the product vision and works as a rubric against which the team can make better and faster decisions.

The article has some great examples worth looking at. As a big customer journey mapping fan, this is definitely something I want to try out.

I have one quibble though, and that’s with the name… “Story mapping” is already a very well established process in Agile development. Here are just a few articles about it:

• The new user story backlog is a map
• Visualizing Progress with Agile Storymapping
• Winnipeg Agilist: How to create a User Story Map

Semantics are important, so my suggestion would be to simply use a synonym:

@buckhouse Maybe just use a synonym and go with “narrative mapping”?

— Rian van der Merwe (@RianVDM) August 2, 2014

Rich Mironov’s We Don’t Hire Product Owners Here is a treasure trove of advice and clear thinking on the dangers of not taking the Product Owner role seriously in companies that make the switch to Agile development. There are so many good sound bites, but I’ll stick with just one that hits close to home:

Don’t let your customer request list become your roadmap. Kano analysis teaches us that letting current customers prioritize your backlog for you leads to market failure.  Don’t let your product owners confuse “this is what the enhancement request says” with “understanding and solving real customer problems.”

Some truth from Joshua Porter in There is no later for your customers (my emphasis added):

There is no later for your customers. The only thing that matters is what they’re using right now. They don’t give a shit about your roadmap, your brilliant feature pipeline, or your vision of a better future. They’re trying to get work done right now and they only know what you’ve already delivered. So build a discipline around your launches, knowing that your ‘temporary, let’s get this out quickly and iterate later’ release is the current reality for your customers. Build up your attention to detail and force yourself to treat every launch like it is your final launch. Imagine that you’ll never be able to deploy something after this…have you done your best work?

Release early, release often is not an excuse to release crap…