Project managers are process driven people. In fact, without the processes they put in place, project managers would be out of jobs. When it comes to software development, these guys make sure developers stay on track and don’t run down paths that have nothing to do with customer requirements. Sadly, developers are known for this. Something about personalities… I still don’t get that one. If more developers learned how to understand and speak to customers, project managers would be obsolete…
I digress – The point here is, the Agile Software Development methodology, while it has it’s benefits is a tool for the project managers of the world to help enforce a process that actually is not as “agile” as it sounds.
Don’t get me wrong – for initial delivery of projects, the agile methodology has it’s benefits, but when customers hear the term “agile” they are thinking something a little different than what your local IT organization is thinking. A customer hears a PM sell them on the “agile” development team and thinks, “Once we’ve got our application, bug fixes and improvements will come immediately. This team is dedicated to my project and I can call upon them at a whim for my needs”
As a member of several of these development teams, let me break it down for you. With the agile methodology, any single customer is only as important as their initial delivery. Every development team in any decent sized IT organization has several customers to deal with. Each one of those customers is just as important as the next unless this is the first time you have encountered this customer.
The first time you encounter a customer, that customer is Priority 1. Your team (or usually just the PM and lead developer) sits down with the customer, gathers requirements, and sets a schedule for the development team to follow. This schedule is usually designed for delivery of software within 3 to 6 weeks. From that point, until the end of the period, that customer’s requirements are the only priority because the goal here is to win them over with the speed at which your group can deliver product. You’ll have your daily scrums to discuss any issues that your testers have found, you’ll prioritize specific features against user requirements, and you’ll have two or three meetings on the design/architecture of any particular feature, and somewhere in between, you’ll find time to actually write code. Usually, in a last minute push, your team somehow, miraculously pulls this delivery off just under the wire and the customer is elated.
This will last right up until your customer finds the first problem with the product you’ve delivered – so usually about two hours. Congrats – you’ve just finished your first iteration of the product and now you’ve been tasked with more to fix or improve. Lucky for you, your PM is there to block all of that non-sense. Now that the system is in production, a bug or new feature has to be put into your issue tracking system which will later be prioritized and scheduled against every other issue from every other customer .
This is the point where the agile method ends up being not quite so agile for the customers at least. Sure, your development team is running through about 50 features every 6-week Sprint. And yes, you are spending 50+ hours get all of the tasks you have in this Sprint done, but no single customer is feeling the love because you’re not delivering in an agile enough way specific to their project.
Look at it from the customer’s perspective. You have moved from developing and delivering a full blown production system in 6 weeks to now delivering 2-3 bug fixes and 2-3 feature improvements (of the 30 they’ve asked for) every six weeks. You no longer appear to be this agile team that they were sold on. In a lot of cases, the application is turned over to an operations team that doesn’t know what it takes to keep the application running in production and can’t fix bugs as quickly or as effectively as the development team.
The new and emerging trend is the concept of a “Dev-Ops” team. “Dev-Ops” teams are development teams that are integrated with the operations team to effectively manage issues as they occur in production. I find the trend interesting as a few of the teams that I have been involved in have been doing this for a very long time now. We’re able to mitigate production issues quickly and effectively because our development team is also the operations team. We are not bound by the order of the Scrum and Sprint. It’s a process that seems to work well… that is until you decide to form a process around it, which I do not doubt will happen.
Process is important and the Agile Software Development Methodology is not all bad, but looking at it from the customer perspective it could be more “agile”. I’m in favor of these dev-ops teams, mostly because in my experience they seem to work more effectively for the customer, and if you ask me, how the customer feels is better than any process that makes an IT organization look good.
You’re currently reading an entry written by Tim Tutt
- 06.22.11 / 11am
- agile, agile methodology, agile software development, application development, customer requirements, devops, operations teams, scrum, software development, software engineering