“Agile Architecture”: Is Your Product’s Architecture Simply a Reflection of its Release Schedule?

After recently reading George Fairbanks’ Just Enough Software Architecture and obtaining 90% in my TOGAF 9.1 Foundation Certification exam in Enterprise Architecture, I’ve naturally been thinking about Software Architecture a lot. The other day a friend and I were talking about a typical scenario, involving large scale products with multiple sprint teams on a tight delivery schedule. I will over-simplify and over-generalize it here:

The Scenario

Let’s say you’re building a product which requires a feature that a snapshot can be exported to a PNG file. This is typically what would happen:

• Product Owner: “As a user, I want to export snapshot to PNG, so that I can email it as an attachment to the Finance Department”
• Story is added to Product Backlog, prioritized during the Sprint Grooming and estimated in the Sprint Planning
• Developer Dinesh starts working on it, he adds the Export to PNG feature, it is demo’d at the end of the Sprint and everyone is happy

The feature and product iteration is shipped, customers start using it, the product team goes back to juggling new features and bugs. Priorities and sprint teams change. Somewhere down the line, another requirement comes up:

• Product Owner: “As a user, I want to export snapshot to PDF, so that I can archive it in the Document Management system” (Don’t ask why the two systems can’t work with the same format).
• Story is added, prioritized and estimated. This time though, Dinesh isn’t around (he’s either on vacation, promoted, no longer in the company or simply more focused on another aspect of the product)
• Developer Gilfoyle starts working on this feature. From this point on, 3 things can happen:
  • Rearchitecture: An experienced developer or architect recognizes the potential of code reuse/refactor/rearchitecture between the two implementations. A common interface emerges, common functionality is moved up and specific functionality is moved to concrete classes. Note that:
    • Code is refactored
    • Some previously existing code is even thrown away
  • Technical Debt is accrued: Gilfoyle has limited time to implement the new feature; on the UI side the “Export to…” menu selections show up users would expect, but the internal implementation is disjoint. The code is not clean (but does the job), the Export functionality is not unified into a single interface and there is code duplication.
    •  In some of the stakeholders’ minds, code has been “reused” from the previous implementation, but in reality it has been copy-pasted (imitation being the best form of flattery towards Dinesh)
    • The team and PO might even recognize the Technical Debt and add it to the backlog, to be dealt with in the future at a lower priority (although that tends to lead towards a Bottomless Backlog)

In both cases, layers emerge in software over time as features are added and the product evolves. However, the first case has architectural layers and the second exhibits feature layers: In extreme cases, you might even be able to infer the Product Backlog by looking at the order in which features were added.

The Analysis

Some thoughts:

• “The Technical Debt Trap“: Doc Norton explained it very well at CraftConf 2016 (video link): (a) Most of what we have come to call “Technical Debt” is actually code cruft, and (b) “clean, testable code is a pre-requisite to being able to pay back Technical Debt”.
• Show me the $: While a Product Owner may have limited influence over where budget is spent, a Product Manager may be in a better position to limit the long term negative effects of decisions made within the scope of individual sprints
• One size does not fit all: Complex products or long development cycles, must be overseen by an experienced Architect or Development Lead, who advises the PO, PM and other decision makers
• Stakeholders pay for the product, not the code: For stakeholders coming from a more traditional software engineering background, it may seem like throwing away (or refactoring) code is a questionable decision, because money was spent on producing it. This thinking must be erased by clarifying the benefits of a more robust and maintainable design.

The Solution (Maybe)

In summary: Features, as seen by the business, are not always the same as features, as seen by the developers. I’m tending to think the solution might be to maintain two backlogs: a business-oriented Product Backlog, and an architecture-oriented Technical Backlog. The latter would go into the details of how the business needs will be met at a technical level, driven by the objectives of overall cohesiveness, maintainability and constant reduction of Technical Debt. Here’s how I imagine it:

Note that the technical effort to achieve a given amount of business features, is more than what it would be if the team worked off of a single backlog. This is simply because the Technical Backlog takes into account the additional effort of refactoring/rewriting, which is normally not covered in the typical Product Backlog.

I’m curious about what you think, please leave a comment below or get in touch on Twitter: @survivalcrziest.

(PS: Here’s a tip: VCS-based Software Analysis by Adam Tornhill)

Update: Prioritization of Items in the Technical Backlog

Based on some of the readers’ feedback, I would like to clarify how I intend the system to be used:

1. The top of the Technical Backlog is prioritized / groomed based on (a) “Technical Value” and (b) budget and schedule constraints (“effort”).
2. •  Technical Value here is defined as the value delivered by the technical solution towards meeting the needs of the [prioritized] Product Backlog.
3. Items may be to the Technical Backlog not just based on the insertion of new features in the Product Backlog, but also based on technical reviews / retrospectives where it is identified that an architectural change is required (e.g. for purposes of maintainability or compliance).
4. The items pushed to the bottom of the Technical Backlog thus represent Technical Debt.

 

Evangelizing Lean Product Development

I’ve written and tweeted before about how influential I think Eric Ries’ The Lean Startup has been for me. While we wait for Eric’s next book, The Startup Way, which is more focused on bringing lean thinking to big companies (and by the way is being researched in a very interesting way — read about it on KickStarter), the timing was right for me to assimilate my thoughts and share them with a group of colleagues.

While I’m still waiting for the feedback to pour in for my 3-part course, I’m very happy to have had the opportunity to share with others that “Lean” is not just some black art practiced in car manufacturing plants, and “Entrepreneurship” can take root even in large, established organizations. Now, more than ever, we are all living (and trying to thrive) in “conditions of extreme uncertainty”.

I hope I have been able to get across some of the thinking behind the concepts covered in Eric’s book: the Build-Measure-Learn feedback loop, the Minimum Viable Product, Innovation Accounting, Vanity Metrics, practical techniques like Cohort Analysis & Five Whys and finally the most relevant: The Innovation Sandbox.

I also threw in a bit of George Fairbanks’ Just Enough Software Architecture, which addresses “engineering risk”, as opposed to “project management risk”. And of course, lessons learned from my enlightening weekend at Lean Startup Machine a couple of years ago.

The coming days will tell if the course was useful and comprehensible enough for others to practically apply some of the principles to their projects. I hope that over time we can build a community of like-minded lean practitioners within the organization, acting as enablers of sustainable innovation. #WasteNot.

Scrum, Kanban, Scrumban or Just Ban Scrum? (Part 2 of 2)

Part II: Some Solutions

Continued from Part 1, with the same disclaimer applied.

 

Collaboration and Distributed Scrum

If you’ve been in a successful Scrum Team with geographically distributed members, I would really like to hear from you, O Venerable Master. After all, team effectiveness has been known to diminish with as much as 2 meters of physical separation. If you must do Distributed Scrum (hopefully as a transitory step), then here are a few tips that will (I hope) save you the trouble of learning the hard way:

1. Obviously, ensure everyone on the team is fully aware of language and cultural differences, especially the Power Distance Index (if that sounds familiar, it’s from Malcolm Gladwell’s Outliers)
2. Email is only 14-17% effective as a medium of communication (Videoconferencing helps)
3. Further, information is lost exponentially as a function of distance and overhead of tools used (simply put, people are inherently lazy…)
4. …Which may prevent you from achieving fully cross-functional teams without specialists
5. Agile at scale requires trust at scale
6. Everyone needs to have access to the same infrastructure (at the same latency) and an identical development environment
7. Get Agile Evangelists (SM, Coaches, stakeholders) at every location and get them to agree on your organization’s Scrum process
8. Eliminate mixed signals, possibly by having a Proxy Product Owner
9. Empowerment and Autonomy are useless without Feedback
10. Establish an Exchange Program where [at least some] developers from different locations get to experience the reality of their counterparts (This will probably be your best investment)

The most important consideration, given all the specific limitations of your situation, must be that whatever arrangement you come up with, is sustainable. Create success stories and replicate the model. And note that Distributed Team can very well exist without Distributed Scrum.

Why Are You Doing Scrum, Anyway?

One day I’m going to be an Anti-Agile Coach. Because I’m convinced they’re so many people getting it wrong, that there’s a lot of money to be made from it. But first, some free advice: You should really consider if Agile or Scrum is really applicable to your Organization, Industry and Business Context. A good starting point is the following thought process:

You would like to adopt Scrum (or Agile) because…

1. …Your scope/specifications/customer commitments change often (If not, you might be indulging in WaterScrumFall)
2. …Your market changes often, requiring quick adaptability (e.g. Competition pops up out of nowhere overnight)
3. …You need to deliver (or release) continuously (As opposed to a one-time deployment, followed by maintenance)
4. …Your technology stack can/will change often (i.e. you haven’t invested tons of $ in license fees, and/or you will evaluate multiple options)
5. …You have the flexibility to experiment/take risks, and your organization rewards failure (or at the very least, doesn’t penalize it)
6. …Your dev team is nascent, so you expect dev processes to evolve
7. …Your industry is neither mission-critical nor heavily regulated (although there are exceptions as Nancy Van Schooenderwoert explains)
8. …You have metrics to show that Scrum would be more effective
9. …Your Admin/HR/IT teams have Daily Standups (yes, I have seen them happen)
10. …Everyone else is doing it

If you scored low on the above checklist, please consider that Iterative Software Development is still a thing, especially if you’re dealing with hardware or manufacturing. It’s not Waterfall, but it’s Scrum with a bit more commitment.

On the other hand, you might be in a field of work where you’re ready to treat software development more like Surgery than Civil Engineering (as Dan North explains in his talk).

Whatever you do, don’t indulge in Reverse Waterfall: Convincing yourselves that what you delivered is in fact what you intended to deliver.

(Please share your thoughts and experiences as a comment or connect with me on Twitter: @survivalcrziest)

 

Scrum, Kanban, Scrumban or Just Ban Scrum? (Part 1 of 2)

Part I: Some Problems

I have been playing the Scrum Master role off and on since 2008, almost all of it for geographically distributed teams. During this period, I have been lucky enough to work for 3 different companies in 4 countries. Over the years, a sinking feeling has been growing within me that we have started using “Agility” to mask unwillingness (or I dare say, often, inability) to commit. Allow me to crystallize some of the thoughts that are forming in my head.

(My usual disclaimer applies: none of the below is intended to reflect on my employer(s) or specific colleagues, whether past or present. These are my personal, generalized opinions intended for retrospection.)

Ceremonies and Metrics

First and foremost, if you don’t have Sprint Retrospectives, or in your organizational/business context, are unable to enforce accountability for, or effectively followup on, action items identified in the Retrospective, then read no further. Your Scrum is Doomed.

Sprint iteration size matters, too: “A 2-week sprint is just enough time for a mini-waterfall, and thus we are all basically whitewater rafting all the time” ( — Dan North).

If:

• you’re not collecting metrics (at the very least: Capacity, Velocity, Committed vs Completed Story Points, Release Burn Up, possibly correlation between Story Points and Hours, if you’re organization is into that sort of thing, and various forms of Lead Time)
• or not really paying attention to what they’re telling you
• and they are not visible to and understood by the whole team

then you have already failed, you just can’t see it yet.

Demo vs Release

On the other end of the spectrum, when the mandate for Scrum or Agile comes top-down, often there is excessive emphasis on ceremonies. Specifically, the end-goal of the Sprint becomes the Demo, rather than the Release. Scrum clearly dictates that no additional or specific effort must be spent on the Demo, it should be more like a natural outcome.

You can have as many Demos as you want, but what really matters for a product is Customer Feedback. Which, just to be clear, is not the same as Internal Management Feedback. Management is inherently biased in favor of your team, after all they very likely played a big part in hiring and building it. 10 internal demos are worth a single demo in front of a potentially paying customer.

The focus, then, should be on the Release of the Potentially Shippable Product Increment (complete with changelog, user documentation, installers, troubleshooting guides and quality reports) rather than an orchestrated demo in a controlled environment. This is where Continuous Integration, Continuous Deployment and more recently, DevOps comes in to the picture. If your Release Process is time consuming, unpredictable, not automated and/or has too many dependencies that are not in your control, your team is not yet Agile.

Dependencies

If your software dev team is Agile, but the rest of the organization is not, Agile is going to fail. By rest of the organization, I mean other dev teams that they have dependencies on, manufacturing, HR, Admin, IT — every single department in the organization needs to understand, live and breathe Agile. Because if they can’t respond to change effectively, then they will hold your software dev team back.

The most effective way of crippling a self-organizing Agile team is to give them full accountability, with limited or no influence over those responsible for potential impediments.

Another assured path to mayhem is when multiple teams work on a shared codebase in concurrent sprints, or when a dependency is being iterated on in the same sprint as a feature that needs to be delivered.

The Bottomless Backlog

Often in geographically distributed teams, and/or on large scale projects, the physical Scrum Task Board is replaced by a more practical virtual one. Such task boards, like those provided by JIRA Agile, Rally, Trello and several others, replace Post-Its by virtual cards, enhanced by features such as attachments, comments, time tracking and reporting. Just like any other application of technology, there is a flip side: It just a matter of a few clicks and keystrokes to add something to your Product Backlog, or to alter project plans in a significant way by moving tasks around. It’s very easy to get carried away, and often we start injecting scope creep into the Backlog, disguised as finer details of existing features (for example see User Stories vs The User’s Story).

If your organization uses different tools for Requirements Management and Project Tracking, and if there’s no strict mapping from requirements to user stories (yes, it happens 🙂 ), then it becomes very easy to lose control of the project without realizing it. A more typical scenario is working with a limited budget (usually allocated upfront),  but adding tasks endlessly — kind of like a fractal with fixed surface area, but infinite perimeter. Even with regular Backlog Grooming and prioritization, your team will still feel dissatisfied because a major chunk of the Product Backlog will end up remaining undelivered.

Finally, if you’re not in a position where you can compromise features over quality, then your Agility is severely limited.

Upfront Architecture and Specification

Probably the biggest excuse we use Agile for is to do away with high-level architecture altogether. Different Sprint teams work on different areas of the project, each optimizing locally and focused on the immediate Sprint (or two). Eventually it becomes apparent that several teams have been solving the same problem, maybe (surprise) even in different ways. The Scrum of Scrums can help, but on the rare occasions when it does happen, it is more focused on execution than design. Towards the end, more incompatibilities surface and there is a rush to “adapt the Architecture to the Business Reality”, which is basically an update of the Architectural artifacts based on the code being delivered, rather than the other way round.

So let’s recap:

1. Being Agile does not mean no design, it means less upfront design.
2. There needs to be traceability from Requirements to Specification to Architecture to Design to Execution to Validation to Deployment. It doesn’t matter what you call these things in the context of your Industry, but just because you aren’t doing Waterfall doesn’t mean you can decouple execution from specification.
3. Technical Delegation is not the same as Management Delegation. If you ask 5 teams to report progress using a specific tool, they will all report it the same way. But if you ask 5 self-organizing Scrum Teams to architect a technical solution, you will get at least 3 different results, if not 5 (or 7 with secondary recommendations).

Read on for some recommended solutions. I would love to hear your thoughts and experiences, please leave a comment or connect with me on Twitter: @survivalcrziest

Craft Conf 2015, Day 3

Continued from Day 2, here is a summary of talks I attended on Day 3:

From the Monolith to Microservices: Lessons from Google and eBay

By Randy Shoup | Video | Slides

Another eye-opening presentation with valuable insights, such as the fact that [a big organization like Google] doesn’t need architects, it just needs standardized communication and standardized interfaces. And that one of the biggest mistakes people make with microservices is reflecting the provider’s model instead of the consumer’s model. I highly recommend his talk, because it is based on the analysis of several Silicon Valley giants, successful either in the past or the present.

Interaction Driven Design

By Sandro Mancuso | Video | Slides

Sandro’s presentation was full of real examples rather than just theory. I had never heard of the Walking Skeleton before. It was an interesting intersection of DDD (Domain Driven Design), MVC-type architectures and SOLID principles, leading up to a pragmatic way of structuring and packaging software projects. Other advice from Sandro included modeling behavior, not state and not necessarily representing repositories as first-class citizens.

WebSocket for the Real-Time Web and the Internet of Things

By Peter Moskovits | Video | Slides

Not only was it an amazing presentation with live demos, Peter was also fully prepared with a backup plan for everything – including a PDF version of his presentation. After a historical perspective & technical explanation of how WebSockets work, he jumped into Kaazing demos which you can also experience online here. The most interesting was a kind of MVP for disseminating airline telemetry data (here).

Why Is An API Like a Puppy?

By Ade Oshineye | Video | Slides

RESTful APIs are not the solution to all of the world’s problems: Ade was short, succinct and insightful. The title of his talk reflected the fact that an API is an expensive long term commitment, it’s not just about the initial cost of software development. He got a lot of attention when he revealed that Google’s most successful API is AdWords, and it’s SOAP, not REST. Although REST is theoretically good, it doesn’t usually fit well with the real world consumer’s way of thinking. Another one of his gems was that if your [public] API is not being spammed/abused, then either no one is using it, or it’s happening and you’re not aware of it.

Implementing the Saga Pattern

By Caitie McCaffrey | Video | Slides

There wasn’t anything interesting to me during this time slot, so I decided to go with this one just for the Halo reference. There was just one picture of Halo. And a lot of “so” and “like”.

Techniques and Tools For a Coherent Discussion About Performance in Complex Architectures

By Theo Schlossnagle | Video | Slides

Theo decided it would be a good idea to plaster all his slides with huge pictures of steak. Anyway, after establishing that User Experience is measured in milliseconds, and that performance is also about the time spent between service layers, he covered distributed tracing systems such as Dapper and Zipkin.

Great Engineering, Failed Product

By Marty Cagan | Video | Slides

Marty drew on decades of experience in Silicon Valley to summarize why great products and companies fail over and over again. I highly recommend watching his inspiring and insightful talk. Some of the things he touched upon while comparing successful and poorly performing teams:

• Customers and company executives are a bad source of product ideas, because they don’t know what’s technically achievable
• Developers are a good source, and so is Data (analytics, metrics, usage)
• Multi-billion dollar projects are not based on a Business Case accurately predicting future revenue
• Roadmaps are not a good indicator because Customers have other options available to them
• Think Time to Money, not Time to Market – which means more than one iteration is involved
• Product Managers are not mere [user] story writers – they need to have a deep understanding of the business, industry, customers and constraints
• Most teams work in a way that gives them probably 20% of the benefit of Agile Methodologies
• Value outcomes over output; think in terms of results, not projects
• Successful teams run as many as 20 MVP experiments in a week – even if it involves hardware
• Successful companies use an OKR approach to measure progress

• The four product development questions:
  1. Will the customers choose it? (Customer Validation)
  2. Will they be able to use it? (User Experience)
  3. Can we build it? (Feasibility)
  4. Can our stakeholders support it? (e.g. Legality)

______________________________________________

Craft Conf 2015, Day 2

I had the privilege of attending the second year of CRAFT, a tech conference in Budapest focused on software craftsmanship. The last year (which was the first time it was held) had completely blown my mind. A year later I still keep referring back to the talks and haven’t finished fully absorbing them and putting all those inspiring ideas into practice.

In short…

Craft Conf 2014 was better. The speakers came from a more diverse background, the talks spanned a multitude of unrelated topics and I remember it being very, very hard to choose from talks happening in parallel. Each minute spent there was a revelation.

This year, though, many of the talks seemed to be plug for a company or a product, in disguise. Certainly there were brilliant takeaways, but not at the same scale as the previous year.

In my opinion, 2014 was also held in a better venue, although the 2015 venue was outstanding too, as far as tech conference venues go. But the rooms were too far spread out (the map was inaccurate), the acoustics were bad everywhere except the Main Room and unlike 2014, the WiFi was not flawless. Lastly, there were far fewer food choices, longer queues, no bottled water (even for the speakers) and therefore a lot of glasses clanking.

On the positive side, the schedule was followed down to the minute, the live video streaming was smooth and considering the scale of the event (1300 attendees), everything was beautifully organized. I’m not complaining – it’s just that the first CRAFT had set a pretty high standard.

(Video and Slides links will be updated by next weekend, when they become available)

Agile Engineering in a Safety-Critical World

By Nancy Van Schooenderwoert | Video | Slides

“Instead of freezing the ocean, learn to ride the waves” – Nancy’s talk was mainly about how our need for predictability for effective coordination is at odds with our need for fast learning to handle unknowns. She pointed out that in the agile context, “Architecture is any design decision that you cannot easily change”.

There was the customary reference to WikiSpeed to dispel the myth that hardware changes can’t fit within 2-4 week iterations. And an interesting one to a paper called TIR45 from AAMI: Guidance on the use of AGILE practices in the development of medical device software.

Coding Culture

By Sven Peters | Video | Slides

Sven’s talk was both informative and inspiring. Some of the key takeaways:

• Innovation needs time
• Stop and celebrate wins, however small they may be
• Balance your passion for code with your passion for customers
• Turn your passion into product
• Value trust, autonomy and transparency (Atlassian achieves this by using chat over other communication means)
• Products come and go, culture stays

Take a look at Atlassian’s Mood App and Stash Reviewer Suggester.

Building Reliable Distributed Data Systems

By Jeremy Edberg | Video | Slides

This one was good, until we went deep diving into the NetFlix Simian Army, which was also good but could have been summarized in just one slide. One thing that stood out from Jeremy’s advice was to “build for three”, because if you can overcome problems there then the solution can be [more] easily scaled up to n.

Don’t forget to check out NetFlix Open Source Software Center.

Oh! You Pretty Tools

By Andrew Bayer | Video | Slides

Andrew gave an interesting talk about the role of internal tools and their developers in the organization, covering both the pros and the cons. For example while making the build or buy decision, consider the fact that people are more expensive than software. And some thoughtful insights, like how Integration Tests can double-up as the roadmap to your tool’s usage. He also revealed that Cloudera runs ~2000 Jenkins CI builds every day(!)

The rest of it was basically about, and lessons learned from, CloudCat.

Testing and Integration (The Remix)

By Ines Sombra | Video | Slides

Ines entertainingly summarized everything we know so far, and topped it off with new insights for a good measure.  She emphasized:

• The importance of lightweight short-lived branches so that CI is not overlooked
• The more likely a test is to fail, the sooner you should run it
• The testing of provisioning systems, such as Chef Recipes, too
• How test setup time and parallelization are the key factors in minimizing the testing cycle time

She recommended this talk about the Google Build System.

Her punchline was that CI is a predictor of professional maturity at the organizational and individual level, and she ended with a “rantifesto” about building a culture of quality.

Beyond Features: Rethinking Agile Planning and Tracking

By Dan North | Video | Slides

From Cutting to Curing: Dan presented the powerful and inspiring idea that maybe software engineering is more like surgery than the civil engineering principles that we currently use to manage it. Agile methodologies essentially optimize for predictability, and this not necessarily a good thing. He mused on how a 2-week sprint is just enough time for a mini-waterfall, and thus we are all basically whitewater rafting.

After reviewing where the Agile Manifesto has brought us, he set an ambitious new goal to sustainably minimize the lead time to business impact. 

He ended with:

• The role of Features, Delivery and Kaizen
• Schedule, Measure, Track, Showcase
• How Value Stream Mapping can reveal surprises like typically a piece of work spends upto 90% of it’s time waiting for dependencies

How To Save Innovation From Itself

By Alf Rehn | Video | Slides

For me, Alf’s talk was the highlight of the event. It was so good and so inspiring that I won’t even summarize it here. Go watch it!

______________________________________________

The day ended with a party thrown by EPAM, which included free beer, a DJ-saxophone duo and a surprise flashmob.

You may also want to read my review of Day 3 of Craft Conf 2015.

 

 

 

 

 

Such UI, Much Refactoring

As the entry barrier to developing software gets steadily lower, as agile development practices (release early, release often) gain popularity and as the success stories coming from continuous and/or early feedback become industry legends, we find ourselves in a world where perfection is no longer a differentiator, it is an unspoken expectation and an implicit requirement. This applies even to products and services that are virtually free for the consumer. When was the last time your social network was down? Or your maps app crashed? Or you discovered a bug in your favorite (modern) web browser? For that matter, do you even know (or care) which “version” of software you are using?

Welcome to the new reality of iterative perfection.

But iterative perfection brings with it the cost of iteration: the cognitive load on the user having to continuously re-learn, re-orient and re-familarize. I’m not referring to the the step change introduced by MS Office Ribbon UX, or desktop apps migrating to Web UI interfaces… But smaller, mostly less disruptive tweaks and updates (usually referred to as “minor improvements”). While many of these affect the inner workings or performance, a seemingly high proportion directly affect user experience. In the spirit of the development process they hatch from, these changes are small & frequent, and are sometimes even rolled back if found to be unpopular. A fashionable “iteration” these days seems to be changing the colors or shapes of icons or other UI elements.

Making a product faster, more stable or more secure is one thing, but is tweaking the user interface of a product that is already in production a good thing? Does familiarity breed contempt, or confidence? There was a time when building a great product was given due recognition – success had been achieved, the job was well done, lessons were learned and everyone moved on. These days we change things – partly because we are expected to, but mostly just because we can.

Think about it. Once an idea has been commoditized by a company, what is the motivation for further innovation? The trend these days in web products is to keep revamping the User Interface every few months (sometimes weeks). To me, that is a reflection of a bigger issue than vying for the often limited attention span of modern consumers (through brighter and shinier objects).

What I think really happens is this: A bunch of smart people are hired, they build something great together, but now neither does the company want to let go of them (they’re smart, committed employees) nor do they have a plan for what ought to be built next. So, they resort to iterations and improvements (often poorly made choices to emulate a successful but unrelated product) to keep the “resources” or “talent” busy. Maybe sometimes the boredom gets so much that the only way of injecting vitality into what was once an awesome startup is to acquire one (which seems to be happening a lot these days, at atrocious values).

Secondly, having a continuous release schedule [perhaps subconsciously] puts pressure on the development team to deliver some tangible change with each release. After there is nothing left to add or take away, well, there is still the user interface.

I think as engineers, UX practitioners, software developers, product managers and builders of things, we all ought to learn how to recognize perfection when we have achieved it. We need to iterate less and progress more.

Update 2015-02-18: What Happened to Apple Design? by Jose Berengueres mirrors some of these thoughts.

User Stories vs “The User’s Story”

Last year I bought DiRT3 for Windows DVD on sale. Based on its ratings, It seemed a good candidate to try out my Poor Man’s Xbox: An Xbox WiFi controller connected to a Windows laptop, hooked up to the TV.

Even though I had bought a DVD, it wanted me to register online with a Windows Live ID. Well, if I wanted to play a game online, there are plenty of options. Why would I buy a DVD? So every time I started the game, I would select some fake name, configure all my settings (controller, driving aids and so on). But because I had refused to sell my soul, the game wouldn’t save my settings locally.

After a few times I got fed up and decided to create an ID. How hard could it be, right? Right?

Let the Games Begin

It had read before on that gmail addresses can be used for Live. So I provided mine at the game startup. A few “Next” clicks later, it refused to recognize it. Then:

1. Exited game
2. Fired up web browser
3. Went to Microsoft site
4. Registered my gmail ID for the Live service. What fun, a verification email was sent.
5. Opened gmail
6. Clicked on verification mail. Read through cheesy welcome notice.
7. How cool! Now I have a free Xbox Live gamertag. Which I can change. For free. Only once.
8. Decided if my profile was going to be online, might as well use a gamertag that my friends would recognize. Isn’t that the whole point of social gaming?
9. Changed gamertag. Now my Xbox Live page was in a state where the new gamertag appeared in some places, and the original was still retained in others (e.g. the logout option)
10. Logged out, logged back in to make sure the change had taken effect (standard Microsoft workflow: If it acts weird, restart it)
11. Still the same. OK, whatever. But wait… in doing all this experimentation I discovered “Privacy Settings”.
12. Changed my privacy settings to sane ones. Hopefully they were mine, because they still referred to the original gamertag.
13. Finished, closed browser
14. Fired up game

You’d think that 14+ steps to register for playing a game would be enough. But no. Now that I had a valid XBOX Live ID, I could log in. And now that I had logged in, I needed the latest updates to the XBOX Live gaming system installed on my laptop. Someone had decided to reuse code for this: it would be installed as a Windows update! And guess what, after that I had to restart my laptop, too! Because apparently only selling your soul just doesn’t cut it these days.

But finally I was getting close. I had restarted laptop and game, logged in and voila! Since by registering online I had clearly indicated that I’m heavily into social gaming and all that, now I was being asked to supply my YouTube credentials so in-game video could be uploaded to my channel. Which doesn’t exist.

Past that , the game wasted some more seconds checking for Downloadable Content. Which I was least interested in, considering that I had barely even played the game yet. But, it still checks every time I start the game. The exact same check every time, which notifies me about the exact same shiny new packs available, which I’m exactly as disinterested in.

And here is the highlight of the whole experience: After going through the effort of registering online, I still have to re-configure my settings every time I start the game. Because apparently saving a few strings of text to a file requires something more that investing in a laptop, operating system, DVD and Internet connection. In the attempt to play this game, I spanned 2 types of storage media and 4 internet services,  gave up my privacy and recreational time, and it still forces me to use factory settings. On the other hand, the graphics are a generation ahead, the menu has 3D text and the game makes the CPU generate unbelievable amounts of heat. Which is exactly how things were back in 1996.

Conclusion

1. User experience and usability are not just about product features. They are also about the experience of reaching the point where the product can be used. Any software that requires more than 10 steps and an hour of time is unusable.

2. In the year 2014, the only reason I should be forced to restart my computer is to prevent catastrophic meltdown. Not to install updates. What’s next, autonomous cars pulling over on the side of the highway and restarting because the manufacturer decided to push updates?

(EDIT: I wrote this as a joke but a reader pointed out that this is actually happening right now: Where’s my Knight Rider 2000?)

3. This whole experience stank of multiple individually proven and smooth solutions sloppily strung together to deliver working software. I can bet Codemasters and/or Microsoft were thinking they were being agile, leveraging reusable components and delivering in an impossible schedule. All the user stories were delivered, but did anybody step back and think of the user’s story?

“I just have to…” Project Management

(EDIT: This post was republished by PMHut.com here)

If you’ve worked in/with a software development team, in any capacity, you have heard this optimistic statement before: “I just have to <insert_trivial_sounding_technical_task_here> and then I’m done!”

• “The new approach worked. I tested it. I just have to move this method to the other class, and then I’m done!”
• “I’ve committed my changes in a branch. I just have to re-run the tests once more, and then I’m done!”
• “I’ve finished everything. I’m ready to start the next task. I just have to update the README and then I’m done!”

Well, you know what they say: in any software project, 90% of the work is completed in the first half of the schedule. To complete the rest 10%, it requires the rest half of the schedule, plus another 50% schedule overrun, plus x extra resources, everyone working overtime and oh yeah, we’ll ship the documentation later because we were focussing on delivering the functionality… you get the point.

You know Brook’s Law? It applies to machines as well. When you write tools and post-build scripts to automate development tasks, when you adopt the latest DVCS, when you start using the latest test automation framework… you are adding resources to your project. And it has been clearly established that adding resources to a project that is already behind schedule (and which project isn’t) is only going to make it later.

Here are a few things I’ve learnt over the years:

1. Nothing on planet Earth is a zero-time activity. Your plan: “I just have to move this method to the other class, and then I’m done!”. What happens in real life:

1. • You need to get your code peer reviewed.
   • But there is nobody available at the moment to review.
   • You finally interrupt someone, because y’know, it’s just one method, you just have to quickly review it… (of course you would conveniently forget how you would feel if you were the one being interrupted)
   • What? It’s a public API? Then you have to update the acceptance tests.
   • And the unit tests.
   • Go back for peer review and sign off. After lunch.
   • OK, all done, just commit and… WTF now I need to merge?!
   • And rebuild.
   • And re-run the tests.
   • And re-start the PC because of that pesky Visual Studio bug.
   • WTF? Windows updates? Now?!
2. Murphy’s Law is as fundamental to computer science as boolean algebra. It’s a pity they don’t teach it in school.
3. Remember algorithmic analysis? When you estimate something, don’t always consider the best case. The worst case happens more often than you’d think.
4. ABC: Always Be Collecting. Data. Statistics. Your past project data will show unrealistic your estimates really are. Nothing else can convince you as much.
5. If you haven’t been able to solve a problem for too long (confused customer, unreliable dev environment, too many distractions or interruptions), then maybe it’s not a problem, it’s a fact. So adjust your future estimates accordingly.
6. Say “out of scope” more often. Just because it’s software and easy to modify, doesn’t mean it should be modified. Agile doesn’t mean the freedom to constantly change requirements, it means adapting to changing requirements (amongst other things). Changing requirements doesn’t mean freedom to change fundamental constraints. Think of it this way: if you were building a bridge, it would be acceptable to try out different road surfaces. But would you change the bridge into a tunnel because it offers less wind resistance? And should there be a need in the future, you can just drop the already built tunnel underwater? Some software change requests and developer’s grand visions are equally unrealistic, and unnecessary.
7. Life is a fractal. If you’re late every day, you will be late every month, every year… and you will feel the same way about your whole life. It happens at home too: “I just have to get dressed, and I’m ready to leave”. Real life: Get dressed, grab snack, drink water, close window, remove phone from charging, respond to missed call, tie shoelaces, oops mismatched socks, find keys, lock door, wait for stuck elevator…
8. Work-life balance doesn’t mean work-life separation. Bring your good habits to work. Inculcate learnings from your work into your personal life. Why limit Continuous Improvement only 8 hours in a day?
9. Learn from other’s mistakes. Every time someone is being a moron, they are secretly trying to teach you something. The daily standup is not only about you, it’s also an opportunity to improve based on others’ experience.
10. Most importantly: Stop saying “I just have to…”  🙂

Takeaways from Craft Conference 2014, Budapest – Day 3

Continued from Day 2, here are the talks from Day 3 in order of my personal preference (and relevance) which may differ from yours:

Complex Projects aren’t planable but controllable

by Jutta Eckstein (Slides | Video)

Sadly, Jutta’s slides aren’t available online but the talk was packed with solid advice for Project Managers. Some of them were:

• Our predictions are usually based on a coherent story, not a complex, dynamically changing reality
• Targets should be ambitions, not absolute
• Focus on the value gained, rather estimates of the effort required
• Having an  annual budget is like having a bank that opens for business only once a year
• Annual budgets are not optimal because they are never underutilized: the excess (if any) is still used up, never returned back
• Consider [event-based] rolling budgets, rolling plans and rolling control
• Check value and progress regularly
• Don’t just trust the experts, seek feedback from diverse groups
• Have different planning strategies for Roadmap (themes only), Release (features based on value & velocity) and Iteration (Stories based on value (+estimate) & velocity)

Recommended reading:

• Implementing Beyond Budgeting: Unlocking the Performance Potential, by Bjarte Bogsnes

Architecture War Stories

by Stefan Tilkov (Slides | Video)

Probably the most amusing talk of the event. Stefan shared some hilarious real-life examples of architectural disasters… some of them still very much in use (of course no names were revealed). His advice was to go back to the basics:

• Make data free of code dependencies
• If it makes you want to pull your eyes out, maybe you shouldn’t be doing it
• Better ask for forgiveness than permission
• Development environment is not the same as production environment
• Feedback, reflection, iteration

Responsibly maximizing craftsmanship in software engineering

by Theo Schlossnagle (Slides | Video)

Theo revisited the basic problems plaguing software development today and went on to share some of his experiences at Circonus. One of the tips was to treat all software you write as open-source within the organization, even if you don’t plan to release the source outside. Other highlights:

• Turtles all the way down: Software at scale is tied together with loose string & hope
• We use human language to describe software specifications, and this can be interpreted by different people in different ways (like poetry)
• Technical debt is non-linear; large monolithic components are more likely to fail because they are hard to maintain
• Reusability is good, but use the right tools for the right purpose. Accept that that right tool may not yet exist and may need to be written
• Diversity is an emergent property of scale
• Thou shalt be judged by your API

For software developers, the message was loud and clear:

Data-Driven Software Engineering

by Jevgeni Kabanov (Slides | Video)

Jevgeni went thorough the effort of analyzing 1000+ projects on Productivity, Quality and Predictability. Sadly the slides aren’t available, but the raw data they were based on is. You can still watch the video and grasp the most important points, such as the fact that the best software projects are delivered 80% of the time on schedule and still have 25% critical issues. Or that automated tests improve quality by 26%. There were also secondary interpretations such as code reviews improve architecture, not just code quality.

Jevgeni emphasized on the importance of measure & experiment over simply “doing agile”. Some suggestions for measurement were:

• Deadline misses
• Scope changes
• Blockers after release
• User satisfaction

The presentation became a bit controversial later but as Jevgeni said: “People, chill – I gathered data and presented my analysis – feel free to take the data and do a better job”. And I think this talk had the most creative closing slide ever 😉

Without Present or Past: How to Think Distributed – The Hard Way

by Endre Sandor Varga (Slides | Video)

By far the most profound and philosophical talks at Craft. If you have an interest in Distributed Systems, AI or Information Architecture, I would strongly recommend watching the video. The core concept was based on applying epsitemic thinking to systems that are distributed, concurrent, able to fail independently, and communicate over a lossy medium with non-deterministic communication delay. Endre touched upon:

• Two Armies Problem
• The final important message
• Difference between actual state and observed state
• The Omnipotent Observer (doesn’t exist, because state is always queried)
• Global introspection and self-awareness
• Cone of the past
• The present is volatile and subjective
• Going from someone knows -> someone knows everyone knows -> everyone knows everyone knows

Endre ended with this advice:

• Have a properly defined failure model
• Never assume reliable communication
• Never assume common knowledge

Functional Reactive Programming in Elm and JS

by Evan Czaplicki (Slides | Video)

Evan is the designer of the Elm language and his enthusiasm is infectious. Over the course of his talk, he built and demonstrated a simplified (yet slick) Mario game complete with physics and reaction to keyboard inputs. Elm is a Functional Reactive Programming language for web browser based GUIs and this game was a fine demonstration of concepts that Bodil Stokke and Jonas Boner touched upon in their respective talks.

There is no doubt that Elm is a game-changer. Here is another example of traffic simulation.

Further reading:

• Go try Elm!

Find the Right Abstraction Level for Your Tests

by Gerard Meszaros (Slides | Video)

If you’ve ever been haunted by the question of what level of testing is enough (and who hasn’t?) then this presentation was for you. The key message was to think in terms of not what you can add, but what you can leave out of the test: “if it isn’t essential to conveying the essence of the behavior, it is essential to not include it”. Over 39 slides, Gerard illustrated this step-by-step with one, continuous, easy-to-follow example.

Software Psychology: The Art of Listening to Code

by Bjorn Freeman-Benson (Slides | Video)

Bjorn talked about the concept of code screams: behavioral indications of a deeper problem in the system. For me the key takeaway was that you should continuously monitor your processes as well as your systems in production (e.g. by gathering usage statistics) and fix the root cause when a problem is found.

Others

Here are some talks that I missed, but which received a lot of positive feedback. Thanks to ustream.tv they are available online. Also check out #CraftConf on Eventifier.

Jackstones: the journey to mastery

by Dan North (Slides | Video)

McDonalds, Six Sigma, and Offshore Outsourcing: Unexpected Sources of Insight

by Chad Fowler (Slides | Video)

Testing the Hard Stuff and Staying Sane

by John Hughes (Slides | Video)

The Better Parts

by Douglas Crockford (Slides | Video)

Functional Examples from Category Theory

by Alissa Pajer (Slides | Video)