Working with distributed teams (III)

(you might want to read parts one and two first, but they are not needed)

Ok, so by now you should already know that, when compared to co-located teams, distributed teams sucks badly. That does not mean at all that you can’t have great distributed teams: it’s just way more difficult and hard to find. Communication, culture, identity, collaboration, trust, awareness and several other key factors for performance are affected when we can’t share the same space.

As I wrote in my previous article, if you can’t get rid of the noise (i.e., bringing your people back together), you have to increase the signal. You have to think on ways to increase al these performance factors remotely, and invest into them aggressively. I promised to give you some clues, tips and insights on how to deal with this, so here you are.



  • We are a team: and not just any kind of team, but a problem-solving team. This is different, for instance, from a bowling team or a chess team, where every ‘team’ member will play their game and add their score to the ‘team’s’ result. In such a team, if results are bad but one team member won his games he might say ‘hey, it’s not my fault, I did my part’. This kind of behavior does not work well when we have a common problem to solve. Being a team means that decisions are made together, information is shared and we help each other to succeed. This needs to be enforced through the rest of these rules.

  • Enforce communication: communication must be pushed, not pulled. Team members must not seek for communication only when they feel that it is important or needed, there must be something similar to the ‘osmotic communication’ that happens on a co-located team. For some distributed teams I’ve coached, it was usual to have not one but two daily meetings to synchronize and organize work.
  • Enforce collaboration: the trend to work alone and isolated is bigger on distributed teams. Team agreements should encourage people to share work items and work together at them as a way to share knowledge and achieve a common understanding and way of working. Tools like a version control system, shared environments and continuous integration help teams to be aware of what everyone else is doing and force people to collaborate on a frequent basis. If you have people in two locations, making them team across locations instead of creating local teams will help to lower all the communication and collaboration barriers created by distance (see Jeff Sutherland’s notes on SirsiDynix case).
  • Frequent delivery: risks on a distributed environment are greater. In order to find out problems as soon as possible, you want to make feedback loops as short and frequent as possible. For instance, you could consider asking for working software at the end of every week instead of every two weeks.
  • Inspect and review: especially for outsourced teams, it’s not enough to have working software. Even running, tested features might hide spaghetti code, rat nests and technical debt that will make software maintenance or evolution a nightmare. Code must be inspected locally to be sure that the remote team members are following the relevant guidelines, code standards and best practices. You don’t have to read every line of code, but opening some files and ‘smelling’ the code daily is a very good practice. For distributed teams, each team member should take the daily task of inspecting someone else’s code for a while.


Bonus tip: you might want to check Luis Gonçalves’ article on how to build trust on distributed teams.




  • Videoconference: nowadays, with ubiquitous and free videoconferencing tools like Skype or Google Hangout, there is no excuse not to incorporate videoconferencing as a regular mean of communication amongst team members. Planning sessions, retrospectives, demos and daily meetings work better if we can see each other while we discuss.
  • Shared desktops: the ability to share a document and see what the other person is doing, or even being able to write, code or modify a file together makes it really easier to collaborate. Skype is a good tool for this, but there are others you might want to explore. 
  • Shared folders and repositories: a version system is a must for any software development team, Git /GitHub being one of the main players in this area. Google Drive, Gdocs, Dropbox and similar services have made sharing files something trivial, although your team might need some rules on how to modify these files without smashing other people’s changes.
  • Same environments: you have to make sure that everyone is using development environments that are identical, meaning same versions of   product development stack, database, etc. Using a shared environment for everyone is a controversial measure – it ensures that the environment is the same, but it might introduce more trouble if someone breaks it and might scale worse – like, for instance, if someone need to stop a service and then everyone else must wait. The shared environment approach can be substituted by frequent code chek-ins, frequent builds, frequent test runs and frequent deploys.
  • Constant Chat: Videoconference is great for meetings, but you need a lightweight solution for constant communication. Chat and Messenger tools are the preferred approach for many teams, but I’ve had some success using Audio chats: all team members will log in to a common audio chat room and use headsets all the time they are at work. This favors all kind of informal communication to happen, all the time (like someone inadvertely saying ‘dammit, why is the server not responding?’). If someone needs to be concentrated and not interrupted, he might open a separate audio room with the title ‘do not disturb’, which still allows other team members to reach him by audio in case of an emergency. Ventrilo or Team Speak are a couple of tools I used in the past, you might want to try others. Very recently, the Happy Melly crew gave some enthusiastic reviews on Slack, you might also want to check that one.


  • Project Management Tools: In case you need some project management and coordination software, Basecamp, Asana and Trello are very popular tools these days. If you can afford Jira + Confluence it’s also very recommended tool. I’ve also found that many teams will just need GitHub for coordination and project management. Anyway, review your actual need of these tools. I’ve found many times that a simple shared spreadsheet with the backlog and little more information is bare enough to coordinate most teams.
  • Knowledge sharing: In his (recommended) book about managing a distributed team at WordPress, Scott Berkun describes how most teams at Automatt used a WordPress Blog with a specially customized theme (P2) as a repository of most team conversations, tasks, discussions… This makes it easier to search for past discussions, or even to leverage the learning curve of new team members. Wikis might also be a good tool, specially if you can link them to the project management / software development tools – check Confluence for this.

In my next articles about distributed teams, I’ll share some final thoughts on working across different time zones and cultures, as well as some rules for working solo at home. Stay tuned for them!

Posted in Articles | Tagged , , , , , , , , | Comments Off

Working with distributed teams (II)

In my previous article about distributed teams, I mentioned several reasons why having remote or distributed teams might be a bad idea, and I also acknowledged some valid reasons to have distributed / remote teams at your organization. Some of these reasons might include outsourcing software development if it is not your core business, access to talent or providing some perks to employees.

In the following discussion, some people pointed out that a valid reason might be growing your company elsewhere if there is no availability of software developers wherever your core business is located. I’m not sure I agree with this. If your company is cool enough, people will move to wherever your company is based. Zappos moved from San Francisco to Las Vegas (which looks like hell for coders when compared with the mythical Silicon Valley) and close to 80% of the company moved with them. If you are not (still) as cool as Zappos but you are in desperate need of software developers, you might consider moving your company to wherever it makes sense. You know, if the mountain does not come to Mohammed…

Anyway, let’s face it: several companies have a ‘business core’ at some place and a ‘development factory’ elsewhere. Several other will have a telecommuting workforce for good or bad reasons. We already listed all the problems that a distributed team implies, so let’s move into what we can do if, despite the impediments, we end up in this situation.

The first thing you should try is to actually reverse the situation: bring back the team together. Analyze the reasons that your team is distributed, but please understand that ‘it’s not my fault’ or ‘I inherited a distributed team’ are not valid reasons. When Marissa Mayer became Yahoo’s CEO in 2013, she cut down the company’s policy on working from home. A week after, Best Buy followed Yahoo’s lead and also decided to lower their ‘flexible work policy’ too.

This decision was vastly criticized both by media and some well-known agilists. Mayer’s explanation was that, yes, people might be more productive on their own if you measure them individually, but if you are looking for collaboration, synergy, innovation and creativity, then working together as teams is better. ‘Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings’, she wrote.

Many people inside the company recognized that, although it was nice to have the perks of working at home, they were pleased to see that someone was taking leadership at their company and was placing her actions where her words were.  It is nice to say that teams are important, but these kind of measures actually support the collaboration culture. By the way, you might want to read Zappos CEO’s opinion on banning telecommuting.


ScrumMastership P5Bringing people back to the office does not need to be a permanent or full-time decision. People might keep the right to schedule Pijama Days – an agreed day where all the team will stay at home and focus on more individual tasks. The amount of Pijama Days per month might vary depending on team maturity, collaboration needs or other factors.

Again, why am I stressing so much the need to bring people together at the office? In fact, several people advocate against office work. On his TED talk about why work rarely happens at work, Jason Fried defends the idea that offices alter the capacity of people to focus and be productive, mostly because M&M’s – Meetings and Managers. He stresses the fact that, when people need to ‘finish something’, they prefer to do it at home, at a fancy café or maybe even at the train, where they will have fewer interruptions.

In my opinion, if your office is full of interruptions, distractions, noise and unproductive meetings, the solution is not to keep people out of the office. If you do so, you might be solving the wrong problem or, as we say in Spain, ‘killing the dog so there won’t be any more rabies’. Jason Fried shares this feeling, and he also proposes several strategies to make your office more productive. In fact, his company’s office (37Signals) is often featured by the media as an example of how creative work is supported.

If you think of offices as a need to control people and provide resources (computers, phones), the concept might even be outdated. Most of us have everything we need to do productive work at home, and controlling working hours is so 20th century-ish industrial thinking that it doesn’t even make sense any more in the knowledge-based economy. But from the perspective of collaboration, innovation and communication, sharing the same space and interacting face to face is a big asset.

Summarizing, some of the reasons why co-located teams are better include:

  • Communication: Alistair Cockburn often refers to the term ‘osmotic communication’, the chance that you would get some piece of information just by being on the right place at the right time. The communication bandwidth between people is maximum when we are face to face – specially if a whiteboard is involved – and minimum when we just send a document and expect the other person to correctly understand what we tried to express in it.
  • Collaboration: just being on the same project or having the same goal is not enough to claim ‘collaboration’. Sometimes teams are just coordinated or are cooperating – two forms of individualistic effort that will be added to a common production stack afterwards. Collaboration means actually working hand to hand on the same issue, discussing strategies, approaches, methods, and steps. Examples of this include pair programming, swarming or mob programming.

ScrumMastership P10

  • Knowledge transfer: collaboration fosters knowledge transfer. No matter how many documents, handbooks or WiKis you create, the best possible way to spread knowledge and make people learn is hands-on work guided by an expert.
  • Culture and Identity: people who collaborate, communicate and work together, sooner or later, belong together. This is especially true if facilitation is available to navigate them through conflict.
  • Awareness: when a team is working at the same physical place, there are more chances that someone will spot impediments, colleagues in need of help, emergencies or other issued affecting the team. It is also easier to spot interesting conversations or meetings taking place.

ScrumMastership P11

  • Availability: when a specific person’s knowledge or skillset is needed, having the option to nudge her or even unplug her earphones – even at the cost of interrupting her focus and flow – might be an overall benefit for team performance.
  • Trust: it is easier to build trust with your colleagues when you have constant visibility of what each of you are doing, and also when you are attending the same meetings, working over the same items. making questions to each other and even hanging out at the water fountain.
  • Quality: it is easier to ask for reviews or for other people to test your code if they are immediately available. There’s even the chance that someone will pass behind you and say ‘yoh, dude, what are you exactly doing right there?’

So, what if still we have a distributed team? In my opinion, having a remote team introduces noise into your process. That’s why my first advice is to get rid of the noise and bring your people back together – with the occasional Pijama Days. But if you absolutely can’t reduce noise, then you need to increase signal. To increase signal, yo have to review all benefits of co-located teams and try to enhance them on your distributed team.

In the next article, I’ll give some specific practices and rules that will help you increase communication, collaboration, knowledge transfer, culture, identity, awareness, availability ,trust and quality in your distributed team. So…Stay tuned!

Posted in Articles | Tagged , , , , , , , , | 1 Comment

The three questions at daily meetings

The three questions at daily meetings

At the Agile by Example 2014 Conference in Warsaw I delivered my “Developing ScrumMasters” talk, probably the one that people give more enthusiastic feedback about amongst the many other talks I keep in my speaker backpack. As you probably know by now, this talk features the evolution path of the ScrumMaster or, form another point of view, different coaching styles depending on team maturity. For immature teams, the ScrumMom is presented as a protector of the team, a moderator and an impediment solver. She will also set somehow tight boundaries around the team on things like process, ceremonies or tools. ScrumMom will also avoid conflicts in the team by preventing them. ScrumMoms are still prescriptive and sometimes even bossy, but might be needed if we want to move immature team out of their comfort zone.

Self organization P26

ScrumMom is partially inspired on Jeff Sutherland’s Shock Therapy approach, where a team will be forced to do Scrum “by the book” for a while before they have any authority to change the process, thus providing a baseline of (allegedly) good practices to compare with.

Of course, if both team and ScrumMom get too comfortable in this situation, the team never really grows. That’s why a True ScrumMaster is needed somewhere over time. True ScrumMaster will stop solving impediments for the team and will show them how to solve them by themselves instead. True ScrumMaster will do less moderation and more facilitation. True ScrumMaster will concentrate on team growth by progressively delegating responsibility and authority over the team. True ScrumMaster will engage conflicts constructively as a chance to make the team more robust and mature.

Self organization P24Anyway, I received an interesting e-mail about the state that comes before the ScrumMom – that’s the ScrumDude. ScrumDude is the archetypical team member that has just been designated as ScrumMaster and doesn’t really understand what’s his duty. So he basically will just schedule daily meetings, ask the three questions (what have you done, what are you doing, what impediments are you facing) and maybe keep a list of impediments out of the team’s retrospective. He is basically a team scribe, nothing more. That’s the reason we sometimes see teams rotating the ScrumMaster role – I don’t see that happening too often when it comes to the CEO role or the Product Owner role.

So the question I received by a session attendee is in the line of “is it wrong to ask the three questions?”. He understood that I was relating these three questions to a poor engagement of the ScrumMaster. Time for some clarification.

From my perspective, the three questions is just a way to get started with daily meetings (stand-ups, daily scrum or whatever the flavour you are keen on). But the problem with these questions is that they rapidly create a sense of “conformance to the process” – we just have to make these questions and maintain the meeting short, then we can call ourselves “Agile”. Hence, the main goal of the daily synchronization meeting is lost. It becomes a reporting meeting, each team member reporting their situation to the ScrumDude, who sometimes turns out to be a project manager in disguise.

Specifically, the three questions are very individualistic – what have YOU done, what are YOU doing, what impediments are YOU finding. I find this to be against the concept of a collaborating team. It seems that plain old “pool of resources” and assigning individual tasks to each person.

This is probably one of the main reasons that some people find daily meetings boring: I have to listen to five people’s stuff, which I don’t really care about, before we can get to my part. If you are seeing this kind of dynamics in your team, you probably need to reengineer work distribution and find ways to enforce the ideas of a common team goal, collaborating over the same items and keeping Work In Progress (WIP) low. There are several strategies to do so, including vertical slicing of stories to include all end-to-end layers and components, working on smaller stories, pairing, swarming or even mob programming.

So, if we don’t use the three questions, what can we do instead? My advice would be:

  • Focus on team goal: instead of looking for individual status, try to see how far are you from the iteration goal. What advance have been done? What needs to be done next?
  • Look for common awareness: try to make everyone aware of what everyone else is working at. The use of avatars in the team board is usually a good and fast way to solve this. Ask everyone to rise awareness on any important information they found during the past day.
  • Watch the board: look for bottlenecks, queues forming, lack of progress… Discuss them with the team and agree on a common strategy to deal with them.
  • Find what’s affecting us: try to spot impediments. These are not only “blockers” or “stoppers”. For instance, too much noise can be distracting us. Maybe we need to do something now or maybe we should discuss it at the next retrospective.
  • Find who needs help: instead of just getting the next post-it on the backlog, people should try to find out if they can help someone finish their task first. This helps to lower the WIP and also fosters collaboration and learning.
  • Follow up improvement plans: you surely committed yourselves to do something at the last retrospective. How about reviewing how good are you doing at those improvement backlog items?
  • Share some love: truly. Thank people for their contribution. Congratulate on finished items. Encourage people going through difficult issues. Bring team’s attention over some unnoticed success story or team member’s action.
Posted in Articles | Tagged , , , , , , , | Comments Off

Team Maturity vs. Delegation

I bumped into this video by chance, and I found it very well aligned with my own materials on the evolution of ScrumMasters (ScrumDude, ScrumMom, True ScrumMaster), which are by far the audience’s favourite slides on all the conferences I’m delivering in the last couple of years. As a plus, it is very well visually facilitated by Marcel Van Hove, who has a YouTube channel with plenty of other visual videos. I haven’t met him yet, but I’m eager now :) . Hope you enjoy it.

Posted in Articles | Tagged , , , , , , | Comments Off

Unicorns, Krakens, Self-Organizing Teams and other mythological beasts

This was the title of my latest keynote talk at Agiles2014, the latin-american Agile conference that took place on Medellín, Colombia, during October 2014. In this talk, I propose an incremental transformation model from pure command-and-control, coordinated teams to full self-organizing, collaborating teams. As Jurgen Appelo uses to say,  all models are wrong, but some models are useful, so I hope that his model is useful to some people. It includes several perspectives, including corporate culture, team maturity, delegation levels and coaching approaches. Unfortunately I was not able to record it, but I’ll be giving this talk again soon and I hope to share a video then.


I have to say that the Agiles2014 experience was really overwhelming. Great conference indeed, 700 people from all over America, and the warmest welcome by any audience ever. I had the opotunity to chat again with Tobias Mayer. We were both Keynote Speakers at Agile Spain 2013, so it was nice that we were Keynote Speakers at Agiles 2014 (it seems that a pattern is being developed over the spanish-speaking Agile community :P ).

It was also a pleasure to meet several other amazing people, including Martin Alaimo , Alan CymentJavier Garzas, Bob Galen and many other new friends from Colombia, Argentina, Uruguay, Miami and the rest of central and south America.

Posted in Articles | Comments Off

Working with distributed teams (I)

Distributed teams

Last week I was delivering a keynote at Agiles2014, the Latin-American Agile conference. I have to say that this was one of the most rewarding experiences I’ve had as a speaker, as the Agiles community was indeed the most welcoming and thankful audience I’ve met so far – besides the fact of having seven hundred people cheering at my jokes and taking pictures with me. I thing I need an Ego-starving diet after that.

Anyway, there were a lot of very interesting hallway conversations with several different people and I’d like to capture some of them in a series of articles. I’ll start with this one: how to work with remote or distributed teams?

As a start, there’s always a question I need to make: why do you have remote teams? I mean, there is no real advantage on having your people scattered around the globe. The Agile experts have been telling us that software development is a cooperative communication game for longer than some want to remember. Co-location of the teams is a usual prescription to more effective teams, and even experts outside the Agile environment will rapidly agree that having the team together is better.

So why have remote teams?

The usual answers come in a series of delusional and dysfunctional flavours:

Cheaper labor: oh, yes. This is what your business need: cheap programmers. Besides, have you ever heard about this “total cost of ownership” thing? If you just look at “per hour programmer cost” you are going to miss all the costs associated to having your people working on their own – not as a team – in some other place of the planet. Be prepared for misunderstanding, cultural issues, wrong products, ever-growing bureaucracy…

Cheap Labor

If you pay peanuts…

Can’t find talented developers: well, we all have hard times these days finding talented people. That only means that you have to increase your efforts, invest more in your hiring process and, of course, make your job offer more attractive to candidates. A talented software developer can easily decide between several jobs in these days, why they should chose yours? Honestly, most job offerings I read suck terribly. They only talk about what they want, what they are searching for or the requirements they ask, but there’s hardly a single word to try to seduce and convince candidates. Is this the same way you sell your products?

Remote working as a bonus: in some cases, people will state that they allow their people to work form different places as a reward. That means that working at their offices is a punishment. What does it say about your office environment? MAybe you should work into making your office a collaboration place and then people will be eager to go to the office instead of staying at home.

Cutting costs: some idiots published a series of studies several years ago where they claimed that having remote workers is cheaper for the company: less electricity, less furniture… This might be right if you are hiring for brute-force, algorythmical, repetitive workers, but when it comes to software development the cognitive stuff matters. For software teams, collaboration and effective team work are key to competitive advantage and great products. Do you think that the people behind the iPad were concerned about cutting down air conditioning costs?

Productivity: agains, some study showed that people are mote “productive” when they stay at home – usually because, as we said before, your office environment is ruining any attempt to be productive with meetings and managers interrupting creativity and innovation all the time. But consider that at-home productivity is personal, individual productivity. It means that it also decreases team productivity. You have to ask yourself if you really buy this “teamwork” stuff or you are just forming teams in some form of cargo cult.

No wonder some people go as far as to say that distributed teams are not “teams” at all, just a bunch of people working on the same stuff. So, once again, why on earth do you have remote workers?

There might be some valid reasons, of course. Outsourcing is very usual when it’s not about your core business, and sometimes it pays off to have a talented but remote outsourced team. There are also good examples of distributed teams creating great products on the Open Source community. What makes the difference here?

In the next articles, I’ll write about why co-located teams are better, my personal basic rules for remote team working, several remote working tools and references, the problems of working with people over different time zones, cultural clashes between remote teams and some telecommuting caveats. So… stay tuned!

Posted in Articles | Tagged , , , , , | 2 Comments

New slides!

Hi all!

I have been featured by the awesome people at Noteshelf – for me, the best app for sketchnoting in the market and also an awesome tool for note taking, sketching, doodling and boosting your visual facilitation skills.

I started using it a year and a half ago and one of the results is the new slide deck of our Agile training. Enjoy it!


Posted in Articles | Comments Off

Agile Angel – February 2014

If you like the following post, you might want to join our Agile Angel Monthly(ish) Newsletter and receive them earlier.



Agile Angel Monthly(ish) Newsletter

Issue #6 – February 2014

“Someone is sitting in the shade today because someone planted a tree a long time ago.”

- Warren Buffet

Long time no see!


What can I say? I’M SORRY! No issues since May 2013, even though I promised to launch in November and December… 2013 was a strange year in fact. I committed to send my new book, ‘Agile Kaizen: Continuous Improvement Far Beyond Retrospectives’ to my editor by February, and I couldn’t manage to send the first draft until December. This, added to the many conferences I attended last year, explains the blank in my other writings until now – including the Newsletter. Final edition of ‘Agile Kaizen’  is taking place right now and the book should be available somewhere mid-2014 – you’re gonna love it, I promise!


In the last issue I was just back from Scrum Gathering Las Vegas, which was a real blast. Since then, I’ve been to quite a lot of conferences (you can check them here). You can find links to videos and Slide decks later in this very Newsletter. A special mention to CAS2013, the Spanish Agile Conference, where I got to deliver the opening Keynote and I met Tobias Mayer amongst some other amazing people.


2014 has started fine. You might be aware about the situation in Spain – if not, I’ll summarize: no good. This year everything seems to point out that recovery is sloooo-ooo-ooowly taking place, but macro-economic recovery will take a while until it reaches micro-economics. Still, many companies are contacting us in order to train, improve and prepare for a complex future. We have scheduled a full training week in May (Madrid, Spanish), including Management 3.0, Scrum, Advanced Scrum and Agile Kaizen courses; and, for the European guys, I’m delivering a Management 3.0 seminar in Mallorca with my dear friend and M3.0 Fellow trainer Michael Leber. That’s Mallorca like in “MALLORCA, BABY!”. We even plan to rent a boat for the weekend and do some kind of Leadership Retreat – how cool is that?

I keep receiving reviews of my first book inAmazon, every single one counts to make the book more visible, so if you feel like doing something for me and you’ve read the book, go comment! Jurgen Appelo rated it four stars in good reads, and said it was “a good overview and funny too” :)

Mmmm… What else? Oh, yes! I Started Sketchnoting and drawing after Scrum Gathering Las Vegas and I have plenty of doodles up in Tumblr – Learning To Sketch . I even conducted a “Drawing 101: mastering the stickman” workshop at ALE 2013 and it was reaaaaally fun! Some people even started to illustrate their blog posts and books since then – check  Fabian Schiller’s ‘Agile Planet’, for instance. Sketchnoting is really trendy right now, and it’s lots of fun, be sure to check it.

Upcoming conferences!  This year I want to cut my conference schedule a little, but I’m available to any conference organizers who will cover flight + hotel (this is a must now). I will probably be at Mix-IT 2014 (Lyon, France) and then my Schedule is clear, although I’m in conversations with a couple of events – stay in touch.

As always, I’m looking for new companies to work at this year. If you need Agile training (Scrum, Kanban, Agile Leadership and Coaching, Agile Product Management, Management 3.0, Continuous Improvement, Lean Startup, you name it) or you need someone to assess your Agile transformation, boost change through your company, take your teams to next level or just make your company more Agile, why don’t you drop me a line or two? I’d love to hear about your situation :)


Please, refer us!


Refer us to your Agile pals by forwarding this e-mail, tweeting about it or sharing the subscribing page! (easy to remember: Go share some Agile Love! :)

Our Agile Advice:


A couple of flash-style reflections  to look at your environment from outside the box


  • The old, boring question keeps coming to me every once in a while: ‘what electronic tool do you recommend’. My first answer is to always stick to physical boards. Physical boards have so many features that electronic tools will never be able to replicate, starting with the physical gathering of all team members around them – thus becoming a team ‘Totem’ or even a team’s identity ‘Avatar’ – and including the stimulation of your neurons when you perform something manually. But if you really, really, really need some tools, go for the well know ones (Jira being an obvious option) and be sure to use them as a backup addition to your physical boards.

  • What have you changed in your company in the last six months? Change does not always mean improvement, but improvement always means change – better processes, better tools, better people, better products. If nothing really changes, chances are that you are not improving!

  • When was the last time you read the classics, the sources of all – I mean, “No Silver Bullet”, “The New New Product Development Game”, “Peopleware”, “The Mythical Man Month”, “Scrum and XP from the Trenches”, “The Scrum Papers”… Even if you read them time ago, you are not the person you used to be then any more, and a new lecture will give you new insights.

  • Is there any part of your company where you could be applying Agile principles and methods? Is there anyone willing to try stand ups, post-it notes, iterations, retrospectives…? Have you asked? Why not?

  • Are your products or projects conceived in an “all or nothing” way? If so, there’s little chance of reaching real, full Agility. Evolutive, iterative and incremental design is at the heart of Agile Product Management. Prioritization has small value when you have to wait for the whole pack of features.

Agile Books of the Month:

- Not exactly an Agile book, but I’m using Peter Amstrong’s “Programming for Kids” (Mac edition) to teach the fundamentals of Ruby to my 8 years old kid, how cool is that? :)

- ‘Gemba Walks’ by Jim Womack is an amazing book about continuous improvement and how to look at Status Quo with the Kaizen eyes. Kindle edition was not available for purchase when I checked it today, but I swear I have one.

- Haven’t read it yet, but ‘The Year Without Pants’ became very popular amogst Agilists last year. Specially recommended if you are working with remote, geographically dispersed teams, but also recommended to anyone who wants to get a glance at modern corporate cultures and environments.


Non-Agile, but still recommended book:


- ‘Running with the mind of meditation’. Two awesome practices for mind and body in one  easy to read beginner’s guide – for nine bucks! Who could ask for more?

- “The Sketchnote Handbook”. It will not teach you how to draw, but it will surely motivate you enough to start practicing and learning. There is a Sketchnote podcast too.


Some of the best Agile articles out there:


- Be sure to Check Vasco Duarte’s series of articles about #NoEstimates and new managerial approaches.

- Dean Leffingwell ‘s SAFe model (and certification program) is being talked a lot in the Agile blogosphere. Check for the discussions in your favorite forums O:)

- How to Hire an Agile Coach – terrific blog post by Jason Little

- 10 Things to drive your Product Owner crazy, by Marc Löffer

- Top 10 lessons learned from practicing the Toyota Kata, Tom Lombard, great post from a health care organization perspective


Agile Videos:


Sorry, but this time I’m going to include a lot of my own videos that I did not share yet in this newsletter… :-/


- Infoq did a terrific work editing my Agile Tour London talk on Developing Great ScrumMasters and including the slides. Thank you guys!

- Check also Agile Bodensee: Why Agile? keynote and ALE: Lean Startup for Agile Product Management talks

- Especially for the Lean / Kanban guys: Flow Eficciency (one and two)

- ALE Hangout : Agile Management, with yours trully. This is me talking an awful lot about my stuff, with terrible light, so only recommended for hardcore fans :P

- Shorter one – why write a book, with Jurgen Appelo and me.

- Product Tank Berlin – Control vs Trust – With Stefan Haas


Just not to make this too egomaniacal:

- Agile Product Ownership in a Nutshell, by Henrik Kniberg – really cool!

Slideshare Presentations:


- All the Slides for the above videos are available as usually at Slideshare.

- ‘Some things I’ve learned about facilitating Workshops’, by Sacha Chua. Be sure to check her other slide decks, she’s awesomic.

- ‘Adapting to Agile’, by Mike Cohn

- ‘Hiring or Growing the Right Agile Coach’, by Lyssa Adkins and Michael K. Spayd

Conferences and Training Courses

- Not my cup of tea, but more and more people keep asking me about the Play4Agile events, some even say it’s fun and worth it. You might want to give it a try.

- Remember we are offering the following (Spanish) training courses in Madrid, mid May 2014:


- Management 3.0

- Agile Kaizen Workshop

- Basic & Intermediate Scrum

- Advanced Scrum

–  Be sure also to check our Mallorca Management 3.0 and Leadership Retreat


That’s all folks!


If you have something you’d like to see, promote or recommend on next Agile Angel’s newsletter (mid November, probably), be sure to send me an email or tweet . Until then, may the Agile Force be with you!

Posted in Articles | Comments Off

Agile Angel – April 2013

Hi everyone!

Starting today (June), I’ll start posting last month’s Agile Angel Newsletter in this blog. If you want to get the all fresh Newsletter, be sure to check the previous link and join it! We send just one issue every month or two, so no Spam or high bandwidth required.


Continue reading

Posted in Articles | Comments Off

The Easy Way To Stop Estimating


Wow, it’s been a long time since I wrote my last post… I don’t want to bother you with the reasons, let’s just say I took something similar to a sabbatical – jealous, right? :-D

Anyway, some interesting things happened in the last months. One of them was I got to make a workshop about reducing estimations at XP2012. I already presented something similar at ALE2011, so it seems like I’m becoming an expert on the issue :-D. Here is the video and the presentation I used:

The Easy Way To Stop Estimating – Workshop at XP2012 from Proyectalis on Vimeo.

I realize I should have tested some of the excercises before, as they became somehow messy but, hey, I’m a Spaniard, we like everything las minute! :-D . I also need to impprove my pronunciation, although it feels like I can make myself better understood than a year before, when I talked even faster and with less care on pronunciation. Anyway, we had lots of fun and it seems that some people liked it so much that they invited me to do talks in their own events… More info on that soon (I hope)!

Posted in Articles | Comments Off