Agile

Archived Posts from this Category

May 23, 2013

UX and Agile: How we do it

Posted by Arin under Agile, Design | Tags: , , , |
Comments Off 

UX Magazine had an article last month by Michael Lai entitled “UX and Agile: Tying the knot”, which used a great marriage analogy to discuss how UX and agile are and must be intertwined. At AgilityFeat we are very passionate about both UX and agile methods, so this article certainly spoke to me.

Michael emphasizes that UX has to be embraced by the whole organization, and I couldn’t agree more. Our most successful projects have been those where our UX leads were highly integrated into the project, and where UX was a key part of why the customer chose AgilityFeat over other development and design shops. When our UX and design team has the flexibility to work with our customers on their vision, that is when we really flourish.

Our agile development process complements this creativity very well. Here’s how we combine them for maximum punch:

1) Assessments up front

2013-03-22_09-23-07_309We like to start off our projects with customers by assessing where they are at now (especially crucial if they already have a product), and helping them envision where they want to go with their product. We do this by learning about their business and processes, their customers, their current software, and what internal and external stakeholders to the product value. At the end of the assessment we produce a presentation that shows our recommended process flows, a prioritized development backlog, brand guide, and high level design.

2) Sprint Zero to get ahead of development

Once the assessment is complete and we have agreement with the customer on the high level vision and design, it’s time to start development. Well, almost time. We start our projects with a Sprint 0 where two things are happening. First, the development team is setting up the coding infrastructure that they need and building a “walking skeleton” that shows how key frameworks or interfaces in the application are going to work. In parallel to that the UX and Design leads are building the first wireframes and mockups on the highest priority development items. This Sprint 0 usually lasts two weeks.

3) Iterative UX and Design to match development

DavidMarianaOnce we are into development, our teams work in short one week sprints with frequent demos to the customer. The UX and design leads are working on the same cadence, and always make sure that the mockups and designs for next week’s sprint are ready prior to the sprint planning. This allows for very efficient UX and design because we are not designing things until right before development is ready for them. That leaves plenty of time for the customers to adjust features, while still staying true to the overall vision developed during the assessment.

This pattern of agile development, UX, and design has worked very well for us. Does this match how your teams work? Do you have questions about how you can get your teams to this state? Setup a free chat with me using soHelpful.me/arinsime and I’ll be happy to share notes with you!

 

May 22, 2013

Red stickies as an expedite lane in Scrum

Posted by Arin under Agile | Tags: , |
Comments Off 

When teams move to Scrum from a more chaotic development method, there is often a struggle with convincing the new Product Owner (or the business folks that they report to) that the team cannot be retargeted on a whim. A benefit of Scrum is that teams get to focus heads down on a set of functionality for the entire sprint.

What if a production bug comes up that cannot wait for the next release at the end of the sprint? What if something less important than a production bug comes up, but the product owner still sees it as an “easy fix” that would really make an important stakeholder happy?

Should you allow diversionary tasks?

Scrum by the book says you should not allow this to derail the team, and I’m all for that, but often there has to be a balance when an item truly is critical.

Kanban teams handle this by having an “Expedited Lane” where the business can put a story that bypasses the normal process and takes precedence over anything else the team is working on. This is to be used sparingly, and under strict rules like a WIP limit of 1.

I’m coaching teams at a large internet company right now that struggled with a problem of lots of little requests eating away at the team. We handled it in two ways, and things seem to be moving really smoothly now and everyone’s happy (the team and the business).

Step 1) Make the little things visible

In the team’s first sprint, as they transitioned to Scrum, there were still lots of carry over items that had not been written as proper agile user stories with Scrum in mind. And lots of these were little “one off” requests. To make the impact of these visible, those items all went on red sticky notes on the board. The newer agile items that went through the proper process were on yellow sticky notes.

The goal was to make it clear how much the team was getting sidetracked, and this was obvious when half the board had red stickies at the end of the first sprint.

Step 2) A Scrum version of Kanban’s Expedite Lane

2013-05-22_13-49-41_813As the team and the business got used to Scrum, those red stickies decreased in number significantly and quickly. There are still issues though that truly would benefit the business if they could be addressed more quickly than the 2 week sprints allowed, and requests that are so small that they do not benefit from the agile planning process.

The team wanted to shut down most of these types of requests and say “add it to the backlog”, but they also wanted to stay flexible to the needs of the business. How could we create a process that allowed for that flexibility while discouraging the abuse of it?

The solution we used was to put two “red sticky” boxes on the team’s scrum board, in a corner and set aside from the rest of the scrum board stories. If the Product Owner wanted to give the team a red sticky request during the sprint, they were allowed to do that anytime, as long as they put the red sticky in one of the two boxes. Once there, the red sticky stayed there as a way to record what the request was, and that one of the two allotted spots had been used.

This simple method effectively created a WIP limit of 2 diversionary requests per sprint, and gives the business the flexibility they wanted. But the product owner also had to consider carefully before they used one of those spots, creating an incentive not to abuse the system (which is what the team wanted). It’s worked well enough that multiple teams at this client are now using it, and it’s unusual that both spots are actually used in a given sprint.

 

April 26, 2013

Lean Start-up, now what?

Posted by Ford under Agile, Lean Startup, Startups | Tags: , , |
Comments Off 
Back in November we slogo-6780bb8e6725e305cb28224811f5fc81at down with Tony Cappeart, COO and Co-Founder at Contactually to talk about how they are applying Lean Startup methodologies to build their business. We talked about how Lean Startup had guided their product design, market segmenting and customer development. Contactually just announced the launch of version 2.0 of the product so we decided to check back in with them and see how things are going. Here’s what Brian Pesin had to share with us on how Lean Startup is informing the business as they step from version 1.0 to 2.0.

How did you determine what features to build into 2.0? 

We spent a lot of time talking to our users and potential customers to understand the pain points they were trying to solve by using Contactually. They also told us about how they worked and the tools they used to accomplish their goals, which gave us a few key narratives on which we focused in order to come up with new product ideas. In general, we heard that we were great at telling them who to talk to and when, but they still had a hard time figuring out what to say in order to stay top of mind and relevant.

Additionally, our customers were successful when it came to following up with individual contacts, but they wanted to engage more people meaningfully and at scale. At that point, we’d already partnered with ActiveCampaign, MailChimp and a few others, but there was still a gap when it came to personally engaging multiple people at once.

Brian Pesin

Brian Pesin- Marketing Manager at Contactually

What were your biggest surprises in usage for version 1.0 (were there features used more or less than you expected)?

We were really surprised at the amount of time that people spent on Contactually.com. Initially, we focused on having users come in and spend a few minutes sending follow-ups before going out the rest of their day. However, users kept returning to interact with their rich contact data, so we realized the importance of having a powerful contact database, especially given the lack of a great solution at the time. This led us to spend a lot of time developing our new search engine.

Why did you decide to do a full 2.0 release instead of smaller, iterative releases?

We normally iterate quickly, pushing new product features or small changes several times a day. However, the 2.0 features ended up being larger and more interconnected. We actually had a group of about 150 beta testers that got to use the features before we released it to the general public, and they often saw multiple product changes throughout a given day. The timing ended up coming together in one concise narrative.

Did you speak to customers about the 2.0 features and if so, how?

Definitely! We log every piece of feedback and every product suggestion we got, whether from an interview, phone call, support ticket, live chat and beyond, internally. We see what repeatedly comes up in conversations and use that as a basis. We also engage our top users to understand how they work and the features they need to achieve their goals.

What tests did you run to determine the features for 2.0?

We spent a lot of time creating wireframes for the new features before reviewing them internally and with a few of our power users. Then, once we built the initial feature, we shared it with our beta testing group to get their feedback.

How was developing 2.0 different from 1.0?

For 2.0, we had to build and develop for scale. In the early days, it was fine for us to build features that didn’t scale well. However, now that we’re supporting tens of thousands of users and their data, we have to keep completely different things in mind. For example, our previous search engine lived on a single server. We now have five servers running continuously.

 

April 22, 2013

Setting up a cadence on your agile team

Posted by Arin under Agile | Tags: , , , , |
Comments Off 

I’d like to share with you a common cadence that we are using on agile teams that I coach, and also on many of AgilityFeat’s development teams with our clients. For an agile team to get into a solid rhythm of work, they need to have a set cadence of sprints. This means that demos are always done on the same day (regardless of level of completion), sprints always end on the same day, planning is always done on the same day, etc. While there are obvious exceptions around holidays, it’s important that you stick to the same size sprint as much as possible. Without that set cadence, your team will lose rhythm and focus, and metrics like story point Velocity will be meaningless.

A Typical 2-week cadence

On teams I am coaching right now, we are setting a regular cadence of these meetings:

  • Standups – daily of course
  • Prioritization meetings
  • 3 Amigos meetings (a concept I learned from Lithespeed and George Dinwiddie)
  • Estimation meetings
  • Planning meetings
  • Demo and retrospective on the same day

For teams that follow a two week sprint, here is an example of what your cadence may look like on a calendar.

Screen Shot 2013-04-22 at 3.38.03 PM

Notice that this cadence is ongoing across sprints.  The planning meetings for a given sprint are spread out over the previous two weeks, so that in true agile fashion, you are regularly doing small chunks of planning just before the actual work is to be done.

Setting up a cadence like this means that your actual sprint planning meetings will be pretty short, because most of the hard work was done in prior 3 Amigos and estimation meetings.  This makes for less stress on the team because there is time to correct any deficiencies or gaps found during the planning process.

It’s also less stressful for the Product Owner, who is assumed to be drafting the stories in this model, because they know exactly when they need to have the stories done by, they have time to do it in small chunks, and there is time built into the schedule for them to meet with stakeholders and confirm priorities.  Instead of having a half day marathon planning session filled with questions, your planning session will often be 30 minutes or less because you already hammered out the details of each story and the team has already agreed the story meets their “Definition of Ready” for development.

Here’s a break down of each meeting:

Prioritization Meeting

Screen Shot 2013-04-22 at 3.43.23 PM—Purpose:  Review the backlog, and adjust the priorities of upcoming stories as necessary.  Product Owner can make projections of when stories will be worked on based on historical velocity, but they cannot commit the team.
—Look out for:  Any fixed constraints or new issues from stakeholders may require changing priorities
—
Outcomes:  Product Owner knows what stories to prepare for the 3 Amigos meeting


3 Amigos Meeting

Screen Shot 2013-04-22 at 3.52.33 PMPurpose:  Review the upcoming stories for the next sprint.  This is a chance for the team to verify that the “Definition of Ready” criteria are all met and the team has a shared understanding of the story to be developed.
—Look out for:  Missing Acceptance Criteria, dependencies on external resources or architects, edge cases that need to be considered.
—Outcomes:  The team agrees that this story can be estimated and can be considered for the next sprint’s planning session.


Estimation Meeting

—Screen Shot 2013-04-22 at 3.54.14 PMPurpose:  Go through all the candidate stories for the next sprint.  These stories should have already been approved in a 3 Amigos meeting, or adjustments made based on feedback from that meeting.  Stories are estimated by the full team using story points.
—Look out for:  Major team disagreements on what a story means.  If stories are too big to be comfortably completed in the sprint, they should be broken up.
—Outcomes:  1-2 Sprint’s worth of User Stories are ready for planning.


Planning Meeting

—Screen Shot 2013-04-22 at 3.59.11 PMPurpose:  The hard work has already been done.  Now the team is just going to compare the list of prioritized, estimated stories to historical velocity and decide how many to commit to in this sprint.
—Look out for:  It’s ok for the Product Owner to add stories at the last minute on occasion, just prioritize and estimate them quickly at the beginning of the meeting prior to the planning.
—Outcomes:  A completed Sprint that the team is comfortable committing to and tackles the Product Owner’s highest priorities.


Too many meetings? Maybe!

This may look like a lot of meetings, and depending on your team, it may be too many.  Remember, agile methods are not meant to be overly prescriptive.  Do what works best for you, but this is a common pattern I see, especially at large companies where there are lots of stakeholders to coordinate with before a sprint can be planned.
Agile teams that are particularly small or have product owners with complete authority may not need this.  Other agile teams may just be very mature or working on a system that they understand completely, and they don’t need the extra hoop of 3 Amigos or prioritization meetings.  If your team is already doing all the planning in 2 hours or less and still maintaining high quality, then this example cadence may be too much overhead for you to incur.
But if your scrum team is taking a half day or more to plan a sprint, or there is lots of argument during the sprints about what user stories actually meant, then this type of cadence may work well for you.  Try it out for a couple of sprints and see – you can always change it later!
 

March 28, 2013

Three things I learned on a work-cation..

Posted by Ford under Agile, Customer Development, Lean Startup, Nearshore Agile | Tags: , , , , , |
Comments Off 

Last weekend, I traveled to San José, Costa Rica to meet with the Agility Feat team. As usual, the trip to Costa Rica was absolutely amazing even though there were no beaches nor rain forests on the itinerary. This time, we used the weekend to separate from our day to day responsibilities, mixing planning with doing. Here are three things we learned;

1. Make time to look back and think big- It’s very easy to get wrapped up in meetings, to do lists, testing skype and (ack!) e-mail. The volume of information pushed, pulled and programmed into our modern work day is astounding. This has the effect of making us feel productive by pushing e-mails around as we find satisfaction in a clean inbox. But a clean inbox, a business does not make. However, by taking a step back and turning off the digital world for a bit, we can truly connect with our trajectory in a way that is meaningful. On Saturday, David, Arin and I did just that. We spent the day with our computers closed and reviewed the past few months of AgilityFeat. By giving ourselves the space to think and discuss, we not only made better decisions but we were able to truly explore opportunities, raThe Lab at work!nk them against one another and come up with a list of experiments to test our assumptions.

2. Experiment, now!- On Sunday we invited the team over for a lab day. Our team of entrepreneurs is always eager to explore business ideas so we decided to spend the day spit-balling and building experiments. We spent a few hours continuing the customer development work we started in Tamarindo a few months back and then divided into teams to work on experiments that we wanted to run. By the end of the day, we had a much better definition of our customer segments and 3 experiments up and running. Not bad for an afternoon!

3. Experiments are fun- Many of us have spent large parts of our careers following best practices and conventional wisdom. While there is certainly a great deal to be learned from the experiences of others, there is no substitute for testing an assumption in the real world. Validating ideas not only lead to better information but it’s fun to run experiments because no one is expected to know the answer.

Now you probably don’t need to go all the way to Costa Rica to take a step back from your business (but I highly recommend it, just make time for the beach too).  However, it’s critical for all businesses to make the time to talk without distractions. Getting away physically helps but the key is to turn off the constant flow of information that is our digital lives. By creating the space to think big and test your assumptions, you can make incredible progress in just a few short sessions.

 

March 21, 2013

Learning to accept simplicity

Posted by Arin under Agile | Tags: , , |
Comments Off 

airheadslogoRecently I was in a meeting with one of our clients at AgilityFeat. The project lead at the client made a simple, but very powerful statement as we presented an assessment and proposal. “One of our challenges is that we need to learn to accept simplicity.”

I love simplicity, and breaking complex systems down into smaller parts. It’s the most important skill I learned in engineering school.

Some of my favorite things in life are simple. I like to ride motorcycles, but I don’t like the real showy or fancy kind.

My wife and I own a couple of old BMW motorcycles that are referred to as “Airheads”. They are called that because the engine cylinders stick horizontally out the side of the engine, and are cooled by air instead of oil. That makes the design of the engine much simpler.

This is not my bike, but it looks very similarNot everyone likes the look of those engines, but they have a loyal following of people who say that the simpler design makes them a much more reliable motorcycle. My 1973 R65/5 (black with white pinstripes of course) is now 40 years old and still a great bike.

Well, let me be a little more honest. My bike is still a great bike, but it doesn’t run great because I work on it, and I’m just not a very good mechanic. But when I’ve taken it to friends with real mechanical skills, they comment on how easy it is to work on and maintain. No doubt they are wondering why a smart guy like me can’t do it myself.

Part of my problem is that I’ve hacked on it too much. I stripped the engine down to replace the clutch and never put it back together properly. I’ve let parts of it deteriorate like the left hand mirror whose threads are stripped and allows the mirror to spin at higher speeds. I did a poor job of rewiring the bike once when I added a sidecar to it and now the electronics are a mess.

My wife is much smarter and doesn’t let me work on her Airhead. Not surprisingly, her bike is much simpler and it runs better.

Enough about my bad mechanical skills, the point here is that usually the simplest design is the best. However, accepting that is easier said than done.

Our client employs a lot of smart people. However, just like I did to my motorcycle, they have overcomplicated it. They cut and pasted code and processes multiple times because they didn’t have the time to architect a more flexible system. They tried to bolt on third party and open source systems without integrating them in a way that maintained user experience.

Is your company in the same situation? Are you making things too complex?

Here are a few tips that have helped us, and our client:

Tip #1: Question assumptions

It’s great to talk about the pain points of how users are doing things now, but you need to back up further and understand the overall goals of the users. They may be blinded by their current experience and the current system they have.

Don’t just map out the business process as it’s done now – look for the commonalities among disparate but similar business processes, and simplify them. Question the implicit assumptions behind how things are done now.

Tip #2: Listen to the real customers

If you are trying to convert someone’s manual spreadsheet process into a database for example, it’s easy to think of the company’s internal staff using the spreadsheet as the only customers to it.

Don’t focus only on internal users, but also the actual customers of the company who may only interact with the system indirectly. That internal business process is still modeling interactions or touch points with real customers. How does it affect them?

In our case, we were able to identify that external customers were gaming the system that was modeled in the client’s current systems because it was too cumbersome. This created pain for the client’s customer service team as customers kept asking for exceptions to rules. By simplifying the process to focus on what was most beneficial to the external customers, we are also making the lives of our client’s support staff easier.

As a side benefit, it’s also making the software much easier to build, and therefore less expensive.

Tip #3: Use customer scenarios to test the process

After we thought we understood the problem, we identified a simpler process and the associated business rule changes that would be necessary. Our UX lead Mariana made a great set of user flows that showed how customers would interact with this new system, using very specific data points that allowed us to consider realistic situations.

Even though our client had a hint of where we were headed, they were impressed and the visual scenario made a big difference. It helped them visualize the results of the process and technical change.

Accepting Simplicity

It was this visual representation that triggered the client to comment, “One of our challenges is that we need to learn to accept simplicity.”

He liked what he was seeing, but was a little worried how others would react. The company culture is to worry first about the exceptions, before accepting that a simpler design could be better.

A big part of accepting simplicity is to separate yourself from the past and how you’ve always done things. That cultural shift can make it a road hard to travel, but is well worth it.

 

February 20, 2013

7 tips for when the going gets tough

Posted by Arin under Agile, Nearshore Agile | Tags: , , , , |
Comments Off 

Arenal Volcano, from manueb on flickr http://www.flickr.com/photos/manueb/7159742363/sizes/z/in/photostream/Not every project is going to run smoothly, even in the best of teams. We have a great team here at AgilityFeat, and we’re very selective when choosing our customers, so our projects tend to be very successful.

But every team is going to hit bumps in the road sometimes, and we’re not immune to it. Recently we’ve had two projects with very important deadlines and ambitious agendas. One in particular also has a tight budget. As if that wasn’t enough, these important deadlines on separate projects ended up being right next to each other.

Sound like a recipe for disaster? It was definitely fraught with danger, and I’m not boasting when I say that many lesser teams would have failed in spectacular fashion. At this point, we’ve navigated the dangers and both projects are doing well.

No matter how good your team, process, or customers are, you’ll hit turbulence too. Here are seven tips we have learned:

1. Keep communication clear and open

When things start to turn ugly, development teams have a tendency to clam up. They invite the product owner over to their desk less often, the mood at standups gets more sarcastic or somber, and the whole team is ignoring the elephant in the room: “We’re going to be late, and we all know it. I just don’t want to talk about it yet.”

Team leads should be in constant communication with stakeholders, and you can’t spare them the bad news. You don’t have to rush to them in a panicked tone every time something goes wrong, but you also need to remember that bad news does not get better with time.

Keep the communication open amongst your team and with your stakeholders. Keep the tone unemotional, rational, and make sure everyone is well informed. At least everyone will see the bad news coming, which allows stakeholders to quietly plan for it.

2. Align team incentives

What are the constraints on your project? Is it features, a budget, or a timeline? Whatever it is, make sure the whole team understands the constraints and align their incentives with that.

I recently had a developer tell me that “Oh, I didn’t realize this project was fixed price. I would have handled that differently.” He didn’t realize the project was fixed price because he is paid hourly. It’s not that he is wasting time or anything, but his incentive is to build the best software he can, regardless of how long it takes. But our client was judging us against a fixed budget, and the team was not aligned to that.

Ideally the team gets compensated when and how the business gets compensated, be that fixed price or hourly or whatever. That’s not always feasible though, but I have learned that the full team still needs to understand what will make this project successful and profitable for the business as a whole.

3. Reassess priorities and constraints regularly

At the beginning of every project, I ask clients what is their most important constraint. Budget, schedule, or features? They only get to give one answer, and we plan around that. I also ask what their most important priorities are for the project – what features or goals will make this successful?

It’s important to remember that all of those are subject to change. As the original deadline nears, don’t assume that everything is still the same as when you started this project months ago.

Because you’re keeping open lines of communication with the customer, and sharing the good as well as the bad news, your customer may change their priorities. Continually revisit priorities with them, and ask questions like “So our top goals for the deadline next month are still X,Y, and Z, in that order, right?”

At the risk of being annoying, you should confirm those priorities regularly, and then make sure you actually complete those features in priority order before moving to the next one. Don’t work on X, Y and Z all at once. If you’re late and none of them are done, then you are guaranteed to have an upset customer.

But if you can at least get X and Y done, and you are only late on Z, the customer is much more likely to be forgiving. They might even ease one of the project constraints, like budget.

4. Communicate impact, but stay flexible

If you’re working in an agile fashion, then you have a process that encourages the customer to constantly add new work to the backlog and suggest revisions and improvements. That’s great, and you should encourage that because it makes for happy customers and better software.

But those frequent changes can be stressful when you are nearing the all important deadline or budget cap. As it approaches, you will need to communicate the impact of those changes with the customer and constantly ask for feedback on priorities.

A good customer won’t mind a discussion like this: “I realize that you would like to add more stuff to feature X, and I’m fine with that, but is it okay if we make that a lower priority? Since X works as it is now, we can finish up Y and maybe Z first, and then we’ll come back and make the additional improvements to X.”
By communicating the impact clearly to your customer, providing them with options, and empowering them with a choice, you are setting up a collaborative tone where you can negotiate as the deadline draws near.

5. Deal with contracts diplomatically

If your stakeholders are internal to your company, then this might not apply to you. But if you’re a service provider like AgilityFeat, then contracts are a necessary evil and will guide the relationship with your customer.

Take a moment and think about how your contract model is affecting the dynamics of your relationship with the customer.

A fixed price and fixed scope contract seems to favor the customer on the surface by removing perceived risk of budget creep. But it also creates a confrontational dynamic where both sides have an incentive to jockey for power over the other.

A Time & Materials contract seems to favor the service provider on the surface because they get paid fairly no matter how long the project takes. But it also creates fear and doubt in the customer’s mind. Can they trust you to get it done on time, or is this going to cost me a lot more than you estimated?

Regardless of the contract model you are using, remember that it will have a big impact on how you and the customer deal with each other during the most stressful phases of a project. Be diplomatic when dealing with the topic, and don’t rush to say things like “But that’s scope creep and not in the requirements!”

Be open about your concerns, but try to deal with them in a flexible manner that creates a win-win for everyone. The customer gets most of what they want and you don’t go broke doing it.

6. Assume best intentions

Contracts are a good lead in to this next bit of advice. No matter how tough the going gets, do your best to maintain a level composure with the team and the client. Getting angry is a valuable communication tool, but it can only be used sparingly.

Assume that everyone has the best intentions, even if you disagree with decisions they’ve made.

Even if you don’t actually believe it to be true, pretend everyone wants this project to succeed. They almost certainly do, and you’ll remember that too if you take a deep breath. In stressful times, we may not all behave exactly the way we want, but try to look past that and recognize that everyone is doing the best they can to be successful in a difficult situation.

That bad decision someone made is probably not because they are trying to deep-six the project. They probably just don’t understand the big picture, and as a leader you can communicate with them better to make sure they know what is expected of them and when.

7. Agile teams need leadership too

Self-organization is one of the key principles of agile. Good agile teams are made up of people you can trust to do professional work and to make good decisions. If someone is only comfortable when being told exactly what to do, they are not a good fit for an agile team.

When you build a team of highly skilled commandos, like we have at AgilityFeat, then it’s easy to forget that they still need leadership. Agile teams still need a visionary leader who can set the tone and the goals for the project. Sometimes they also still need the strong leader who can redirect them when they go astray, or even give them a loving kick in the butt when standards are not being met.

When the going gets less tough…

If you keep these 7 tips in mind when things are rough, then eventually you’re going to make it to the other shore and things will improve. At this point, don’t forget to take a moment to breathe and lick your wounds.

Last week after getting through a tough phase on multiple projects, we bought massages for everyone on the team. It was a small gesture to show our commandos how much we appreciated them. They rallied together during a tough phase, and in the end, we became a stronger team and created happy customers.

There’s still a lot more work to do, but it’s nice to see the sunlight again and know that you are a little wiser for the experience you just went through. That’s how a great team deals with adversity.

 

February 18, 2013

4 ways Perfection is killing you

Posted by Arin under Agile, Lean Startup, Startups | Tags: , , , , , , |
Comments Off 

This is what angry customers might look like. Don't make them angry.Whether you are a bleeding edge startup or a large corporation running agile teams, here are four ways that you may be abusing agile concepts and letting perfection kill your chances of success.

Product Owner Perfection

In an agile team, the Product Owner (PO) is the “voice of the customer” to the development team.  They play an incredibly important role in the success of the project.  The PO will end up writing most of the user stories that describe the features the team will work on next, and equally important, the PO sets the priority of what to work on next.

Implicit in this prioritization duty is that the PO is also the person who says “go” and approves the deployment of new functionality to production.  So what happens when your product owner keeps saying “just do this one more thing and then we’ll deploy”? 

For a startup, this sort of “all or nothing” attitude will not just kill your project, it will destroy your business.  It will take you so long to satisfy that perfectionist Product Owner that you will end up missing your window of opportunity with customers.  Somebody else is going to build a less perfect version of your idea first, and they will win the customers before you even have a chance.

For a large company, Product Owner perfectionism is still bad.  It means that your schedules are going to slip, major initiatives will not be completed on time, and your agile team is going to look a lot like a very slow waterfall team.

Developer Perfection

Good developers are an essential part of a successful project, and so it’s easy to go overboard and hero-worship their technical prowess.  But sometimes that desire to be the best developer out there can kill your project.

Developers (in general) are very creative folk who take immense pride in their work.  The best ones also really enjoy playing around with the latest technologies and trying new things.  But even if you’re a non-technical leader, you can’t give them free reign or they will have so much fun building shiny objects that they will never get the project done on time.  I’m a developer by training … trust me on this.

Even if you can’t debate the details of technical decisions being made, you need to set clear boundaries for the team to work within.  If there is a fixed date you must have the functionality done by, communicate that from day one.  Make it clear that meeting that date is the most important thing, and you are willing to compromise on anything but that date.  The same is true for other project constraints such as budget or feature sets.  You can’t have everything, so pick one constraint at the beginning, and make it clear to the development team that is the constraint that must be met above all else.

If you’re project has no constraints (yeah right), then make one up.  You need to give the developers those guardrails.

Scrummaster Perfection

Are you agile enough?  I mean, are you truly Agile?  If you hear this a lot from your newly minted and Certified Scrummaster, then you are at risk of Scrummaster Perfection.

It doesn’t have to be agile methods like Scrum or Kanban, or even the Scrummaster as the culprit.  Perhaps we should just call this Process Perfection instead.

Any process should be judged by the results it produces.  Not the process results (aka documents and meeting rituals), but the actual value delivered to customers.  Are customers happier with us than they used to be?  Are they getting more value from us than in the past, and are we delivering that value more efficiently?  Than our process is working.  That’s all that matters.

It just so happens that agile methods tend to do the best job of delivering more customer delight more efficiently.  That’s why agile is popular.  But they can be abused and if you spend all your time worrying about adhering to some agile book you read, then you will not deliver much customer delight.

Please remind your Scrummaster and team that agile methods are not meant to be prescriptive – they are a set of guidelines and principles.  You can (and should) constantly change your process in order to better serve your customers.  As long as you are still adhering to the basic tenets of the agile manifesto, you can declare yourself agile.

From your customers’ perspective, they don’t even need to know you’re agile.  They don’t give a rip.  You should just be doing a better job for them than you used to.

Quality Perfection

I’ve already complained about perfectionism from our product owners, developers, and scrummasters, so who’s left for me to alienate?  I know, let’s pick on testers for a moment!

I am all for testing, both manual and automated.  I am also all for high quality software.  I hate it when a bug keeps me from doing something important on another company’s web site, so why should I accept anything less on my own?

The thing is … all bugs are not created equal. If I can’t accomplish core web site functionality on the most commonly used browsers, then yes, that bug has to be dealt with quickly and should be caught before it’s deployed to production.

But should bugs in older browsers keep you from deploying software now?  It depends on your customer base, but probably not.  You can probably live without a fully functional site in IE 8.  Or you can change the code for that browser to be simpler and not have as rich functionality.

If the bug is in an obscure part of your administration console that very few users notice, then maybe it doesn’t need to be dealt with right now.

The point is, many testers have a problem with perfectionism.  I find this to be particularly true with testers in large companies because in the past they were judged by the wrong metrics.

A tester should not be judged by how many bugs escaped the test environment and made it to production.  A tester should be judged the same way as the whole team – are we making our customers happy by getting them the right features at the right time with an appropriate level of quality?

Unless you’re building safety-critical systems, you don’t need to deliver perfect quality.   You only need to deliver just enough quality, focused on the right areas.

Is your perfectionism holding you back?

What is keeping you from deploying that code today?  What is keeping you from making that deadline next week?  It may just be endemic perfectionism in one or more parts of your team.  Go find that person right now and reset expectations with them before it’s too late.  You can still save that project if you act now!

 

February 9, 2013

Improving our Sprint Zero process

Posted by Arin under Agile, Nearshore Agile, Projects | Tags: , , , , , , , |
Comments Off 

Project on-boarding is key to success

Step2Step two is always a question mark. It’s one of my favorite meme’s on the internet. Some joker on a message board will say they have a great idea, and their business plan usually goes something like the image on the left.

It’s a light hearted way to poke fun at other people on the internet when they act like they have a great idea that will make them millions, but no idea of how to implement it. Or this meme is used when you want to mock someone else when they clearly have a hare-brained idea.

Coming up with ideas is easy. I have a folder full of them on my laptop. I’m not saying they are all profitable ideas, but if you pay attention to the world around you then coming up with ideas is the easy part.

Step 2 is the hard part.

How do you take that great idea and make a profit with it?

This is the part where companies like AgilityFeat make a big difference. You probably have the idea, and you may have a good plan to make it profitable, but you need someone to implement it for you. And you are probably looking at outsourcing the implementation of this idea because it’s not your goal to become a software development company. You just need us to design and develop your product so that it will turn a profit.

Don’t miss the big picture

DavidMarianaDrawingThe problem with our process to-date at AgilityFeat is that we’ve realized we were paying too much attention to the day-to-day part of our agile process (stand ups, planning sessions, demos, retrospectives, etc), but not enough attention to the kick-off process.

One of our current customers helped highlight this problem to me last year when he said that “You guys have missed part of the big picture of why we are doing this.” That hurt a little bit, but I’m really glad he said it.

When we gathered our team in Tamarindo Costa Rica for our DareToBeLean workshop, fixing this on boarding problem was one of our main goals.

For us, Step 2 of making a profit really has a couple of sub-parts. We’re getting the 2nd half right. It was the first part that needed some help, where we make sure the whole team understands the customer’s needs. It’s not good enough to be really efficient at building the wrong thing!

Our process for new projects

IMG_9107We spent some time drawing out what an agile on-boarding process looks like for us. Here’s the sketch we made on a white board, which like all good processes ends in profit: for us and for our customers.

After we revised and agreed on the sketch, the whole team signed it. That’s not to indicate that this is set in stone however. Like all good processes, we expect this one to change and adapt over time as we continue to improve. But this is an excellent start.

Here’s a walk through of our new project on-boarding process…

Sales process

During this pre-project phase, generally just the AgilityFeat executive leadership is involved. Either myself (Arin), David, or Ford probably brought in the project as a lead, and once it seems to be a “warm lead” we will let the others know about it and decide if it’s a potentially good project for us.

As part of this vetting process, we are interviewing the client as much as they are interviewing us. We want to know that it’s a good fit for us technically, financially, and contractually. Ford, David and I comparing the prospect to our typical customer segments. This segmentation drives how we will structure and price the project.

Once we have a contract in place, we move onto the kickoff process…

Kickoff process

BuildConfidence

The goals of the kickoff process are twofold:
1) Build the Team
2) Build Confidence with the Client

The kickoff process is where we start to bring in other members of the AgilityFeat team. Mariana, Gabriel, or Daniel might start to look at the project from a User Experience, Visual Design, or Marketing/Branding perspective. David or I might start to look at the client’s existing code or technical architecture along with one of our senior developers.

The key thing in this kickoff process is knowledge transfer. Up to this point, Ford, David, or I have been the only ones talking to the client. Even among the three of us, it’s probably just one of us who has been responsible for nurturing that prospect into a customer.

Now we have to start transferring that knowledge to the rest of the team, as well as validating to the client that we understood their needs. This is one are we agreed that we have fallen short in the past.

To build confidence with the client, we validate our understanding of the project through a lightweight Agile Project Charter. This document is based on interviews with the client to make sure we understand the true pain point that is being solved.

The document must be lightweight and to the point – this document only serves as a way to validate conversation and in itself delivers no other value. The point is to get to writing code very soon.

An Agile Project Charter

ProjectCharterIn our Agile Project Charter, we focus on these areas:

1) Restating the client’s goals for this project, and the pain point that we are trying to solve

2) Stating the biggest technical risks that need to be addressed (this could affect how we staff the project, or it could address which features we need to work on first)

3) Stating the biggest business risks that need to be addressed (this is basically the first round of a lean startup process. What assumptions have been made about their customers or the product? What can we do to validate those assumptions, and then quickly test proposed solutions?)

4) What constraint is most important in this project? In any project, the contractor and the client have to balance three things: Budget, Scope, and Timelines. We validate with the customer which one of these things is most important, and cannot be violated. There can only be one answer, because the other two may have to adjust to accommodate it. This decision is very important, because it guides how the contract is structured and will help us to know what the most important success criteria is for this project.

Sprint 0

At the end of the kickoff phase (which can be anywhere from a couple days to a few weeks depending on the project), we are ready to move into Sprint 0.

Agile teams work in time-boxed iterations called “Sprints”, which are typically 2-4 weeks in length. We actually prefer to work in very short 1-week sprints. This forces us to divide the work into smaller pieces and to demo to our customers more often, both of which are good things when dealing with startups and distributed teams.

Sprint 0 is an exception for us. In our experience this phase of work takes 2 weeks, but it positions us to work efficiently in 1 week sprints afterwards.

During Sprint 0 there are as many as 5 different things going on in parallel:

1. Epic Creation

EpicCreationThe UX lead and/or the Scrummaster are working with the client to define the “Epics” to be worked on in this project. These are the high-level user stories, or feature descriptions, that the team needs to work on.

This is done in close coordination with the client because this list must be prioritized. By the end of Sprint 0 we should have a complete and prioritized list of Epics.

The highest priority epics on that list will also be broken down into smaller stories for the first development sprint.

2. Branding and Design Language

BrandDesignThe Visual design lead is also preparing for the first round of development. We prefer for our developers to start each sprint with all the visual design artifacts that they need.

This includes mockups, cut up graphics, and often also the CSS/HTML layout. For that to happen, the UX and Design have to get ahead of the development team.

As part of those first designs and mockups, the Visual design lead is also working with the customer to come up with a consistent “look and feel”, or brand, to the website. Any logo and theme designs are worked on and approved with the customer during this phase.

3. Information Architecture

InfoArchitectureThe UX lead(s) are also working on something called the “Information Architecture” for the application.

In traditional projects this can be a very laborious process, but we emphasize doing it in the most lightweight way possible.

This architecture will define the overall flow of the application, how users and data will traverse the system. This architecture is another way for us to confirm that we understand the customers’ needs, and it also serves as a guide to the upcoming design and development.

The Information Architecture is the “big picture” in flow chart form.

Based on the information architecture and the priority of epics and user stories, the wireframes for the first sprint of development will be created.

4. Walking Skeleton

WalkingSkeletonRemember how in the project charter we identified the biggest technical risks to the project? These could be things like interacting with a client’s existing API’s, web services, or databases. It might be integration with a third party application.

The development team will identify a “thin vertical slice” of functionality with the customer that can be developed which will prove the project is technically feasible.

The end result of this is not something which is pretty or even usable by the end customer. But it shows that we know how to connect the key blocks together, and it also helps us get the technical plumbing in place for the actual development to start.

5. Testing Plan

TestingPlanAgile teams don’t create heavyweight testing plans or uber-detailed testing scripts.

But nonetheless we do need to identify the main functionality to be tested.

Our testers will be going over the user stories and epics as they are created, and will begin to do some lightweight and part-time planning for how to test the code.

Co-located or virtual?

Most of the AgilityFeat team is in Costa Rica. Most of our clients are in the US. And the vast majority of our projects will be conducted virtually. The Sprint 0 phase is an ideal time to get at least part of the team together.

The client can come visit us in Costa Rica for a week or two, or we can send one or two team members up to the client’s location.

The AgilityFeat team on the beach in Tamarindo, Costa RicaEither way, we find this to be invaluable and a strong predictor of project success. The chance to get to know the team in person, build up personal relationships, and have very efficient conversations about the project vision is well worth the cost of a couple airline tickets.

We’ll be glad to make sure you see some of the beauty and “pura vida” of Costa Rica while you’re here!

Estamos Listos – “We are ready!”

At the end of this two-week Sprint 0, the team has a solid understanding of the project and how our customer is going to judge if we’ve been successful.

We have a common vision, we’ve built the team, we’ve prepared the first wireframes and created a product backlog of epics and user stories. We’re now ready to start running short agile sprints or lots of lean startup experiments for your product.

What are you waiting for? Let’s jump into “Step 2” and kick this project off!

 

December 28, 2012

A #leanstartup and #agile tour of @Twilio

Posted by Arin under Agile, Lean Startup, Startups | Tags: , , , , , , , , , , |
Comments Off 

Who’s ever heard of a telecom lean startup? That’s sort of what Twilio is, and it’s a pretty cool company and interesting case study.

When I attended the LeanStartup.co conference in San Francisco recently, one of the parts I was most excited about was the tour of area companies. The first tour that I did was at Twilio, and it was very interesting from a lean startup and an agile engineering perspective.

What exactly is Twilio?

Screen Shot 2012-12-26 at 1.17.26 PMTwilio.com tells you that they “bring voice and messaging to your mobile applications.” They have built a great API that developers can use to quickly and easily provision new phone numbers, and build in voice and text messaging automation to your applications. That’s even cooler than it may sound, and if you setup a trial account with them then Twilio will quickly give you a new phone number and guide you through a short tutorial. In less than 15 minutes, I had setup a customer voice mail message on my new phone number, send myself text messages from that number, and setup auto return text messages from that phone number. All of this was done using extremely simple code that they gave me.

Twilio’s guided tour of their features is probably the best I’ve ever seen. I got a quick sense of their capabilities in a very short tour, and I was impressed with how simple they made it look. They have taken an intimidating topic, broken through the learning curve barrier, and got me hooked. Within ten minutes later I was asking their sales team if they have any phone numbers available in Central America since that is where I do a lot of business. I’ve got ideas brewing for how to use Twilio!

Cool office? Check.

2012-12-04_09-09-41_359Talk about Twilio has been trending in the development community for a while now, so I was excited to see their office and meet some folks. Their office feels like a startup. They have the obligatory indoor bike racks, big monitors, and open room feel.

The desks are all handmade by the team members out of doors and cheap lumber. They started out with a lean budget for office furniture and see no reason to change it. It actually looks good, and beats the used-door desk I had in college. The conference rooms are all named after famous technical people who have inspired them, like Steve Wozniak or Hedy Lamarr (an Austrian actress and scientist who invented frequency hopping).

We sat down at large tables (hand made of course) in the kitchen area. Joel Franusic (@jf) is a developer evangelist and gave us a great demo.  Then Kyle Conroy (@kyle_conroy) talked about engineering at Twilio.  Kyle is a former intern at Twilio who is now a developer there.

2012-12-04_09-57-30_437They gave us a great tour of the API, similar to what you’ll see on the website. Joel was getting our phone numbers from people on the tour, and sending us text messages from his console in seconds. It was an impressive taunting of the demo-gods, but it went flawlessly and Twilio has a lot of confidence in their API. It’s the keystone of their business.

Agile Engineering? Check.

How do you develop that much confidence in your software? I asked about agile engineering techniques like test automation, and how they use QA teams. Kyle’s answers were very interesting. Twilio has no QA department, and no testers. They preach code ownership and so the developers are responsible for all testing before it goes to production.

They do lots of automated testing, and those tests run regularly under Continuous Integration servers so that they know how stable the main branch of the code is. They have tried Cucumber, which is one of my favorite tools for automated acceptance testing. For them though, Cucumber was too verbose. They are mainly testing an API, and they felt that the “Given/When/Then” syntax was simply too cumbersome.

I can see where that would be the case. One of the big benefits I think of Cucumber is how it gives you “plain English” executable tests that you can show to your customers. However, in Twilio’s case, everyone understands the technical talk, because serving developers is everything to them. So the extra verbosity of Cucumber is not worth it.

The development process is automated at Twilio so that they can do frequent deployments whenever the developers have small changes ready.

Applying Lean Startup stuff? Yeah, pretty much.

Those of us on the tour also asked Kyle and Joel about their application of lean startup methodologies to their business model. Twilio didn’t start out applying those concepts, but they have done more of it over time.

They pointed out that they suffered some in the past because they had not applied lean startup methodologies or customer development. They spent a long time building a new product called Twilio Connect because they were sure they knew what developers wanted. After investing a lot of time, it was not received well when they launched it.

How long should your betas be? Although I’m not fond of the term beta, Twilio has found that they have to be careful about making too frequent changes to an API. Developers expect you to maintain reverse compatibility, and you can’t change the API all the time or you will break companies’ production code and alienate customers. It’s not as simple as a UI driven company where you have much more freedom to change the look and feel of your website, or make constant small tweaks to the user interface.

2012-12-04_09-04-52_718So Twilio has found that long beta cycles work well for them. This gives developers a long lead time to start testing with the new features. Twilio tries to communicate clearly that the code is not ready for prime time yet, and so they have the freedom to change the new API calls significantly during the beta period based on feedback from early adopters. This allows them to get very valuable feedback early on from developers, without jeopardizing the stability of the official API.

Once they have a solid understanding of what the development community wants in the new features, then they can publish them into the official production version of the API.

Metrics? Check and Double-check!

One final conversation that came up is very important to those of us interested in the application of metrics to lean startups. Twilio originally did a lot of funnel analysis to get more people signed up for the service. But they realized that they were over-optimizing the sign up process, and the use of their API and customer retention was bad. In other words, they were getting more people to sign up, but they were the wrong kind of people. Some people thought they were signing up for a consumer focused VOIP solution, not a development API.

Twilio had to tweak their metrics to focus on what really matters to them: use of their API. Lower sign up conversion rates are acceptable if it means that the people who do sign up are actually using the API more. Metrics matter a lot in lean startups, but make sure you are focused on the metrics that actually matter to your core business model.

Go check ‘em out…

Screen Shot 2012-12-26 at 1.24.27 PM

By the time I finished this blog post, their sales team had already got back in touch with me. That’s pretty great for the day after Christmas as I was writing this. While it turns out they don’t have phone coverage in Costa Rica yet like I hoped, there is still so much cool stuff to play with that I will have to make some more time for fun holiday hacking with Twilio. You should too!

 

Next Page »