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?