Board your plane paper-free

I’m in my hotel room and I realize I should check-in for tomorrow morning’s flight home. I’m too cheap to pay extra for the hotel’s WiFi service. All I have is my phone and its web browser. I bring up the airline’s mobile web site, and a few minutes later I’m all set.

Pain free, 100% mobile check-in and boarding is here. Lufthansa does it really well. On your phone, browse to m.lufthansa.com. Enter your name and confirmation code, and they’ll let you select your seat, just like on the desktop web site. Confirm your check-in, and they’ll send you a text message or email with a link to your boarding pass.

Show your phone with the boarding pass and the 2D bar code on the screen to the nice security guard at the airport terminal. Place your phone on the 2D bar code scanner to board the plane. Enjoy the free German chocolate onboard. It couldn’t be easier.

Pro tip: Save your boarding pass on your phone’s local memory in case you can’t get a network connection at the airport. It’s really embarrassing when you hold up the line trying to download the bar code to show the nice security person that it’s a real boarding pass.

Pro tip #2: Peak around the corner at your Lufthansa gate, and you’ll find the coffee machine. Enjoy a free espresso!


8 ways to kill Agile

Want to kill your high performance agile dev team? Make it hard for them to deploy to Production. Set up a bureaucracy of approval gates, review boards, committees, and meetings. Make sure they miss their deadlines and disappoint their customers.  Control them until they can't get anything done.

Don’t let them deploy to their Staging environment. (1) Make them present their product to a VP for software maturity approval. (2) Then make them ask permission from the local change approval board. It doesn’t matter whether they approve, because you’ll (3) make them seek additional permission from the global change approval board. Ask for proof that all of their customers formally signed off; never mind that their customers run their own bureaucracies and can’t tell you who is authorized to approve. (4) Finally, make them get permission from the global Ops approval board. It doesn’t matter that the team practices DevOps, and that their Ops team is integrated into their Dev team--the global Ops approval board needs to rationalize their existence.

All that just to deploy in Staging, simply to rehearse Production deployment.

(5-8) Repeat these four formal approval gates for Production deployment. Ignore the fact that your high performance agile team knows what it’s doing and does it well. Just make them jump through the hoops. Eventually they’ll get tired, stop fighting it, and slow down. They’ll bow to your pressure and stop their frequent delivery of new value to their customers.


Instead of handcuffing your high performance agile team, how about helping them deliver value to their customers? Try asking them for one concise formal statement of readiness. They already produce it as part of their Definition of Done.

Nominate a single person from Dev and a single person from Ops to be responsible for deciding whether the product is ready for Staging or Production deployment. These guys cares about getting it right--they get fired if the team deploys something that sucks, something that yields downtime for their service or for their customers’ services.

The DevOps team wants to be great. Champion their cause, don’t get in the way. Help them deliver value to their customers.


Why can't we be as good as Nokia?

Nokia has a great reputation in the Agile community.  Why can't we be as good as Nokia?  It turns out we can.  Here's my presentation from the Nokia Agile Community Autumn Meet 2010 conference in Helsinki, held on December 7.  Use the Nokia Test, a simple value stream map, and Theory of Constraints, and you can transform your dev team from good to great.  Apply Scrum rigorously, and success just happens.

What do you think?  Want to transform your team from good to great?


My Product Owner will kick ass

My Product Owner is my business owner. He deserves all the credit when we succeed, and all the blame when we fail. He has the most important role in my Agile team. He should be the highest paid, because he takes the greatest risk: if he fails, he’s fired. So says Mike Dwyer, and I agree.

My PO will run my business unit. He will be a courageous, ballsy, gutsy entrepreneur. He will lead my dev team as if it were his personal business, with his own money on the line. My team costs around $2.5million per year. He will embrace this responsibility and direct our spending that money wisely.

My PO’s success will be measured by the amount of business value we deliver into production service. If we don’t deliver what he promises, he fails. If someone on another team blocks our production deployment, he fails. When we deploy in production, our PO succeeds. When our service approaches 100% uptime, he succeeds.

My PO will be our head sales guy. He will be our customers’ best friend, building deep relationships with them. He will schmooze. It’s his job to take them out for beer or dinner. He'll play golf with them and give them tickets to a show or a big game. He will get them to trust him.

My PO will know what our customers really want. Is it high availability? Is it new features? Is it guaranteed backward compatibility? He will listen and understand. And listen some more.

My PO will be a visionary. He will be a domain expert with a long term vision for our product.  He will guide us from the big picture to the nitty-gritty details. He will care about every pixel in the UI.

My PO will sell both the vision and the detail to our customers. He’s already their best friend, and he spends a lot of time listening to what they want, so this should be easy. And when his vision isn't exactly what they ask for, he will convince them that it’s what they meant to ask for. He’ll sell our road map to them and convince them that every small release is a step on the way to what they want. He will turn our customers from antagonists into allies.

My PO will sell his vision to my dev team. He will inspire the team to build what our customers want and need. He will introduce our customers to the team, and the team to our customers, so they understand and trust each other.

My PO will define every product backlog item in extreme detail. Every backlog item will be ready-ready. I will know that it’s what our customers want and need before we start building it.

My PO will show up. He will attend our estimating meetings and explain the backlog items to us so we can estimate them well. He will help us on sprint planning day, explaining the goals and the details, and guiding us to choose the right backlog items and the right amount of work. He will take part in our daily scrums so we don’t go off track. He will watch our sprint demo and applaud us when we get it right or tell us we suck when we get it wrong.

My PO will win and bring us along with him. My PO will kick ass.


Hardening sprints? Sorry, you’re not Agile.

We do a series of sprints to build our product, then we do 4-8 weeks of hardening sprints to really test our code and get the bugs out before we deploy it in production.
Guess what? You’re not Agile, and you’re not doing Scrum. You are using the jargon, maybe because it’s fashionable, or maybe because you’re Agile practices are misguided. But you’re not Agile.

In fact, you are doing Waterfall, masquerading as Scrum. You probably did a lot of big up front analysis and design, followed by a coding phase (your early “sprints”), followed by a testing phase (your “hardening sprints”). You are masquerading as Scrum by using the Scrum jargon: terms like Sprint, Burndown, and Product Owner. You are applying that jargon to Waterfall. Some people call this Cragile. I call it Shcrum.

The problem with “hardening sprints” is that you are lying. You make believe your imaginary burndown during the initial sprints shows that you are approaching Done. But it’s a lie--you aren’t getting any closer to being ready for Production until you begin your Test phase. You wrote a pile of code that you didn’t test adequately. You don’t know how good it is, you don’t know how much work you have left to do, and you don’t know how much longer it will take, until you are deep into your Test phase.

I don’t mind that you’re doing Waterfall. Just don’t call it Scrum or Agile. And don’t do it on my team, because I don’t want my team to suck.

If you need “hardening sprints” before you can deploy in Production, you’re not Agile, and you’re not doing Scrum. What is stopping you from being Done at the end of each sprint?


A fire hose of programmers, a straw of testers

The programmers write new code so fast, the testers can’t keep up. It’s like shooting a fire hose into a straw. It doesn’t matter how fast the programmers shoot new code out of the fire hose, because the testers have to get it all through the straw before we can say it’s Done and deploy it in production.
You have a problem
The problem is easy enough to recognize. You have a killer programmer team, but the test team can’t keep up. You have a bunch of features that were coded, so you think they are almost done, but the features haven’t been tested yet, so you can’t deploy them to production. You’re frustrated that you can’t get stuff out the door.

And it just gets worse. No matter how close the test team comes to catching up, the programmers keep adding new, untested code. It seems like you can never get Done, and you have no idea when you’ll get Done or how much more it will cost.

Your problem is you
You need to ask why. Make a list of reasons this is happening and think of ways to fix it. Here are some possible causes:

  • You have the wrong mix of players on your team: too many programmers, and not enough testers.
  • The test team is distracted. They spend too much time doing bug triage or preparing for future new features. They attend too many meetings. They spend too much time on customer or production support.
  • The test team has inadequate computing resources. Other teams borrow their test environments, totally blocking the test team. When the testers get their environment back, it takes too long to reconfigure. To make matters worse, components of the test environment are unreliable, with too little disk space or subpar network infrastructure.
  • The test team relies too heavily on manual testing.
  • Your release criteria (your Definition of Done) are so onerous that the team can’t ever be Done.

Fix it
Given that list of problems, the solutions seem obvious:

  • Stop hiring programmers--more programmers won’t help you get Done any faster. Add more testers, or make the programmers play tester.
  • Protect the test team from distractions. Your testers are the critical constraint--don’t let them do anything that doesn’t help them get Done. Other people can represent them in meetings or help with support issues.
  • Get the test team the computing resources it needs, and don’t let anyone else use those resources, for any reason. Stabilize the environment’s infrastructure. Manage the infrastructure yourself, so you can fix problems immediately instead of handing them off for another team to fix.
  • Automate!
  • Review your release criteria. Does every item add value? Does every item protect against low quality? Can you remove some criteria? Can you address the criteria earlier, as part of getting each story or sprint Done?

What are you doing about it?
Why can’t your test team keep up? What are you doing about the fire hose of new code shooting into the straw of testers?


Use the new Blogger tag cloud widget

Blogger has a new (to me) tag cloud widget that's way better than my old one. To install it, edit your blog's layout by clicking New Post / Design / Page Elements. In the Page Elements window, click Add a Gadget. In the Gadgets list, find Labels and click +. In the Configure Labels window, click Cloud, then SAVE. Save your new design, and you're all set.



People need mastery and purpose, not bonuses

Pay people enough that they don't have to worry about money, and they'll perform well. Don't bother with monetary incentives beyond that. Want people to perform better? Establish an environment that encourages mastery and purpose.

That's the essence of this great video from the nice people at the RSA. Thanks to Jeff Sutherland for the pointer.


See Damon Poole at Agile Boston tomorrow

Damon Poole will be at Agile Boston tomorrow night.  Here is a preview of Damon's talk:
KANBAN and SCRUM, Like Chocolate and Peanut Butter
You may have heard that Scrum and Kanban are mutually exclusive or that Kanban isn't good for large software projects. In fact, much as Scrum and XP play well together, so do Scrum and Kanban.
This session will introduce Kanban from a Scrum perspective, show how the Lean practice of "One Piece Flow" is the key to both, and look at how to mix and match Scrum and Kanban to fine tune a process that fits your circumstances. This will include: decoupling once-per iteration activities from the iteration, work-in-progress limits, and the concept of "pull."
Register for the event, and I'll see you there!


Sprint length: it's all about batch size

What is the ideal sprint length?

I've been thinking about this a couple of ways. First, what is your definition of Done? For my teams, Done means, concisely, it can be deployed in production, and people can use it world-wide.

Then, think about your minimum batch size. How much work do you have to do to be able to add some business value and be Done at the end of a sprint? In addition to implementing new stories, what other things do you have to do each sprint to be Done, and how long does that overhead take?

For my teams, two weeks is the right sprint length. At one week, our maximum batch size is approximately 0--we add hardly any stories of business value for it to be worth our time, given the other sprint-Done activities that we do each sprint. With a two week sprint, we can add value and get the system totally stabilized and ready for production deployment. More than two weeks isn't worth talking about, because we can get stuff Done in two weeks.


If you're not Done, you're not Agile

Done is the crux of doing Agile well. You can do all the Agile activities--the iteration planning, the daily standup, the burndown--and still suck. But if you focus on getting things Done, two things happen. First, you start to actually get stuff done, and you can recognize your success. Second, when you don't get stuff done, you know it, and you recognize your failure. When you know you failed or are failing, suddenly all your activities have focus.

When you focus on Done, your daily work has focus: get stuff done! Your daily scrum has focus: point to tasks on the board that you got Done yesterday and that you will get Done today. What is preventing us from getting tasks Done? A ha! Now we have focus, the ability to identify impediments, and the ability to remove them, every day.

When you focus on Done, your sprint has focus: get your sprint commitment done. Your sprint retrospective has focus: either we got the sprint Done, or we didn't. If we got it Done, what did we do that made us successful? Let's repeat those things in the next sprint. If we failed, why? What impediments prevented us from getting done? A ha! Now we have focus, the ability to identify impediments, and the ability to remove them, every sprint.

Done is the crux of Agile because Done focuses you on getting done, and on removing impediments and making improvements. Removing impediments and making improvements is the crux of improving your velocity and becoming a high performance team. The ability to get stuff Done is what Agile is all about.

If you don't know what Done means, you can't get anything done. What is your definition of Done? Is it the same as your customers' and managers' definition of Done? How does your definition of Done help you get stuff done, and how does it help you remove impediments and increase your team's velocity?


Scrum and Agile lack credibility outside our community

At the Scrum Gathering in Orlando, we talked about company management as an impediment to the adoption of Agile and Scrum within organizations. Within the Scrum/Agile community, we are all believers and advocates. We network within our community. We publish data that support the adoption of Agile and Scrum, and we trust the data because they come from our community.

We thought that part of the problem might be that company management lies outside of our community. Our community's studies, reports, and supporting data don't show up in the things they read. We wondered what it would take to get more crosstalk between our communities, and how to get our stuff published in places that have credibility in the management community.

I recently read The Business Value of Agile Software Methods by Rico, Sayani, and Sone. The authors do a good job documenting various Agile practices and their return on investment. It is a businessy book, and we can use it when we present to the management community.

What else can we do to engage the individual managers and the management community as a whole? What magazines should we publish in? What conferences should we present at? What else can we do to make Agile and Scrum part of the management community's vernacular?

(Crossposted as a LinkedIn discussion)


You're a loser. Get a job! (Part 3 of 3)

Don't change
In parts one and two of this three part series, I explored that you need to be prepared and that finding a job is your job.  Before you needed a job, you were doing a lot of things right.  Why stop now?  Keep doing the things that made you successful in the past, and you’ll be successful this time, too.

Daily routine
Treat every weekday as a work day, just like you used to when you had a job.  Wake up early.  Bathe, shave, and brush your teeth.  Dress for work.  Drink your coffee, eat your breakfast, and go to work.

Don’t be a loser
When you were working, you didn’t act like a loser, so don’t do it now.  Don’t stay up late watching TV and drinking beer.  Don’t roll out of bed at noon.  Work a full day, 9:00 to 5:00 every weekday, just like you used to.

Don’t get down
It’s easy to feel like a loser when you don’t have a job.  Your former coworkers were part of your social network; without them, you feel isolated and alone.  Keep your social bonds alive!  Go to industry events, meet new people, and reinforce old friendships.  Hang out with friends.  Make appointments for lunch, coffee, dinner, and beer with people in your professional network.

Continue doing the things that used to make you happy.  Watch funny movies.  Go to the gym, go out dancing, and do all the other things you used to do to stay physically active.  Don’t stay inside--get out!  Take the dog for a walk, watch him play in the park, and be friendly with the other dog people. 

This series
I hope you enjoyed this series, and I hope some of this advice helps you on your job search.  Don’t be shy--reread parts one and two, and let me know what works for you:
Part 3: Don’t change


You're a loser. Get a job! (Part 2 of 3)

Finding a job is your job
In part one of this three part series, we explored that you need to be prepared.  Part two is about the fact that finding a job is your job.  Don't act like you don't have a job, because you do.  You don't get a paycheck for it at the end of the month, but it is your full-time job.  

Know yourself
An important part of finding your next job is to know yourself.  Who are you?  What do you love to do?  Given your passions, what would be the perfect job?  Spend a few days introspecting.  Think deeply about who you are and what you want before you start looking, and then focus your search on the kinds of roles you want.  For myself, I think of things like, "I want to be awesome and help other people be awesome," and, "I love to lead tech teams, do tech work, and mentor, coach, and train people."  

Next, concisely describe yourself.  If you had only 30 seconds to introduce yourself, what would you say?  Make it clear and powerful.  Imagine walking into a store, asking what they sell, and hearing, "Um, I'm not sure, we kind of do X, but we also do Y ..."  My concise introduction goes like this:
I am a tech leader.  Most recently I was director of engineering at a company building mobile phone apps.  I was in charge of the dev team building the apps, and I was in charge of the production op's team that hosted the server side of the apps.  I am looking for my next job, project, or consulting gig, either leading tech teams or helping transform a team by showing them how to do Agile really well.  Do you know anyone looking for this kind of help?"
Exercise: Write down three things you are passionate about.  What are the best jobs for your passions?  Now write your concise introduction.  Practice your introduction, first by yourself, and then with everyone you meet.

Sell yourself
Now that you know yourself, learn how to sell yourself.  You are offering your services to potential buyers.  You need to market yourself just like any other product or service.  You are the salesman and you are the product.  Sell yourself!  

Start by finding your market.  Don't waste your time browsing jobs web sites like Monster or those of large companies, and don't submit your resume through a jobs web site.  Instead, identify your professional network and your prospects.  Make a list of everyone who might be able to help, including all your former coworkers, the people in your social networks, your phone and email contacts, contacts from previous job searches, neighbors, family, and friends.  

Think of your network as a sales funnel, starting with everyone you know, and eventually leading to job offers and your new job.  Organize your contacts into a backlog, prioritized by how likely each person is to lead to your new job.  Use your network, asking people for leads, and offering to help them with whatever they need--your job search is not a one way street.  

Be persistent, contacting and recontacting people by email, phone, and other media, but don't be a pest.  As you talk with people, listen well.  Read How to Win Friends and Influence People; the prose is dated and corny, but it is an amazing guide to building and using your network.  

Expand your network.  Before you attend an industry event, make a list of the people you want to meet.  At the event, introduce yourself with your concise introduction, ask for a business card, and offer yours.  Always sit next to people you don't know yet, and introduce yourself to them.  Be friendly, smile, and say something nice to old friends and new acquaintances.  Make sure your business card reinforces your image--you are the real deal; don’t hand out cheap looking, self-printed cards.  

Have a great looking resume, and publish it conspicuously on your blog.  Recall from Part 1 that publishing a blog is a great way to build your reputation.  Having found your blog, make it easy for them to learn more about you.

Is your sales pitch ready?  Your spiel starts with your concise introduction.  As the conversation progresses, have some good open ended questions ready: What are your biggest problems?  How can I help you solve them?  What can I do to help you succeed?  What do you like least/most about your company?  

Know your target salary, but don't share your price until the right moment.  When an interviewer asks what your most recently salary was, don’t answer; instead, ask what you would be worth to the prospective company.  Prepare for sales objections, such as, "We are a big company, but you've never worked for a big company."  Close the deal!

Exercise: Write down the questions you would ask at a job interview.  Establish your target salary.  Predict and write down the hiring manager’s objections, and write down your responses to the objections.

Do your job
Finding a job is your job, so do your job!  Get off your ass and do it full-time, at least 40 hours a week.  if you didn't contact at least 20 people today, then you didn't do your job.  

Do your homework before every phone call and face to face interview.  If your are interviewing for a job called Product Manager, you better damn well know what a Product Manager does.  Part of my spiel is, "a great tech leader does three things ..."  My spiel is honest--I know myself--and I rehearse it just enough that I sound confident but not fake.

Exercise: You better be prepared for this interview question: "It's your first day at BizCo and you are a JobTitle for Product X; what do you do?"  Write down your answer.

This series
Reread part one, and stay tuned for part two of this three part series:
Part 2: Finding a job is your job
Part 3: Don’t change


You're a loser. Get a job! (Part 1 of 3)

I am a loser, a good for nothing jobless scum.

Not really, but that’s how I sometimes felt when I was looking for a job.  Are you looking for work?  Are you good at it?  How long will it take for you to find a job?

I left a job I loved to join a small promising start-up.  It turned out much less promising than I hoped, and a month later I was out, looking for a new job.

Some of my friends had been looking for work, too.  I seemed headed for success, but my friends seemed like they didn't get it, they didn't know how to go about finding a new job.  They spent way too much time browsing jobs web sites like Monster instead of being invited into companies through their professional network.  

I landed my next job.  I think I know a few things that work.  I want to share what I know with you so you can get your next job, too.

Be prepared
There are three fundamentals to landing your next job.  First, be prepared.  In part one of this three part series, I’ll discuss what it takes to be ready to find a job before you need a job.  Next, finding a job is your job.  You have a job: finding your next job.  You're just not getting paid for it.  Finally, you're a wonderful person--don't change a thing!  I’ll cover the latter two topics in parts two and three.

Already have a job
They say luck is a combination of preparation and opportunity.  You can't control opportunity, but preparation is all yours.  The most important part of being prepared to find a job is to already have a job, and to use it as the springboard toward your next job.  

Looking for work is stressful, and running out of money more so.  If you already have a job, you won't view every job opportunity as the pot of gold that can't live without, and you'll perform better at your interviews without the added financial pressure to win the job or lose your home.  

Make sure you have adequate savings.  If you got fired tomorrow, how long would it take you to find another paying job?  A week, a month, three months?  Do you have enough savings to cover your expenses for that long?  If you already have a job, you can take your time and pick a company that has a business model with which you are comfortable, whether it is an investor funded venture with a fast burn rate or a more stable company with a sustainable business model.  Already having a job puts you in the driver's seat.

Build your reputation
People in your industry should know who you are.  Make yourself well known and credible in your field: write a blog, speak at conferences and industry events, and get published in magazines and conference proceedings.  It is surprisingly easy to submit a presentation proposal, get it accepted, and speak at a conference.  With just a little effort, you will stand out from the crowd of job seekers, and people will be eager to meet you and invite you in for interviews.  

Build and reinforce your professional network before you need to use it.  LinkedIn is a useful tool for managing your network, but the only thing that counts is face to face contact.  As part of building your network, don't be an asshole.  Be helpful--do selfless things for people that help them succeed.  

Exercise: Stop reading for a few minutes.  Write down three things that you can do to build your reputation.

Don’t suck
The third part of preparation is not sucking.  At your current job, kick ass!  Be valuable.  Help the company win.  Be highly competent in your role, in your field, and in your industry.  Read, read, and read some more.  Take classes.  Attend conferences and industry events.  Don't ever stop learning.

Coming up
Stay tuned for parts two and three of this three part series:
Part 1: Be prepared
Part 3: Don’t change


Eat at Pasha

Pasha is a great new Turkish restaurant in Arlington Center. Stop by for the warm decor, the relaxing atmosphere, and the rich food. Finish it off with a Turkish coffee. They are at 669 Massachusetts Avenue, Arlington, MA 02476.

Here is a scan of their menu. Call them at 781-648-5888, order a skewered chicken sandwich to go, and enjoy!

(It appears you don't have a PDF plugin for this browser. No biggie... you can click here to download the PDF file.)


Use Agile for mobile, and be awesome

Your dev team sucks.  Use Agile software development for mobile, and be awesome.
That was my pitch Saturday morning at MobileCampBoston3.  I led a session later that day, titled "Agile for Mobile."  I introduced Agile, explained some of its rationale, and identified some of the Agile frameworks.  I talked a lot about Scrum and a little about XP.  I had a blast, and I hope you did, too.  Here are my notes from the talk.

Why you need Agile
I contrasted traditional software development with Agile, and I offered reasons you should go Agile.  Some of the reasons are:
  • So you don't suck
  • So your group or company doesn't get shut down and you have to look for a new job
  • To build what your customers want, efficiently
  • To build what your customers really want, so they can change their mind and get something better quickly

I mentioned the Agile Manifesto, and I compared it to a businessy view of Agile.  The Agile Manifesto says fluffy things like, "Individuals and interactions over processes and tools."  Fluffy doesn't resonate with business people.  A businessy rationale for Agile is:
  • Customers get what they want, so
  • We make money faster, and
  • Our workers are happier, and
  • Our costs are lower, and
  • Our customers are happier, so
  • We get more repeat business

Which Agile framework should you use?
There are many flavors of Agile.  They all have the same overall goal, but they use different means to achieve it.  This chart from Mads Buus Westmark and Jesper Ronn-Jensen places a few of the Agile frameworks on a scale of prescriptiveness.  How many rules do you have to follow to be able to say you are using a particular framework?


Scrum will help you identify many impediments, some of which are business issues, and some of which deal with technical practices.  XP is a set of practices that address many of your technical problems.  Use XP in conjunction with Scrum.


How to be a great tech leader

Anyone can write code, but how do you effectively lead a team building an excellent software product?  To guide your team to greatness, you have to be a great technical leader.  A great tech leader does three things: know what to build, help the team build it, and help the team continuously improve.

Know what to build
Being a great leader is all about enabling a great team.  That starts with helping the team know what to build.  What does your customer want?  What does he really want?  Why?  Your team needs a deep understanding of your customer's needs.  They need more than a formal list of requirements--they need to understand the rationale and intent behind the requirements.  If your team doesn't know what to build, they simply can't build it, and your customers and managers will be disappointed.  If the team doesn't understand what to build, they will build something technically great, but that isn't what the customer wants.  They will hyperfocus on some requirement that's not important to the customer.  They will build something that is interesting to them, but not to the customer.  They will build exactly what is listed in the formal requirements document, and nothing else, missing the customer's target because they didn't understand the customer's goals.

Scrum and Agile make it easy to know what to build.  Instead of a big formal requirements document, use a product backlog.  Fill the backlog with user stories.  Each user story communicates both the What and the Why--what the customer wants, and the intent behind it, so even if the What statements are incomplete, the team understands the intent and can fill in the blanks.  Prioritize the backlog by your customer's business value.  Always honor your customer's prioritization; always build the most important stuff next, build the less important stuff later, and postpone the least important stuff, maybe forever.  Add good acceptance criteria to each story, so your customer can better articulate his desires, and so the team better understands what to build.  Estimate the complexity of each story as a team, so everyone understands the What and the Why, and so the team can preview upcoming stories and put some context around the current sprint's stories.  During the sprint planning meeting, decompose stories into tasks and estimate the effort for each task, so the team gets an even deeper understanding of the What and the Why.

Build it, and deliver
Now that the team knows what to build and why, they have to build it. More importantly, they have to deliver it--building it doesn't count if they can't deliver.  Software is intangible, and building it is an intellectual exercise.  But delivering it makes it a tangible, demonstrable thing: you either delivered it to your customer, or you didn't, and your customer either accepts the delivery, or he doesn't. Your customer doesn't care how hard you worked or what hurdles you encountered along the way--he just wants you to solve his problems. When you deliver something, your customer feels less anxious and less stressed--you have proven that you made progress, instead of just making a claim of progress.  For your team, build-and-deliver needs to be the norm, not the exception.  If you plan to deliver exactly one time at the end of a long project, without having had any practice at production deployment, then you are planning to fail.  So instead of building it and delivering once, your team needs to make delivery a regular activity, repeated every two weeks.

Scrum and Agile help here, as well.  Make sure your user stories are small enough that the team can get any story done within half a sprint.  At the sprint planning meeting, the team makes a commitment to itself, to you, and to your customer, to build and deliver some stuff.  When there is a problem that impedes getting the stuff done and delivered, the daily scrum and the sprint burndown chart alert you to the impediments early, so you can fix the problems early, before they torpedo the sprint.  Break the user stories down into small tasks, each no more than eight man-hours of effort, so you can gauge daily progress--if you started a story yesterday, but it's not done today, there's probably something wrong. Display your impediments on an impediments tracking board so you don't lose sight of them and so there's pressure on you and the team to remove them.  The sprint demo focuses the team on getting stuff done--when you demo i in front of an audience, the stuff better work! But don't just demonstrate what you got done--deliver it in production.  Focus the team on Really Really getting things Done Done: if it can't be deployed as a production service at the end of the sprint, then it's not Really Really Done Done.  Guide the team's definition of done to include "it was deployed in production." With the sprint rhythm, the team gets into the habit of delivering to the customer every two weeks.  Build-and-deliver becomes a normal behavior, not an exception.

So you built and delivered some stuff.  Did you meet your commitment?  Were you Really Really Done Done?  How much stuff did you get done?  Do your customers and managers expect more out of the team?  They are paying a lot of money, and they expect more stuff done, faster, at a higher quality level.  Can you do that?

Once again, Scrum and Agile make this easy.  Help your team know its velocity by estimating user stories in story points.  Use a product burndown chart, and gauge the team's likely, best, and worst velocity.  Inspire the team to increase its velocity, and help remove the impediments on their velocity.  Keep in mind that velocity is a vector--not just a magnitude, but also a direction--and that you can't just get more stuff done, you have to get more stuff done toward your customer's goal.  Keep using the daily scrum and the impediments board to achieve sprint commitments, and use the sprint retrospective to find and fix larger impediments.  Don't just react to the impediments you know today, because you're already too late; instead, anticipate upcoming impediments, and eliminate them before they slow down the team.  Do third party dependencies slow you down?  Crappy tools and hardware?  Lack of XP practices, such as continuous build or automated testing?  Help the team identify its problems, help the team get them out of its way, and they'll help your customer and management team kick ass.

So there you have it, the three fundamental abilities of a great leader: know what to build, help your team build it and deliver it, and help your team get better at it.  Scrum and Agile are the leader's toolkit to make it easy.

(Boston Celtics photo credit: http://www.lebasketbawl.com/why-will-the-celtics-win-it-all-next-june-this-team-has-depth/)



Hear ye, hear ye: The third annual Mobile Camp will be on Saturday, April 3, at MIT. Full details and registration are on the MobileCampBoston3 wiki page.

I plan to lead sessions with titles like these:
If you're into mobile or just looking for a good time, register and join us!


See Lyssa Adkins at Agile Boston

Lyssa Adkins gave a great "Coaching the Coaches" deep dive at the Scrum Gathering.  My big take aways were learning how to be a better listener, being empathic, not interrupting, and really trying to understand people's message, motivation, and feelings.


How to: subversion build number in your Android app

So you're building an Android app, and you want your app to display its build number on an About screen. You want the build number to be a unique identifier like the Subversion revision number. That's easy, you say: I'll build a simple About screen, put a TextView in it, and use Subversion keyword substitution, like this:
package com.kasperowski.example;

import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.TextView;

public class BuildNumberExample extends Activity {
    /** Called when the activity is first created. */
    public void onCreate(Bundle savedInstanceState) {

        View aboutView = aboutWithKeywordSubstitution();

    View aboutWithKeywordSubstitution() {
        TextView aboutView = new TextView(this);
        aboutView.setText("Build number: $Rev$");
        return aboutView;
And for bonus points, you could play some regex tricks or something to make the version number look like 42 instead of $Rev: 42$.

But, uh-oh! That's the revision number for that file, not the global revision number for your whole project. So it's no good as a build number.

You could play other games, like using a serial number file and writing a script that increments the serial number every time you build. But then you'll have a different problem: my sandbox and your sandbox will increment the serial number independently, oftentimes using colliding serial numbers. It would be a sandbox-specific serial number, hardly a good way to identify a build. You could build a shared database column with a globally incrementing serial number, but that's overkill.

Instead, use svnversion, a command line tool that returns the global version number of your repository. It is a stable, unique number that everyone can use, and it yields a true build identifier. At the command line, type svnversion, and you'll see your repository version number:
$ svnversion
To inject the svnversion number into your Android app's About screen, add a new resource to your strings.xml file:
<?xml version="1.0" encoding="utf-8"?>
    <string name="hello">Hello World, BuildNumberExample!</string>
    <string name="app_name">Build Number Example</string>

    <string name="app_svnversion">foo</string>
Then, make sure you have an ant build script. I created my project using Eclipse, so I don't have a build script yet. Tell Android to create an ant build script for you:
$ android update project --path .
Now you have a build.xml file, and you can type things like ant clean, ant debug, and ant install to build and install your app. Test your build script to make sure it works:
$ ant clean
Buildfile: C:\usr\local\workspace\build-number-example\build.xml
    [setup] Project Target: Android 1.6
    [setup] API level: 4

    [delete] Deleting directory C:\usr\local\workspace\build-number-example\bin
    [delete] Deleting directory C:\usr\local\workspace\build-number-example\gen

Total time: 46 seconds

$ ant install
Buildfile: C:\usr\local\workspace\build-number-example\build.xml
    [setup] Project Target: Android 1.6
    [setup] API level: 4


    [echo] Creating output directories if needed...
    [mkdir] Created dir: C:\usr\local\workspace\build-number-example\gen
    [mkdir] Created dir: C:\usr\local\workspace\build-number-example\bin
    [mkdir] Created dir: C:\usr\local\workspace\build-number-example\bin\classes

    [echo] Generating R.java / Manifest.java from the resources...

    [echo] Compiling aidl files into Java classes...

    [javac] C:\android-sdk-windows\platforms\android-1.6\templates\android_rules.xml:248: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
    [javac] Compiling 2 source files to C:\usr\local\workspace\build-number-example\bin\classes

    [echo] Converting compiled files and external libraries into C:\usr\local\workspace\build-number-example\bin\classes.dex...

    [echo] Packaging resources
    [aaptexec] Creating full resource package...

    [apkbuilder] Creating BuildNumberExample-debug-unaligned.apk and signing it with a debug key...
    [apkbuilder] Using keystore: C:\Documents and Settings\kasper\.android\debug.keystore

    [echo] Running zip align on final apk...
    [echo] Debug Package: C:\usr\local\workspace\build-number-example\bin\BuildNumberExample-debug.apk

    [echo] Installing C:\usr\local\workspace\build-number-example\bin\BuildNumberExample-debug.apk onto default emulator or device...
    [exec] pkg: /data/local/tmp/BuildNumberExample-debug.apk
    [exec] Success
    [exec] 17 KB/s (13601 bytes in 0.781s)

Total time: 2 minutes 2 seconds

Add a new target to your build.xml file. This target executes svnversion and injects it into your strings.xml file.
<target name="foo-update-svnversion">
    <exec outputproperty="build.svnversion" executable="svnversion">
        <arg line="-n -c" />
    <property name="match.start" value="<string name="app_svnversion">"/>
    <property name="match.end" value="</string>"/>
    <replaceregexp file="res/values/strings.xml"
At the command line, invoke the new ant target and then look at your strings.xml file. You'll see the svnversion number in strings.xml:
$ ant foo-update-svnversion
Buildfile: C:\usr\local\workspace\build-number-example\build.xml
    [setup] Project Target: Android 1.6
    [setup] API level: 4


Total time: 2 seconds

$ cat res/values/strings.xml
<?xml version="1.0" encoding="utf-8"?>
    <string name="hello">Hello World, BuildNumberExample!</string>
    <string name="app_name">Build Number Example</string>

    <string name="app_svnversion">22</string>

Now add some build targets to integrate your svnversion target with the default Android targets:
<target name="foo-debug" depends="foo-update-svnversion">
    <antcall target="debug"/>

<target name="foo-install" depends="foo-update-svnversion">
    <antcall target="install"/>
Finally, let's go back to your About screen. Add a method, aboutWithSvnVersion(), that grabs the svnversion resource and displays it on the screen:
public void onCreate(Bundle savedInstanceState) {

    View aboutView = aboutWithSvnversion();

View aboutWithSvnversion() {
    TextView aboutView = new TextView(this);

    String svnversion = getResources().getString(R.string.app_svnversion);
    aboutView.setText("Build number: " + svnversion);

    return aboutView;
Build your Android app by typing ant foo-debug or ant foo-install. This does exactly what you want, and now the world is safe again.



Certified Scrum Practitioner

I am now officially a Certified Scrum Practitioner.

So what?

So it signifies that my peers recognize that I understand Scrum pretty well. The certification shows I have actually applied Scrum for real, on a real project, in a real organization, for real stakeholders. It's not a big deal, really. It's just a token from an independent group of people--not me, not my friends, not my coworkers or business partners--that I probably know what I'm doing. But there are only about 1,000 CSPs in the world, so it helps distinguish me from people who haven't been similarly recognized by their peers.

Click through for more information on Scrum, the Scrum Alliance, and the Scrum Alliance certifications.


See Richard at Scrum Gathering 2010

I will be presenting at this year's Scrum Gathering in Orlando, March 8-10. My first presentation is Sneaky Scrum, a Pecha-Kucha, on March 9 at 8:00 in Sanibel 1 & 2:
Does your organization resist Scrum? Is your boss afraid of Scrum because of the strange jargon and lack of big up front planning? Do your developers say it's a good idea, but they can't deliver done stories?

Try Sneaky Scrum. Trick your teams into adopting Scrum, one practice at a time. Use my subversive system to stealthily sneak Scrum into your organization. I did, and I'll show you how I did it.
My second presentation is From AnyCo to AwesomeCo: A Case Study in Scrum Transformation, a full length presentation, on March 9 at 3:30 in Osceola 2:
We started as AnyCo, and we became AwesomeCo.

We spent two years applying various agile practices, trying to improve our project success rate.

Then we met Scrum, and 12 months later, we were a great team.

This is a case study of an actual mobile software company, whose name has been changed to protect the innocent.

I joined AnyCo to help transform it to AwesomeCo by applying agile practices. AnyCo's initial software process was waterfall.

We eventually found and rigorously applied Scrum, with great results.

AwesomeCo now delivers truly great software products, with very high quality, predictable time lines, predictable costs, and satisfied customers.

I'll share how we made the transformation, what prompted it, how I got the courage to do it, and our successes and failures.

The presentation includes:
  • Scrum and agile history
  • Why generic agile failed at AnyCo
  • How AnyCo used Scrum to transform itself into AwesomeCo
  • AwesomeCo's new awesome powers
  • Pitfalls during the transition
If you'll be at the Gathering, let me know--I'd love to hang out with you.


What are you putting in your mouth?

 Have you ever picked up a piece of fruit and not known exactly what it is? Maybe you were at the grocery store, or maybe you were unloading your Boston Organics produce delivery. Is that an apricot, a plum, or a pluot? Exactly what kind of apple is that?

Did you notice the sticker with the numeric code on your fruit? That's a PLU code (Product Look-Up or Price Look-Up code). PLU codes are maintained by the International Federation for Produce Standards, and you can look up codes in their searchable database. SupermarketPage has a good list of PLU codes.

Fight the power! Look up your PLU codes, and know what goes in your mouth!

Image from Organic Food Coupons



WiFi! On an MBTA Commuter Rail train! Yeah, it's old news, but it's still pretty cool. I am posting this from my comfortable seat on the train from Ashland to Boston.

In my speed test on an old ThinkPad running Windows XP, I saw downloads at 199 kbit/s with 138 ms latency. On my iPhone, I saw 157 kbit/s with 0.317 seconds latency. This sample is about half as fast as the download speed I measured in my Peter Pan WiFi speed test.


Cygwin rxvt redux

You're in for a treat when you upgrade to Cygwin 1.7: instead of bash running inside a plain old DOS-style window, you get a built-in Start menu shortcut for rxvt. Forget about creating your own rxvt shortcut--this one does everything you need. Thanks, Cygwin team!


How to embed a PDF in your blog

Pictures are more compelling than words. Don't just link to your files; display them inline on your web page. Here's one way to do it for PDF files.

First, create your PDF file. Sometimes, I use PDF Creator to print my documents as PDFs. Other times, I use Google Docs and download as PDF.

Next, upload your PDF to a hosting service. To keep my life simple, I use Google for most of my services (blog, file hosting, email, etc.). For file hosting, I usually use my Google Group http://groups.google.com, and I add the file to my group's files area. Wherever you are hosting your PDF, get the file's URL and remember it. To get the URL in Google Groups, copy the URL from the group's home page.

In your web site or blog entry, use the HTML editor and paste this in:
<embed width="500" height="400"
Replace YOUR-FILE'S-URL with your file's URL and adjust the height and width until your file looks just right. For example:
<embed width="500" height="400"
That's it--now your PDF is displayed inline on your web page.


How many registered Certified Scrum people?

Every wonder how many Certified Scrum people there are? The Scrum Alliance web site has the answer. Scrum Alliance lists the names of all the registered certificate holders at http://www.scrumalliance.org/training. If I count correctly, these are the numbers, as of January 13, 2010:

Registered practitioners 53,9903,558 908 23105

There is some double counting, but it's not very significant. For example, most CSTs are also CSPs and CSMs, and they are counted in each category.

Here is a chart showing the same data:


Scrum Guide

The Scrum Guide is the definitive guide to Scrum. It precisely summarizes and hones the canonical sources from earlier this decade: Ken Schwaber's books, Agile Software Development with Scrum and Agile Project Management with Scrum (affiliate links). The Scrum Guide is hosted at scrum.org under the aegis of Ken Schwaber and Jeff Sutherland.


See Mary Poppendieck at Agile Bazaar

Mary Poppendieck will present The Leadership Team and the Software Crisis: A Cautionary Tale at the Agile Bazaar on Thursday, January 7. The festivities begin at 6:00 PM at Constant Contact in Waltham.

Before you get here, read a couple of Mary and Tom's excellent books. Lean Software Development: An Agile Toolkit is your guide to everything lean. Leading Lean Software Development: Results Are not the Point is their latest, and a good read as well. (Yes, those are affiliate links.)

See you there!


Related Posts with Thumbnails