Shared: This Feature Should Be Easy

It’s everything around the feature that makes it harder: UI design, localization, refactoring, accessibility, state restoration, getting new artwork (for a toolbar button, for instance), dealing with errors, testing, updating the documentation, etc.

inessential.com: This Feature Should Be Easy

If you want to make sure your feature request is dismissed or put at the bottom of the list, make comments about how easy it should be to implement it. Maybe it is easy. But, as Brent notes, it’s likely not so easy and saying it is can be perceived as condescending. – Josh

Wardley Maps for product development

Wardley Mapping is most commonly associated with higher level business strategy. When I’ve talked to people familiar with Wardley Mapping, they’ve been quick to dismiss it as a tool for the C-level suite, not for mere mortals developing products. I disagree. The following will attempt to explain why I find Wardley Maps not only relevant but vital to product development. If you’re unfamiliar with Wardley Maps, I recommend watching Simon Wardley’s 2017 Google Next talk for a good overview. If you want to take a deeper dive, I suggest Simon’s free online book.

Digital Beanie Baby: Husky
Welcome to the future. Digital Beanie Babies. Trade them on your favorite exchange!

Imagine. We’re transported to a time where it seems like anything with the label “beanie” is drawing attention, mostly because a new form of Digital Beanie Babies (DBB) has been skyrocketing in value for over 12 months. An entire ecosystem has sprouted up around the digital critters. In the midst of this beanie bonanza are exchanges launching to enable trading DBB, much like other exchanges exist for trading stocks, fiat currency (e.g. USD), etc. Each new DBB exchange has its strengths and weaknesses.

A few entrepreneurs identify an opportunity to create a new exchange that fills the gaps left by even the most successful DBB exchanges, while also adding a couple innovative features. They’re focused on meeting existing customer needs in a burgeoning market, not building a larger technical “platform” that has aspirations beyond being a very successful DBB exchange. The founders form their startup, get some technical people on board, build a proof of concept, raise funding, and continue building on the vision of providing a better DBB exchange for traders big and small.

But how does the startup know that they should build this product from the ground up?

Product development for this new exchange is focused on continuing the path the proof of concept set – build a secure, fast, trustworthy, and feature rich DBB exchange from the ground up. In such a new market space this seems reasonable. Put together a small, agile/lean development team and continue to build a product that meets the needs of its traders, validating the product as it is built. Lean startup style.

But how does the startup know that they should build this product from the ground up? Are there pieces they should buy? Higher level functional open source components they should adopt? The assumption is made that because DBB trading is a fairly new market it requires building a brand new product from scratch. Besides, many of the most successful DBB startups built their exchange from the ground up. They blazed a trail, this new startup is simply following in the path that’s cleared for them.

Enter Wardley Maps, a way to visualize the evolution of the underlying landscape anchored to the needs of users. When we map out the Digital Beanie Baby trading landscape, including high level components/requirements of a DBB exchange, we start to see that a number of core components of the exchange are available for purchase, leasing, and/or open source. After all, exchanges have been around quite a while in various forms.

Based on the product development approach the Beanie exchange startup is taking, we’d expect to see most of the exchange components and requirements in the “Custom-Built” or “Genesis/Novel” lane, but instead a majority of the core exchange features in development (highlighted in blue) fall into the “Product/Rental” lane or very close to it. What does this tell our startup? It’s telling them that the bulk of what they’re currently developing is something that has (probably) been built before and is available to buy, lease, or simply use (open source).

A common objection I hear at this point is: OK, but what if you’re wrong about the position of various items on the map? That’s quite possible. The potentially incorrect map positioning can drive meaningful discussions as well as further research to either validate or invalidate the position. The beauty with the map is that we’re: A) having the product/business strategy discussion based upon a shared visual aid and context B) able to identify our assumptions. In the case of our startup example, the biggest areas likely up for debate are core components (that they’re creating themselves) like the matching engine, order book, API, web app, etc. Maybe with some further digging the discovery is made that commercial offerings exist, but they’re immature, or expensive, or rigid, or any number of other issues that may make them less viable as options. Maybe we find that certain components are available as products, but are only really suitable for more traditional exchanges, not for those aimed at trading digital beanies. It’s also possible that we discover there are numerous existing components and products that fit our needs and validate the position of those items on the map.

The Wardley Map provides a higher level view that can help drive lower level product development decisions.

Another objection I’ve heard is that what I’m crediting to Wardley Maps is really just another path to market research that any business should already be doing. Possibly, but the map provides a shared context that market research does not commonly provide, as market research tends to end up buried in docs and slide decks. A group of people can look at a Wardley Map together and start to quickly identify areas of alignment, disagreement, opportunity, etc. Those with more industry expertise can be brought in to look at the assumptions on the map and determine if those assumptions are on track or need adjusted.

In our startup’s case, the map identified some potential blindspots in the product development approach. Should the exchange startup be building something from the ground up that is already available for purchase, rent, and/or adoption? Unless the devil is hiding in the details of those components mapped in the product lane, then it’s unlikely the startup should pour further (fairly limited) development resources into those items. 

It makes more sense for the startup to consider focusing its development time and talent on building items in the novel or custom lanes. Or, possibly focus the engineering team on implementing the items in the product lane, become experts on operating those in production (much sooner than the homegrown equivalent would be available), and then discover through real customer feedback what should be introduced on the exchange next. The possibilities the map opens up are much greater than what development teams tend to consider when they’re building a product, such as, should we: Scale back feature X, Y, Z? Reprioritize the backlog? “Pivot” to target only one subset of customer initially? Change our approach to development in order to increase velocity and lower time to market? Reset some or even all of our goals for the MVP? Those are all legitimate options to consider in product development, but they may be too nearsighted and ultimately limiting. A startup is particularly sensitive to this form of myopia, as the business and product the startup is building are so tightly coupled, it can be hard to determine where one ends and the other begins. The Wardley Map provides a higher level view that can help drive lower level product development decisions.

Adding Wardley Maps to a product development team’s toolbox is a valuable asset, even if at a first glance it’s hard to understand how. Mapping is not a silver bullet or even a tool that is immediately easy to grasp, but it’s worth learning. This example only begins to touch on all the nuances of Wardley Maps. There are many other nuggets of strategy gold to be found for those who take the time to learn how to create and collaborate with these maps.

Not about school

Consider this a parable of sorts for those building products. I’ll leave it up to the reader to determine its meaning.

Carl is a senior in high school and has a D in Algebra II heading into the last semester. He wants to bring his grade up to a B so that he can qualify for college scholarships. Quizzes and tests make up 80% of a student’s grade. The other 20% consists of completing homework (15%) and classroom work (5%). Carl’s Algebra II teacher, Mr. Smith, insists that Carl catch up on all his missing classroom work first, even though most of that work will not help on upcoming quizzes and tests. Mr. Smith works with his student to create a rather large yet well-defined backlog of all the classroom work Carl needs to catch up on so they can track his progress together. Carl diligently works on burning down that backlog. He finally catches up on the classroom work near the end of the school year. Mr. Smith pats him on the back. Carl’s final Algebra II grade is a D+.

A remote retrospective

It’s been a while since I last facilitated an all remote retrospective. Below is an email I sent out to the team I’m currently working with to help us prepare for our first “retro” together. We’ve since held the retro and it went well overall, so I thought this prep and guidance might be useful for others to iterate on.

—–

Hi All,

On Tuesday we’re going to have a Project Retrospective (aka “retro”). In my experience, retros are hugely beneficial opportunities for teams to learn and grow.

Please take the time to read the rest of this email. It outlines how the retro will run. In order to make the most of our time, it’s best to come prepared. 🙂

Retro Goals

  • Learning jointly – From each other’s different perspectives, feelings, and current thoughts about where the team is at since launching the project.
  • Taking action – Based on learning together, we identify where we can most benefit from improvement and take action.
  • Strengthening the team – We’re in this together. By listening, learning, and taking action on what we’ve learned, we develop a stronger bond that is bigger than “just the work”.

Ground Rules

Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

  1. Be respectful
  2. Be present (no phones, no “side chats/conversations”, no browsing, etc.)
  3. Everyone gets a turn to speak
  4. No interrupting
  5. No judgement on feedback (use “I statements“)

Before The Retro (between now and when we meet)

Please take time between now and when we meet to think about the following in relation to your experience and/or what you observed during your time with the TGE project:

  • What you want us to continue doing
  • What you’d like us to start doing
  • What you’d like us to stop doing

You can add your items to this doc, which we’ll use as part of the retro: Google Doc

The Start

Check-in: We’ll go around the call and have everyone provide one word for how they’re feeling in the moment. Have trouble coming up with a word for how you’re feeling? I know I do sometimes! Try this to help identify a word: https://verbaliststravel.files.wordpress.com/2016/01/the-language-and-vocabulary-wheel-for-feelings-verbalists.jpg

The Middle

Part 1) We’ll use the “Before the Retro” section above to guide the initial discussion. What we want to: continue, start, and stop doing. If you haven’t added your items to each area, we’ll have a short time for everyone to add to each list.

Part 2) We’ll go through each item and open it up for questions/clarification. I will do my best to encourage open, focused discussion that honors our time.

Part 3) Everyone gets 3 votes per area to put against the items they think we should take action on now, not later. You can apply more than 1 vote to an item if you feel that strongly about it.

Part 4) Identify the top item in each area and determine next steps (which can be as simple as identifying an owner to drive the action post-retro). …But what about the other items – aren’t they important too? Yes! But focus is key. Just because an item isn’t made “top priority” doesn’t mean it won’t see progress in the future.

I’m accountable for ensuring the 3 items we identified to take action on make progress. Don’t expect miracles. Some things require a a fair amount of determination over a period of time to show results. My commitment is to continue to provide visibility to the items and help move them forward. Expect this to be part of our weekly meetings, even if it’s just a quick update.

The End

Check-out: Everyone on the call gets a brief (30 seconds or less) opportunity to express closing thoughts/feelings now that the retro is at a close.

Looking forward to learning and improving with you all!

Josh

Deploying a Python Flask web app on AWS Lambda

The best server is no server?

OK, servers are still involved with “serverless computing“, but not ones that you and I need to worry about maintaining and scaling. While serverless platforms like Amazon’s AWS Lambda, Google’s Cloud Functions, IBM’s OpenWhisk, Microsoft’s Azure Functions, and others aren’t the right fit for every need, I’m beginning to think they’re applicable to more apps and services than not.

I’ve been playing around with AWS Lambda for a little while now. After getting a number of functions up and running, I started to think about how this platform might be applicable for web apps. While I’ve built a Slack app using Node.js, I have to admit I missed the elegance of Python.

I settled on getting a little web app based on a Python web framework up and running on Lambda. I wanted the deployment to be as painless as possible (i.e. easily repeatable once configured). For this exercise I didn’t care about integrating with outside services. I was fine with running against a local SQLite database, knowing I could switch over to RDS or another database at another time. Here is what I ended up selecting for this task:

I chose Flask because it’s well regarded and simple to get running. I chose the Serverless framework (versus something like Zappa) because Serverless provides the ability to deploy Python and non-Python based projects quickly while also allowing you to deploy to other cloud providers like Google, Microsoft, etc. I chose the Flaskr app because it’s simple but not too simple.

Before we get started

There’s quite a bit that needs to be setup and running before my howto below will work for you. Here is what I expect to be running:

Also, my instructions assume you’re on Linux or Mac. If you’re on Windows, you’ll need to adjust the commands for your environment.

How to get it all running

  1. Setup Serverless and the Flaskr app locally
  2. Modify SQLite code to run in Lambda (and locally)
  3. Configure the Serverless deployment
  4. Deploy to AWS
  5. Remove from AWS
1. Setup Serverless and the Flaskr app locally

In a terminal session run the following:

# Install Serverless globally
npm install -g serverless

# Create a flaskr in our home directory and clone the flaskr project
mkdir ~/flaskr
cd ~/flaskr
git init
git remote add -f origin https://github.com/pallets/flask.git
git config core.sparseCheckout true
echo "examples/flaskr/" >> .git/info/sparse-checkout
git pull origin 0.12-maintenance

# Move the flaskr project out of the examples dir & get rid of the examples dir
mv examples/flaskr .
rm -r examples
cd flaskr

# Install the Serverless WSGI plugin locally
npm install --save serverless-wsgi

# Create the Serverless AWS Python template
serverless create --template aws-python

# Add Flask 0.12.2 as a requirement
echo "Flask==0.12.2" >> requirements.txt

# Make flaskr runnable
export FLASK_APP=flaskr
sudo -H pip install --editable .

# Initialize the database
flask initdb

These commands install the Serverless framework, downloads the Flaskr app from Github, sets up the app to run with Flask, and initializes a local SQLite database with the necessary table. If all goes well, you should be able to start up Flaskr locally:

flask run

In this case I can access http://127.0.0.1:5000/ in my browser and see something like this:

2. Modify SQLite code to run in Lambda (and locally)

We need to modify the flaskr/flaskr.py file in order to get SQLite to work in Lambda. In case it wasn’t already obvious, this setup is not meant for production. With that out of the way…

Modify the replace the app.config.update section with the following to configure the SQLite database file to be created in /tmp:

flaskr/flaskr.py

app.config.update(dict(
    DATABASE='/tmp/flaskr.db',
    DEBUG=True,
    SECRET_KEY='development key',
    USERNAME='admin',
    PASSWORD='default'
))

Then look further down in the file and modify the @app.route(‘/’) section with the following:

@app.route('/')
def show_entries():
    db = get_db()
    entries = {}
    try:
        cur = db.execute('select title, text from entries order by id desc')
        entries = cur.fetchall()
    except:
        init_db()
        entries = {}
    finally:
        return render_template('show_entries.html', entries=entries)

The above change tries to query the database and if there’s an exception, will attempt to call our init_db() function to create the SQLite database and set an empty entries variable.

3. Configure the Serverless deployment

Now we need to setup our Serverless deployment by setting the serverless.yml file to:

serverless.yml

service: test

provider:
  name: aws
  runtime: python2.7

exclude:
    - node_modules/**

plugins:
  - serverless-wsgi

functions:
  flaskr:
    handler: wsgi.handler
    events:
      - http: ANY {proxy+}
      - http: ANY /

custom:
  wsgi:
    app: flaskr.app

These settings tell AWS we have a Python based function to run, we’ll use the serverless-wsgi plugin, all http requests are to be handled by the WSGI handler to run our flaskr.app. Note we need to explicitly set events to respond for “/” even though we have the catch all entry of {proxy+} set. If we don’t, AWS API Gateway will return an error of Missing Authentication Token.

Let’s test this locally one last time before we deploy to AWS:

sls wsgi serve

You should get a message telling you where the Flask app is running (e.g. http://localhost:5000) to the one above, complete with a locally running instance of the flaskr app.

4. Deploy to AWS

Now we’re ready to deploy to AWS:

sis deploy -v

This can take a little bit to run, as this single command takes care of all the AWS setup for us to access our flaskr app via Lambda. When successful, you should see output towards the bottom similar to the following:

Stack Outputs
FlaskrLambdaFunctionQualifiedArn: arn:aws:lambda:us-east-1:770800358818:function:test-dev-flaskr:31
ServiceEndpoint: https://zwe667htwd.execute-api.us-east-1.amazonaws.com/dev
ServerlessDeploymentBucketName: test-dev-serverlessdeploymentbucket-s03hsyt0f0oz

Copy the URL from the ServiceEndpoint and access it in your web browser. You should see something familiar:

If you don’t get a response or see an error of some sort, it’s time to look at the logs on AWS:

sls logs -f flaskr -t

If you want to make changes to the app (e.g. change templates, modify routes in flaskr/flaskr.py, etc.) and don’t need to make changes to your serverless.yml file, you can do a much quicker re-deploy of the code (i.e. no AWS configuration):

sls deploy function --function flaskr
5. Remove from AWS

Once you’re done with these steps, it’s a good idea to remove your function so that you don’t get unexpectedly charged for anything related to this deployment. Don’t fret, it’s only one line to get it all running again. 🙂

sls remove

Where to from here?

I may get this example working with a proper database. If I do, I’ll be sure to add a new post explaining how I did that.

Agile project management in 2017

The Agile Manifesto turns 16 this year. Scrum turns 22 years old. The grandfather of Agile and Scrum – Lean Manufacturing – has been around much longer, nearly 70 years with the advent of the Toyota Production System (TPS). Put in that perspective, Agile project management is not the new kid on the project management block anymore. Odds are good that an organization has adopted (or is trying to adopt) some form of Agile project management in 2017. Not only has Agile established itself as a viable project management framework for technology projects over the past twenty plus years, but the technology used on those projects and the business environment is constantly evolving, and sometimes even changing in revolutionary ways. And so the question must be asked, what does Agile project management mean and look like in 2017?

Agile Defined

Before examining the details of what Agile project management means and looks like today, it’s important to get a baseline of what it is in general. Wikipedia does a good job of summarizing:

Agile management, or agile process management, or simply agile refers to an iterative, incremental method of managing the design and build activities of engineering, information technology and other business areas that aim to provide new product or service development in a highly flexible and interactive manner; an example is its application in Scrum, an original form of agile software development. It requires capable individuals from the relevant business, openness to consistent customer input, and management openness to non-hierarchical forms of leadership.
https://en.wikipedia.org/wiki/Agile_management

While it might be tempting to jump into a rundown of the latest trends in Agile project management in regards to new frameworks, tools, and concepts; it’s important to see how Agile has evolved in relation to its values and principles. The Agile Manifesto serves as our guide. In its simplest form, the manifesto is expressed in the following value statements:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

http://agilemanifesto.org/

Supporting these values are twelve Agile principles, which this article will examine within the context of what they mean and look like in 2017.

Agile Principle One

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

When major software releases were measured in years, delivering valuable software every month via an Agile framework like Scrum was considered a crowning achievement. Fast forward to today where the internet is ubiquitous, as are powerful computers in our pockets. Continuous delivery takes on a meaning all its own, with the goal being that when new features and functionality are done, they’re ready to be delivered. It’s up to the business to decide when to release, not dictated by technical gatekeepers. In practice this can look like Etsy, where continuous delivery is put on steroids and becomes continuous deployment; meaning every successful build through the delivery pipeline is released into production immediately. This approach can mean new releases go out 50 times a day! It can also look more conservative, yet nonetheless impressive, like the HP LaserJet Firmware division’s move to continuous delivery that resulted in overall development costs reduced by ~40%, programs under development increased by ~140%, and development costs per program dropping by 78%.

Agile Principle Two

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Welcoming changing requirements has become more important in an ever faster marketplace where the hottest product today is tomorrow’s Blackberry phone. Even when businesses have a laser like focus on planning, customer’s needs and wants can seemingly change overnight. This need for near instant change of direction doesn’t mean a lack of planning, but rather the discipline to plan early and often; adapting to the feedback customers are providing. Roadmaps are still necessary, as we all need maps to understand where we are, what the terrain around us is, and where we’re headed. The path we take to get to the destination may (and likely will) change, but we still use the map to get there. A constantly groomed product backlog that aligns with the roadmap is a critical element of Agile project and product management in 2017. The backlog is like the turn-by-turn directions to the roadmap’s line drawn across the landscape. Both need to adjust to an ever changing environment.

Agile Principle Three

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Much like the first principle, the time to deliver working software should be getting shorter, not longer. The only way this is possible is to have the right level of technical automation (testing, builds, deployment, etc.) combined with tight collaboration across the various roles required to build and deliver working software. There is also a need to breakdown features into small enough pieces that can be delivered frequently. There is a high level of discipline and skill required in order to cut problems into smaller deliverable slices, both from both a technical and business standpoint.

Agile Principle Four

Business people and developers must work together daily throughout the project.

This principle can be construed as one only for startups, where the image of a small team working out of someone’s garage building the next big thing is romanticized. There is a common misperception that enterprises have drastically different needs and therefore can’t have business people collaborating daily with developers. Due to the need for delivering faster, tighter collaboration between business people and software development team members is greater in 2017 than it’s ever been before. In fact, the lines between business people and developers is blurring evermore, as the technology becomes more prevalent, business people feel the pressure to become more technically literate, and developers realize there is a difference between “coding” and “software engineering,” which means developing with the business in mind, not only the technical problem at hand.

Steve Jobs hiring smart people quote

Agile Principle Five

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

It may be easy to dismiss principle five as common sense. Of course you want motivated individuals who have what they need to get the job done. However, there was a trend in the 2000’s to outsource anything tech related in mass. This often resulted in contractual relationships where individuals were seen as not much more than “headcount” or “resources” to be shuffled on a spreadsheet to make the numbers work better for one side or the other. Project teams, whether in-house or outsourced, need to be made up of people who are motivated, aligned, and trusted to meet the goals of delivering valuable software quickly and consistently. Smart organizations in 2017 understand the importance of people and the need to provide them with a healthy environment that motivates them and engenders a high level of trust in order to deliver valuable solutions for customers. It doesn’t matter if these people are sitting in the same building together or halfway around the world working under a contract – the same principle applies.

Agile Principle Six

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

With more organizations employing remote workers and teams spread out across the globe, this principle is being put to the test more and more as time goes on. The days of hiring for one specific location so everyone can collaborate in the same physical space are dwindling. The advances of technology and the need for businesses to hire the best people regardless of their location translates to the need to work effectively in a distributed fashion. Organizations that take a “remote first” approach to the way they operate stand the best chance of making this work, where the tools and culture are in place to support working across multiple locations. And even though the “7% rule” (where it’s said that only 7% of communication is conveyed in the actual words said) has been debunked, these same organizations will also recognize the importance of spending time in person, and provide resources to allow project teams to gather in the same physical space in order to encourage team building that cannot occur any other way.

Agile Principle Seven

Working software is the primary measure of progress.

Gone are the days of measuring the individual phases of the software development lifecycle (SDLC) as a meaningful form of conveying progress. Working software takes precedence because working software can be used by people, and that means people can provide feedback on how valuable they find the software. The growing adoption of minimum viable products (MVP) in even large organizations only makes working software as a measure of progress that much more relevant.

Agile Principle Eight

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The only way to continuously deliver a product is if the approach is sustainable. This doesn’t only apply to technical decisions but how projects are managed; including how teams are formed and developed over time. Project management that places too much overhead (in the guise of being more disciplined) on individuals will not promote a sustainable development model. An example of this is the organization adopting Agile coming from a strict waterfall approach. What was once deemed necessary may no longer be so, but, due to cultural influences, may be enforced just as strongly as before regardless of its effectiveness. On the other side of the pendulum swing, project management that maintains little discipline will also not provide a sustainable model of development, as people will burnout trying to make up for a lack of consistency in how the project is managed. Examples of too little discipline can be found in organizations where there is a culture of celebrating cowboy heroics and never ending workdays.

Agile Principle Nine

Continuous attention to technical excellence and good design enhances agility.

The world of tech and software is not getting simpler in 2017. The rapid change of pace in both technology and business requires agility, and the only way to become more agile is through a continued focus on sound technical design. IoT, big data, artificial intelligence, machine learning, microservices, apps measured in the millions upon millions of active users, etc. are all technologies that are currently hot and adding to the capabilities as well as complexity of products. As mentioned earlier, HP LaserJet Firmware is a good example of an organization that refocused its attention on technical excellence and design in order to enhance their agility. The legacy platform they were building on made it difficult to move at the speed the business required. New product rollouts and features were delayed due to a technical foundation that made it impossible to respond in a timely manner. By putting in place the design, technology, and automation to deliver continuously, HP LaserJet Firmware became more capable of meeting customers’ demands.

Einstein simple quote

Agile Principle Ten

Simplicity–the art of maximizing the amount of work not done–is essential.

As the quote attributed to Einstein goes, “Everything should be made as simple as possible, but not simpler.” The technology landscape is becoming ever more complex. The possibilities are endless and so are the temptations to create solutions that are unwieldy and untenable long term. For every shiny new technology that comes along promising to make your product better, faster, smarter, etc. there is a potential hidden tax in the form of additional complexity. The challenge is just as the principle states: maximize the amount of work not done. Reaching the proper balance of simplicity and technical excellence is an ongoing pursuit.

Agile Principle Eleven

The best architectures, requirements, and designs emerge from self-organizing teams.

There are a number of frameworks and philosophies catching on in popularity around scaling Agile as we start into 2017. Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS) are two of the most common frameworks organizations turn to when they want to implement Agile enterprise wide. These frameworks try to address some of the perceived gaps in Agile implementations like Scrum, XP, and even more Lean inspired practices like Kanban or Scrumban. These frameworks for scaling Agile aren’t inherently good or bad, but there is a risk that they override principle eleven by implementing such a rigid structure that self-organizing teams are a near impossibility. The question remains whether this principle is true or organizations are finding a more well defined structure brings about the best architectures, requirements, and designs.

Thomas Edison fail quote

Agile Principle Twelve

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Lean Startup movement has popularized the slogan and concept of “fail fast.” The idea is that you build and test in smaller increments so that you can fail faster, thus learning lessons faster as well. Much like Thomas Edison’s famous quote implies, “I have not failed. I’ve just found 10,000 ways that won’t work.” This principle of reflecting at regular intervals coincides perfectly with a culture of failing fast. Some organizations will mistake a fail fast approach as one where failure happens early and often but little to no reflection is required. While this may seem obvious, failing early and often with little to no reflection only leads to chasing the same problems without applying lessons learned.

Conclusion

Even though Agile is no longer new and a hot trend, the principles still hold up today. The tactics for how to apply the principles has changed as technology and business have demanded, but the underlying principles remain the same.

Two quick tips for cyclists and drivers

What a ride this morning. And thus, I have two tips. One for drivers. One for cyclists. Here goes:

  1. Drivers. Three lanes with no traffic except one pickup truck and me. The driver of that truck got within inches of me, even slowing down as if to prove a point. As the driver (finally) sped away, I saw numerous HGH decals plastered on the truck. If you’re going to get that close to me, please hand out samples, alright? OK, now for the real tip: If there are 3 lanes for you to drive in and one is occupied by someone on a bike, it’s best to use one of the other lanes if at all possible. You’ll get to go as fast as you want and the person on the bike will be happy. Win-win.

     

  2. Cyclists. Unless you’re trying to be a ninja on a mission of (your own) death, PLEASE PUT ON SOME LIGHTS. I know, you won’t be as aero. I also know that some of the cool kids around town might think you’re a dork. But guess what? You might actually be noticeable versus several of the riders I (just barely) saw early this morning before sunrise cruising around with zero lights. Sure, some wore “high visibility” pieces of clothing, but that does you no good in the dark. Put a solid white light on the front and a red light on the back. Give yourself a prayer out there. HGH pickup truck driver will probably still get within inches of you, but most other drivers won’t because they’ll see you before it’s too late.

Racing bicycles is strange

Seth Davidson SCC

I recently listened to an interview with Seth Davidson on The SoCal Cyclist Podcast. Definitely worth a listen. Seth is the proud owner and author of the Cycling in the South Bay blog. He has no shortage of opinions on all things cycling, most likely because he loves riding his bike. He loves it so much that he participates in this strange sport known as bike racing. His interview got me thinking a bit about racing. My (random) thoughts follow.

Continue reading “Racing bicycles is strange”

Silver bullets

silverbullet

In folklore, a bullet cast from silver is often the only weapon that is effective against a werewolf, witch, or other monsters.

https://en.wikipedia.org/wiki/Silver_bullet

I’m not sure how many of us in tech are hunting werewolves, witches, or monsters, but there are A LOT of us looking for silver bullets. Take one look around at the world of software development and operations today and it’s baffling. A perfect example of what I’m talking about can be found in this CircleCI blog post, which sounds like nonsense but actually sums up the current state of software development and operations quite nicely. Maybe we’re not looking for silver bullets. Maybe we’re looking for the gold bullet, then the platinum bullet, then we move onto missiles, bombs, etc. It never ends.

I’m not talking about the evolution of technology as a whole. We have a desire to always learn and progress. What we have in software development and operations today is a hyper spin cycle of the next shiny object. Very little of it gets mature enough before it’s thrown out in favor of the new-new silver bullet. Unlike the last silver bullet, this one will kill werewolves AND witches. If you’re a software engineer caught up in this never ending hype you can find yourself using all the latest and hottest tech with so much complexity it will melt the minds of mere mortals. This happens rather easily because the hottest tech often comes from companies like Google, Facebook, Netflix, etc. who are solving extremely large and complex problems. They are generously (and often strategically) open sourcing a lot of that work, which turns into the hottest tech of the month club. But most of us are not solving problems at that scale. When we take their tech and apply it to our problem we can easily find ourselves with a lot of moving parts when only a few would likely suffice for our problems. Multiply this problem by the output of the firehose of “innovation” happening. I put innovation in quotes because what comes to us in the guise of innovation is often a company’s hope to ever so slightly improve upon a good enough solution and take away market share in the process. Even when there is legit innovation, the benefits of adopting a brand new stack or even layer in the stack are questionable when weighed against building upon a solid foundation.

Again, to get the best grasp of what I’m referring to, read the CircleCI blog post. It’s short, funny, and maddening all at once. We need to stop the never ending pursuit of the silver bullet and figure out a more sustainable way to build great services people find value in. Otherwise, I’m afraid we’re spending too much of our time porting or, worse, figuring out how to port existing stuff that works well onto something that is now deemed “better”.

Chat 🤖s

Fred Wilson has a short post on the state of chat bots. Surprise, surprise – chat bots haven’t taken over the world. One of the main culprits? Artificial intelligence (AI) and natural language processing are not there yet. I’m happy to see these posts that combat much of the hype surrounding chat bots and take a more realistic look at where we’re at and where we might be headed.

I do think chat bots will continue to see growth, both in the number of people using them and in the capabilities of the bots and platforms that host them. With so many people using text messages (in whatever their choice of messaging service is), it makes sense that a lot of interactions should happen within the messaging/chat context. I’m mostly impressed with bots targeting teams/groups at this point, but I might be biased. Bots make a lot of sense in that setting because they can quickly help everyone in the group. A simple example would be the group lunch. Getting agreement on when and where to eat can take a miracle. There are bots to help simplify that process. Again, a simple example, but there are many more out there where teams are more productive due to having information and the ability to take action on something within the flow of a chat. Little to none of this requires AI or natural language processing. Those technologies are getting a lot of attention and investment. It’s only a matter of time before chat bots make use of them in a way that makes sense.

Are chat bots THE NEXT BIG THING? Probably not. They’re a nice step in making chat smarter and better. I think they’ll grow in importance for some use cases and shrink for others. As Fred pointed out in his post, it’s (already) past the hype cycle for chat bots and into the figuring it out phase.