Regardless of whether a team has devised personas or not, I tend to see user stories written too much from a what-the-software-does perspective. I’ll just use Joel’s off-the-cuff example for a user story, reproduced below, as an example to highlight this failure mode that so many teams suffer from:

The conversation then typically continues with a “But…” and I end up elaborating on why I say that. This time I’ll elaborate in the Internet, which hopefully helps spread this thought.

“I want to test a private method”

The fundamental motivation for wanting to test private methods is fear. We fear that our code coverage report’s 100% result isn’t the whole truth (and it isn’t) and we don’t trust our unit tests – the ones that already test the private method indirectly – to have kept out all critters from that piece of code encapsulated behind the magic keyword private.

Why don’t we trust our tests? First of all, in most of the cases when this question is popped the code hasn’t been written test-first. Tests that are written afterward tend to suffer from confirmation bias – we write them to prove to ourselves that we are indeed the great programming geniuses who never make a mistake. Such tests can indeed be much less than a full-cover insurance.

The code is also to blame for our lack of trust. We rationalize our need to write direct tests for a private method by pointing out how hideously long, complex and ugly that method is. This line of thinking exhibits itself quite clearly when people respond to my strict statement with, “…but you just said that we should test ‘everything that could possibly break’ and this private method here looks so ugly that it could break at any time!”

“I understand. And you should not test that method if it’s private.”

In this phase of the dialogue we’ve typically establish one thing: the person asking the question really wants to test that private method, usually for the reasons mentioned above. And that is perfectly reasonable. Yet, I persist and restate that they should not write tests for that private method. So what am I thinking? Why shouldn’t we test it directly?

For one, writing tests for a private method might not be technically possible in your chosen programming language without obnoxious trickery like invoking a private method through Java’s Reflection API. Such tests are also bound to break when you swoosh ahead with those lightning-fast refactorings your IDE vendor has graciously automated for you – because referring to methods and classes through literal strings makes the IDE blind to that link, effectively cutting your tests off from the reach of the Rename Method refactoring you just pulled off in Eclipse.

Second, private methods are details that you clearly don’t want to expose through the class’s public API. After all, if you’d be OK with making that private method public then you wouldn’t have asked the question in the first place. Package private and protected methods are a bit of a gray area in this regard. Bumping up the private method’s visibility so that the tests can invoke it but not so much as to make it part of the public API kind of solves the problem of resorting to ugly hacks – you can now invoke the method without reflection. However, the artery is still exposed and your class’s internals are leaking on the floor. Your tests are testing the object’s implementation, not its intended behavior.

“So what would you do?”

At this point we’ve usually established that the method in question is covered indirectly by other tests but that it’s so complex or important that you want to test it directly. So what would I do?

I would test it as a public method on another class.

The whole pain of seeing that private method, wondering whether it truly works or not, and struggling to decide whether to leave it like it is, whether to increase its visibility and test it directly, or whether to resort to the mortal sin of reflection – all of this pain is trying to tell us something. The code is trying to tell us something.

Clearly that piece of code is important and essential enough that it should get a new home and become a public method on some other class – quite possibly on a whole new class. Writing direct tests for it over there would not be an issue anymore.

A place for everything and everything in its place. It seems that Mr. Franklin was a programmer himself.

My journey from code to design

At first my attention was consumed by the engineering practices that XP imposed on the kind of cowboy programming I had seen around me – and performing myself – both in the context of ad hoc and of supposedly highly disciplined methods. I forced myself to write my code test-first, I asked to pair program with others, and I checked in code in far smaller batches than before.

Looking back at around five years ago I can see my interests starting to move towards team work and project management. There was still plenty of improvement to make as far as engineering practices went but that work wasn’t consuming as much of my learning cycles as it had before. I routinely ran classes on test-driven development and spent a lot of time pair programming with clients, coaching them in writing better unit tests but I was increasingly more curious about the kind of insanity and waste I observed happening outside of an individual programmer’s sphere of influence.

Since about 2005 the majority of product development efforts I’ve been involved with have been “Scrum projects”. Considering the Scrum trifecta of a development team, a Scrum Master, and a Product Owner, I can see a slight trend of my work starting from the more technically oriented end of a development team through the more team work and facilitation-oriented domain of Scrum Master, and lately more and more towards the prioritization and product design-oriented world of the Product Owner.

The constant through this change

The single common thread throughout these years has been that my goal has been to help clients succeed with their product development efforts. At first I saw severe problems with code quality and discipline that I could help alleviate with certain engineering practices and processes. Later I saw dysfunction in collaboration between people in different roles and strived to improve that collaboration with facilitation and coaching, applying methods like Scrum. Then I saw dysfunction in the Product Backlog and around the Product Owner’s role, seeking to help the people involved understand the system and how they can influence its behavior in more productive, more effective ways.

Other people have had the same goal of helping clients succeed with their product development efforts for at least as long as I have. I work with some of those people. Many of those people also have had a vastly different approach to reaching that goal. After all, we all have our individual experience, skills and quirks that we must play with and make the most out of them.

Introducing user experience

In 2005 we hired a couple of professional interaction designers. They brought in just such vastly different skills. Up until then we had survived with our engineering-oriented, albeit multi-disciplined, staff, every now and then reaching for outsourced help with interface design. We had almost invariably been disappointed with the results from such outsourcing and yet we knew that we weren’t delivering the best user experience we could for our clients. Not that the clients were complaining but we knew and we do have a thing for perfection.

From the beginning our interaction designers were loudly proclaiming that “programming should only start when the interaction design is done.” Essentially their message was that interaction design was the king. That didn’t go down too well with the XP/Scrum-minded folks who were almost 100% programmers and very much into short iterations, incremental development, and generally allergic to big-design-up-front. After all, most of us have worked for major consulting companies and even the smallest hint of waterfall would give us the chills.

After a while the exaggerated soundbites started making room for more constructive discussion and more open-minded search of a Better Way. From one project to another our engineers and designers grew experience and formed a way of working that seemed to yield the best of both worlds, accommodating iterative and incremental development without a big design up front and the kind of smart user interface that truly was fit for purpose. We started being more and more pleased with the approach. We had a gold standard for how we want to run our application development projects.

We still had a problem as we only had a couple of interaction designers and plenty of projects that desperately needed their precious attention. We have found ways to alleviate that bottleneck – including hiring, of course – but we’ll come back to that topic later. Right now, I’d like to explain how we execute UI-intensive software projects today, combining user interaction design and agile methods into what I personally consider the best way I’m aware of to build such software products or applications.

Just enough design up front

Some of our engagements don’t involve any code to be written, some of our software delivery projects don’t involve a single graphical user interface, and some of our software delivery projects have a user interface that quite frankly isn’t all that important. When we do engage in a project where delivering a great user experience is essential, this is how we work.

To start with who’s involved, there’s a dedicated development team made up of generalist software developers capable of turning requirements into working software. There’s also a dedicated user interaction designer who’s capable of interpreting what different people are saying into a functional user interface design.

We start with what some might call “just enough design up front” where, over a time span of a couple of weeks, the user interaction designer digs into the problem domain and carries out a number of interviews with different people. Those different people may hold titles such as Product Owner, Product Manager, VP of Product Development or, if we’re lucky, titles such as Junior Sales Associate or Cashier. We want to talk to users, not somebody who pays the bills. Sometimes this luxury is available and sometimes we’re not that lucky.

Based on this work the user interaction designer identifies and documents the essential usage scenarios that represent the most significant, most valuable use of the system. With these scenarios to work with the designer starts iterating toward a user interface design that supports these scenarios with the best possible design, starting with just one scenario and incrementally expanding and editing the design one additional scenario at a time. At some point the designer starts involving the client’s staff to help validate the designs, which at this point are generally sketches or paper prototypes.

When the designer feels confident enough that the main cruces of the problem domain and the main usage scenarios have been solved, the design is considered stable enough to start programming. Up until this point in time, the development team has usually set up their infrastructure or worked on specific bits of implementation that do not involve the user interface.

The very reason we don’t start implementing the user interface on day one along with the user interaction design work is that it’s much, much more expensive to iterate in code than it is to iterate on paper. There’s a lot of rework to be saved by investing some time up front on this work.

Working with the designs

Once implementation begins, what the development team works with is a Product Backlog derived from general system requirements and the functional design – the sketches and paper prototypes – provided by the user interaction designers. By the iteration planning meeting the Product Owner and the user interaction designer have identified vertical slices of end-to-end functionality that could be implemented in the next iteration.

Sometimes those vertical slices are straight from the designs, e.g. a panel that displays information. Sometimes, those vertical slices are a stripped down version of the design resulting from a decision to down-prioritize a particular usage scenario. Sometimes, however, there’s a need for an intermediary design that introduces partial functionality with the intent that this is a temporary solution. In those cases, the development team and the user interaction designer are looking for a compromise that delivers the best user experience feasible with the boundaries of implementation effort and iteration length.

During an iteration the interaction designer reviews and validates the implementation as it progresses and serves as a quality gate – “reviewed by interaction designer” is often part of the team’s Definition of Done. Essentially, the interaction designer’s attention is split between this iteration and the next iteration(s), very much like that of the Product Owner’s. Just like the Product Backlog continues to live and evolve our user interface designs continue to live and evolve.

Beyond the bottleneck

As I said before, we hired a couple of trained professionals in interaction design back in 2005 and that wasn’t even remotely enough to staff all of our web development or desktop application projects with a full-time interaction designer. I also said that we’ve found ways to alleviate that problem.

The most obvious solution is, of course, to hire. That has proven to be somewhat difficult and even though we received almost a thousand applications last year only a tiny fraction of those applicants have had the right profile. Instead, we’ve had to find ways to source that talent from within.

A couple of years ago we started an internal apprenticeship program and a handful of solid programmers jumped on the user interaction train. Our experienced interaction designers taught their apprentices in regular training days and mentored them almost on a daily basis. In practice this meant that our senior designers had to take on much less work than before. On the other hand, we immediately had a wider spread of limited knowledge and skill – enough to fulfill the immediate needs of a development team – and bigger designs would still be reviewed together with a senior colleague.

Seeing the apprenticeship program become as successful as it has makes me wonder at the courage and drive of the individuals who saw the importance and dared to make the leap. Others have also taken part in the trainings and the whole company is more or less familiar – at least on a theoretical level – of how user interfaces are designed with our iterative method.

Personal touch

Some time ago I was a developer on a software project where we had an apprentice user interaction designer on staff and a senior designer paying us a visit one or two days a week. It was a relatively big project for one designer, however, with multiple teams working on an application where a good user interface was considered crucial for commercial success. Our sole full-time designer frequently had her hands full when a larger UI change was approaching and user stories would pile up towards the “interaction designer’s review” column on our story board.

I took part in one of those larger UI changes in a small team of four developers. The whole thing had bubbled through the Product Backlog very quickly and we didn’t have a single sketch or prototype to work with. We could’ve said, “no, we can’t do this before the designer has time” but instead we said, “yes, we can do it.” After all, it’s not a problem for us to take collective ownership of code given that we all know a bit of everything in the code base so why should the UI be any different?

Art of the possible

We decided to take the reality by the horns and make the best of what we had. We started preparing for the upcoming implementation between ourselves, trying to verify that we really do understand the big picture, identify the relevant usage scenarios, and sketch solutions that would support those scenarios as best we could. Stepping outside of our respective comfort zones wasn’t anywhere near as frightening as it had sounded a couple of weeks earlier.

Once we had agreed about the overall design with the team I set off to create a more detailed design for one particular user interface geared at managing orders and their logistics. I looked at the usage scenarios and specified what kind of information does the user need at which stage, what kind of information does the service provider need, and what kind of a workflow and interface design would tie it all up such that all of the scenarios would be supported and that I wouldn’t be leading our team down the front end programmer’s equivalent of Dante’s Hell.

That was hard. Not because I couldn’t have designed a user interface but because nobody from our team knew what the people in logistics actually do, how they work currently, and what kind of a user interface would best support them in their task. Our Product Owner knew something about it but he also had just second hand information from the management of the logistics department. This was when it finally sunk in for me how crucially important it is to get to talk to actual users – I had no idea what the warehouse dudes actually have to do before Tom’s new mobile phone and Jean’s shiny new iPod leave the premises with the correct transport manifests and everything.

Again, I knew that I could only do my best with what we had. Besides, I had been through the basic training on user interface design, I’d read Alan Cooper’s classic about inmates and an asylum, I’d read “About Face”, I’d familiarized myself with user interface design patterns, and I’d seen many designs created by our awesome interaction designers. It wasn’t difficult to design a good user interface. Maybe not a great user interface but it’s perfectly doable to design a decent solution by following our method, focusing on the usage scenarios, and iterating the design, simulating against the scenarios.

Creeping insecurity

At this point I had a design that I thought was good but I also knew that I’m relying on the hearsay and babble of the Product Owner, which shed some insecurity into my doing. I had just leaned back in my chair, looking at the sketch in front of me and wondering whether it really is good enough when our senior interaction designer walked in. He wasn’t supposed to be at our disposal – he was there for another project – but I thought, “screw it, he’s there and this will only take a few minutes.” After all, I might get an opinion back in two seconds that could be compressed into something along the lines of “that’s the crappiest solution I remember seeing” but at least I would know so I walked over and asked if he had a moment to take a look at my design.

I explained the usage scenarios for which the design was made and what kind of widgets and behavior I had drawn in it. He asked me some clarifying questions and I did my best to answer them. Most of the questions were related to what happens at the logistics department when orders are coming in and how the logistics people juggle the orders internally, alone or collectively, grouping by customer or by product, whether the delivery address influences the way they are processed, etc.

After some five to ten minutes I walked away having crossed over one panel that wasn’t actually necessary for the scenarios and with a couple of other minor changes to make. We didn’t only have a better design but also a good feeling about having done our best despite our lack of availability for user interaction design expertise. We had likely done a good job (which later proved to be a correct assumption) and most certainly better than the CRUD-crap that we’d seen some competitors produce in the past.

Parting thoughts

It was definitely worth taking that step outside of the comfort zone. Looking back at this experience, it has provided me with a lot more perspective and tools for my coaching work with Product Owners. In fact, I’m certain that it wouldn’t hurt for a Product Owner to invest some time and effort to learn about user interaction design. After all, it’s all about product design, learning and knowing what your users need, working that knowledge into the Product Backlog, and refining your designs to allow for iterative and incremental implementation of that Product Backlog.

Scrum Masters are not supposed to be managers. Scrum Masters are not some kind of coordinating bodies between teams and Product Owners. Scrum Masters don’t manage anyone but themselves. That’s one of the reasons why it’s often easier for a non-manager to take on this role – lacking the baggage of old habits of managing others.

It shouldn’t be a surprise that we may have established such mental models, however. After all, even some Scrum tool vendors get it somewhat wrong and Wikipedia’s agile software development-related articles are notoriously flawed. Even the Scrum Alliance, who’s supposed to be the official center of Scrum-related knowledge and information (along with the competing Scrum.org), has such utter bull on its website (I’m referring to the sidebar of that page and the Scrum Master having “three primary responsibilities in addition to leading the daily scrums“…) that we’re left without an authoritative source of information beyond individuals we trust.

Personally, for such authoritative source of information, I recommend reading writings by people such as Ken Schwaber, Craig Larman, and Bas Vodde. These are predominantly books. One notable exception is the Scrum Primer (PDF), which I find to be perhaps the best description of Scrum available online.

The Scrum Alliance’s role description is not total bull, however. Namely, their list of Scrum Master’s responsibilities isn’t far from what Certified Scrum Trainers have taught for almost a decade now:

What the Scrum Alliance says about the Scrum Master’s responsibilities

The Scrum Master is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues.

• Ensures that the team is fully functional and productive
• Enables close cooperation across all roles and functions
• Removes barriers
• Shields the team from external interferences
• Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
• Facilitates the daily scrums

Notice how the Scrum Alliance’s definition doesn’t put the Scrum Master in between anyone else except between the team and “external interferences”. The Scrum Master is not supposed to act as a single point of contact towards other teams or towards the Product Owners. The Scrum Master, according to the Scrum Alliance, does have administrative responsibilities such as issuing meeting invitations to the Scrum ceremonies (standup, review, planning) and the facilitation of the daily standups.

I would personally go even further and say that the first two bullets in the above list imply that the Scrum Master should seek to detach himself from much of that administrative work over time, as the team begins to take responsibility over their own productivity, cooperation across roles and functions, removing more and more of their barriers as they empower themselves, learn to stand strong in the face of external interference, and facilitate their own collaboration.

Note that this doesn’t necessarily mean that the Scrum Master’s role wouldn’t be a full-time job.

For a description of the Scrum Master’s responsibilities that is more in line with the original spirit of Scrum and the role, this is how Ken Schwaber and Jeff Sutherland, original creators of the method, describe the role in the Scrum Guide:

The Scrum Master

The Scrum Master is responsible for ensuring that the Scrum Team adheres to Scrum values, practices, and rules. The Scrum Master helps the Scrum Team and the organization adopt Scrum. The Scrum Master teaches the Scrum Team by coaching and by leading it to be more productive and produce higher quality products. The Scrum Master helps the Scrum Team understand and use self-organization and cross-functionality. The Scrum Master also helps the Scrum Team do its best in an organizational environment that may not yet be optimized for complex product development. When the Scrum Master helps make these changes, this is called “removing impediments.” The Scrum Master’s role is one of a servant-leader for the Scrum Team.

This is much closer to the mindset that I’d like to see adopted as far as the role or responsibilities of the Scrum Master are concerned. Scrum was developed within a software company over several years as the group devised and refined their engineering and product management practices. It’s a designed system that creates a dynamic equilibrium. If we move one lever the others will inevitably move as well. If we compromise on one front or one aspect of our system we shouldn’t expect too much on the other fronts either.

Assuming we want to make the most of Scrum we need to pay attention to Scrum, its roles, and what they entail. We need patience and drive to study, learn, and understand Scrum. Skimming a book or sitting through a presentation is clearly not enough.

The next time you catch yourself or someone else blurt that the Scrum Master “removes impediments” or “facilitates a standup”, stop for a moment to make sure that the parties involved in that conversation understand what these soundbites really mean and, perhaps even more importantly, what they don’t mean.