In this six-part series, Shirley provides pragmatic advice on adopting Agile Development methodologies.
Agile Development is a software development methodology based on incremental, iterative development – where requirements and implementations evolve through collaboration across self-organized teams. Agile Development promotes product delivery as a series of functional (and potentially shippable) product updates, enabling teams to rapidly adapt to change.
Moving Beyond Best Practices
There are a litany of books, blogs, websites, consultants and training courses aimed at helping companies adopt Agile Development and yet most companies struggle with moving beyond Agile “best practices” to a “common practice” that’s adopted throughout the organization.
To ensure success, Agile should not be seen as a way to “make engineering better” but as a strategy to streamline a business. Agile adoption should have executive visibility and support, and the benefits should be explained to and embraced by the entire company.
Part I – Preparation
Before starting your first Sprint it’s important to “set the stage” for success.
Educate and evangelize.
Take every opportunity to present the benefits of Agile to members of your organization. Let’s look the benefits you should present to different stakeholders.
Executives: Better development predictability, accelerated time to market, greater alignment with business objectives.
Product and Engineering: Increased collaboration, closer alignment with business objectives.
Sales and Marketing: Competitive leadership, faster time to market, confidence in product delivery dates.
The key tenets of Agile Development include iterative development, continuous integration and testing and self-organizing teams; resulting in a ‘potentially shippable product increment’ (hyperlink). This cannot be accomplished by a silod, functional organization.
Rather than impose an Agile structure on your Engineering organization, use this as an opportunity to model self-organization. Set the parameters (including number of teams, need for a balanced skills composition, etc.), stand back and let them organize. It may not come out exactly as you’d expected, but it will create a strong sense of empowerment and begin to signal how things will be different.
Work with product owners to rework outdated MRDs and PRDs into a prioritized sprint backlog of stories.
Follow a disciplined approach, and the standard format: ‘As a …I would like to … so that I can …’
Note : The ‘so that I can’ is what defines the scope of the story and informs QA of the underlying intent. (you will be pleasantly surprised how this will help to flush out unclear or key requirements that may have been overlooked previously)
Scrum boards, Scrummaster, Post-its
Identify or hire a Scrummaster. It’s important that this person is an impartial facilitator. Their role is to help uncover and remove impediments for the team. Don’t appoint the Director or VP of Engineering to fill this role unless you can be sure that no one on the team is concerned about sharing openly with them. If your Scrummaster does not have prior Agile experience, I recommend investing in a Certified Scrummaster (SCM) course.
Create physical scrum boards. Even though most companies will adopt an online tool to manage their agile process, nothing beats the visibility, transparency and visceral pleasure of moving post-its on a physical scrum board. It also creates a place for the team to assemble and hold daily standups or daily scrums.
Start with at least 6 columns on your board (To Do, In Progress, Ready For QA, In QA, Verified and Done). As your process matures, you can re-draw the board to include more granular activities (such as Unit Testing, Code Review, etc.)
Invest in ‘super sticky’ post-its. Whether your scrum board is a white board, a section of wall or foam core board, if you use regular post-its they will likely fall off and disrupt your sprint.
Establish and Communicate Core Principles
Decide what’s important for the success of your Agile Development process and socialize them as core principles. For example,
Fixed 2 week Sprints, starting on a Monday
Aligned Sprint boundaries (all teams start and end their Sprints on the same day)
Sprint commitments are made during Sprint Planning based on the Product backlog
Task breakdown is completed for all committed stories on the first day of the Sprint
Tasks are broken down to 1 day or less
Sprint deliverables are ‘potentially shippable’ product increments
Daily stand-ups use Scrum board to track progress
‘SWARM’ on a single story where possible (remember, the goal is to get more stories completed during the sprint.) “It’s better to have 80% of the stories 100% done, instead of having 100% of the stories 80% done.”
Minimum of 1 developer and 1 QA per open story
Do not exit a sprint with code or QA debt
Everything worked on MUST be on the board
Now It’s Time to Start your First Sprint…
The next in this series will help you introduce the Agile process and begin to establish the foundation that you and your teams will build upon.