Agile – Planning

September 16, 2013 | By | Add a Comment

Having led large international R&D teams, I’ve seen too many managers let their teams do whatever they want and call it Agile! Well, may be it is technically but it is certainly not the process. Planning is a key part of the Agile process and it happens *before* you start the project. Common sense you say? Well, let’s dive into some of the difficulty.

Take two key aspects of the Agile process: 1. Continuous Integration and 2. Automated Testing. I will not sanction an Agile project without these two items. All the other aspects of iterative development, just enough documentation, paired programming, absorbing change at any time etc. assume that these two elements exist so that the project can tolerate such chaos. But, these two are not easy. You need to create a structure, both organizational (people) and development (environment) that will enable and support these.

Let’s talk about the people aspect of continuous integration. “My stuff was working before the India team merged their <stuff> in.” Have you heard that? If so, you are running a team that is not prepared for continuous integration.  Have you then – to “solve” the problem – asked the India team to back their stuff out? If so, you are not prepared for continuous integration. Breaking things is an essential part of continuous integration. It’s like introducing two cats. They’ll always hiss first, then they’ll groom each other and look at you like you fuss a lot! Trust me. Don’t spend too much time trying to figure out what will break. What’s the point? That’s what the compiler and “build together” process is doing for you. Just be Agile. Fix the problem and move on. No one broke anything, they just brought something that would have been broken later to light – and the key word – “sooner”. That’s the whole point. So first, prepare your people for continuous integration and then tackle the easier part of preparing the code repository. This is not a source code control issue, it’s a people issue.

Then, let’s talk about automated testing. Test first? Really? Do you do that? The method is supposed to create test code before product code and execute it and let the product code fail and then you start filling in product code. I’m sorry but this is garbage. Developers – and the good ones – don’t work that way. They understand the problem and think of broad concepts, then whiteboard a design and write code – code to make the problem go away, not to test the problem and enjoy it breaking. It won’t happen. Don’t police this. What’s important is that you – as a team – have thought about the complete test framework. A framework that enables 100% automated testing with validation, not just execution. You’ll have to address this at several levels, component (unit is just too small), feature, product and system. Creating an automated test environment is a development job, not a test job. The skill set you are going to need to get this done is that of an architect, a distributed system and solution creator. Your test teams will be the consumers of this and give you needs. Use one of your development managers to chair this activity.

Allot a significant portion of your planning to these two aspects – continuous integration and automated testing. Continuous doesn’t have to be nightly. In a global development environment “nightly” is hard to define. Require a senior manager or lead architect to oversee the system that’s put in place for this and make sure that it addresses both – people and frameworks.




Filed in: Articles

About the Author (Author Profile)

Bernie is a distinguished technologist from the Mobile industry. Having authored several inventions in intelligence and automation, Bernie launched iDid Inc. and created a mobile platform for Contextual Intelligence.

Leave a Reply

Trackback URL | RSS Feed for This Entry

You must be logged in to post a comment.