There are many benefits to using Agile especially as technology continues to evolve. This modern methodology has allowed us to find more efficient ways to deliver working software by eliminating heavy documentation and encouraging frequent change.
Agile has created a space for product managers to adopt a modern approach when it comes to project management. This has helped teams to decrease dependencies, create an efficient work environment, limit distractions and misunderstandings.
Frameworks
Agile
Agile came to fruition because the traditional waterfall approach was too much upfront work that was locked in with a lack of encouragement to change requirements throughout the process.
The agile approach
- is used for complex and uncertain projects
- no heavy detail planning upfront rather an agile project evolves as short increments are completed
Agile is an iterative and incremental evolutionary approach to project development which is performed in a highly collaborative manner by self-organizing teams with just enough ceremony that produces high-quality software in a cost effective and a timely manner which meets the changing needs of its stakeholders- Scott Ambler
Agile Manifesto
The agile manifesto is a foundational document that was signed by 17 leading software developers in February 2001 to help encourage light weight quality-driven approaches to software development. This became known as the Agile manifesto.
Four main points in the manifesto:
- Individuals and interactions over proceeses and tools: While processes and tools are necessary the emphasis is on individuals and interactions between them
- Working software over comprehensive documentation: Documentation doesn't demonstrate progress or value therefore the emphasis is on working software (Working software is the primary measure of progress in an Agile team)
- Customer colloboration over contract negotation: Rather than creating a detail statement of work and negotating contract. Developers and customers should colloborate in order to progressively determine the requirements of the project.
- Responding to change over following a plan: Rather than being constrained by an original plan developers should embrace change in order to meet the dynamic needs of the customer.
Where a Product Manager fits in
When it comes to Agile a product manager doesn't lay out every detail of how a product should work. Rather they have conversations around what needs to be done with light requirements. This is translated into low-fi mock-ups to test with real users before engineers spend a lot of time developing something users don't find value in.
Scrum
Scrum is an approach that was introduced in 1986 by Hirotaka Takeuchi and Ikujro Nonaka. It became formally introduced in the early 90's as Scrum. Scrum became a new approach to increase speed and flexibility by providing value through working software at the end of each sprint. The goal is for value to be delivered from the very beginning of a project incrementally with each sprint.
Scrum is one of the most popular agile frameworks that has laid the foundation for specific ceremonies such as: daily stand-ups, grooming, sprint planning, retrospectives and demos.
In Scrum, teams work in 1-4 week sprint cycles. The most common approach are 2 week sprints. At the beginning of each sprint the team will have sprint planning where the scrum master pulls work from the backlog that needs to be brought into the sprint. By the time you are in sprint planning work that is pulled from the backlog and brought into the sprint should be estimated. However, this does not mean that requirements and story point estimations are finalized.
💁♀️ Tip: Always go through the backlog before sprint planning. Once in sprint planning go over tickets with your team to finalize estimations (story points) and requirements before pulling tickets into the sprint.
Throughout the sprint the scrum master, engineers, and design team meet for a daily stand-up for 15 minutes to share progress. Usually in the format of:
- What you did yesterday
- What you plan to do today
- Any impediments
At the end of each sprint the team will have a retrospective to discuss what went well, areas of improvement, what should be done differently, what puzzles them, and talk about team health. It should be attended by the complete scrum team which includes engineers, designers, and the scrum master. Product managers and product owners are considered optional. The retrospective is a place where teams can voice their concerns in private without backlash from upper management. I always say 'retrospectives are Vegas because what is discussed here will stay here."
One of the last ceremonies to take place before sprint end is the sprint review. This is when leadership, product management, and scrum masters meet to discuss what was accomplished during the sprint. Then, there are demos. This is time-boxed at one hour for each week of the sprint. If the sprint was 2 weeks it would be 2 hours. This doesn't mean it should run 2 hours. Gradually as teams become more efficient and confident when showcasing their work a two hour demo will become an hour.
During demos the entire organization should attend if they are interested in the project and teams success. The purpose of demos is to demonstrate working software and access feedback. Feedback may range from full-acceptance of the completed software to complete rejection by the product owner/product manager.
Kanban
The second most sought out framework in Agile is Kanban. Kanban is very popular in a DevOps environment as DevOps combines the dev and ops teams into a synergistic process that ensures quicker deployment of the value created by the development team. By not being locked into a sprint it makes it easier to meet customers needs and expectations by continually deploying through CI/CD.
The framework of Kanban is specifically used to implement Agile in a Devops environment because of the pivotal nature of Kanban. Teams are not locked into a sprint and are able to pull in work as needed and limit work in progress items to prevent work overload.
Devops is the process of moving code from development to testing, to production or from one environment to another in an automated and efficient way.
Agile teams using Kanban cannot be successful without strong support from devops. Ops will need to work closely with the development teams to make sure the processes run smoothly.
Scrumban
Scrumban has become more popular over the years because it combines two of the most popular frameworks that value delivery of working software. Scrumban encourages an environment of structure, stability, and predictability of Scrum while using Kanban's flexibility and continuous workflow (CI/CD).
The difference between Scrum and Kanban is that Scrum values an iterative approach to delivering working software and Kanban values continuous delivery of working software.- Product Girl
Many organizations implement Scrumban by keeping the same ceremonies or combining them and opening up the sprint so it isn't locked-in. In many circumstances, they will still have a 2 week check-in to discuss WIP (work in progress) items, what is completed, pipeline work and changes that have been made.
Measuring work
Story Point estimations
Agile estimation is a team sport. Everyone on the team brings a different perspective on the product and the work required to deliver on the goal. With this being said, estimation is hard. For software developers, it’s among the most difficult—if not the most difficult—aspects of the job. When estimating you must take into account a slew of factors like rework, specialist resource hours, reliance on other teams, etc.
Story points rate the relative effort of work which means you are accounting for non-project related work that pop-ups over the fence and creeps into your days. This includes: e-mails, meetings, interviews etc. Also, every team estimates work differently, which means their velocity (measured in points) will naturally be different. Story points reward team members for solving problems based on difficulty, not time spent. This helps engineers to keep focus on delivering value, not spending time.
A popular way to estimate stories is through planning poker. During planning poker each engineer independently estimates what the effort of work will be for a story and then everyone reveals their guesses at the same time. This is very beneficial because it creates a team work environment where collaboration is encouraged.
Above all, it helps to improve planning by breaking down the level of effort a feature/story would take. If an engineer thinks it will be a 13 and another engineer feels it's a 5 they will be able to discuss any discrepancies and be able to mitigate them.
Final Words 📖
It's important to adjust and be 'agile' as much as possible and be able to adapt to the various frameworks. Many, if not most teams, do not implement Scrum or Kanban the way it's laid out and the ones that do ultimately fail because the process is too rigid. Remember it's called 'Agile' so that you can move quickly and efficiently.
Also, remember at many companies the Product Manager will operate as the Product Owner and the Scrum Master (this was me). If the roles are split the PM will be more focused on strategy and the Product Owner more focused on the day-to-day aligning closely with the Scrum and engineering teams.
Bear in mind, there is a difference between a product owner and a scrum master. A product owner is a part of the scrum team and is responsible for managing the backlog, the stakeholders and validating/accepting when work is complete. A Scrum Master will encourage the practices of Scrum, run ceremonies, and remove any impediments the engineers may have to make sure they can run efficiently.
Next Steps 🚀
- What is Agile
- What is Scrum
- The Kanban Method- The Ultimate Beginners Guide!
- Basics of Scrumban
- What are story points?