“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:2xBacklogs

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”).
    •  Technical Value here is defined as the value delivered by the technical solution towards meeting the needs of the [prioritized] Product Backlog.
  2. 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).
  3. 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 Waywhich 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.

Lean Prezi pub

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 Architecturewhich 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).


  • 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.


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

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.


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:
    • 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?!
  1. Murphy’s Law is as fundamental to computer science as boolean algebra. It’s a pity they don’t teach it in school.
  2. Remember algorithmic analysis? When you estimate something, don’t always consider the best case. The worst case happens more often than you’d think.
  3. ABC: Always Be Collecting. Data. Statistics. Your past project data will show unrealistic your estimates really are. Nothing else can convince you as much.
  4. 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.
  5. 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.
  6. 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…
  7. 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?
  8. 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.
  9. Most importantly: Stop saying “I just have to…”  🙂