I’ve had the pleasure of spending the last three days at an Agile course run by Berteig Consulting. I’d like to seriously recommend Berteig’s courses to anyone interested in Agile . Far from the boring, un-engaging presentations that constitute many professional courses, this course was engaging from the moment I sat down on the first day to the end, thanks to Mishkin Berteig, Mark Levison and Jim Heidema (surprise guest) who ran the course, and the interesting participants that attended.

While I learned a lot during the three days, the course has really help crystallize my thoughts on why Agile can work. I’ve seen Agile working well for many of our teams and our customers at Architech, and now I think I understand more than ever why that is. There are many intuitive aspects to Agile that ring true to seasoned technical professionals. It was clear to me that any successful project I’d ever been involved with had already embraced many of the aspects of Agile development already, such as constant communication, focus on quality, and so on. But Agile takes it all a step further. I think now I can see why some of those things work, so here it goes.

Why Agile development (specifically Scrum) works (or can work) for everyone (especially those building software products):

• Agile adapts to change. In fact, change is embraced in an Agile methodology. Change is a fact of life, and pretending that we can see into the future and build to a single unchanging goal has been a fantasy of the IT industry for many years. We’ve all realized it just doesn’t work, and more than ever business and technical environments undergo change (monthly if not more often). Accepting and dealing with this fact is a huge strength of Agile.
• Agile supports the creative process. The process of software and technical solutions development, whether you like it or not, is almost as much of a creative process as a scientific one. Creative processes are hard to predict, hard to model, and cannot be shepherded along by fixed predefined steps. Agile allows for the creative process to occur within teams through collaboration and focus on the team and the individual, rather than on process and methodology.
• Agile allows every team to be a consulting group. Agile’s focus on the team and its ability to deliver end to end value in an application, makes each team somewhat independent in terms of affecting change and delivering value. In this sense, each Agile team is allowed to perform and can be seen as an individual group of consultants. The idea of ‘big IT’ is one that is finally starting to fade. As people realize that massive groups of departmentalized people are often no more affective than smaller effective, ‘flat’ teams of individuals, there’s more need than ever for everyone to play the role of a consultant, being adaptive to the next change and the next project.
• Agile exposes hiders. We’ve all seen these people in ‘big IT’ groups, that coast along week to week delivering nothing and often leaving chaos in their wake of their apathy. They manage to hide and shelter in the noise and chaos of the large corporation. In an Agile team, it quickly becomes apparent if a team member is failing to be involved or to care and do their best to deliver value. In fact, it will be made uncomfortably obvious who these people are on a daily basis. The best part is that Agile can help people who might be struggling with their skills or understanding, but truly want to deliver value, by giving them the opportunity to do so. Agile demands a lot from a team member and will bring out the best in a team if done well. It will always make it clear who are the hiders who are simply in the wrong place and the wrong role or team.
• Agile allows for team building – real human team building. Top level down, structured processes don’t work for people. It’s hard to build cohesive teams with hand off responsibilities between members – these kind of roles and processes foster the ‘it’s not my responsibility’ mentality. Agile methods work differently by focusing on the team and encouraging the teams success, by allowing them to work together to resolve process that works for them, and having them succeed or fail as a group. This makes it a more human centric methodology. And the bonus is, that successful teams deliver more than individuals and heroes alone.
• Agile gives ownership back to the individual. By making the day to day process of development open, it becomes clear to any team member how he or she is contributing. When someone can see the difference they’re making, and the impact they’re having, this gives a real sense of ownership to them.
• Agile removes ‘us’ versus ‘them’ islands. By including the business directly in the project (in the role of product owner and at end of sprint demonstrations), the business is constantly engaged, and being given clear visibility into a project. Being able to see what’s happening and have a say in what’s next increases the level of engagement and removes the common feeling of division that occurs without visibility. Studies have shown that a client who is more frequently consulted will be happier with the results, regardless of the level of success. In addition, a sponsor or stakeholder who can really see what’s occurring with a project team is more liable to trust that team and understand when they’re asking for too much.
• Agile removes pain points. By seeing continuous improvement, removing defects constantly, and by having input into what’s next, many smaller ‘pain points’ are removed. When a business owner and application user sees frequent deployments that constantly remove those niggling issues in the application, people are liable to be able to cope with whatever features are still missing. By removing those smaller pain points, people can see the bigger picture and accept that change is ongoing.
• Agile encourages learning. We don’t know everything, and we certainly won’t know what we need to know up front. Agile encourages a team to just get going and figure things out as you go. While this can be somewhat un-intuitive, it really, really works. Even if a sprints worth of work is throw away, getting going and learning that lesson is more value that sitting around in ‘analysis paralysis’ mode.

One way to summarize all of this is that Agile allows for people. As humans we think, and have been taught, that we work in certain ways. Often times (especially in artificial environments like companies and new teams) we don’t work how we might expect. Agile takes account of humans being human beings, and the tenants that make up its methodology take account of the way we work. That is to say, not the way we traditionally thought we might work or the way economists and process people have necessarily traditionally thought we might work, but in the ways that studies and science are showing that we really do operate. I’m sure some of that has come about by design and that some of it has come about by observation and continual improvement (another word for this is learning – how Agile!). In any case Agile seems to acknowledge that people aren’t always perfect.

Agile isn’t a silver bullet. Agile teams can clearly still fail. It’s hard work to do Agile well, but for those people who want to perform and see results, embracing Agile methods increases the likelihood of success greatly over more traditional methods and therefore well worth the investment.

Are you embracing Agile methods? Why have you seen it work or perhaps fail? I’d appreciate your thoughts.