I wrote an article last week on Waterfall vs. Agile, and while I didn’t get into too much detail then, I did commit to writing again and expounding on some of the thoughts I have on the topic.
Before I start, I have to mention that I’ve read a lot about Agile (and have experienced many close-approximations) over my career, however, it’s not until I started working at my current employer that I finally experienced what I consider the agile promise-land.
So, credit to the solution leaders and Scrum masters that have honed my perspective on the topic!
What is Agile and why does it matter?
The term Agile is actually an umbrella term as it doesn’t refer to a single methodology. Agile principles were first popularized in the field of software development following the creation of a “Manifesto of Agile Software Development” by Kent Beck and a few others in 2001.
Some of the common Agile methodologies that you might have heard of are Extreme Programming (for software development), Scrum and Kanban (for software-project-management practices).
While Extreme Programming is dreamy, you’ll be hard pressed to find faithful implementations of it at most companies. However, over time, a lot of its teachings (and their benefits) have been accepted into the programming world’s set of best-practices (e.g. Test-Driven-Development, Pair-Programming…etc).
On the other hand, a few different Agile project-management methodologies emerged as well, each with their own unique strengths and areas of focus. The most common of which are Scrum and Kanban.
In this post, I plan to focus on Scrum specifically as it’s the more popular of the two, but, please note that a lot of companies use Kanban and are quite happy with it as well.
So, for the rest of this article, when I say Agile, I’m talking Scrum specifically.
Now, let’s talk about the why of Agile.
I already alluded in my previous post as to some of the frustrations I felt with Waterfall on many a project.
Don’t get me wrong, there’s still a place for Waterfall. If you’re designing software for the next Space X rocket, software agility isn’t necessarily what’s needed, rigor is (if you work at Space X and know differently, please let me know!).
However, in the world of start-ups, Bitcoin, and constant “disruption”, the approach prescribed by Agile seems much more of a fit for most companies.
The market is moving fast, customers expect incremental features, you don’t have to ship your software in CDs, and you don’t wait for a few years before each major release.
Instead, most software projects are built as websites and mobile-apps where change is constant and the user feedback cycle is very short.
What does this rapid pace and constant incorporation of user-feedback result in? Well, I’ll let this quote by author Edward Berard sum it up:
“Walking on water and developing software from a specification are easy if both are frozen.”
From a developer’s perspective, this constant change is maddening!
If you’ve spent months as part of a Waterfall project writing the perfect specification and authoring dozens, if not hundreds, of UML diagrams to describe the behaviour and technical architecture of your system, then the worst thing the business can say to you is “we’d like to go a different direction – our priorities have shifted”.
Scrum is designed to address the needs of the modern-world by introducing a compromise for how to balance constant re-prioritization with a fixed and well-understood scope.
Oh, and in solving for that main problem, Scrum has incorporated a few other elements that on the whole make teams more collaborative, deadlines more palatable, and keeps meetings to a minimum!
Overview of Scrum
By definition, Agile delivery requires cross-functional team members. It’s a close collaboration between business and IT for delivering software.
The composition of an Agile team is therefore an important consideration.
Depending on the size of your project, you’ll need a product owner, a Scrum master, software architect and developers, quality analyst(s), and optionally a UX/UI designer and a business analyst.
The product owner, especially, is a key role. This is a representative of the business stakeholders and their needs who has the ability and authority to make crucial decisions in terms of feature prioritization. He/she should have, or be capable of getting, answers for any business-domain questions that arise during the project. They should be the de facto subject-matter-expert on the particular area that the project is tackling.
Depending on the size of your project and team, the Scrum master may play the additional role of the business analyst as well. The UX-designer is also an optional team member for projects where a user interface is an integral part of the deliverable.
As for the actual delivery, the solution architect, software developers and the QA analysts will work collaboratively to ensure that features are being built and tested to the product owner’s expectations.
So, with the key roles of a cross-functional team described, let’s jump into the various aspects of Scrum.
The primary tool that Scrum employs to solve the ever-changing-scope problem described above is the idea of a sprint.
A sprint is a 2-week period where developers get to work on a particular set of features that isn’t subject to change.
Right before a sprint starts, the development team reviews the highest priority user-stories (which are light-weight feature descriptions and business requirements) and commits to doing a particular set of those stories by the end of the sprint.
Hidden in that seemingly-simple sprint planning session is a lot of the magic of Scrum.
The product owner needs to have prioritized the user-stories ahead of that session while the Scrum master (playing the role of a business analyst) needs to have included enough details in these prioritized user-stories to make them ready for estimation.
The solution architect needs to have also added their thoughts on an implementation approach and potential technical risks.
Finally, the team, together, goes through an exercise of estimating the prioritized user-stories using story points (instead of man-hours) and committing to completing certain stories by the end of the sprint.
Side Note: story points are a measure of complexity of each user story relative to each other. For example, a 5-point story is a bit more than twice as complex as a 2-point story. Story points solve many problems associated with typical software estimation in my opinion, and deserve their own future post 🙂
The beauty of developing in 2-week sprints is that both the business and the development teams get their say.
The product owner is the one who came up with the user-stories and feature list to begin with, and every two weeks they get to decide the priority of all the remaining features in the system. They also get a commitment from the development team as to which stories they will tackle and finish (Murphy’s Law notwithstanding, of course).
On the other hand, the development team gets to have a say in determining how complex these proposed features are, and what they think is a fair amount of user stories to finish in the 2 weeks. They also get a “frozen” scope for a period of 2-weeks, which is a miracle in and of itself.
It never ceases to amaze me how much gets done and how well everyone cooperates when a sprint-goal is set. The development team becomes a unit that strives for keeping their word, as a team. When a developer finishes earlier than anticipated, they try to jump in and help tackle any outstanding stories or help their fellow developers as much as possible; it’s team-pride on the line, after all!
The product owner, Scrum master, business analyst and UX designer (if present) all become goal-obsessed. They become efficiency boosters, striving to melt away any blockers that stand in the way of the development team’s efforts.
Speaking of blockers, another feature of Scrum during a sprint is the stand-up meeting. In its purest form, it’s meant to be a very short daily meeting where everyone who’s actually tackling stories or tasks on the Scrum board (JIRA or similar) gets to report their status and any blockers.
There are a few crucial elements to a successful stand-up meeting:
- Since they occur daily, they must be as short as possible (ideally, 10 minutes or less)
- In order to ensure that these meetings are as short as possible, everyone on the team must actually stand up during the meeting.
- If you find yourself reaching for a seat, then that’s a clear sign that the meeting is not going as quickly as it should, and so something needs to be done about that (Scrum master, fix it!!)
- Only members of the team who are actually delivering points on the board report their status.
- This isn’t a meeting where the executives or interested business stakeholders join to reiterate this or that point. This is about the delivery team reporting concise answers to the following three questions:
- What did you work on in the last 24 hours?
- What do you plan to work on in the next 24 hours?
- Do you have any blockers?
- This isn’t a meeting where the executives or interested business stakeholders join to reiterate this or that point. This is about the delivery team reporting concise answers to the following three questions:
Again, the benefits of well-done stand-up meetings are subtle but numerous.
Getting together frequently and reporting our status in such an efficient manner solves several issues common during delivery. Gone are the days of 2-hour weekly status meetings where we sit captive while listening to a couple of individuals hijack the entire meeting to discuss their technical issues or requirements in never-ending detail. During stand-up, developers only mention the user-stories they are working on specifically. Sometimes, the story-number (e.g. ABC-72) alone is almost sufficient for answering each of the first 2 questions.
Also gone are the days where someone gets stuck for days at a time and no one is the wiser. If you’re doing stand-up meetings right, then people are bringing up blockers the day they encounter them! The ears of the product owner, Scrum master, and solution architect must all perk up when a developer mentions a blocker. That’s typically when someone jumps in to say “I can help with that, let’s talk after the stand-up”! In cases where it’s not clear who can help, the Scrum master will follow up with that developer after the stand-up and work with them to identify what’s needed to get them unblocked.
There’s also a concept we adopt at my company which is the parking-lot meeting. Sometimes there are things we want to discuss that don’t fall into the efficient 3-question format above.
These are usually deferred to the parking lot, which typically takes place after the stand-up round is complete. It’s important for the Scrum master to identify who needs to stay on and for which parking lot items, and offer people to leave the meeting right after stand up if the parking lot items aren’t related to their work.
Don’t underestimate the power of having to report your status daily and publicly, while listening to the progress made by others as well. Developers get better at staying focused on their prediction for the next 24 hours, and take pride in knocking off as much stories as possible to contribute to the overall team velocity! In a sense, this is a great example of gamification – motivating developers while delivering more value to the business in the end.
The combination of a fixed scope, together with daily stand-ups proves to be quite valuable for delivery, yet that’s not all!
One of the pillars of Agile is delivering frequently, and that’s exactly why the sprint-review and associated demo come into play at the end of each sprint.
At the end of the sprint, the delivery team (Scrum master / architect / developers) along with the product owner and other business stakeholders get together to review and view a demo of what was actually completed and built during the 2-week sprint.
Developers had committed to a number of stories at the beginning of the sprint, and now they get to show the stakeholders the progress made and the features implemented. There is a sense of team pride when all the stories are completed, and the demo is a nice touch that allows the team members to showcase their contributions! The demo keeps the development team focused on delivering something demo-able by the end of the sprint, and it also helps arm the product owner with enough information and ideas from the invited stakeholders to prioritize remaining user-stories in the backlog before the next sprint starts.
The end of the sprint is also a time for reflection.
During the sprint, everyone is so focused on delivering user-stories and unblocking or assisting those who are delivering those user-stories that there’s no time to get together and discuss minor (or major) refinements to the team dynamic/tooling/practices.
This is the role of a sprint-retrospective. This is where the delivery team (including the product owner) get together and reflect on what went well during the sprint, what could have gone better, and any other thoughts/comments. The suggestions brought up during the retrospective are captured by the Scrum master, with the goal of keeping what worked, and improving what didn’t ahead of the next sprint.
There are more Scrum elements to describe, however, I feel that the above broad strokes are the heart of the Scrum methodology and pack a lot of value already.
The goal of each day in a sprint is to report progress and identify blockers, while the goal of each sprint is to deliver the stories that the delivery team committed to and have something to demo to the stakeholders. Finally, the goal of Agile delivery itself is to keep developers sane and productive while accommodating the ever-changing-world two weeks at a time!
Win-Win!
Stay curious,
MJ
