The Kaplan Engineering Blog

Kaplan Test Prep engineering teams have been working hard on getting key features in the hands of students to help them focus on achieving their learning objectives.

In the first video, the team talks about key features focused on simplifying a student’s learning experience.

The second video talks about key features in the mobile app for our students to learn on the go.

The third video describes a key feature called dashboard that brings together critical information for the student in a single view helping them focus on what is important to achieve their learning objectives

Let’s start by getting one thing out of the way - Kaplan’s mobile app strategy and “mobile-first” development are not the same thing. Generally speaking, a mobile-first development strategy usually works by defining the best experience on the smallest device (mobile phones) and then working your way up to the larger devices (tablet, desktop) that have more screen real estate. There are many pros and cons with “mobile-first” development (as you can read about here), but the key takeaway is that the same content is generally presented in both places.

For Kaplan (and test prep in general), the same content doesn’t necessarily work in all locations. For example, Kaplan offers full-length practice tests (that take several hours) for students to take on their computers at home. But does anyone really want to take a multi-hour exam like that on their cell phones? Likewise, is reading a full eBook with a separate paper and pencil for practice questions the best experience for a mobile user? Aside from the fact that most cell phone batteries would likely be drained from such an activity, session times on mobile are shorter overall:

With an average time of about 5 minutes in an application, there’s a real emphasis on smaller reward cycles for users, rather than trying to emulate the same full-course experience on a smaller device. Keep in mind, mobile device users are also mobile in the sense of mobility. Our students want to be able to prep while they’re on the bus, waiting in line at the store, or even when they just have a few minutes between places. There generally isn’t going to be time or a location for students to fully sit down and prep for a full length exam on their mobile device, or sit through a full class session. That said, Kaplan’s been in the test prep business for nearly 80 years - we’ve spent a lot of time trying to perfect what we feel is the best balance of course materials and live prep instruction. How can we boil down that experience into 5 minute chunks?

That’s why we’re talking to students, and using our war room to try and build some pocket-sized study experiences. We’re not aiming to emulate a full “official test day” experience on a phone because you don’t take the official test on a phone! Our goal is to deliver a meaningful experience on the go, and a lot of that boils down to finding out which elements of our comprehensive prep are most valuable on the go, and finding new and fun ways to present that.

We’re currently working on developing a fully-in-house project for mobile, and we can’t wait to share it with you soon.

As you may know, a typical Scrum Master responsibilities include:

Instills agile values in team

Does anything possible to help team perform at highest level

Protects team from over-committing (counter to PO)

The catch, for me, is you can have a team that has a great Scrum Master – great process – but the product that gets released isn’t used by students.  And who cares if you have great process if your product is a bust? So while the Delivery Manager also has deep knowledge of agile values, principles, and practices, she is a Product Owner / Tech Lead peer and is accountable for the same things as a PO/TL: code pushed to live rapidly that has a successful outcome.  This mindset is broader, more empowering, and more valuable.  For example, I’ve gravitated towards taking lead on metrics for my team, since I see this as the surest way to keep our team on course.  This isn’t necessarily a typical SM thing, but is natural for anyone with a DM mindset.   

In Marty Cagan’s view, the DM gets a “best-idea” hand-off from the PO’s discovery track and is then responsible for getting these best ideas through execution quickly and pushed to live.  DMs take point on other late-execution responsibilities, like releases and production issues.  Marty likes the role because it frees up the PO to focus on discovery so the team has a strong, validated backlog.  And we certainly want our Kaplan POs to focus on identifying insights through discovery, and then translating these insights to a strong backlog.  Without this focus, it can be easy for attention to stray to other, less important things, such as surfing the various waves of stakeholder opinion.  We also want to be explicit about including engineers in our discovery process. Other things successful DMs do:

Reduce cycle time in delivery of new work

Gain satisfaction of individuals in the organization

Can spin up new teams and make them effective and happy

Make an impact on the greater technical community, including presentations, writings, and meetups

As Kaplan continues to move to Cloud Ops, our DM responsibilities will shift in a subtle way.  DMs already participate in releases by scheduling them, organizing the people who participate in them, and then joining releases and smoothing over hiccups.  As we transition to Cloud Ops, I see the DM participation in releases continuing and becoming a more explicit responsibility.  I think we’ll find that it will be natural for DMs to assume Cloud Ops release management responsibilities, and I don’t think it will be a lot of additional work on our DM team, as we are already heavily involved. The one change that will be an adjustment is taking more post-prod defect calls and troubleshooting issues during nights and weekends.  The DM will likely need to work with the TL and play point in organizing these sessions, and that is not something our DMs (or our engineers) currently do all that often in our current state.  Our DM team is excited to take this challenge on over the weeks and months to come.

Last week, over 25 Kaplanites ran through the streets of Midtown East on a scavenger hunt.  Except this was no ordinary scavenger hunt.  In the digital world we live in today, everyone seems to have a smartphone.  Smartphones with great cameras.  Put the two together and it's perfect for a Photo Scavenger Hunt.  If you're not familiar with what a photo scavenger hunt is, it's a fun team-based scavenger hunt with an interesting twist — the goal is to take digital photos of places and things outside of the office.  By doing this, people will capture good memories and also have fun working together as a team. Really, how can these people not be having fun?

First we needed a clue sheet - I jotted down all the fun and crazy things that were in the area and converted some of them into puzzles (because I like to give folks a challenge).  When I was done I had a list of things that ranged from as simple as finding a person with a white beard to something that required a bit of searching - like finding a giraffe.  You must be thinking how in the world do you find a giraffe in Midtown East.  I suppose some of them did…

Next thing we needed was a way for everyone to share their photos.  Since we love Google, I thought, why not create a Google Community and have everyone upload their photos there?  So we had everyone download the app on their smartphones - we eventually figured it out.

Then, everyone was broken out into nicely balanced teams with a healthy mix of members from different teams.  This is the perfect opportunity for members on different teams, who may not know each other very well, to use their wits and work together as a team.  We’ve also had some new hires and colleagues visiting all the way from Florida who had a chance to do things you probably wouldn’t typically see them do...

There were a few who weren’t able to participate but that didn't stop us from putting them on a team...

Everyone rushed back to the office after an hour to get the results and announce the winning team.  After tallying up the points the winner was... Team Bobcats!

At the end it wasn’t about who won or lost but that everyone had a great time, became a bit more familiar with our new neighborhood, maybe learned an interesting fact or two about their teammates, and built some lasting memories.  I had an amazing time organizing and watching our teams come together for this event, but more importantly, to have the support to have all the teams to take the time to participate in this event - that’s the amazing culture we have here and that’s the culture we'll continue to embrace. Who knows, maybe this will be an annual event!

Tom Cheng, Associate Product Owner; Director of QA and DevOps

This is the second of three installments of my takeaways from Mind the Product San Francisco, which I attended earlier this month. The first installment was Products that Delight.

Most product managers spend the bulk of their time thinking about and looking at their own products--the product's roadmap, design, implementation, revenue model, support process, etc. This is natural, but it's helpful every once in a while to look at your users' world beyond their interactions with your product.

After all, Kathy Sierra reminded us in her presentation at Mind the Product SF, users have feelings, obligations, goals, and interactions unrelated to our products that may nevertheless influence their experience with the product. Jon Kolko, in his presentation, distilled this context into two dimensions: value--what the user hopes to get out of an activity (which your product facilitates)--and identity--the user's aspirational image of him- or herself. In any case, examining the context in which your product is used, argued Sierra, can result in happier users, more effective products, and maybe even higher-end customers.

Users live in the real world--a world that is messy and unpredictable--and their lives are not perfect. By acknowledging and recognizing this, we can start to address the external sources of friction that can detract from the "flow" we discussed in my previous entry, making the product more effective and more satisfying to use.

Furthermore, when friction does occur, we have an opportunity to make users feel like human beings--not just another number. In addition to whatever technical issue a user may be experiencing, he or she is likely also experiencing very normal emotions--panic that his/her photos have been lost, stress that he/she can't get a task done in time, fear of looking stupid. That's why the "Mayday" button on the latest Kindles is so effective--not only does it provide an easy, straightforward way to get help, it speaks to the emotions that a user may be experiencing, and acknowledges them as normal.

And while contextual research is a well-established way of coming up with new product ideas, it can also be used to expand the reach of our product or even move up the value chain. Sierra gives the example of a "Horse Sounds" app on iOS, which sells for $0.99. If the creator of the app, who clearly intended it as a novelty item, explored his user base, he'd find that he could repackage it and market it to serious equestrian photographers, who are willing to pay far more than $0.99 for such a tool (which, Sierra explained from personal experience) is effective in keeping a horse's attention during a photo shoot.

So how do you do contextual research? Jon Kolko described the process he went through for a career app for new college graduates. The product team spent about 4 hours with each end user (students, recruiters, hiring managers) in their "natural habitat"--dorm rooms, classrooms, offices--and recorded the entire visit. They then transcribed everything the users said onto slips of paper, and clustered them into themes. This process yields the behavioral insights around which you can design and plan your product.

Tom Cheng, Associate Product Owner; Director of QA and DevOps

Last week, I attended Mind the Product San Francisco, a gathering for passionate product managers to share ideas, learnings, and experiences. The presentations, from a wide array of industry-leading product managers and designers, were all exceptional, and the perspectives ranged widely from the philosophical down to the day-to-day practical. The conference blog has a good synopsis of each presentation, but I saw a lot of interesting themes running through them. The first of three major themes that jumped out at me is what it means to create delightful products, which I’ll cover in this post. In later posts, I’ll discuss the other two themes, understanding your users and creating a culture of learning.

Many product designers focus on making their products fun and easy to use--to wit, the many, many attempts to "gamify" education software or the adage that "If you need a manual, the product is too hard to use". This is misguided, according to Kathy Sierra, who says, "If your product doesn't need a manual, it may be because your product isn’t interesting."

The key to an enjoyable user experience is establishing "flow"--the state of being focused on the task at hand without being distracted by external worries or concerns. This may entail introducing some level of cognitive challenge: if the UX is too simple or doesn't require thinking, the user will just click mechanically and his/her mind will wander. On the other hand, if the UX is too challenging, the user will simply get frustrated and give up.

Thus, the user experience should align with the user's skills and expertise level. However, that does not mean you need to tune your UI to a specific group. If your user is a hero in an adventure novel, then your product is his/her sidekick, mentor, or ally--at core supporting the user on his/her mission (even if it is just to find the right pair of pants) while providing tips, suggestions, and support when needed. Tooltips, "tutorial" or "novice" mode, and tips-of-the-day are good examples of ways to provide help only for users who need it.

All that being said, to truly delight users, we need to create what Tom Chi refers to as "Magic Moments"--those points in the user experience that are so amazing that the user's eyes light up. All great products have one, but Uber has two: 1) when the car you ordered appears and 2) when you step out of the car and go on with your life without pulling out your wallet, parking the car, or paying a valet.

Note that the user isn’t interacting with the Uber app in either of Uber’s magic moments. The moment is magic because of how frictionlessly the car appears and disappears.

The upshot is that a product designer has to two distinct and independent concerns: reinforcing flow and amplifying the magic moments. Flow is a usability exercise--removing the friction or discontinuity that distract or frustrate users; magic moments, on the other hand, are a design exercise--melding the product experience seamlessly with the user's intentions and goals. 

Using Java and Selenium To Dodge Session Management

I wanted to use Selenium to test some capabilities of this web application my team was building, so I wrote a lot of tests in Java and started running them. Okay, great, if any of these capabilities being tested break in the course of development, the robots will find out about it and report back to us. Nothing new here; that’s the nature of test automation. The same old story usually continues down a path like “These tests are great, but what can we do to optimize how they run?” For example if we want our full suite of tests to go through an end-to-end run in less time, we’ll consider running tests in parallel. And so that’s what we did.

There are a thousand and twelve benefits to running your UI tests in parallel, and it feels like there are just as many pitfalls. I’d like to address one of the pitfalls I encountered, and that was dealing with our application’s session management. This web application requires its users to log in in order to access any of the good test-worthy capabilities. When a single user logs in on Computer A, a session is created for that user — this is so all the parts of the application know that this user guy is authorized to see and use all these protected capabilities, at least until the session ends or expires. But then if the same user logs in on Computer B, a new session is created for that user and that first session is ended. So back on Computer A, the user suddenly loses access to all these protected capabilities. The end result is if we wanted to test two capabilities on different machines at the same time, we were going to need to do it with two different users. Substitute “x” for “two” where “x” is the number of tests we wanted to run in parallel, and you see the kind of problem we were trying to solve.

Here’s how we did it.

The plan was to set up a queue of valid test accounts. When a test script wanted to log into our application, rather than each using the same “userX” login, they’d grab the first test username in line, removing it from the queue. That way when the next test script wanted to grab a username of its own, it would get the new first-in-line username and everyone would have its own unique test user and it would be all smiles and magic and butterscotch valleys. When a test script was finished it would add its username to the back of the queue so some future script could reuse it.

First, we registered an army of test accounts in our application, with usernames in a series like this:

Since we have 40 robots, we can run up to 40 tests at a time without running out of valid usernames to use. For us, that’s plenty.

Now, before we set this up we were passing the username as a straight up string for Selenium to plop into the “login” field of our application:

and then…

What we wanted to do was populate that value with a String popped off our queue:

and elsewhere:

In RoundRobin, we’re setting up the Queue of appUsernames which will live in this class and will hold those 40 Strings, valid login values for our application. When we want to populate that Queue, before we start running all our tests, we have the setup class setRoundRobin fill it up with Strings and return the whole object so the setup class knows the deed is done. Here’s what the setup class looks like:

@BeforeSuite is a TestNG annotation that tells this class to run before any other tests are run. In order for the test classes to know that this is living out there, expceting to be run first, we have to make sure that all our test classes extend this setup class, like this:

You’ll notice the ‘returnAppUsername’ method used in teardown — that’s what adds the username String to the back of the line for re-use. In RoundRobin it looks like this:

And there you have it. With this little trick we’ve been able to winnow down the number of pitfalls related to parallel testing to a lean one thousand and eleven.

Phil Wells, Test Automation Engineer

Lean UX Practices and Product Discovery Immersion Workshop

Hey, my name is Raghavendra Reddy and I am a Software Engineer at Kaplan. I would like to share my experience about a Lean UX workshop held at Kaplan on 1/13/2014 - 1/17/2014, by Jeff Gothelf and Jeff Patton (http://www.leanuxbook.com/).

There were total 11 different teams that participated in this workshop. It was a great learning experience to collaborate, interact with real users, work in cross functional teams, and come up with a shared understanding for working together.

Kaplan adopted Agile methodologies very early, and this workshop helped to make our methodologies even better. Often we build products/applications by making assumptions that these products will solve user problems, and we spend a lot of time and resources in building these applications. This workshop changed the paradigm of how we build the application/products for the current fast changing world.

These are the core ideas behind Lean UX:

1. Empathize: finding the problem statements and new ideas. We do this by observing users using the product, getting their feedback, understanding their pain points, and creating personas.

2. Define: once a problem statement is identified, it's important to define it and have a shared understanding across all the stakeholders. Talk to the personas (real users) and validate your hypotheses.

3. Ideate: at this stage, we know the problem statement and we work on a solution for the problem.

4. Prototype: build a quick prototype.

5. Test: test the prototype with real users.

Testing our assumptions in every step and iterating based on what we learn helped us focus on creating the highest value features for users. By doing this, we reduce the time for getting user feedback, and come up with MVPs (Minimum Viable Product) in the least time and resource usage possible.

"Fail early" is the key for success. Feedback in every step of lifecycle will save significant time and resources.

From the traditional way of building applications, to agile, and then to Lean UX, we are changing a part of our organization culture. I can see the tremendous improvement in the way products are built and tested at Kaplan. People from product, technology, content and design teams were at the table, thinking through the hypothesis and personas, talking to real users, prototyping, and designing. This was a great experience.

Here are few more pictures from the workshop.

I would like to thank everyone for making this event successful. Overall, the Lean UX workshop was a very productive 5 days with many great ideas prototyped, built, and tested.

Reference Books: http://www.leanuxbook.com/

This year’s company hackathon took place from 7/31 - 8/1. A large total of 28 different teams participated in the hackathon. It was a great chance for developers and anyone with an idea to build a prototype of new creations and products.

I spent my time working on Team Doogie. Remember that robot from the last post? It was put to work testing Kaplan’s iPhone apps. Doogie is based off of an open source hardware design by Jason Huggins, who Phil Wells brought in to help us construct an iPad sized robot as well as help us put Doogie to work.

Working with Team Doogie turned out well despite some setbacks. The iPad sized robot, who we named Kaptron, didn’t work so well due to issues with its construction, but we were able to get the smaller Doogie to use one of our iPhone apps. And I even ended up contributing to 3 of the different open source projects we were using on GitHub.

While using one of these robots for real testing might not be immediately viable in the short term, we also found that we could start using Appium, an open source automation framework, to automate mobile testing at Kaplan.

The hackathon began with an opening ceremony in which the rules and prize categories were presented.

After the opening ceremony, the 28 teams went to work hacking away to get their ideas implemented within the short 48-hour time limit.

Team HiredEd

The panel of judges

All in all, the hackathon was a very productive 48 hours with many great ideas prototyped.

In April I attended a Robot Hackathon focused on constructing a robot that could use a mobile device and run test cases.  The robot is built and, as you can see, it dances:

As thrilling as that is, where exactly does mobile device testing come in?

An important piece of that puzzle is an open source project called Appium, which is sort of like Selenium for native iOS and Android apps.  Appium is designed so that a tester can tether a device, like an iPhone, to a Mac running XCode.  We then run Appium scripts to simulate screen taps and gestures on the connected device.  The device reacts as it normally would and sends results back to Appium, which compares those results against assertions.  If the results match, the test cases pass, and our Product Owner is very happy.

The idea behind the robot is this: if we can send an order from the command line telling the robot to dance, then it’s possible that we can send it commands from Appium telling the robot to interact with an iPhone underneath its stylus which happens to be running our native app.  Results are sent back to Appium as usual and checked against our test cases’ assertions.

But why?  If Appium can send these commands virtually with greater accuracy and speed, why would we use a robot for this?  I can think of a couple of reasons.

For one, there are some gestures and scenarios which can’t be executed via Appium and XCode.  For example, the process of switching from one app to another, a popular test case, cannot be easily automated since the XCode simulator can only run a build of on app at a time.

Another reason to use a robot is, well, it’s a robot!  Look how cool it is!  Let’s face it, software testing as a practice has a reputation for being repetitive, tedious, bureaucratic, yadda yadda yadda. But here is a QA project that utilizes, yes, robotics, but also bleeding edge open source software, a whole array of modern mobile devices (Appium supports iOS, Android, and even Firefox OS), and 3D printing technology (those arms are an open source design).  Let’s get excited about test automation!

In the summer of 2012, I was approached about writing a book on HTML5.  Now mind you I had never written a book before, so I was a little intrigued (and perhaps a little perplexed) by the proposal.  After some thought (and a few Google searches), I decided to ask Gabriel Balda, whom I consider a pro at all things web, what he thought.  After about 2 (or maybe 3) seconds of reflection, he said, "Let's do it!" We met at a Starbucks that weekend to plan out what we were going to write about and to rough out an outline to propose to the publisher.  I think back to that time and wonder at what we thought we were getting into. I mean, how do you write a book anyway?  What do you cover?  What do you not cover?  Who do you assume to be your audience?  What would they care about?  How do you demonstrate in a cohesive way all the topics you want to talk about?  We decided to build as an example a movie finder app called MovieNow.  It would encompass many of the features of HTML5 we wanted to cover: geolocation, video/audio, canvas, web workers, etc.   Once the outline was approved and the contract drawn up and signed, we started writing.  We were given a schedule of two weeks per chapter.  Gabriel and I decided to alternate chapters.  We placed all of our drafts in a shared Google Drive folder.  We put our sample code in BitBucket.  We started developing the sample app by using a cloud-based IDE called Cloud9 (https://c9.io/) in particular because it boasted many features centered around collaboration -- which is something we were doing a lot of -- but after failed attempts to run and commit our code as well as general bugginess, we abandoned it in favor of local text editors.  As for the actual writing part, let’s just say you have to sit and write...and write...and write.  The publisher gave us a set of Word templates with their own pre-defined styles for everything including headers, bullets, and code.  Once a chapter was completed by one of us, the other proofread and reviewed it before submitting.   All in all, it took us about 5 months to write the rough draft.  Once the rought draft of the book was editorially accepted, the book went into technical review, which went on for about a month.  We received a few chapters at a time with embedded comments pointing out errata, things to note, or just general suggestions.  After a couple of revisions per chapter were submitted, the book went into pre-production wherein they convert the Word documents into the final layout.  At this stage, we were delivered the pre-finals in PDF format and were asked to make final suggestions for which we were given about a day per chapter.  When we submitted all of the pre-finals with our comments, the publisher uploaded the final version to Amazon for the Kindle edition, which was available on the Kindle store about a week thereafter.  

  I think the biggest thing we learned was that it takes a really long time and a lot of discipline to write a book.  Nevertheless, it is worthwhile if for nothing it forces you to turn the tables and get into the mind of your audience.  Teaching (and perhaps learning as well) is far different from doing in that it is more of a metacognitive activity and that in itself affords a valuable perspective on how things can or should be done.

Netflix recently published information on how they are evolving their API architecture. At first glance it may seem like they are moving away from REST principles but I think they are making these trade-offs based on their use case requirements and lessons learned from the past. According to them, one of the key drivers was to reduce the chatty nature of client/server communications and in the process create a fault-tolerant, high-performance platform architecture. This strategy seems important as Netflix is seeing a big growth in their mobile usage and they now need to ensure and preserve a positive user experience across all their mobile devices. In order to optimize for a great mobile experience, APIs need to be designed well. For mobile it means minimizing network connections, caching, and designing APIs that return only the data that is needed.  Netflix's shift drives home couple of points. One, there is no single correct architecture. Two, always focus on the core use case requirements when coming up with a good API architecture. I call this purpose-driven API. We applied these very principles when building our mobile flashcards app for MCAT Students. To learn more details on our implementation, check out Daniel's multi-part series on the Architecture of Kaplan Flashcards.

MCAT® Flashcards for iOS

Flashcards is a system, designed for mobile devices, that allows students to play with questions and answers. The application is based on scores of how many questions, represented as cards, the student is able to tag as “Known”, “Unknown” or “Unsure” in a deck. Many projects at Kaplan stores data in different types of databases, including Relational Models, NoSQL or even plain XML files. The content is composed by exams like MCAT, LSAT, GRE, and students profiles. These applications place very different demands on storage, both in therms of content type, authoring, and presentation layout. In this article we start to describe the simple model provided by the RESTful Flashcards API architecture, which gives clients dynamic control over consuming data, presenting different layouts and formats. I describe the design and implementations of the architecture created to accomplish cross-platform mobile Flashcards clients.

MCAT® Flashcards - Web Version

Introduction

Over the last years we have designed, implemented, and deployed a distributed API system for managing structured data at Kaplan. The Flashcards API is designed to reliably scale to different sources of contents and thousands of machines. The Flashcards API has achieved several goals: wide applicability, scalability, high performance, and high availability. The API is used mainly by two Kaplan pilot projects, Flashcards Mobile and Flashcards Web, but is extended to custom authoring tools like the Flashcards Content Manager. The API clusters used by these products span a multiple range of configurations, that servers JSON to handle mobile native applications and browser based clients requests.  The Flashcards API provides a transparent interface to multiple content repositories performing content conversion, versioning, in-memory cache implementation. It provides a simple data model that supports dynamic control over data layout and format, and allows clients to reason about the locality properties of the data represented in the underlying storage. Data is indexed using users metadata, clients can control dynamically how to present it to the user.

Architecture Characteristics

The Flashcards architecture was created with coordinating a set of constraints that attempts to minimize latency and network communication while at the same time maximizing the independence and scalability of components. The Representational State Transfer (REST) fits very well once its became a consolidated style developed to accomplish all these points. First Stage: A slice of an example database that stores questions and answers. The application receives multiple HTTP requests, it reads the content from a stand-alone database and return serialized JSON responses, asynchronously. In a first stage we settled on this minimalistic model after examining a specific use-case, handle requests to different types of mobile platforms and browsers using a unified protocol. We removed almost all business logics from the server, placing constraints on connector semantics. Important points moves from the server to the client like:

1. Page Rendering

That is, the logic to generate dynamically web pages or views, like JavaServer Pages (JSP), was moved from the server to the client. Today, with the advance of HTML5 and Javascript engines, it became very efficient render pages inside the client. Most of times, clients utilize fluid layouts and customized components to present a better user experience. Aside the page rendering, a solid communication protocol  allows native Android, iOS applications to exchange data with the server.   

2. Sessions

Avoiding sessions leads to a more scalage and usable architecture. We are keeping the clients state on the client. 

3. Caching

REST enables the caching and reuse of interactions. The server sets a group of HTTP Cache-Control directives. That is, it delegates the responsibility of caching to specialized systems like the browser or forward proxy.

Summary

This post makes part of a detailed group of implementations. I’ll show how all components fit together and share more details on what’s coming next. Stay tuned.

If you have read other posting in this blog, you already know that Kaplan technologists enjoy working hard and we also enjoy celebrating the work that we do and the impact it has on student’s lives. In the summer, we had a Hackathon. In the winter, we had another exciting event, the first ever Kaplan Demo Fair. The purpose of the Demo Fair was for our IT teams to meet and share with each other and with the business our accomplishments during the year - the new products we developed, new technologies we used, new design solutions we are proud of - and to talk, learn from each other, and celebrate our joint success. When we organized the event, we asked the teams how they’d like to participate and the response was overwhelming - 21 teams opted in including our colleagues outside of IT in marketing and content development - and each of them came up with a creative and exciting way of presenting their achievements. So I’ll tell you the rest of my story in pictures so that you can feel as if you were there with over 100 onsite and about as many remote participants of this event. Early in the morning of the event, participants started setting up their booths at Kaplan office at 395 Hudson Street in New York in Kaplan Cafeteria (referred to as “Kapeteria”).

In a few hours, the room was full with participants walking around, talking, sharing their experiences, and exchanging ideas.

The teams shared their exciting products and back-end systems with other IT teams and showed them to the business.

Kaplan has a Flexible Work Arrangement policy and many Kaplan employees work remotely, so we made a special point of making this experience as exciting for remote participants, as it was onsite. We had a reporter, Erin (in other days, she is an Executive Director at Kaplan), but for the Demo Fair, she became a head of a crew that made this event so cool for online participants who asked their questions via Google hangout,  exchanged remarks online, and participated in the event with the help of Kaplan own Live Online media crew.

Everyone who came to the Demo Fair greatly enjoyed the event. How do we know, you’ll ask? We know because we survey all the participants for every new initiative. We care about what everyone thinks and each time we plan anything, we base it on the suggestions from the prior event. That helps us become better and better in everything we do. You will ask who am I and where is my team? I am a member of Agile Center of Excellence. We are a team of coaches who work with Kaplan agile teams and every day brings fascination and excitement of the new products that we build. Here’s me with my colleagues Ilio and Terrence:

and here is Lori (you’ve met her in one of the earlier pictures). Lori is an Agile coach and also, a scrum master on our amazing web site team:

Hope to talk to you soon about new exciting Kaplan initiatives. Bye for now!

In a 48-hour coding spree, KTP's engineers were encouraged to work on anything that they were passionate about. It was fun and we got a lot done!

Check out Ilio's post and this write up in IntrapreneurLabs for more details. 

So your company recently decided to adopt Agile software development practices.  Some of your software teams are using Scrum and some of them are using Kanban.  All of them have continuously improved and become more self-organizing. You like this new way of working.  Since the adoption of agile, you’ve presented to your CEO in demos.  You’ve participated in a hackathon.  You’ve worked successfully with other agile teams on cross-team dependencies and as a result you’ve grown closer to your co-workers.  You’ve become increasingly excited about the product you are working on. However, when you needed to work with team outside of the technology department’s agile teams – teams with names such as finance or editorial or marketing or operations or corporate or “the business” – you were sharply reminded of the way things used to be.  You might have even found that yourself wondering if these non-software teams might benefit from adopting some agile practices. Until recently, this is the situation I was in at Kaplan.  Our software development agile teams were making great progress, but there were opportunities to improve communication and collaboration with non-software teams in other departments. So when an executive on the business side of Kaplan asked me if I wanted to coach a non-software team on how to write a book using agile practices, I jumped at the chance.  If we could be successful writing a book using agile practices, we could more easily show the value of adopting agile practices to other non-technology departments within Kaplan. The first thing we did as a team was decide what success would look like.  We decided there were two things that needed to come into being for our team to be considered a success: 1.   A highly-reviewed book on Amazon 1a. Genuine collaboration Two weeks in, our goal of collaboratively creating a book is in progress.  Here are twelve things I’ve learned so far:

If someone says she wants to “go agile,” have lots of direct conversations with her about what that means before you start “going agile”

When forming a new team, get executives excited about the idea first, as this makes everything else easier

Be clear about the team’s goal immediately and often

Be clear about non-negotiable things immediately (e.g., the book will need to go to the publisher on December 15th)

Until you realize that coaching the team will take more of your time than than you initially thought, you will not be putting in enough time

It is 2012 and video conferencing is easy to use and often free, so if you ever have remote team members, they should be up on video for every single ceremony, no excuses, no exceptions

Whether you have remote team members or not, you should leave a group instant messenger chat window open all day, as this will help to quickly answer questions that would otherwise have become an impediment

A team can adopt Kanban without knowing that they are adopting Kanban; simply use regular words to describe the value

A well-run standup is a powerful thing for people who have never participated in one; if you do nothing else, conduct a well-run standup

Someone, somewhere, will think less of you if you link to Wikipedia

So can we write a 4+ star Amazon-reviewed book using Kanban?  I certainly hope so, but quite honestly it is too soon to know for sure.  Our pilot will likely have some bumpy patches, but because we all understand the goal, and because our process has short feedback loops built in, we’ll learn from the bumpy patches and I believe we’ll come out with a book product that is better than any book product we’ve created before.