Creating An Agile Culture

[img_assist|nid=1518|title=|desc=|link=none|align=right|width=250|height=167]My mission in this article - to get rid of the illusion that your Software Development Process determines if your company is ‘agile’ or not. It’s down to the culture, the mindset.

To prove this, we have to go back in time a bit - to February 2001 actually - where the Agile Manifesto was set down. It’s amazing how many people read this, and don’t pay attention to what’s said. To summarise:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

So, point number one, says that’s it’s about the people in your team and not the process you’re using. I’ve even heard people go as far to say that you can still be agile using a Waterfall process - after thinking about it, I don’t disagree.

So, the key thing, is responsive, responsible individuals on your team who are focussed on the project outcome.
To get the whole thing right, there’s a few values that need to be maintained. Here’s my list of what those things are:

1. Communicate
   The standing meetings concept (mostly from XP) is a good one. Don’t worry about having a meeting for the sake of it - invariably, someone will have something to say - and if there’s nothing important, the meeting will be over quickly anyway.
   Make sure that all team members give updates on what they are doing. Something you think isn’t important might be vital for someone else to know.
   Keep the test team involved (there’s a tendancy for developers to leave them out) and make sure to leverage their experience.
   Encourage desk reviews of code and design with all the stakeholders.
   Everyone should try and inject energy into the team - if everyone feels empowered, encouraged and motivated, you’ll have no problems reaching the project goals.
2. Blame Doesn’t Fix Bugs
   Solution oriented people are much more useful than problem oriented. That’s a known fact - and it holds true in software development too. Casting blame makes people feel defensive, while being constructive makes people feel empowered. The focus needs to be on outcomes, and the team should work together to find ways to solve problems, rather that over analysising them.
3. Fix Misunderstandings
   This could fall under the communications category, but I thought it’d be good to add in as a seperate issue. Consider, if someone misunderstands a requirement, API call or a decision, chances are someone else has also misunderstood. So, when you’re addressing one persons misunderstanding, make sure everyone else knows about the clarification too.
4. Keep It Simple
   Ask yourself if what you’re about to do is required for the project outcome. You’ll be surprised how many times it isn’t. Don’t write documents unless you really have to.
   A simple design always takes less time to finish than a complex one, and is a lot easier for everyone in the team to understand.
   Keep things as simple as possible for as long as possible by never adding functionality before it is scheduled.
   I looked at a Standish Software Survey graph - it showed that there was 45% of features that are never used. NEVER! So I definitely don’t want to spend my time working on Never Used stuff.
   That alone is motivation for me to make sure what I work on is relevant.
5. No Broken Windows
   Anyone that’s read The Pragmatic Programmer will be familiar with this.
   The experiment carried out goes along the lines of leaving a nice car in a dodgy neighbourhood. They come back a week later, it’s still there in perfect condition.
   So they break a window, come back the next week and the car is burnt out.
   Why? Because they started a pattern of disrespect.It’s the same in software - no one wants to be the first to start this pattern - I don’t want to be first to introduce a defect. So if we repair any “broken windows” as soon as they appear, everything will be in prestine condition for the duration of the project.
   This really is worth noting - maintain high standards in everything that you do.
6. Embrace Change
   Decisions - in software they’re not cast in stone, they’re written in sand. Things will change, and there’s no point complaining. If something does change it’s for the good of the project outcome.
   Embrace change (as XP would recommend), or just roll with it.
   Don’t fixate on a given plan, respond to the changing environment and learn.
7. Be Flexible
   To be truly agile, you need to be able to cross disciplines - leading, coding, testing, requirements, fixing a machine - take it all as part of your daily job. You’ll increase your own learning, and value to the company.
   Be ready to do everything!
8. Keep Everything Releasable
   If you’re a tester this is easy to understand, if you’re not just imagine you are for a second.
   To test or check progress, you need to see output - whether it’s fully ready or not. You don’t want to be told that you have to wait a day for a build!
   Everything should be ready to pass on at any time. It’s easier for everyone involved.
   It doesn’t need to be perfect, it just needs to be transparent.
9. The Big Picture
   Understand the business and big picture implications of all decisions.
   This may be done by a Product Owner – (this could be a committee, Requirements Engineers and Architect). If using a product owner concept, use them as a “Customer”
   People need to be reminded of this vision by the Product Owner.
   To forget what the outcome of the project needs to be is the worst type of failure.
   If we keep selling a vision, people will believe.

So there you go - my opinions on real Agility.
It’s all down to the people and their mindset. If you have a team of developers following the above values, you can use any tools/processes that you want, but you will have agility.