Scrum (quick & simple)
These days, agile methodologies are a much more accepted best practice, when compared with waterfall. Scrum is the most common form of the agile project development methodology. Kanban is also common and is typically used for an operations team, help desk, or other team where the work comes in smaller less predictable pieces. A "scrum" is a rugby term where the team of players all link arms and move together as group, so it's all about being a team. Agile development emphasizes flexibility. As with any methodology, there are notable advantages and specific things to watch out for.
The main advantages of Scrum
- Many small iterative releases
- The team learns from each release: This is a bonus because with each release, the team and customers learn more about what they want from the next release. The traditional waterfall methodology requires that the planners know what they want before they have a functional tool to test with. With scrum there is far less guesswork and more planning which is based on more reliable data.
- This helps plan an especially realistic schedule: Unlike the waterfall methodology, were predicting how long a task will take is often based on what people hope for, the team learns there is empirical actual development pace quickly. It makes it easier to predict when a finished polished and tested product will actually be completed.
- Consistent and steady work vs sleep deprived work: This usually makes for more steady and consistent work in the short term and fewer problematic "all nighters" when notable deadlines get close.
- Less guesswork: With the traditional waterfall methodology people are doing far more guesswork on what they should build. With Scrum they are basing their decisions more often on functional code.
Accountability, responsibility, and visibility: A notable advantage of agile methodologies is that both for the team and the individuals, it's kind of clear how much people are getting done. Everybody can see what everybody else is doing. This makes it feel like a team doing the work, rather than people being in individual silos.
- Imperatively-based time estimates: The burndown chart is one of the main advantages of SCRUM. It helps to make it visually aparent over time whether or not progress is being made. "Estimates" are inherently simply estimates. A system that takes that into consideration and works to more closely reflect reality is good.
The main challenges with Scrum
- Requires cultural acceptance of methodology: Of course this this is the case for any methodology.
- Too much development based on too little planning This is the main potential risk of scrum in my view. Waterfall methodology is all about planning ahead of time. Typically way too much planning without gathering enough data to validate assumptions. But on the other hand, the scrum methodology does not enforce planning things out enough ahead of time.
- Keeping to a timeline and roadmap Scrum is both good and bad with regards to getting work done with a planned timeline and roadmap. There's an assumption with scrum that the only thing that solid is the current Sprint. Thus planning farther ahead can be problematic. But in a business, there are real-life deadlines for software that need to be agreed upon and met. My solution to these potential risks is to do extra planning ahead, even if it can't necessarily always be validated. And to have the people who are doing the implementation put in extra energy early on to help build the roadmap and the find detailed steps needed for each ticket, along with time estimates for each ticket. In other words, for vital projects with lots of moving parts, there should be a live Gantt chart that automatically updates when a ticket is closed.
- Keeping the daily scrum on time The daily scrum takes effort, but it's also worth it.
- Sticking to the Scrum methodology despite distractions or obstacles Production issues, competing projects, sick team members, and other such challenges can get in the way of properly doing scrum. But when scrum can be stuck to, the progress can be consistent and a thing of beauty.
- Does not work well for a team which is too big or too small In some ways this is not really a problem, since teams that are too large should probably be broken up anyhow into smaller organically structured groups.
The User Roles
- Product Owner: They make sure that the user stories (enhancement requests or issues to be fixed) are being prioritized correctly. They represent the users and customers of the product.
- Scrum Master: This is the project manager. They help get rid of obstacles from everybody working on the project, help make sure that the project is on schedule, sets up meetings, helps plans the releases, helps keep the daily scrum from taking more than 15 min.
- Developer: The folks who are doing the programming and development. Different types of developers will likely be needed for any given project.
- Tester: The people who test to make sure things were implemented properly.
- Customer: Folks who will actually end up using the product in the end or who best know what the end users will need.
- The Backers: The people that hold the purse strings and management responsibility.
The main Concepts
- User stories: With other methodologies these are typically called RFEs (Request For Enhancements), feature requests, or bug reports. With the Scrum, the are phrased as "As a [role], I want [feature], so that [benefit]". This helps the project to keep in mind the crucial aspect that the end-user experience is critical.
- Product backlog: This is the collection of all of the user stories. In other words these are the features we want added or issues we want fixed.
- Burndown chart: For a given sprint, it shows the remaining days of work better left. Each day, everybody on a given sprint estimates their tasks. These are added up to the amount of time left. When these estimates are viewed in a chart seen over time, they are a Burndown chart, and they give a very good empirical estimate of how much time is left before the sprint is completed. If needed, the scope can be reduced in order to complete this print in the desired time frame.
Release/Project Planning
Tying together the many sprints that are needed for the entire project to be created.
- Identify User Stories for the release: Identify the most critical user stories in the product
backlog for a given release - Prioritize + Estimate time for the User Stories: Prioritize and estimate work for the user stories in the backlog for the given release. If a user story takes too many days of development, break it down into smaller elements with more manageable chunks (so we can see hours of development per item rather than days of development per item).
- Effort estimates: Estimates should be done by hours, days, and months, where estimates are rounded up the the next higher bucket. Often Fibonacci series are used up till about 20d or so. Buckets may be, for example, 1h, 2h, 4h, 8h, 1d, 2d, 3d, 5d, 10d, 1m, 2m, 3m. But any item that's more than a few days should be broken out into smaller tickets that get esimated, and the estimates of the higher item should be the lower items accumulated (ideally using a Gantt chart).
- Take the time to add the details: Put in the time and effort to build out all of the needed tickets. The people doing the work need to be the people doing the time estimating. This way there is actual accountability and buy in.
- Plan out sprints in the Release: Sprints should be kept as short as possible while being realistic. The goal is to do several sprints (each with their corresponding sprint backlog) can be done in parallel for a given release.
Day-to-day Sprint Progress
- The Daily Scrum: Each day have a fast 10 or 15 minute meeting where each person very quickly discusses the following...
- What did you do yesterday?
- What will you do today?
- What's are potential problems in your way? What are the blockers and how can the blocker be cleared? Likely the scrum master takes this on as a top task. In some cases breakout meetings are planned to solve the issue.
- Update the user story time estimates: This way a new burndown chart can be computed on a daily basis.
At the end of each Sprint
- A Sprint retrospective meeting: Everybody talks about what worked and what could be improved.
- Demo: Consider demoing what's been built.
Contact Julian
Get in touch and chat about your company or project.
Julian Cash 415.738.9385 julian@HireThisGeek.com or see the contact page.