Agile is the buzz word these days. Everyone is talking about it. Interestingly many organizations / teams think they are agile. As Pekka Abrahamsson says, Agile is a non defined term, so it seems to be everything or nothing. There is no line to say if you cross that you are opposite of agile. Agile or Agility is a positive term everybody wants to be associated with . Being Agile is a journey, not a goal.
This series of blogs will try to touch up on few aspects of agile transformation. Recently, I was talking to a team which said they can’t be Agile (or follow SCRUM) because they are working on legacy code and they can’t have good unit test coverage or builds on every check in etc. The team was under an impression that if they following a couple of XP practices they would be agile . This kind of misconception is equally true at management levels who perceive Agile / SCRUM to be a silver bullet to solve all of their problems.
Why to Transform
Organizations need to have a clear vision why they want to “Get Real Agile!”. In my opinion, there are 2 key goals why an organization / team should go for an agile transformation.
- Identify and effectively address challenges with their current base ground.
- Increase efficiency/ effectiveness by changing organizational / team working structures to increase predictably, adaptability and happy peopleJ.
Common challenges I hear with traditional processes
- Project timelines are missed.
- Product quality concerns.
- Project runs over budget.
- Unsatisfied customers.
Agile Check: Where do you stand now?
Agile transformation should be done iteratively. For this, we need a backlog of activities to deploy Agility / SCRUM into organizations. This backlog is created (of course bound to change during deployment) during “Agile Check” with a cross section of the organization. Typically I conduct “Agile Check” with a group of 10 to 15 people which consists of managers, developers, QAs, team leads, architects etc.
Start Agile check with a stand upJ. Instead of a typical stand up, it’s about Name/Role, expectations from Agile check and anything they foresee going wrong during Agile check. This gives a fair idea of mine as well as audience’s expectations.
Run a retrospective of their current process / structure. I like to give 6 post it notes to each individual, and ask them to write 3 positive points and challenges they currently face, one point on each sticky note.
Make groups of 3 to 4 people, don’t propose groups, instead, let me them arrive at it. Once they form groups, ask them to discuss among themselves and pick 3 positives and challenges at a group leave.
Each team presents their list then and a consolidated list of formed. Help them to arrive with top 5 positives and challenges from the consolidated list. I usually do it by voting. Each member gets 5 votes for positive and 5 for challenges. Each member can put his/her votes against the list based on what he/she feels important.
Now, we have a list of things that are working well and things to improve. Sometimes it requires some discussion around the same, but usually this is the time I give an introduction to SCRUM. Depending on the audience’s Agile exposure, this session’s focus ranges from explaining “Why Agile/Scrum” to core principles, and mapping them to retrospective list.
SCRUM Deployment backlog creation:
By now, groups would have understood what challenges they have, and how Agile/ SCRUM would help in addressing them. Ask teams to think about various activities which they feel are required to deploy SCRUM in their environment. Once every group has a list, help them to come up with a prioritized list. Usually I ask everyone what should be the first step. For e.g. someone would say, training is the first thing, someone might say, identify pilot project or management commitment. After this exercise, we end up having a prioritized backlog for SCRUM deployment.
That’s it, objective of Agile check is accomplished! A prioritized backlog for SCRUM deployment is ready.
Of course, once this is done, there is a management meeting when we identify and Agility Stakeholder, who owns this backlog and agree upon timelines, pilot project etc.
So this blog is about How and Why Agile Check. Stay tuned for more!