Blog – Page 4 – Founder Success

Scrum / Agile / Waterfall - what are these terms and how can they help my business? In this article, we'll go into detail on what each one is, why they came about, and how they can help grow your business. The success (or otherwise) of your business will not depend on you using Scrum, Kanban, Agile, Waterfall or any other Project Management methodologies. What will have a major impact on your business is when you focus on the strength & purpose of good Project Management quality control. What is SCRUM? The software development term SCRUM was first used in a 1986 paper titled "The New New Product Development Game" in the Harvard Business Review For the first time, the authors described a new approach, based on case studies from manufacturing firms, to commercial product development. Using a holistic approach (the Rugby Union metaphor – Scrum) The focus was on increasing speed and flexibility as the whole process is performed by one cross-functional team across several overlapping phases. What are major roles in SCRUM? A SCRUM team can generally be split into 3 categories: Product OwnerDevelopersScrum Master Your Product Owner(s) is generally responsible for the requirements. When the team is asked "What do you want?" it is generally the Product Owners who has the final say on what is in and out. Your Developers are the team members that "do the work". And the Scrum Master has similar responsibilities to those of a Project Manager. Think of a Conductor in an Orchestra. The Conductor's role is to ensure the team know what to play and when. The Scrum Master has two major responsibilities: Project Schedule (on time & on budget) and resolving issues (sometimes refered to as Blockers) Blockers are those problems that arise that stops or slows down the team. A great Scrum Master will build trust and open communication so the team feels comfortable raising potential blockers as soon as they appear. What is the workflow of a Scrum Team? How does work get done? The major workflows of a Scrum Team are: Sprint planningSprintDaily standupsRetrospectivesBacklog refinmentCancel a sprint Sprint Planning A Sprint Planning session should be a short, 1 - 2 hour session where the whole team is involved. Its primary purpose is to clarify: What are we deliverying? (Specifically) what do we all agree will be delivered at the end of the sprint? (features, bug fixes, enhancements etc) How do we know we are finished? This can initially be a little confusing for some, so its important to be clear - what is the criteria that defines "done"? This can be in the form of a Quality Assurance (QA) process, a demonstration of the features or a specific checklist. Its less important "how" this should work, its far more important that there is consensus amoungst the team A good Scrum Master will monitor these two elements like a hawk! Sprint This is where the rubber meets the road and the work gets done. Developers take the tasks from the Product Backlog and gets to work. In my experience, a Sprint should last roughly 2 weeks. Longer and you're losing the benefit of SCRUM, deminish the value of the other components (Planning, Retrospectives, Backlog etc) Daily Standups For me, the Daily Standups are by far the most important element of SCRUM. A Daily Standup is literally that - a daily meeting where all team members attend and are standing (not leaning, or sitting). Its purpose is: to be short (that's why all members remain standing) and to the point. No wafflingAddresses 3 main questions:What did you do (yesterday)Specifically!! What will you do today?Are there any blockers? Again, the power of Scrum is its subtlety. A great Scrum Master will hold the team accountable and get specific - what did you literally do yesterday? This is important for the visibility - are you working on tasks that contribute to the success of this sprint? What will you do today? Again, this brings the team focus on what needs to be done Are there any blockers? Hopefully not, but if they are, they are quickly addressed or taken offline (to be resolved outside of the daily standup) Retrospectives Retrospectives are a great way to get feedback - what worked well, where can we improve, what will we do differently next time. Generally you want all of the team in attendance, sometimes the Scrum Master may invite external stakeholders to provide feedback / insight. Retrospectives can be confronting and uncomfortable for some. An experienced Scrum Master will be aware of this. The lesson could be important, but if it is not delivered in a way for the team to hear / understand / appreciate, then they won't understand and they won't learn from the experience. Backlog Refinement Your backlog is a list of tasks. What do you want? How should it work? What about security? Performance? The Scrum Master will ensure there is a healthy backlog, but what it contains is usually up to the Product Owner(s). Initially User Cases were the common format for backlog items. Nowadays its far more common to see User Stories What's the difference between a Use Case and a User Story? From Wikipedia: A Use Case is a list of actions or steps defining the interactions between a role and a system (eg the user enters a username & password to login) A User Story is a generally a far more relaxed, casual description of what should happen and when. eg Jane goes to the login page, enters her details and shes logged in. As you can see from the definitions, Use Cases are far more technical. If I were designing a traffic light system to manage traffic, Use Cases might be more effective. If I were to define a Timesheet system to be used by 200 employees, User Stories might feel more approproate. User Stories vs Use Cases is like Captain America vs Iron Man. Both serve their purpose and both have strenghts & weakness. Use whatever you feel more comfortable with Regardless if you use User Stories of Use Cases, these should be low level enough that the estimate is around 2 days (or less). If the task is great than 2 days, you should try and break it down into smaller components. You may ask yourself - why didn't we start with the Backlog? The backlog is an ongoing process. Any team member should feel comfortable adding / editing / removing items from the backlog. Its the Backlog Refinment that sets the priorities, ensures the items are defined clearly and are accurate enough for the developers to proceed. Cancel a sprint Ive never worked with a team where we had to cancel a sprint, but it was always good to know that this was an option. Cancelling a sprint is a last resort. Its the team coming to a conclusion that if we continue as is, the consequences will be significantly negative (ie failure!) and a quick reset will get us back on track. If a sprint is cancelled, you would want to allocate extra time to go deeper in your Retrospective. How did we get here? What can we learn? How can we improve next sprint? “If You Fail to Plan, You Are Planning to Fail”Benjamin Franklin. When shouldn't you use Scrum? Like in Rugby Union, scrums are powerful when everyone is onboard and working 100%. If the business is impatient, if the business doesn't understand, or if a team member is reluctant these can sabotarge Scrum. “Strong executive commitment is a success factor for implementing Scrum, and management can best demonstrate their support of the transformation through their actions.”Scott M. Graffius, Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions What is my role in Scrum? Generally, if you're paying the bill, you are the Project Sponsor / Product Owner. The best thing you can do for your team is to have honest and open communication with the Scrum Master. If you don't understand what is being said? Ask. If you feel someone is being detailed enough (eg daily standups) ask for clarification / further detail. You go this!