…with Christmas a distant memory, and the panto season almost over, the look behind you audience participation mentality is never more prevalent than in LinkedIn posts and forums with many advocates claiming the holy grail is achievable and many disillusionists arguing it can’t, and can never work.
Having seen first-hand both sides of the argument, I can confidently say it does work, but as with the methodology, its simple to understand (Scrum alliance publishes 16 pages on it), yet hard to implement well (it’s the mindset shift that proves to be the biggest hurdle).
Here, I share some experiences of what works well, and pitfalls that can hinder the success of the implementation. Ultimately, it comes down to the will of the whole organisation to embrace the change, with the chain being only as strong as its weakest link, taking down the whole house of cards, leaving organisations feeling beaten and reverting to the previous ways that “worked” if implemented badly.
So many times, have we heard “tried it, didn’t work.” And I’m sure it wasn’t for the want of trying, or even giving it 100% by some. Many factors come into play to make an agile delivery a success. Facets once started become second nature and thus not a chore, such as the various ceremonies. Once the rhythm starts to beat, the team gels, the requirements are easy to understand and the product owner is on hand, a succinct timely delivery of a useable product is always the result. But unfortunately, this isn’t the case in many organisations, some fall short, potential reasons are listed below:
Stakeholders
By whole organisations we mean stakeholders need to be available for consultation and advice. Ideally an appointed person who is the product owner, the conduit to the business and knows the businesses wants, wishes, functions and regulations and is empowered to make decisions that impact the wider audience without consulting the wider audience. The product owner needs have control of the “why” and not the “how”.
Pitfalls
Too often stakeholders are not available, a product owner not appointed or given enough responsibility.
How to overcome
Ensure there is a dedicated product owner, on hand within the team, setting the requirements with the analysts, being on hand to answer questions during the sprint, at the stand-ups (to ensure they know the current status), available for user acceptance testing, as well as at the planning sessions to ensure they decide what is being worked on, and finally at show-and-tells to see the finished work of the sprint.
Trust
Trust is also another factor. Teams need to be empowered to be trusted to deliver more often and with the autonomy of the “how”. As long as a sprint has delivered a useable feature at the end of that sprint, the team should decide the how best to implement it.
Pitfalls
All too often teams are overly micromanaged. Teams aren’t trusted and thought of as running away with the development, with stake holders not knowing what’s being developed.
How to overcome.
Teams are comprised of highly talented individuals. Give them the tools, freedom and access to information (stakeholders), which provides the right environment to foster greater productivity and let them get on with it. They will learn from each other through things like pair programming and peer reviews, and will provide honest feedback at retrospectives to get better (as a team) with each sprint.
Location – off shoring
It absolutely makes sense from a financial point of view to get the best labour rate possible, as that’s where the largest portion of the project budget will be spent on. Therefore, getting more for less is always the highest agenda for those with financial responsibility. On the flip side are those with the responsibility of a successful project outcome. For both to meet in the middle, cheaper labour is sought and more often this comes in form of off-shoring some activities to cheaper labour markets. Popular counties include Eastern Europe, South America, India and China. On paper the cost saving can be one fifth of the on-shore contractor rate…
Pitfalls
…But in reality, the productivity gains are also less than a comparable on-shore resource. Not always due to technical ability, but time differences and culture. There are times of the day when both teams aren’t online together. This means answering questions takes longer, reviews can also be pushed out, etc. Then there are the cultural differences, where some teams will follow the requirements to the letter, even if it means knowingly doing the wrong thing rather than be lambasted by their superiors. An area where off-shoring is carried out the most is test. Development occurs locally, and then the test function is sent off shore, severing a team in half, and two of the four agile pillars of the agile manifesto (individuals and interactions, and customer collaboration) are deteriorated.
How to overcome
Teams should be located as close as possible. If off-shoring must be done, then rather than split functions (development or test) split the whole team so parts of development and test are together, able to answer questions and work together efficiently.
Choose locations with closer timelines, so the teams are only out of sync for a shorter period, and then start one team an hour later and one team an hour earlier.
Make the most of collaborative software, so teams are always communicating, via video, messaging, wikis, and source control tools.
Project Managers
Traditional project managers manage projects using something like MS Project to map out individuals as resources, communicating back to stake holders on project progress. They have a totalitarian delivery mentality, where their success lies with the success of the delivered project, therefore they are the servant to their manager as opposed to being the servant of the team (the scrum master role).
Pitfalls
Many project managers have been classically trained in the art of project delivery. With Agile we turn this on its head and deliver a useable piece of functionality every sprint, with a self-organizing empowered team. This is an alien concept to overcome if all you’ve ever been concerned about is the project delivery.
How to overcome
The current solution appears to be to send the project manager on a scrum course. Two days later the project manager is now a certified scrum master. This is more of a hindrance than a working solution. The delivery mindset remains, and only with experience can this be overcome. Appointing an experienced scrum master is a better solution.
Project managers can then be used on the business side, to facilitate communication and for show and tells, but there seems little point with a self-organising team to utilise such a skillset.
Shoe-horning an existing project
Our chosen method of agile adoption in a new organisation is to first roll it out with one team, then the department, and finally then the wider organisation. Each time the visible benefits become more and more apparent, almost infectious. Utopia is best done with a new project starting with a sprint zero, utilising the best devops practices (CI, virtual environments, automated releases), good development practices (Pair Programming, tdd, peer reviews), good testing (automation and exploratory), good story writing (smallest size possible, acceptance criteria that can be adhered to) and product owners that are on hand.
Unfortunately, we don’t live in Utopia, and many pieces of work are on-going, already in progress. So sometimes an agile implementation must take place during a project. While all is not lost, it just means different issues will arise and need to be handled in different manner.
A strong foundation is a good starting point. Getting this part right will be vital to the success. Assuming facets like code repositories and build tools are already in place, the next step is ensuring devops teams are enabling environment provisioning, one click deployments. While this is going on, analysts should work with the product owners to map out the current requirements documentation into smaller stories and features on a feature board. The development and test team should have a cut-off point, where they can semi-park all the current work and use this as a basis to build on. After this point, the planning sessions can be started for converting all future work into sprints, with a sprint planning session for the work to be carried out in the next sprint.
Another option is a kanban style approach, this can also work, as it all depends on the work that is left to be carried out. The best approach for the team to work well together to accomplish the task at hand is always what is most sought.
Teams – “one for all and all for one”
The team commits to a set amount of work for the sprint, and it’s the team that ensures the successful delivery of that work. The definition of “done” for a sprint is all committed work is complete. A common problem that exists is that development is carried out up until the hilt. Halfway through the sprint stories get backed up, as stories could have defects and there is a bit of back and forth between development and test.
The situation could be exasperated further when developers take on more development tasks, rather than looking to take on test tasks. While they may not be the best testers, they are certainly the best developers in the team. They can help with the automation of tests. Writing code up for stories up until the end of the end sprint helps no one.
To overcome this, teams need to understand this is a concerted effort. Developers should not be picking up new stories if there is a backlog elsewhere, that they can help with. This can be a huge mental barrier to overcome for a developer that Elizabeth Hendrickson pointed out so well: “There is an (unfortunate) belief that testers test, programmers code, and the separation of the two disciplines is important.” A good team is one that helps each other, a great team is one that unites and knows that a successful sprint is a team effort.
These are just some examples of areas that can hinder a successful agile adoption. I’ll be writing more about the agile journey in coming months. But I’d like to leave you with this piece of advice:
A strong scrum master who is empowered to lead the team will overcome many pitfalls. It won’t be easy, and there will push backs, but the power of “No” for the greater good can work wonders.
Let me know your thoughts on
Gav.patel@harringtonstarr.com
