On how to go Agile without missing your yearly quota/deadlines

Going Agile in a B2B Company – Part 2

This is the second post about going Agile on a B2B company. Read the 1^st part – that’s where you’ll find the why. This post is about the how.

Well… So much has been written on how to go Agile and what an Agility project looks like. I’m not going to repeat. I’ll be giving some general key guidelines – so that when you go on reading about Agile methodologies you can look at it with the right perspective; When you go to your managers to ask for an Agility project funding and time you’ll come with a good plan; When you speak with an Agile Coach you can see how well he can fit into your Agility project, rather than him dictating you what it should look like.

First thing to know is that Going Agile is not a one-time project thing. It’s a management philosophy. But – if you haven’t been practicing Agility in your company you should start with an Agile project with set goals – ppl like to have clear goals. Still, you should always remember that being Agile should be a general long-term goal. A goal to move fast, to be more productive, to beat competition.

A working company cannot and should not stop everything (development, sales) to have an Agile project in place. No manager would approve that, even in a startup. Most development group is investing about 25% of its time in building infrastructure and refactoring existing code. The initial Agility project would certainly require more resources, but it should not stop every other functional development.

Agile projects are all different because organizations are different and their Agility focus is different. Setting “standard” ultimate goals to achieve in a 6 months project is not realistic. Your managers will not understand where you are heading and what the urgency is (and you’ll miss your quota/deadlines). It’s better to educate your staff with the Agility concepts you want to embed in your process and set short-term goals that people understand. Then continue evolving in the Agile directions.

An Agility project should ultimately reduce development time, shorten release cycles, improve product quality and make your development team happier in general. But these are hard to quantify and it’s hard to “sell” an Agility project to higher management if you talk about these goals. So here is an idea – Start by setting project goals where your product lacks the most in a ways that hurts the SALES cycle and OPs. If you manage to improve here the benefit is measurable, immediate and noticeable. You’ll also make some other department managers happy about your Agility project and it’ll be easy to set new Agility goals.

So if it’s taking 5 days of work to configure each new customer environment – focus to resolve that with the Agility thinking and tools in mind – maybe by automating the installation and configuration process. If your QA cycle takes 2 weeks from code freeze to release – that’s an excellent place to start your test automation. If you’re having troubles upgrading customer’s database every time a new version is released – set fixing this issue as one of your first goals as part of your Agility project – for instance, by moving your database schema to the main code branch, building it as part of every build.

Introduce your managers (group leaders, team leaders) to the Agility philosophy and tools first. Set clear Agility goals for 2 months ahead and get your managers involved early in the process of how to get to those goals in time. Prepare to have some resistance – ppl don’t like changes and in many cases they will see it as an extra workload, even if they agree with your long-term goals. When you have a plan gather everyone and explain them Agility-Why and show them the plan.

Automation… Automation… Automation!

Many of the Agility tools and methodologies involve automating manual work – build servers, automatic unit testing, integration testing and QA automation – all require scripting and batch files. You’ll quickly find that your developers prefer coding in JAVA/C# than in Ant/cshell and that there are only few QA engineers that can script. This means ppl will need to adjust, evolve and learn new stuff as part of an Agility project. I found that I had to replace some of my QA staff with others that had automation and scripting in their background. I had to give some time for my developers to learn Ant scripting so that they can contribute to the Agility project in the short-term and continue developing in an Agile way later-on.

Task force

You’ll surely be creating some new development infrastructure to enable the Agile process to happen. A Continuous Integration Server, updated workspaces/projects for your developers that include built-in emulators for unit-testing, a new product packaging/installer etc. It’s wise to have a task-force in place that would build this infrastructure that would then be used by everyone else. Create a task-force built from engineers from all teams. This will help make sure that planning takes into consideration all relevant aspects and that when the initial infrastructure is ready there are already engineers in all teams that know how to use it and can teach the rest.

The new infrastructure soon affects every engineer’s daily work so it better be stable and solid enough so that it doesn’t break everyone’s work halting development completely. The task force should build the infrastructure and emulators, then the first few unit-tests and scripts on-top of it, to see that it’s actually functioning and can also be used by everyone else as an example. You can also start using the new infrastructure and test automation in parallel with the older process and throw warnings on unit-tests that fail rather than block the process.

In GameGround after the initial infra was developed we took 80% of engineers (everyone but a few left to fix blocker bugs) for a week of writing unit tests. So that everyone had both a chance to experience writing unit tests to their code, use the new infrastructure and understanding how development is going to be changed. This also meant that by the end of that week we also had a significant amount of our code tested regularly by our continuous integration server – 10%-20% of functionality. A good start.

Well, I must say, in reality, it was (is) much harder to achieve… I’ll try to write about the hurdles I’ve had in one of my future posts.

p.s. the post really had little with “yearly quota” – but it comes to show that an Agile project can be done without derailing the yearly planning of the company…

Advertisement

Going Agile in a B2B Company

On why Agile is the right development methodology on non-internet software companies too

Of the 14 years I’ve been developing software 10 years were with companies doing B2B software (intended to be sold to another business, as opposed to B2C – software that is directed at customers online etc.) In recent years the Agile development methodology is growing strong and a recent Forrester study shows that now over 40% of development teams in the US are using some sort of Agile development methodology. I’ve heard of Agile project in some of the larger companies and had a chance of “upgrading” my own development department to work in an Agile environment (we took Kanban as our preferred Agile approach). Now this blog post is not going to be about my experience with Agile. Instead I’m going to tell you about a talk I’ve had with a friend who told me Agile was not for his (awesome) B2B software company and my response to that. So these are the reasons why he thought Agile was not for him:

1. The company’s product release cycle is 3-6 months – They have a larger release and a couple of smaller releases, or Feature Packs, yearly. This is what their sales and channel guys are used to and can handle. They will not accept a daily/weekly/monthly release anyway – this is not how the work.
2. Every other year they have at least one of those larger development projects where they tear apart large parts of the system and re-architect them. This takes several months to develop and runs in parallel to other projects. Those projects will not fit into an Agile development environment.
3. They cannot afford the time it would take to go Agile. They are too tight with schedule to allow their devs to go back and add unit testing to existing code and development infrastructure for automation – and test automation is key to any kind of Agile-ness. Right?
4. Their QA manager is happy with the code he gets and the released product quality is fair.
5. The company is doing well in general – why change?!

At first this all seemed logical to me as I knew that the real power of Agile development lies in the quick release cycles (“give something small to your customers often”) and in cases that the software quality socks. Anyway, with another thought, these are the questions I’ve asked–

• Are you, the product manager (or company manager in a small operation), happy with the time it takes from when you identify a clear customer need to the time you have a new feature that you can sell that customer? If I told you could potentially be in a place to define customer-specific releases that would have the new feature out in 3 weeks – how much does that worth to you? ((AND – your R&D manager is not going to freak-out about this last-minute change, because his yearly timeline is getting fucked and his people don’t like working Saturdays.))
• How much time do you spend before every major release reviewing product requirements and development estimations, trying to fit 30 new features into a 10 features development time. Prioritizing again and again, only to find out 4 weeks before release that 20% of features you were guaranteed to have will not make it on time. Or the deadline must be push.
• How many times did you want something added to the upcoming release, as a large customer deal is pending on it, and your R&D managers said there’s no time and you’ll have to take something out of the release – – or the deadline must be pushed…
• Why is it taking the QA teams 2 full weeks to test a new version release? Does it have to be like this: they first get a version that just doesn’t works 4 weeks before deadline. Then this Ping-Pong between R&D and QA till the version stabilizes: The open bug count starts dropping to the point of reaching the ultimate go-no-go meeting, where the QA manager signs-off the version at the end of an extremely hectic and night-less month. No better way to meet the same goal?
• It happens that the more lines of code we have (and we have more every day) the more QA personal we need. We Often get to the point that the QA manager tells me “…we haven’t had the time to complete the testing of this version…”, “…we need more QA engineers just to complete the STP in time…” – We often release without completing the QA cycle and indeed we often need to patch the version a week or two after release because the version has some major bugs. WTF???
• The product manager often complains that the developers missed some of his instructions in the PRD and that a feature is f**ked as a result. Then the QA manager complains that the version has some features missing and some new features he did not know of and one of the team-leaders told him that some things were changed and showed him a couple this email thread from 2 months ago were those new features were detailed. Well sort of detailed.
• Your development manager is asking for 8 weeks of developer time to conduct a code merge of the new feature that is already tested into the main code branch. The Mac OS-X product was written on a branch that was never merged back to the main branch and devs keep complaining that it’s time we move to a better/modern/faster source control server because those XML files are never merged right and there’s so much manual work to do with every code commit. There must be a better way.
• And the competition is there. They are fast. How come they are faster to react then we are?

Well – you’re expecting this – go Agile.   🙂

I’m not saying its magic. You’ll have to invest time to make it happen. You’ll have to give it some chance and believe it can greatly improve your performance.  Why “Believe???” – – We are engineers (or sales guys) and we have targets and methodologies to work. Why do we need to believe? Because you’ll have to change the way you work. People don’t like to change. People like to stick with processes they know. They mostly don’t see the flaws. They find it hard to believe that it can be so much better.

This is why I think that the goals for an Agile project must be set by a high ranking manager. The R&D manager is going to be involved for sure, but also marketing/product manager, and sales exec for sure as one of the main goals for an Agility project would ultimately be to improve the sales cycle and time to market. So, it seems the division head or CEO is probably the person that should set the goals and allocate the resources for an Agility project.

OK. So you are saying “the above is exactly the problems I see in my company but I’m not the CEO. I’m merely a team leader in the R&D…”  –  Now what? Well, send this post to your CEO – ask for a meeting to discuss the topic. Come prepared. Bring along an Agile couch/consultant. They are used to talking high mgmt. into investing in Agile.

Next up – some guidelines on how to go Agile without missing your yearly quota / deadlines.

Qs and comments are welcome as always.