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?

Technological Dysentery Disorder – A guide to coping

Have you ever met someone who blurted out random technologies or methodologies, at seemly random and inappropriate times? And furthermore, it seems like they are talking out of their you know what? If you are anything like me, then you have had the misfortune of having to cope with this.

Technological Dysentery Disorder (TDD) can afflict many people, from project managers, to sales, to executives, customers, developers, or even in rare cases, QA. Unfortunately, there is no cure for this disease, but simple coping strategies can help mitigate and alleviate the symptoms. It is especially serious when it affects QA, as a QA’s role often dictates that they bring sanity to the projects, and keep the rest of the team in line. When TDD strikes the QA, this is a worst case scenario, just like when illness strikes frontline healthcare workers.

One of the best coping mechanisms is to understand why the flare-ups are occurring. The two main causes of TDD are:

• A desire to appear intelligent in front of peers, subordinates, and/or vendors
  
• A strong fascination with technology, a fascination that is so strong that every single problem looks like a nail that needs to be bashed with the mighty hammer of technology
  

Understanding the underlying reasons for these outbursts will be very useful in helping you keep your patience when dealing with those afflicted.

Another important coping strategy is to refrain from engaging in debates or arguments about technologies or methodologies except when absolutely necessary. Engaging in debates on technology in sales or standup/status meetings is not ideal, you will end up going off on a tangent and wasting everyone’s time. Instead, focus on solving the underlying problem instead of focusing on the technology.

When you are dealing with a stakeholder who is suffering from TDD, try to guide the discussions away from technological, framework, or other non-important issue, focus on the problem, not the technology with which to solve it.

At the end of the day, an expert is a problem solver, not a technology implementer.

Agile is not a process, it's a mitigation strategy

Fellow Macadamian, founder, and Chief Architect at Macadamian has written a great Critical Path article on why design thinking is failing to penetrate software companies.

I had an AH-HA moment when Francis mentioned that "Agile is not a process, it's a mitigation strategy". Truer words have never been spoken.

If you are interested in more about what Alan Cooper thinks about design and Agile, catch his keynote address at Agile 2008, it was very controversial.

This is his complete slide deck and his speaking notes, sorry, no audio. If you want to listen to the audio, one of the attenders of the conference taped it.

A Time appreciation by any other name...

The "last responsible moment" is a term that is talked about a lot in agile and "flexible product development".

The most recent edition of the edition of the Agile Journal has a neat little comic talking about how you calculate the last responsible moment.

As I was reading through this comic I came to a realization, it is what the military would call a time appreciation. You start with when you need the task to be done by and work backwards. It is a pretty simple exercise in logical analysis and problem solving.

In other words, no smoke and mirrors.

Who wags who?

It's an old joke to ask if the dog wags the tail, or the tail wags the dog. The saying fits in many contexts outside of media, including the age old battle between testing and engineering, or the usability of the application, and the technical design of the application. Do the user experience (UX) folks design without regards to the technical feasibility of their work, or does the engineering team dictate design by imposing technical constraints?

Jumping in the way back machine, five or six years ago I was working on a large web application, it was Macadamian's first project where the engineering team implemented the output of an interaction designer. When asked, I told the designer to go ahead, don't let technology limit your designs. Sure enough, we ended up creating an impressive web application (see left) with all the bells and whistles of a rich internet application, all back in 2003. I also lived at work for weeks implementing all that cool stuff. I wish I had read this article back then!

At Macadamian, we have had a world class user experience group in-house for the past few years. Learning to work with this new UX group was not an easy task for a primarily engineering and quality assurance company. It took more then a couple of months to work out the process for collaboration between UX and engineering. Everything Tim has discussed we have also learned, the hard way.

Being that I come from the engineering side of Macadamian, and that most of the costs of the project are on the engineering side of the project, the point that jumped out at me the most was the suggestion to listen to the concerns of the developers.

The first few combined projects between the engineering and UX group resulted in significant schedule delays and cost overruns on the engineering side due to really good, really cutting edge, and extremely difficult to implement designs coming out the UX group. When the estimates were created, the estimator put time in to basically add some form fields, text, and maybe a graphic or two. Pretty naive.

Unfortunately (or fortunately depending on your perspective), the customer saw these designs, loved them, and then expected to get them for the same price as that form with 23 checkboxes and 97 form fields. The complexity and innovation required on the UX side was not expected on the fixed-bid engineering side.

To solve this problem, a simple (and in hindsight, obvious) process improvement was made. The developers had a chance to look over the designs prior to the customer seeing them. This allowed any potential design decisions that would adversely impact the schedule and cost to be caught, and fully discussed prior to the designs being approved by the customer. It wasn't that engineering had a veto over the design, it was allowing the usability group to be made aware of any potential technology challenges to be discussed earlier in the cycle.

This allowed the two groups to work closely together and solve any potential issues. Sometimes the UX folks were able to convince the developers of the critical nature of the particular design, and other times the user experience group came up with another solution that was just as usable, but much easier to implement. However, don't confuse this approach with one where technology drives what personas can and cannot do with the product, that would be a mistake. User needs have to drive the design.