What’s a Consistent User Experience?

In tech, we have all mostly moved on from the days of projects based work and now speak in the language of software products. We have our product lines, product road maps, product backlogs, and planned product features. If you’re in that type of environment you likely leverage personas or user stories to describe your type of users which you then bring in when planning the user experience…which like many areas is the “most important thing”. You may have different goals for your particular user experience but certainly we can assume that you’d like the experience to be consistent and straight-forward.

We are a smaller company and yet we still have 4 core products and one could argue we have many more with the legacy applications features we still support. Its been a tough few years which brought with it resource constraints so we have to often revisit the backlogs and re-prioritize. Because of those constraints we made a strategic decision to not roll our own presentation on our large data sets. This decision was initially made to offer a new product line that would be help a smaller but promising pool of retail suppliers and reps that didn’t need all the features of our flagship. So we partnered with Tableau in order to bring their BI features to help make our retail data analysis pop.

The new product line is progressing but the real change has been the internal emphasis of leveraging Tableau in other products. This one will be a technical dozy for us since we developed a new API with our flagship with the thought that the front-end would be handled by our team via D3 or something similar. Technical issues arise, we’ll handle that.

So what’s a consistent User Experience?

As we’ve moved our systems to AWS and ported many of our stacks away from Windows and into distributed architectures we’ve seen great gains. We’ve also moved from SQL Server to AWS Aurora / MySQL to have both ease of administration as well as a cost savings. With a recent new Tableau deployment a member on my BI team ran into an issue which goes against an ideal user experience. From what I’ve pieced together when Tableau Desktop (a client) is installed it adds all the prerequisites apps and drivers to support MySQL out of the box but when you install Server it does not do this but does install Postgres which it uses internally.

This leads to an user experience where someone can connect to MySQL on their client, make the snazziest dashboard experience known to humankind but when they publish success is not had because MySQL drivers are not present. So on the client side the install does something and on the server side it doesn’t do that same thing?

That to me is a good example of on an inconsistent user experience. Perhaps there is a good reason for it, perhaps there is documentation and instructions to detail it, or a road map item to correct the inconsistency on the backlog. In the meantime, users are going “huh”.

Gist Series – Methodologies: Agile, Scrum, and Waterfall

The Gist series came about from a Senior Design course I’m teaching as an adjunct at the University of Minnesota’s Computer Science department for the 2016-2017 academic year. The focus on that course is to have the team of students design and build a software project while partnering with an industry partner, in our case Microsoft. Just like in my day job, I’m there to assist them through technical and product evolution through leadership and it also offers me a chance to give back to my alma mater. One of the areas where I’m trying to do that is with a ‘real world’ lesson. I plan to take a topic and present a concise take on it. Thus far they’ve been in the top-down academic paradigm which tend to over-formalize processes that they’ll see soon as software engineers. My aim is to help them see that all the theory gets molded and formed for the environment it lives in as well as to respond to fast moving topics that move too quickly for typical curriculum.
Because we are going to use Scrum as our process it seemed the ideal first topic.

What is Agile about?

This deals with the development methodologies. The traditional is waterfall which is a sequential top-down process. And you go down, you don’t go back up…just like a waterfall. Waterfall has been around forever and it does work. Some of the best examples (and worst too) have been with defense software projects. The keys to having success is to be really solid in requirements gathering and being able to effectively lock in the design. However, waterfall often failed leading to really bad anecdotes about development but really good books like the Mythical Man Month. The main reasons it would fail is that requirements typically change. Either the stakeholders want something else because of something unknown or because now that they see it working it matches what they said but not what they meant; often its too late to effectively veer so changes are expensive, deployments don’t always feel like a victory, and folks may be left grumpy. Plus a project can be years long and not all resources are effectively leveraged. I remember a project I was asked to work on for a bank conversion where requirements was going to take 6 months and I asked what the 70 person team of developers would be doing in that time and I was told I would develop a training program for them until the requirements where done. Whoa…outside the scope of normal but true story.

So What is Agile.

To me, Agile is an adaptive, iterative methodology that focus on getting feedback quickly (fail fast for the startup school folks out there) and prioritizes communication over the upfront complete requirements gathering of waterfall. You do this by focusing on smaller chunks of work, typically 2 or 4 week sprints, and can effectively veer based on outcomes that show themselves. These are my words, google can help you find exactness. With agile, specifically scrum, the team is more of a team. The product owner is consistently communicating with the developers so days/weeks aren’t going by with lingering questions or unknowns being left unanswered. Buy in with the team is much higher in my experience because the team should be heavily leveraged in sprint planning by determining cost/risk as well as priority of features to the project. Additionally, communication is key and daily standup’s help foster that team communication. Because the team in constantly checking in with what they’ve done, plan to do, and what they’re hung up on problems are resolved much faster and that brings faster delivery of features. This can be measured with velocity.

Why Does this Matter

This matters because you’re going to work in one or the other process or a mashup of the two or a frakenscrumfall. Either way, in the least its good to know what to expect if you’re ambivalent. Secondly, if you care, then you can look for a workplace that employs the process you most align with. Most newbies think the key to their job satisfaction is the tech stack, the perks, and/or the pay. I tend to find that job satisfactions comes down to your boss and the way the team interacts, oh, and if you have Nerf wars! I miss that job. Lastly, if you don’t have an opinion I really don’t want to work with you. Do you know how boring it is to ask intelligent engineers what they think about something and then hear crickets?

Some Other Common Questions

So what sucks about scrum?

People generally make anything that sucks suck. Agile has very specific roles and responsibilities and they are crucial to success. The biggest is the scrum master who is like the project manager in a waterfall scenario. The scrum master has to keep the sprint running smoothly by facilitating the communication between the product owner and the developers that we’ve mentioned is key. They also have a fair bit of administrative work in tracking the sprints versus the overall project. For this role I really like detail-oriented folks who like organizing folks, in my experience a kick-ass project manager will be a kick-ass scrum master.
The product owner is also a key role as they must have their act together with the stories. The stories are the requirements so they need to write them with that in mind, or have some help from a BA type of person. The dev team also has to learn to be involved and to try to get away from the ambivalent tech gloom vibe that some team members can bring. After a few months they’ll hopefully learn from the rest of the team or figure out they don’t like process enough to find a new home.
What generally doesn’t work but is often attempted at smaller shops is to part-time these roles. If you’re moving to scrum then have the person filling the key roles have a majority of there time spent working in that role. I’ve had scrum masters that only kickoff the stand-ups and don’t do anything else. #thanks #facepalm #supposeyouwantaraise

How do we build something large though?

Scrum can totally be used, Google search can again back me up here. I’m not really covering Scrum per se, just hitting it quick. Stories live on the product backlog and larger stories are called epics. Epics can be contained on a product road map which shows the major features and phases of a specific products. So you can plan out our product for years. That’s part of what I do and I have a road map for each of our major products as well as our tech infrastructure which feeds into the backlog where specific product owners go and add their magic before it goes into the sprint and then gets D-O-N-E.

What tools do you use?

I have a strong view on tools in that they really don’t matter as much as being consistent with whatever tool you have. That being said, from my statements above I must be opinionated, and I am, so I lean towards tools that follow Occam’s razor. I’ve had folks that like to write stories in Drive docs and then copy them to the scrum tool of the moment. If that works for them then awesome sauce but I just prefer to write the story once, in the place where it will be consumed. I prefer to use Trello over Jira because its simpler. For road maps I prefer Drive sheets over SaaS based road map tooling but in the end whatever the team wants is fine by me.

What if someone doesn’t like it?

There are always engineers who don’t like change or can nitpick a methodology to death. You know what, odds are if you do waterfall they will have the same view. Additionally, I’m willing to wager that if you offer this fictional representation of a developer the chance to develop the best methodology that they will pass because they don’t actually care. What’s great about scrum is you can make it light and flexible or as big and heavy as you see fit.

I’m really a kick ass coder and I want to be left alone

I feel you! I used to think like that then I learned I liked sunshine, people, and puppies. Seriously though, this stuff is everywhere so if you have a tough time working with folks you should maybe be a professional widget maker at home or get a gig with fsociety.

Where’s your pictures showing the methodologies that I see in all the good posts?

Who said good post? Anyway, they are only a click away.Here you go!

Teaching Tip: It’s what to do right, not what to do wrong.

Today while driving I was listening to the Barbell Shrugged podcast, it’s been around a few years and while it generally focuses on CrossFit I listen for the episodes when they hit topics like Olympic weightlifting, coaching, or self-improvement. Like this one!

Doug Larson, a Barbell Shrugged OG, raised a point I liked in how he teaches people…on anything. Doug focuses on what they should do, not on what they shouldn’t do. It’s a subtle point to consider and instantly brought me to design sessions I may have with engineers and architects at work where I catch myself often telling what NOT to do. It’s really a poor tactic of persuasion and teaching as it doesn’t focus on what they should do.

Thanks Doug!

Domain Driven Design – 10 Years Later

I’ve been an avid podcaster since its inception and before podcasting I would web stream my favorite radio shows like This American Life or download the files and transfer them to crappy MP3 flash player. Ah the memories of the days before the iPhone.

I finally caught up with a software engineering radio pod from May of 2015 where the topic was reflecting on Eric Evan’s classic text Domain Driven Design 10 years after its publication.  Reflecting is right. When that book came out I about to start grad school at the University of Minnesota and reading every decent text I could get my hands on. I’ve always prefered looking wide and long at the software field and was drawn to software design, product design, & user experience rather than focusing on stack specialization, russian algorithms, etc. so Eric’s book was a natural fit for me and I remember loving it and praising to all my peers.

Those were critical years in my engineering & leadership development, I was two years removed from creating a flexible ecommerce platform with my mentor and was just beginning with a few new firms around e-leasing & digital media ecommerce.

The software engineering pod brought Eric’s voice back into my head and the terms and language from the book flushed into my thoughts. It’s amazing how memory recall can be effortless when the material, even if distant, struck a chord and anchored in your thought process.

This pod covered how DDD relates to the terms of today like: CQRS, NoSQL, & event sourcing. I was struck with how the principles of DDD have been reflected in the designs of the companies, teams, and projects I’ve worked with since 2005, regardless of the tech space or stack.  I think the book provides considerations that are still very valid today. If you haven’t read the book it’s worth your time, if you have read the book then check out the pod.

Eberhard Wolff talks with Eric Evans, the founder of domain-driven design (DDD), about its impact after 10 years. DDD consists of domain-modelling patterns; it has established itself as a sound approach for designing systems with complex requirements. The show covers an introduction to DDD, how the community’s understanding of DDD has changed in the last 10 years, the often overlooked component—strategic design, how to use DDD to design microservices, and the connection between microservices and the DDD bounded context. DDD originated during the era of object orientation and relational databases; the show concludes with a look at the recent impact of functional programming and NoSQL on DDD.




The Best Apps to Run a Startup From Your Phone – WSJ

The recent story in the WSJ about the best apps to run a startup from your phone with is certainly a smile-inducing title. If only there was an app for smart hiring that didn’t screen scrap until they get it working (I mean really), business model canvassing, and accurately predicting market trends.

All of these applications and sites are wonderful and they do allow us to be far more efficient which then allows more time to what really matters whether it be a startup or a legacy company. This brought me to consider the apps/sites I most relied on in my past three workplaces: my consulting days at JD Laboratories, my enterprise IT days, and my current small company product days.

JD Laboratories – Time and Materials / Projects

The key here was project tracking, time tracking, and invoicing. I used Quickbooks for my P&L, financial reporting, and invoicing. I used Paymo to track my time and then generate the monthly statements that feed into quickbooks as my T&M clients were billed monthly.

When I worked on a project basis I initially used basecamp from 37Signals as I was a junkie of their blog, into Ruby on Rails, and they had the best offering. However, my clients didn’t like logging into their system which led me to adopt Trello which I have brought with me everywhere since. I trust their are better systems than Trello when doing feature assessments but at the end of the day I always go with simplicity and actual use before graduating to something more specific and complex.

And my long-term client Mix & Burn used FogBugz for issue tracking which was nice because of tie-ins with our IDE although the UX was sluggish at the time.

Enterprise IT

Enterprise IT certainly brought challenges when coming from my own shop and that was actually part of the allure. Small hurdles were not having the credit card initially and firewall rules for external systems. I was able to bring in Trello for my personal project tracking and then used Jira and Confluence with a new technical team I built focused on enterprise integration. Confluence was wonderful for publishing the standards and practices of our restful API’s as our product support teams could easily see them and we could export them for vendors that were integrating our APIs with their vendor systems.

We also used an agile-ish project management tool that was a $1 a seat; it was a short experiment.

SetSight – SaaS

For SetSight the focus has to be on easy as the history has been a bit of a gunslinger mythos with inconsistent processes so we can use something very rigid. So I brought in Trello to do the product backlog and sprint management. Trello has numerous external plugins that offer sprint scoring, estimating, charting, and reports. My favorite is Plus for Trello. For issue management we use TeamSupport and their is some clamoring for Jira. I think Jira is great but from a process perspective we are at the point we were need to get better at what we do and sometimes there is the perception that the tool will fix bad behavior; I say fix bad behavior first.

From a dev perspective we moved to Git from Svn to improve future tie-ins with external build and testing systems. We have yet to do automated testing and continuous deployments since we’ve moved to AWS but are well on our way.

Source: The Best Apps to Run a Startup From Your Phone – WSJ

MBA Homework – An example of the 20 minute paper

Last week it warmed here in Minneapolis and I felt inspired to do some spring (wishful) cleaning in my Google Drive. While doing the file purge/reorg I came across a paper from one of my last MBA classes, Strategic Management. Strategic Management is a classical business course and the intention in my program was for it to act as capstone course where you are able to combine the past few years of business wisdom you gained from course materials, lecture, and your cohort into honest, deep, and frank discussions around business. The open discussion is where the true learning comes from as there is an opportunity to learn how other organizations approach common business and organizational issues and you have the opportunity to debate classmates in a safe environment.

Capstone classes are historically fun and rather light on the typical ‘work’ you’d come to expect from a graduate program although anyone with a STEM or Comp Sci background will never find any MBA course challenging, at least not compared to discrete mathematics or physical chemistry. Still, there are papers and readings, and my capstone class had ‘light’ papers which warrants the student to pull out the quick response aka the 20 minute paper. Below is one such example which included some personal work references to allow for fast typing and then some class discussion/readings mixed in for completeness. Far from works of art or high mindedness!

Last Capstone Paper

I’m coming up on my one year anniversary at <CompanyName> where I lead up product development. When I began with <CompanyName> my expectation was for my focus to be split 75% on strategic / long-term planning and 25% on tactical / short-term needs and that opportunity is what attracted me to the position. Out of the gate I focused on learning the business, its competitors, and understanding the general environment via Porter’s 5 forces and I found it helpful in my ramp up phase. However, after a few months I was seeing a flaw with my focus ratio regarding strategical/tactical concerns; that ratio just wasn’t what the business needed at this point in time and the percentages should have been reversed with 25% looking strategical and 75% focused on the tactical areas.

Flipping the ratio came from a basic “walk before you run” assessment I made about the organization around the first of the year. An analogy would be with remodeling a home by changing it from a rambler to a McMansion and I was the contractor, bringing me on was a key milestone for our corporate growth initiative. When I walked in the door I was focused on planning the new floor levels, setting dates, & coordinating resources. I had assumed the earlier sitework had been done but I was wrong and had to slow down and consider other factors like the foundation, the utilities, and how the occupants utilize the home and how would they want to utilize it in the future. I had to ask questions like “do the occupants know we are remodeling and if so do they know why?”.

Since then I’ve focused much more on our processes, culture, and bring consistency to the company. I’ve always been drawn to the topics of organizational behavior and how a company’s culture affects the road before it and that came up in our first week of class when we discussed the Miami Dolphin’s story and their failure to understand the implications of releasing key individuals from their locker room. Any team is more than the collection of its parts and working with teams to build the norms and culture that mesh its past norms and future strategic focus is where I’ll keep my focus now and into the future. I plan to do this through providing leadership, personal accountability, and trying to empower others while working with team members to reformulate a culture of greater trust, openness that rewards creativity and attracts smart people.

Leadership is an area of great fascination to me and I’m always striving to grow and improve as a leader and know I have a long ways to go on a journey that shouldn’t have a completion marker just milestones. The type of leader I’ve been thus far is one based on trust, accountability, and action and I’d like to evolve to be more inspirational which I expect to come via wisdom and finding an ocean, hopefully a blue one, that calls to me thus helping me show my passion. I’m aware that if I’m not “on” or engaged that I can present some non-verbals that aren’t ideal leader traits. I’ve been a long reader of Daniel Goleman and his “What Makes a Leader” article in HBR regarding emotional intelligence is an area I have and will continue to put effort into focusing on so that I better understand myself and better understand and relate to others.

One leadership focus I will add to my arsenal is holding more postmortems. Postmortems are a norm in classic project management and while I’m typically reflective when things don’t go well I do so in an insular fashion and wouldn’t host a group reflection to do so. Also, my midwesterner nature would have wiggled out of allowing a postmortem on a successful project initiative much like I’d downplay a compliment but I can see that is where great learning resides. There is much opportunity there and “Why Leaders Don’t Learn From Success” was a HBR piece with much sway on me.

As I mentioned earlier, the past 8 months had been focused on process improvement while the strategic had been limited. We’ve implemented agile methodologies in our development teams which was later adopted on the sales and support teams. On the technical side we’ve devised processes for software deployment, quality assurance and testing, new technologies, and security improvements. On the organizational level we’ve set new HR processes with our review and compensation plans, created an onboarding plan, and beefed up the employee handbook. These are not the areas where I expected to be moving dirt when I joined <CompanyName> but now they are all building blocks that form infrastructure that allows for larger initiatives to come and build on top of. For example, now that we are 5 months into our agile methodology we have data on how much work we accomplish in a sprint to a degree of high confidence and may not apply that metric to the product backlog for our new product version and have a swag estimate as to when it will be ready for the market. This leads to conversations on marketing, sales, and support that then grow into those strategic conversations about business level strategy. And these are the other strategic areas I found so enriching from our conversations and materials: red vs blue ocean and competitive advantage with low cost or product differentiation.

There will be no shortage of areas for me to apply the topics we’ve covered in class and I look forward to having them.

AWS’s use of Gartner

AWS recently came out with a short product marketing piece that highlighted Gartner’s cloud rankings from October of 2015 and AWS’s first place ranking in 4 cloud subcategories. Those working in the cloud space know of AWS’s strong position from both offerings and market share so who is the post for?

Gartner CC Product Scores for App Dev Use Cases image

The answer lies in the source, Gartner, who is akin to the Angie’s List for the Enterprise. Gartner, like Forrester Research, provides rankings, research, and analysis on a range of technology, primarily for the enterprise. The use case I’ve been involved with is selecting new enterprise software for a past organization I worked at. Now you can implement whatever selection process you want but at some point in time you’ll either be using a ranking from a research firm as a positive trait in your budget pitches or at least must be prepared to be questioned on their ranking.

The cost of these platforms are so immense for enterprise customers. My last experience was at a midsized bank and the budget for the integration platform we selected was a solid chunk of the overall IT budget; that was a big deal for us and required presentations to every level of leadership in the organization. Certainly large banks and other enterprises aren’t always incentivized to move fast in technology areas when the high cost brings serious risk and opportunity cost. So marketing posts like these used to help assuage that risk to the enterprise and provide the technology leaders within the research assistance when making their case for a cloud introduction to their enterprise. My suggestion, use risk to your advantage and leverage the ability to use the cloud as a potential failover in your HA environments.

Source: https://aws.amazon.com/resources/gartner-cc-learn-more/