Agile Software Development is getting more and more popular in IT industry. Agile is a mindset - pragmatic approach to day to day work which is focused on frequent delivery of fully completed high quality increments of a product. Agile is built on highly motivated, skilled people who can effectively cooperate with each other and on the atmosphere of trust and confidence.
To make an Agile transformation happen sometimes you need a huge amount of time - depending on how big the organisation is and how complex domains of the created products are. During transformation there is high probability that there would be a lot of mistakes and wrong decisions made. Waiting long for effects of the transformation is sometimes the reason for taking shortcuts which are rarely an appropriate solution. Being a time consuming and complicated process, Agile Transformations end up being incomplete and not working as they should (if working at all).
In the last few years I have seen quite a few attempts to agilify organizations, some successful, some not. Let me share my observations on root causes and what can we do to address them :
Error 1: “It’s so easy so why can’t we make it even easier?”
Agile assumes extremely simple approach to software development with only a few necessary rules which are sufficient to build solid and stable basics for optimizing and extending processes. This minimum of rules sometimes is a reason of thinking that “if there are so few rules then probably some of them are not important” and people tend not to use all of those “too simple” rules. You can find good examples of those problems in many descriptions of ScrumBut, like “We are using Scrum, BUT our Scrum Master/Manager is telling us what to do and when is the deadline”, “We are using Scrum, BUT our daily stand-up is not daily”. “We are using Scrum, BUT there is no time for retrospectives”. That is one of the reasons why Agile or that what is called “Agile” can not work properly.
Error 2: “Agile is like an iterative mini-Waterfall”
If you are implementing Agile especially in organizations which used to use “more complicated” methodologies based on micromanagement, you need to remember that some people’s mindset will have to change. It is difficult and sometimes requires a lot of time. People are used to thinking about software development process as steps which need to be completed one by one like it was done in Waterfall during last several years. This is the reason why sometimes I can see dysfunctions like: “first two days of a sprint are for planning and designing architecture, next few days are for coding and in the end if there is still time left, we will have 2-3 days of code freeze when we’ll be testing” or “First two iteration we’ll spend on planning and preparing environment, next few iterations will be coding and in the end there will be two iterations of testing and integration (if we have time)”. Agile is not like Waterfall - things happen when they need to happen, architecture doesn’t need to be planned ahead - it can emerge. Definition of Done should be met for every feature. To easily do that we need to introduce some coding and design practices like TDD, BDD or Continous Integration.
Error 3 - “Agile management - carrot & stick”
A common problem which I often see is wrong understanding of who a manager is. Many people - both managers and line employees think that a manager is a role responsible for planning and distributing work among the workers, and after it is done (or not) accounting them for job well done (if present). Managers especially in Agile could be leaders, coaches, sometimes servants for the team. Decisions, on the other hand - especially technical - should be made by team itself and results of work should be measured by customers’ satisfaction, story points transformed to $, not billable hours. There are two kinds of problems which I can see here:
- Managers in organizations refuse to change their role and are still looking for more power followed by command and control.
- When people who used to work in command & control organisation don’t know how or don’t want to take responsibility for the job they are doing. Responsibility is key in Agile Software Development, everyone needs to feel responsible for what they are doing. Side effects of taking responsibility are visible in better product quality, which allow to maintain the product faster and easier.
Managers who are trying command and control often get lost in an illusion that they are controlling other human beings. This is clearly not true - people control themselves and an organization is just a complex system created by self-controlled individuals.
One of the tools used by managers is the “carrot & stick” method which if used long-term, causes tiredness and lack of motivation. It results in lower velocity and quality of products.
Error 4 - “Not quite a cross-functional team”
Sometimes organizational structures create communication and responsibility silos which block cross-functionality in teams. You cannot deliver DONE features when you have your testers in a different team than your developers and they don’t have the opportunity to communicate with each other. “Cross-functional” means that the team has all knowledge and skills needed to create and deliver done features in every iteration.
People are the key factor in agile software development, only if you have right, skilled and talented people you can think of changing your organization to an Agile one. On the other hand you can empower your team members to improve their skills and knowledge. Everyone can learn how to be agile - the most important is continuous improvement and learning new skills which would be useful in daily work.
Above you can find few out of many common problems that I’ve seen in organizations which wanted to be Agile in last few years. The goal of my presentation is to analyze those problems and try to find solutions which would be helpful and commonly used. One of the real reasons of surfacing of these problems is the lack of understanding that these are problems at all. Some people believe that Agile should work exactly like that.
You can find some detailed thoughts about this topic (and description of few other common problems) in my blog (unfortunately available only in Polish) here: http://blog.testowka.pl/linki/wdrozenia-agile/