Not about school

thinking emoji

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:

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:

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

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

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

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:

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:

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:

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:

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):

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

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.