Hyper-Productive Distributed Teams?

Agile and distributed development are not supposed to be able to co-exist. Co-located teams are supposed to be one of the key tenants of Scrum.

If you have this (mistaken) belief, then you need to watch this video and presentation. I actually attended this presentation at Agile 2008 in Toronto. If I remember correctly, there were a few skeptics in the room.

The key points are:

• Ability to leverage benefits of distributed development
• Fully transparent teams
  
• Seeding new teams with talent from existing teams
• Automated tests
• Continuous integration, nightly builds, automated tests, performance testing the whole 9 yards
• High quality developers in both locations
• A tight definition of done
• Travel between the two locations
  

I think the travel between locations is a key aspect of their success, remember that both "sides" of the teams have to be equal. Equal in "power", information, and influence, and treated equally in terms of inconvenience. The "remote" guys shouldn't always be the ones staying at the office late.

Another important point to distributed Agile, or even Agile in general is that practice doesn't make perfect, practice makes habit.

The presentation wraps up with the potentially explosive statement that distributed Scrum has more value then local Scrum. What do you think?

Performance Reviews for Developers

It is getting close to that time of the year again at Macadamian, that's right, review time. Luckily however, it is mid-term reviews instead of the full year end reviews. This time of year always gets me thinking about how we review our employees, and to look around for new ways on how reviews could work.

This year I stumbled across the Cockburn-Boehm Levels of Developer's Competency. The focus of this approach is not measuring performance on generic skills, but rather in terms of how to approach software construction projects. It's not about the skills of developers; rather, it's about the characteristics of the developers.

There are 5 basic levels in the scale, higher is better:

1. Level 3: Able to revise methods and methodologies to fit unexpected and unprecedented situations.
2. Level 2: Able to tailor a method to fit a new situation that is expected.
3. Level 1A: With appropriate training, able to perform discretionary method steps, such as estimating features, tasks, and user stories, complex refactoring, etc. With training, can achieve Level 2.
   
4. Level 1B: With training, able to perform simple method steps, like implementing methods, simple refactoring, following coding standards etc. With experience and training could master some Level 1A skills.
   
5. Level -1: May or may not have technical skills, but is unwilling and unable to collaborate in a team environment or follow shared processes. You don't want these people on your team.
   

Then name of the last (and worse) level is illustrative and telling. You would think it should be "Level 0" based on the pattern, but someone is a Level -1 is not a zero, because not only do they not contribute to the team, they actually drag the team down.

Developers at this level decrease the productivity of the team, either through their lack of technical skills, or worse, their poor attitude. A positive, constructive, can do attitude is more important than technical skills. You can usually train people on technical skills; it is much harder to change someone's personality.

Leadership in hard times

It is much easier to be a leader when times are good, when business is plentiful, when the sky seems the limit. The strains put on a leader in bad times are much greater, and this is where you you separate the leadership wheat from the chaff.

A co-worker of mine sent me a newsletter that had a great article on how to lead when times are hard. I hunted around a bit to get the corresponding web page for this article so I could share it. If you are leading people in a company highly recommend that you read this article. If you are not responsible for leading anyone, read this article.

When Macadamian recently had to make some hard decisions, I agonized on how to communicate this to the teams that worked with me. I spent hours thinking about how to effectively communicate the rationale, the plan, and how we can together move forward and succeed. It was the hardest thing I have ever done and I am glad I spent the time to prepare for it.

Is your company experiencing hard times? What are you doing to be an effective leader during this time? What behaviors have you changed?

Whatever it takes

(Well almost.)

Pawel Brodzinsk over at Software Project Management wrote a blog about why developers should work on crappy machines. To sum the article up, developers should use crappy machines to force good programming practices on them, and to some extent, good usability. I am sure that most of the reasons behind the post are related to the frustration users feel for having to deal with bloated, slow performing software, or software that doesn't display right on lower end resolutions; and in that, I wholehearted agree.

However, where Pawel and I differ is how we should deal with that. There are two main complaints in the article,

1. Bloated memory requirements of many applications
   
2. Usability of applications on smaller screen resolution sizes

One of my most important missions as a project manager at Macadamian is to make sure that my developers can work as fast as possible. I don't mean to hack out code without regard for technical debt, but that their tools and the processes don't slow them down. Yes process is necessary, but the right amount of process can make the difference between highly motivated, self-organizing teams able to efficiently collaborate between distributed locations, and teams that are swimming in quicksand unable to make a release to save their lives, or their companies.

Their tools need to be top notch, their development machines are dual or quad cores, 4 gigs of RAM, big and fast hard drives, and dual monitors. And yes, some developers still complain about the setup :) We also invest in tools like IncrediBuild to build code faster, and IT infrastructure that can allow you to copy large amounts of data across the network as fast as possible.

I don't want my very talented, and very expensive developers wasting time on waiting for projects to build, new versions to push to production, or code to checkout. If a fresh build takes much more than a 15 minutes to build, you have just lost thirty or more minutes to a game of foozball, a Starbucks run, or a YouTube foray.

So how do you deal with such things like usability, and performance requirements? Simple, engage in formal usability work and create formal requirements on performance that are monitored and enforced by your testing team.

A proper usability team cannot only design UI that can scale to multiple resolutions, but is actually usable by the end user. They can apply actual scientific research to solve usability problems. And you will get the added benefit of having wire frames that your developers will be able to rapidly develop with less iteration and confusion. A picture is worth a thousand words!

This leaves only performance requirements that need to be tackled. Developers can follow requirements (no really they can!), especially when monitored by your testing team. The memory and processor usage, install size, and overall performance characteristics can be defined in the project requirements. The testing team can then apply tools and process to ensure that these are met, and log bugs if they are not.

An excellent testing team takes responsibility for the overall quality of the application, they don't just run test cases. This will mean they will ask questions like "All I did was log into the application and it is using 123 megs of RAM. Why is it so high?". Your testing team does look for memory and other resource leaks as part of their testing don't they?

The Fall of Agile?

Switching gears a bit from the last post, I recommend you read "The Decline and Fall of Agile".

I agree it is a common misconception that Agile is easy, that Scrum will solve all your problems. That daily scrums and sprints are the path to the rapid delivery of high value software. Many people and organizations say they implement Scrum, but in reality implement "Scrum but". Unfortunately the "but" tends to be the lack of strong engineering practices and a strong Product Owner. Now there is nothing wrong (in theory) with "Scrum but", as a service company, not all of our customers will accept a Scrum methodology, or, we need to follow their development process, some of which are very heavy-weight. But, you need to strive keep the important pieces of Scrum, and the corresponding good engineering principles. While Scrum is a MANAGEMENT methodology, don't forget the engineering part.

In my opinion, the most important pieces of Scrum include:

• The daily standup
  
• Strong collaboration tools to share knowledge and keep everyone informed.
  
• Constant communication with the customer (product owner) and the team
  
• Short iterations
  
• Engaged and highly motivated teams
  
• Motivated product owner

In addition to these management principles, some of the strong development processes we use at Macadamian include:

• Peer review - all code is peer reviewed by at least one other developer. In addition, the test cases the developer used in his testing are also reviewed by a QA that is on the team.
  
• Daily builds - All builds are run daily, failures are reported to the team immediately. The person who broke the build is severely punished by having to buy donuts. 
  
• Continuous integration - Builds are run whenever a developer checks in source code, this aids greatly in the integration and helps catch build regressions.
  
• Automated tests - These tests are run as part of the continuous integration environment, and prior to any patch submission.
  
• Design review - All design is reviewed by the team prior to being implemented. It helps catch any missed requirements and shortcomings in the design. The design can be as simple as some boxes on a whiteboard, or even some interface declarations. No UML is required.
  
• "Wide and Shallow design" - Helps catch fundamental design issues before any of the actual implementation has been done. This allows a more senior developer to help “bootstrap” a project and leave it with a solid foundation for the more junior developers to fill in. Because the design is only stubbed and not cast in stone, the design can still evolve in an emergent fashion.

What do you think? Anything you would add or remove?

From an Agile Legend

Martin Fowler is very well known in the Agile community, in fact he was one of the authors of the Agile Manifesto. Nearly three years ago he wrote about how his company was running Agile companies with teams in Europe, North America, and India. This was quite a few years before most companies were attempting to work on Agile projects distributed globally.

For the last four years ThoughtWorks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we've discovered that we can make it work, although the benefits are still open to debate.

These are all lessons that Macadamian was learning during the same time frame, and I sure wish I had seen this guide to running Agile with offshore development way back in 2006. I read this quite some time ago, but I believe the lessons and practices in contained in this guide should be re-read, and reinforced.

If you are working on distributed Agile practices, or are planning to, read this! Don't learn these lessons through the school of hard knocks. :)

Top 5 Agile Mistakes

A good post over at Agile Software Development on one team's top 5 mistakes on their first Agile project.

They are pretty classic mistakes, and some of them don't relate at all to Agile. Scope creep, and boring demos are widespread in all companies.

It is important to demonstrate features via use cases, it is something tangible and real. Demonstrating abstract back end technology pieces is exciting for geeks, but not users and they won't be able to easily relate what they see to how it will affect their jobs.

Just Lead It

Oh Nevermind! I will just do it myself. It will be much easier, you think to yourself.

How many times have we said this to ourselves, or worse, to someone on our team? How many times have we thought it would be less stressful to just do the task/project ourselves instead of trying to explain the problem to someone else?

Now be honest.

Often? Yeah, me too.

This is a common anti-pattern, especially in the global context when explaining a task with little overlap in time zones. This is where it feels like it will take more time and energy to explain the task then to actually do it yourself. You rationalize this in the name of efficiency. You are being more efficient. Efficiency is good.

Don't fall for this trap! It is an anti-pattern. You cannot be more efficient then a high calibre, well motivated team.

This anti-pattern will have a negative effect on your team's morale as they will see you as a micro-manager. Or worse, they will perceive that you don't trust their abilities. Furthermore, if you don’t take the time to mentor your team members, or provide new and interesting tasks for them to improve their skills on, they will never get better at their jobs, and their morale will suffer. The team will never improve and you will be stuck in a rut.

As a manager your job is to ensure the task is completed as efficiently as possible. Your job as a leader is to look out for their well being, and do what you can to inspire them. A simple rule is to try very hard not do things that will affect your employee's morale; a well motivated and happy employee is a productive employee. A productive employee is an efficient employee. Efficiency is good.

Another part of this anti-pattern is that if you are heads down implementing features, who is leading and managing? Who is looking out past today, or maybe this week? Who is reporting status to the customers, identifying potential risks, building relationships with the customer, or even looking out for the next opportunity? No one is, since you are now focused on the tactical instead of the strategic.

You are creating “project debt” by “doing” instead of leading. Sure it might feel good to make progress on your project, to contribute to the critical path. Maybe get it out the door sooner, perform some technical kungfu. However, you are incurring a lot of “project debt” to do this. At some point “project debt” comes due, and it might be paid for with a missed opportunity, or an unhappy customer due to a mismanaged relationship.

So we recognize that this is an anti-pattern, how do we assign and explain tasks efficiently?

1. In a push task management model, assign tasks several days in advance, and instill a mindset that the team reviews their tasks as soon as they are assigned, even if they don’t plan on starting the task right away. This will allow the team to look at their tasks and seek clarification or answers ahead of time, before they are actually trying to perform the task. Sometimes their questions will flush out missing requirements that might need to be thought about with the customer or product owner as well.
   
2. The same thing applies in a pull task management model, encourage your team to pull the tasks ahead of time, so they can ask any questions they may have before they are blocked for a day waiting for you to answer their questions, or in some cases, wake up.
   
3. Explain the tasks in person, or over video/voice. Follow up with a written explanation. Email works, but a wiki is better. There will be more transparency to the rest of the team, and it will be easy to keep the wiki up to date when things change. We all know things will change right :)
   
4. After you explained the task in person, ask questions to make sure they understand, especially around requirements and any time sensitive pieces.
   
5. In some projects, we use a concept of a “design patch”, in it the developer explains their development approach, basically how they will implement the feature, and how long they think it will take. This isn’t to micro-manage, but often will highlight any lack of understanding. It also has the benefit of improving the teams planning skills and ability to do top down design.
   

Those are five quick ideas I have, how do you delegate tasks?