As a Scrum Master people tend to think that I worship Scrum and all things Agile.
There’s reasons when and when not to use agile methodologies which I won’t go into right now but here are some things included in such that do and don’t really work (for me):
The Good
There are some really key concepts in Agile that I couldn’t live without:
Retrospectives
These are extremely valuable especially when you’re team are open and honest with one another. I believe that regularly mixing retrospectives up by using the plethora of games available keeps the team engaged and makes it a ceremony that they really look forward to!
Showcases or Product Demos
Again, another great ceremony that celebrates the team’s success helping to give them a feel good attitude. Reminding stakeholders the purpose of the showcase at every session helps bring about constructive feedback that the team can take forward into the next iteration.
Ability to change
This is self-explanatory but it’s a very important concept of agile. Not having tight deadlines and being able to adapt and change is a great way of working. If customer requirements change, the impact of incorporating these is less than a stricter way of working.
Communication resulting in less siloed developers
Agile needs communication between individuals in a team in order to be successful. This means that developers can discuss and share ideas and learn from one another. This creates a great working environment and because everyone has a similar skillset, there’s less siloing.
Kanban & Scrum boards
These (when kept up to date) give everyone within the team a good idea of status. It’s also a good way to work out capacity day-by-day and review the goal of the iteration. If someone then is absent for whatever reason, we can easily identify what they were working on and someone else is able to pick that item up if need be.
The Bad
Daily Standups
Whilst catching up with your team members and finding out what each one is doing, the chore of the daily standup is complete overkill. If you’re all in the same team, especially if you’re co-located, if you’re doing agile right then you should just know what everyone else is working on. Granted, I’m not saying “never have standups”, just make them as regular as needed. Doing them daily loses their importance and tends to be “I did stuff yesterday and I’m going to do more stuff today” - how valuable is that?!
Estimations using story points
I know some people will disagree with me here, but I’ve just not been able to get a true reflection of estimates using story points. My team are particularly bad at this, relating story points directly to hours (a pet peeve - argh!). Show me a team who get estimations right from the get-go - it’s a learning curve but t-shirt sizes where you’re not using figures per-se work so much better in my experience. Even better is to use forecasting and projections based on the data from previous iterations.
User stories
Perhaps it’s the nature of the teams that I have worked with, but writing user stories and breaking them down into tasks that developers can comprehend is a difficult process. One has to question how much value is there in doing this? If a customer asks for their data to be stored then the developers need to decide on a solution before we can break it down into what development steps are required. There’s no right or wrong answers here - sure using a relational database may be better than using a spreadsheet but until the developers decide on what the solution is going to be it will be impossible to break down and estimate such tasks! Also, depending on what needs storing, using a spreadsheet might be fine - be careful not to jump to conclusions of what the correct solution might be too quickly.
Releasable products after every sprint
Whilst this is a good aim to have, it’s not always possible to have a product in a releasable state at the end of every sprint. For example, the team I currently work in uses 8 working day sprints - sometimes the scope of the product exceeds that completely. When you factor in the time required to build the foundations of architecture, along with ensuring good test coverage and extensible code, plus setting up servers etc., you don’t have much time left to develop many features in that first sprint. Aim to have a releasable product for sure, but don’t beat yourself up if it doesn’t happen every time.
Sprint zero
Another pet peeve! I absolutely hate discovery sprints. Maybe this is just because I haven’t done enough of them to feel competent, but from my few experiences of sprint zero they just don’t work. Sprint zeros to me feel like something you can’t really plan. They’re like saying to a developer “do stuff” but not really knowing what that “stuff” is. If you don’t have requirements at the beginning of the sprint and the team are expected to find out what the requirements are then what’s the point of the Product Owner role?
Lack of role
Because agile teams tend to be self-organised and everyone has a similar skill set I don’t feel that a software or solutions architect can really lend their valuable skills in this environment. Having worked alongside architects in previous roles, I feel that they’re key in knowing what platforms are available to help us with software based decisions from the get go. In my agile team, if we pick a technology we have a difficult job convincing our server guys why we need them to update their servers/versions of programming languages/install extra tools etc.
“Agile is great” mentality
A lot of agile developers I know firmly believe in the “death to the waterfall” mantra. And often without reason. Different methodologies work for different situations (including projects, team structures etc.). I’ve worked in plenty of waterfall teams that went smoothly and everyone knew what was happening when. I’ve worked in waterfall teams where the methodology wasn’t right for what we were trying to achieve. The same applies to the various agile methodologies I’ve experienced.
There’s no silver bullet, and what works once might not work a second time.
Stakeholder engagement
When the organisation is overall waterfall, it’s incredibly difficult to do true agile. The product owner or stakeholder that you need to be in the room may not have the time to dedicate to sit with the team for an entire iteration of the product. They usually don’t understand the way we work, either, and don’t come back to give the regular feedback we want. This often leads to the team having to second-guess what the end users will want, which means that sometimes products are created that don’t meet the user’s needs.
Kanban/Scrum boards
These are a chore for developers to update (especially when using both physical and virtual boards). If I had a £1 for the amount of times when I have questioned developers what they’re working on and it doesn’t match what’s on the board I would be one very rich lady.
The Ugly
All in all, I’d recommend that you take the best bits from agile but don’t get bogged down in ceremonies or sticking strictly to scrum/another methodology. If a particular methodology isn’t working for you, switch to another one or adapt it to suit your needs. Methodologies aren’t there to be strictly adhered to, they’re to assist with good practices which in turn aid productivity.
Waterfall has its perks as well and shouldn’t be seen as the devil of software development. Regardless of which approach you choose, remember there are many ways to get from A to B - sometimes getting the train can be more straightforward than driving there, the same is true to software development approaches.