Doing Agile software development. Why it's not going to help.
If your company wants to get some training for your development team so you can “do Scrum” or “do agile software development” let me save you a bunch of money in training fees and development time.
- Stand up in the morning
- Plan your work in 2 week blocks
- Throw a couple of ceremonial meetings at the beginning and end of the two weeks to talk about it
- Get your business analysts to rewrite your requirements in the form of user stories
Now you can claim to be “doing agile” while still only releasing your software (probably manually) to UAT every six months and nobody else needs to worry. Right up until the point where your stakeholders or worse still “the business” gets upset that their requirements they documented a year before weren’t met and you end up in the same mess you usually do.
Sound cynical ? Well yes, maybe. But unfortunately this is the experience of so many teams and companies that I get to see.
The problem is that “agile” isn’t about how you run a development team, it isn’t that you have a daily standup, it’s about how you, as a company respond to the inevitable changes in your business.
It isn’t a software development methodology as much as it is a way of doing business.
A lot of companies that decide they want to try agile development don’t take it quite far enough and as a result never really see any value. Even if they manage to convince everyone about doing a pilot and getting some stakeholders on board, they usually do so with an essentially fixed scope and never organise the final step of being able to actually deliver in increments.
So the project starts, they may get regular engagement from stakeholders throughout the business, but still work towards some large end goal and don’t release until they get there. As a result, the projects rarely actually deliver anything faster but the development team have been drawing on the time of other people in the organisation on a regular basis. I often see businesses that have an agile fatigue and the next time around the team get a pushback because “the business can’t commit to the time every week”.
Sound familiar ?
How to do it right
The teams and companies that I see that are really agile find a way to release things early, and release things often. The developers within those teams will go and understand a problem, then go build a small piece of the puzzle and sit down with the people who need to us it and ask “does this help you do your job better / faster ?”. They take feedback. They improve it. Because they are able to ship changes regularly (and yes, Continuous Delivery is a topic for another day) the changes that get suggested are a reality in a short timeframe.
The result ? The engagement level within the rest of the organisation starts to grow. Why ? Because people see their input as being valuable and tangible. Not filtered through a vast and long running system of Business Analysts and specification documents. Solving problems quickly.
I know the reaction to this, “Oh it wouldn’t work in our organisation”. Yep, I’ve heard it before. Yet I see this work in those places. Publically listed Financial Institutions, large ecommerce operations, even Government Departments. It works.
It works when you allow an environment where people can get their hands on working software really quickly and have an open channel of feedback. When you have this, and you seek out the feedback and direction, and by that I mean actively collaborate, you get agility. It’s at this point that when your organisation is faced with a legislation change, you aquire a new customer or a new business with different needs, or anything else that triggers a need for a fast change, you’re in a position to get there. You already have a team which can be agile, you have deployed software in place and making changes is not difficult.
That is agile.
Standing up every morning and putting Post-It notes on a whiteboard are tools, not the end game.
comments powered by Disqus