3

I'm part of a small team of four, and I'm the unofficial team lead (I'm lead in all but title, basically). We've largely been a "cowboy" environment, with no architecture or structure and everyone doing their own thing. Previously, our production deployments would be every few months without being on a set schedule, as things were added/removed to the task list of each developer. Recently, our CIO (semi-technical but not really a programmer) decided we will do deployments every three weeks; because of this I instantly thought that adopting an iterative development process (not necessarily full-blown Agile/XP, which would be a huge thing to convince everyone else to do) would go a long way towards helping manage expectations properly so there isn't this far-fetched idea that any new feature will be done in three weeks.

IMO the biggest hurdle is that we don't have ANY kind of development approach in place right now (among other things like no CI or automated tests whatsoever). We don't even use Waterfall, we use "Tell Developer X to do a task, expect him to do everything and get it done".

Are there any pointers that would help me start to ease us towards an iterative approach and A) Get the other developers on board with it and B) Get management to understand how iterative works? So far my idea involves trying to set up a CI server and get our build process automated (it takes about 10-20 minutes right now to simply build the application to put it on our development server), since pushing tests and/or TDD will be met with a LOT of resistance at this point, and constantly force us to break larger projects into smaller chunks that could be done iteratively in a three-week cycle; my only concern is that, unless I'm misunderstanding, an agile/iterative process may or may not release the software (depending on the project scope you might have "working" software after three weeks, but there isn't enough of it that works to let users make use of it), while I think the expectation here from management is that there will always be something "ready to go" in three weeks, and that disconnect could cause problems.

On that note, is there any literature or references that explains the agile/iterative approach from a business standpoint? Everything I've seen only focuses on the developers, how to do it, but nothing seems to describe it from the perspective of actually getting the buy-in from the businesspeople.

Improve this question
1
  • I would focus on the "get build process automated". Everybody should be able to see that this will improve the quality (did we remember everything? is everything available for the builder, etc) and you most likely have a war story of a crucial time where the current procedure went wrong. When you have THAT in place, you are in a much better position to start discussing what else can be done to improve the quality of your product.
    – user1249
    May 27, 2012 at 16:53

4 Answers 4

Reset to default
4

Be careful. First, why is your cio asking for a three week cycle? Find out if you have not already asked. This is critical because he may be addressing a perceived problem with the wrong solution. Find out the specific issue he is trying to fix. Are you perceived as being slow but accurate? delivering the wrong stuff? Delivering the wrong stuff late? etc etc.

If you are unofficial team lead, now is a good time to start drawing in the others. First put together a proposal for the boss which details how you will address the specific problems. It's important here to be a can do person.

A CI build will be a good starting place. Get one of the other developers to do this. If the idea of getting another developer to do something doesn't appeal, we need to address what this unofficial team lead means in practice. It could mean you are being used, and I mean that as politely as I can.

Finally talk to the developers. They won't buy into anything until you talk to them. Find out what they dislike about the current system and then sell them a more agile approach based on how it will improve their issues.

It's all about communication, and I'll finish on this. If you don't get the communication going, at all levels, with the best will in the world, agile will not work for you. It is 90% about communication and collaboration and 10% all the other bits.

Improve this answer
1
  • Basically the three-week cycle is because beforehand we'd never know when there would be a deployment (average was every 3 months, sometimes 2) and we would have the execs wondering when X is going to be live.
    – Wayne Molina
    May 27, 2012 at 16:02
3

Focus on the people and the process and how they interact.

This is a new (well worth it) initiative for the company. I recommend you:

  • Talk you your CIO. I mean really talk. request a lunch meeting perhaps and then lay out your pitch about things like your excitements about the company, the mission, your work, etc. Then pivot to your concerns and how troubled you are and how you want to help make things better for the company so that you can sleep better at night. Also listen carefully to their pitch about exactly what they are trying to achieve (listen first, understand 2nd, ask/suggest 3rd)

  • Appoint a team lead to do all this. You may need to be this person, even if it's not your ideal thing. The company needs to formally fill the position though to give that person the authority to implement these things without a lot of questioning / resentment / double-guessing. They need to be able to make some mistakes along the way too.

  • Focus on small items. It shouldn't be hard to have some things each time, even if it's just changing the placement of the logo or fixing a typo. If you were busy doing a lot of other stuff for a given sprint, that's ok. You have your sprint planning meeting and then you say why this has been the case for the past sprint and what the reasons were. If you're working on bigger stuff that needs infrastructure first then you say that and look at what can be actually delivered in the next sprint. If this happens a LOT that the either 3 weeks is not a good period, or the results of your efforts are not seen unless there is a front end component.

  • Good Communication - a critical part of the job of project lead is to explain to the owners and product owners what's going on technically but in non-technical terms. If there's good communication and trust (those things take time and effort) it will work better.

  • Focus on the benefits that you'll all get from following these Best Practices. It doesn't mean magic or that there will be big changes each sprint but in the long-term, adherence to the process will greatly improve the results.

  • Ask the developers themselves about how to get the various details done, once the big picture is in place from management. Give everyone a task to do that is part of the change. Perhaps one person sets up the ci, another defines the qa process, another the automated build process, another the sprint planning leader, etc. to get buy-in and involvement.

Improve this answer
0

Craig Larman's Agile and Iterative Development: A Manager's Guide is a great manager/business based overview of agile and iterative development. I recommend it highly.

Other than that, I second @MichaelDurrant --talk about this with your CIO.

Improve this answer
0

Wayne, as specialist consultants in Agile adoption, I must say that the recommended approach is to employ a Mentor: someone who has been through the process before, and so knows what to expect and whether things are going right. Often, things are going right: but, if it's your first time, the lightweight nature of Agile will make you nervous.

Michael Durrant gives some very good advice. It is about 'people'. However, you're also correct to identify the need for a process. So, Wayne, choose one and adopt it! As simple as that. The point being that any process is better than no process. And, once you've adopted a process, you can then evaluate how well it is working. Only then can you decide what to tweak or change. Agile is about being daring; yet, because you'll be running in short iterations, it's easy to correct any errors. Being Agile applies as much to tweaking the process as it does to tweaking the software you're developing.

As for producing 'usable' software from a three week iteration cycle. Yes, that is possible. You need to focus on measurable Requirements. That way you'll deliver something meaningful. However, you will not produce a complete software suite with the piecemeal approach -- iterative development is about riquirements discovery (exploration) and risk management -- but, as your intuition is telling you, there's a bit more to it than simply piling iterations on top of each other. Also, as you're using XP, don't forget about the project's future documentation & training needs!

Most Agile adoption consultancies, like Gatethorn, will give some free advice to people who are getting going. Don't be afraid to give them a call. After all, we only know what help our customers need by answering questions on Forums or taking calls. So, Wayne, keep coming back to this Forum if you need help.

All the best, Richard (CEO Gatethorn Agile thinking)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.