A lot of times I have been told that being Agile is all about attitude, a statement which I could not understand until a while back. I thought like in every process if you do X, Y, Z you become Agile. However lately I have realized that Agility is not just about burndown charts, having planning & retrospective meetings or doing you daily stand-ups.
Being Agile is an actually an attitude, which may sound gibberish but in this post I will try and make some sense of the this "attitude" and try to make it more tangible. So if you are doing planning poker, burndown charts and all that jazz that is great but you should still item about these not so obvious things -
Trust
I talk a lot about trust in my blogs, but what is trust in professional life? In a Scrum project, you can ask yourselves the following questions -
- Do you trust your developers to do the right thing every single time?
- Do you trust the estimates your developers are giving you?
- Do you trust the estimate of the developer even when you see him doing something not related to project?
- Do the developers trust the product owner that the backlog is sufficiently refined and prioritized?
- Do the developers trust that the Scrum Master is helping them?
- Do you trust the Product Owner that he has the larger plan and release date in his/her mind and every action takes you towards that release date?
Trust takes a long time to build and breaks with one small action. The Scrum master, product owner and the developers need to really trust each other if Scrum has to succeed. For example the PO who doesn't trust the team's estimates will always think that the developers are slacking and keep pushing them to do more which will ultimately destroy the team morale and the project.
Courage
Agile or Scrum does not fix a single problem. Yes, that is true! I will only highlight and identify some problems as quickly as you allow it to. One can do all the retros in the world but not have the courage to break the bad news or become the bad guy who bring the bad news. For example, the release backlog is no where near the state it should be or the developers don't have the tools they need, this will be easily identified in the sprint demo or retro but a lot of times people choose to postpone it or ignore talking about it let alone taking tough decisions like backlog pruning or reducing features. Courage can be in simple things like cancelling a phone call if the phone line is not clear, even do it multiple times forcing change to a better communication solution rather than sleep talking on calls.
One should encourage the people who dissent, who shout and scream when they feel something is not right. Most of the times these people will help you avoid the proverbial iceberg.
Motivation
Motivation is a huge thing, and sometimes even Agile will not even identify it. Motivation degrades over time in situations where product is not released for a long time, there are constant changes within the sprint, there is mistrust among the team members or worse case some team members are disgruntled by organization policies or work culture. This situation demands extreme caution and monitoring that falls outside the Scrum purview. This can be indentified while going for team lunches, having one-on-ones with senior management or sometimes encouraging people to vent out their negative feelings. If any de-motivating factors are identified they should be fixed as soon as possible otherwise Scrum or no Scrum, the project is doomed.
Sense of Purpose and Sense of Achievement
The essence of a Sprint is to provide the team a sense of purpose and focus towards a limited set of problems or functionalites so that they can just think about a few tasks each and focus working on them. Developers work in a state of flow, they like it when things are organized and they know exactly what they have to do and what is the next item on their plate and nothing else. I have found programming to be a greater joy when I know exactly what is needed and the business value it will deliver. It makes me believe that my effort is helping someone and is driving the project forward. Same thing goes for a Sprint demo, if your spring demo is successful, celebrate a little, take the rest of the day off for open-source or gaming or whatever you fancy. Success and appreciation are highly addictive it will keep the team coming back for more.
Team Composition and Working Style
Software projects are hard, not only technically but also in terms of team dynamics. Developers meet new team members, work with them for a while and the team is disbanded in six months or so. The whole process repeats itself time and again and is emotinally draining. The best performing teams I have met are the ones where every team member enjoy's the others' company, cracks jokes, pulls pranks on each other and even enjoy the blaring music on their teammates' laptop. This is very hard to achieve and I think the only one way to create such teams is being cautious during interviews. Try and identify the organization culture you want to develop, put it on your website, identify 5-6 culture related questions that you will ask in interviews. Build teams who can share a similar goal, for example a team where the PO is fine to release a half baked product as soon as possible and a team which wants to deliver to great product but with time will find it hard to work with each other. Agile may help you identify such symptoms but it may be too late to fix them by then.
I hope you enjoyed reading this blog, feel free to comment on the non-tangibles of Agile which you feel are important but often ignored.