William Gill

“Being Agile” is more than following a checklist. It’s more than following the Scrum or Kanban handbook (in fact, it doesn’t even matter if you’re “doing” scrum or kanban at all!). Being an effective and productive agile software development team is about understanding and believing in a set of values, practices and principles.

Starting with our engineers, we tried to boil these values and practices down to a handful of core ideas. We wanted to share a common language and have a common set of checkpoints where we could track and assess where we are as a team, and give us guidance on where to focus to help us get better. We created what we call the “Agile Sliders”: a set of 6 guiding principles and practices for agile engineering teams.

1. Code Quality
2. Unit Testing
3. Acceptance Testing
4. Self-Organisation
5. Pair Programming
6. Code Ownership

Each principle exists on a scale representing a journey to an ideal state. In every retrospective we assess our progress against these scales. Did we get better? Stay the same? Get worse? The point isn’t so much to score ourselves, but it is a trigger for a conversation, and a tool for the team to use to challenge themselves on their journey.

We have also found that we can view progress from multiple viewpoints:

1. The team as a whole, and
2. Individual developers.

We’ve had some success linking these principles not only to team targets, but to individual performance targets as well.

We constantly iterate on our “sliders”, and we love feedback. Please leave any thoughts in the comments. I would like to expand the set of sliders to cover Product Owner and Experience Designer roles.

The Agile Team Values Poster

Here are the 6 principles and practices in a poster form. Click the image below to download a larger version suitable for printing. You are welcome to print it, change it, make it better!

I’m often asked for help putting together a job description for a Scrum Master, so I thought I would post an extract of one we’ve used recently.

We are a product team of developers, QA experts, user experience and visual designers and product owners who are looking for someone to help us get better at what we do. We’re pretty good at the basics of agile software development but can always use new ideas about how and where to improve. We’re less concerned about what it’s called (Scrum/Kanban) and much more excited about results, whether that means moving towards continuous deployment, using ATDD, or seeing our active users grow.

You are someone who leads by example rather than by dictate and you know how to bring out the best in people. You’re not afraid to deal with conflicts. You know when it’s good to say “No” and when to push for more results.

In addition, we’re looking for someone to act as a galvanizing force for our whole wider team in terms of sharing Agile knowledge across the company. Whether it be organizing 1-day open spaces for our agile community, or organizing cross-team workshops, the goal is for you to establish an Agile center of gravity around our team.

Your main responsibilities will be:

1. Act as Scrum master for 1-2 scrum teams with a focus on guiding the teams towards improving the way they work.
2. Facilitate sprint planning, retrospective and sprint demos
3. Assist the product owner with keeping the backlog groomed
4. Ensure cross-team coordination
5. Reach out to the larger company network for impediment removal
6. Maintain relevant metrics that help the team see how they are doing
7. Coach and mentor other scrum masters in our product team. Ensure that our ways of working are consistent across the teams.
8. Liaise between the developers and User Experience/Visual Designers. Foster better communication between the disciplines.
9. Act as a project manager when necessary. Take responsibility for managing dependencies between our team and third parties or between our team and other scrum teams.
10. Strengthen the presence of our team as an Agile centre of excellence. Actively contribute to the company’s Agile and Lean Community. Keep the rest of the company network aware of our activities.

Qualifications:

1. Knowledge of the software development life cycle
2. Certified scrum master/scrum practitioner
3. Knowledge and/or experience of Kanban
4. Excellent communication skills in English in written and spoken form
5. At least 3 years experience working in an agile environment, preferably in a variety of situations

Feel free to use this, re-use it and copy it. I hope it’s helpful!

What would you add to make a better Scrum Master job description? Share your tips in the comments.

It’s a question that every tech startup or product has to ask itself: when the budget is limited (and it nearly always is), where do you spend your cash? On improving the product, or on marketing and advertising campaigns? To me, the answer is clear: every dollar spent on advertising is a dollar not spent improving the product. Can you afford that? Can your product afford that?

But what do you do if you don’t have money to spend on marketing?

Twenty years ago to reach a million people with a message you needed to run a TV ad during a prime-time TV show or book a page in the national newspaper. If you wanted to sell your product to 1 million people, you just needed to insert enough advertising cash. Insert x dollars: ship y units.

Today, thousands of blogs, YouTube videos or Tweets reach millions of people every day. And it’s free.

Every individual has a reach now through the internet far greater than ever before. We can communicate messages immediately with our friends, who we trust, as well as broader social networks, easily, and it’s practically free. Everyone in your product team – from the product manager to the last software tester – is a potential marketer, reaching out to their social networks with a trusted and genuine message about your product.

In the world of web products, the products themselves have far greater reach and avenues to be found in the web than any physical product on a shop shelf could ever hope for. You can leverage Facebook and other social networks to promote and talk about your product, as well as create conversations with and between users. You can use Facebook as a platform to publish individual activity or status from the product, which has the dual benefit of strengthening the user’s social feed as well as promoting the product to every one of that user’s trusted network of friends. Pay a little bit of attention to SEO (Search Engine Optimisation) and you can target and optimise incoming traffic from search engines.

Guerrilla marketing campaigns like this one might be limited to a fairly local reach, but they are cheap (and fun!) to execute. Getting the whole team involved in local guerrilla campaigns can also be great for morale. The best performing and self-organising teams look at the whole end-to-end of their product – and marketing is no exception.

Today everyone’s a marketer. Getting the word out, finding more users, getting more traffic: these are no longer only the marketing team’s responsibility.

I was reminded today of a story about managing people. About 8 years ago I was in my first management job, managing a team of about 15 web software designers and engineers. I saw a key challenge in bringing the team together, inspiring one vision and building a sense of identity and unity within the team.

At the time, I was fresh out of the Army, and was still active as a part-time Army reservist. I took to calling the team my “troops”, and turned some of the key challenges we faced as a team into our “key battles”. I saw it as a term of endearment to the team. In my mind, I saw it bringing a sense of unity and a common, understandable vision to the team. I saw it flattening the hierarchy, putting us all at the same level to encourage shared responsibility and the willingness to speak out. I saw it helping to build individual relationships between each of the team members. (Looking back, I think subconsciously I also hoped it would help give me, as a very young manager of an experienced team, a sense of authority; but I wouldn’t have told you that at the time.)

All-in-all, I saw it as a positive, understandable and motivational message. Indeed, military expressions like “rallying the troops”, “strategic battles” and “war rooms” were common in business parlance then, as they are today.

In reality, though, the team themselves saw something quite different. In short, they hated it. They hated being referred to as “troops” or “soldiers”, which they found disrespectful. Where I saw it flattening the hierarchy within the team, they saw a new hierarchy emerging: one with officers who sit back and give orders and soldiers who follow them. Where I saw it encouraging initiative and shared responsibility, they saw themselves reduced to simple soldiers who just follow orders and are not expected to think for themselves. On top of that many found the frequent references to war and battles offensive and tiring. (This was just after the second invasion of Iraq, and soldiers were still dying every day in Iraq and Afghanistan.)

I learned two very valuable lessons from this in my young management career.

Firstly, be very careful with military references in the workplace. While it’s still common in business to hear talk of “battlefronts” and “attack plans” and so on, I’ve learned to be cautious with how often, and in which situations, I use these. I think in the context of a conversation between a few people it’s probably ok; but I wouldn’t frame the team objectives/targets for the year in terms of “battles” and “wars”.

Secondly, sometimes you just don’t know how people are responding to the messages you deliver and the things you say. As a manager, when setting a vision or delivering a message, you need to remember that your job isn’t done until you can confirm that the message was heard and understood by your team in the way you intended. For my example above, how could I have known that my efforts to bring the team together were not working out as I had intended? I think the answer is: ask. Ask for feedback from individuals, from the team. Just like in agile and scrum, constant feedback helps you constantly iterate and adjust, which applies as much to management and communication style as it does to code.

My second Windows 7 Phone app is here!

I’ve recently been experimenting with developing small apps for the Windows Phone 7 ecosystem. My second app, now available in the Windows Phone 7 Marketplace, takes Wikipedia articles in the area around you and puts them on the map.

Discover what’s around you with a tap. The Around Here Wiki app puts you and all the world encyclopedia Wikipedia on the map: together.

Have you ever walked through an unfamilar city and wondered: “What’s that old building over there?” Just pull out the Around Here Wiki, and you’ll find out.

“Is there anything interesting around here to look at?” Around Here Wiki can tell you.

Around Here Wiki is clean, simple and no-fuss. No fancy effects or unnecessary information – just the facts. Want to know more? Just follow the link to the full article on Wikipedia.org.

You’ll always know what’s around you.

Download it for your Windows 7 Phone here. Don’t forget to rate it!

Facebook was not the first social network. As early as the first dot com boom in the late 1990s companies like sixdegrees.com had launched with services similar in theme and purpose to what Facebook became. When Facebook launched in 2004 from a dorm room at Harvard there were already a number of competing products: Friendster and Orkut were already successful online social networks, and mySpace already had millions of users. In fact, MySpace continued to be the largest social network in the world until 2008 when Facebook finally overtook it.

The iPad was not the first tablet, nor was the iPod the first portable MP3 music player. Google wasn’t even the first web search engine.

What Facebook, the iPad and countless other products like them did was take something that had been done before, and did it better.

Facebook took the concept of online social networking, and added real meaning: your real identity, your real-life friends, and a completely new (and naturally addictive) way to share your life with your network. (It also managed to solve the hardware scaling problems that had hamstrung competition like Friendster).

The iPad took the long sought-after but elusive tablet computer and built a beautiful, functional and elegant device that refused to compromise. A device that rejected the assumption that a tablet was a normal PC with a touch-screen, and had the courage to create a whole new form factor.

The point is: it’s okay to be second. Or even third. New product opportunities often lie in re-thinking existing concepts or products: it’s about seeing what can be done better, and having the courage to take the next steps the others won’t.

Steve Jobs one famously quoted Picasso when he said: “Good artists copy. Great artists steal.”

As readers of this blog will know I’m a big fan of agile and lean software development principles and practices, but have you ever noticed how cliquey the agile scene is becoming? How almost cultish?

Here are five reasons the Agile scene is turning into a cult:

You’re either one of us, or you’re not.

You will read the bible, go to church and believe in God, or you will go to hell. Period.

You will use Scrum or Kanban and believe in Agile, or your software will be buggy, over-budget and crappy. Period.

You will respect, honour and awe the founding fathers.

You will honour, awe and respect the founding fathers. The Scientologists have, for example, loopy L. Ron Hubbard, the science fiction author-turned prophet who continues to convince millions of normal people that Earth is a colony founded by aliens. The followers of the People’s Temple in the 1970s honoured, respected and awed their founding father, Jim Jones. 909 of them swallowed poisoned Kool-Aid in 1978.

You will honour, awe and respect the agile founding fathers. The more often you can use this image in a presentation about agile the better.

You will respect the sacred parchment.

Cults always seem to have a sacred parchment, original manuscript or some other artifact that serves to both prove the validity and authenticity of their beliefs, and also lay down the groundrules for how your soul will be saved.

We have the Agile Manifesto…

You will follow the strange rituals.

Secret handshakes, rituals, traditions, sacred artifacts: these are the cornerstone of any self-respecting cult.

Standups, sprint reviews, sprint plannings, a 3-week lunar cycle…

You will read, follow and respect the rulebook.

The path to spiritual salvation is in the bible.

The path to software salvation is in the Scrum handbook.

What do you need to have a great and effective scrum master on a team?

The Scrum Master is, I think, one of the most misunderstood roles on the scrum team. It’s a critical role to ensure your team will perform at their best.

An effective Scrum Master is not just anyone who wears the Scrum Master hat for a few hours per week. I think an effective Scrum Master should have (at least) these three things:

1. An understanding of what it means to be a Scrum Master (it sounds obvious, but evidently sometimes it’s not). A Scrum Master course is the minimum here, I think. It also includes understanding the agile manifesto, understanding lean principles and the mechanics of software development.
2. An innate, natural desire to learn, improve and be better.
3. The support of colleagues, the team and the organisation to be able to do the job.

I’ve seen a lot of different kinds of scrum teams, and some common themes appear when thinking about under-performing Scrum Masters. Here are some sings that you might not have the most effective Scrum Master:

1. Your Scrum Master is responsible for 7 different teams.
2. Your Scrum Master is just one of the developers who has the responsibility to send the calendar invites to the standups and take notes in the retrospective.
3. Your Scrum Master is just someone from your QA team who puts cards for bugs on the story wall.
4. Your Scrum Master cannot describe the Agile Manifesto.
5. The only contact your Scrum Master has had with scrum or agile is the two-day CSM course (or worse, none at all).
6. Your Scrum Master is not able to realistically change the process within which your team works in order to respond to feedback in retrospectives or improve the way of working for the team.
7. The Product Owner or business owners ultimately responsible for the team and the product are the kind who want all the benefits, such as predictability, increased output and accountability, without changing any of their entrenched, old-school, waterfall processes.

I’m sure there are others, but if you see any of these in your scrum team, you might want to take a look at your setup. Note that these things are not always a problem with the person acting in the role, per se – many of these issues stem from organisational misunderstanding of the role as well.

Have you ever wished your life was a movie? In the movies, there’s always the right sound effect ready to roll for every moment. Sometimes our lives need a soundtrack too.

That’s why I created my first ever Windows 7 mobile application called Soundtrack: Life. You can install it on your Windows 7 phone here.

Soundtrack: Life is an application to let you give your life the soundtrack it deserves. With Soundtrack: Life, you always have the appropriate sound effect or musical score ready whenever your life needs it.

I chose Windows 7 Phone as the development platform mostly because that is now the standard platform for Nokia smart devices, and Nokia is gearing up to announce our first Windows 7 phones at Nokia World soon. I expect the numbers of Windows 7 Phone users to increase dramatically when Nokia starts bringing out great new Windows 7 devices.

Learning to program in .NET (had never used .NET or Silverlight before) was an interesting experience. It proved to me once again that learning something new is a hugely rewarding experience. I don’t much like letting my mind stay idle for too long, and little projects like this keep my energy and attention up.

I’ve got more Windows 7 apps on the way… stay tuned!

We all know it’s important to think of our users first, and that user feedback is important; however all of us have to deal with products, processes and systems in our day-to-day lives in which the user was likely at the bottom of a long list of other priorities during the design phase. Anyone who has been through customs in an American international airport as a non-US citizen can understand what I’m talking about.

In Beijing International Airport, however, they appear to value feedback from travelers. Attached to the booth under the window on every customs desk is a small box with 4 buttons. The text above the buttons reads: “You are welcome to comment on my work”, and you’ve invited to press “Greatly satisfied”, “Satisfied”, “Checking time too long” or “Poor customer service”. In full transparency the custom officer’s identification number is shown directly on the display.

Collecting user feedback at Beijing International Airport

It would be interesting to know what they do with the results: whether they use the outcome to performance manage the staff member, or to identify patterns of satisfaction across different demographics of traveler. Either way, it’s refreshing to see an area that appears to be traditionally nonchalant about user satisfaction take an interest in what people think for the purpose of making the system better.